AP2000i suggestion for accelerometer input

[EricTheRed]

Ok, I am sure that I am not the first to think of this, but, the new Wii remote has a 3 axis accelerometer built into it. People are now expermenting with this and this video show the effects of the technology hooked up to the input of a computer (wirelessly)
http://www.engadget.com/2006/12/01/wiimote-acceleration-values-plotted-on-a-pc/

I would like to further the disucssion of the AP2000i using the silicon based accelerometer to supply the input required for the AP2000i to find and fix its movement.

Thoughts?
-Eric

[Xcellgasman101]

Now that was pretty cool... Really kind of... open's thing up.. I wonder how hard it would be to right the software to make this thing work? Nice topic.. one to watch for sure,, XGM

[AZ ChopperCam]

Spartan RC is working on an inertial sensor and have been for a while.

[Angelos]

Silicon based accelerometers are available to buy as electronic components and they only cost US$15-20 for 3 axis. However accelerometers alone can not stabilise a helicopter because dynamic accelerations give a false indication of where gravity is. This is why gyros are also needed. Gyros are fairly also easy to get; a little more pricy but not unreasonably for the scope of such project. The difficult part is the software that fuses all signals together to calculate the final attitude of the aircraft.

-Angelos

[Xcellgasman101]

That is what I'm talking about,, The software,,, I have a son that is in the Army, He is taking collage course's for computer writing software, He want to write game software,, I'll have to talk to him about what it would take to make the signal useable for our process.. This is going to be a great topic,,, XGM

[Angelos]

I am afraid it is not that easy. If it was, there would be dozens of inertial autopilots on the market and they would be really cheap. The high price of systems like the CARVEC and Micropilot is not due to expensive components but due to years of research and development.

The mathematics that make such autopilots work are extremely complex and require a fair amount of computational power from the small onboard computer. To have a chance to make this thing work you will need to combine the skills of

A very good mathematician/physicist
A very competent computer programmer that understands control loops and can write bug free code. Mistakes here are not forgiven.
A hardware designer to develop a dedicated microcomputer powerful enough for the job, lightweight and with low power consumption.

Here is a little taste of what you will be putting yourself into in terms of maths:

Kalman filter http://en.wikipedia.org/wiki/Kalman_filter

Rotation matrix http://en.wikipedia.org/wiki/Rotation_matrix

PID control loop http://en.wikipedia.org/wiki/PID_controller

I am not saying that it is impossible… but be prepared for years of dedication and a very steep learning curve.

-Angelos

[MarkWebber]

Kalman filter http://en.wikipedia.org/wiki/Kalman_filter

Rotation matrix http://en.wikipedia.org/wiki/Rotation_matrix

Ummm...Yikes! :shock:

[Nitrospazzz]

Kalman filter http://en.wikipedia.org/wiki/Kalman_filter

Rotation matrix http://en.wikipedia.org/wiki/Rotation_matrix

Doesn't look that bad really, just time consuming.

Can't wait to see what you come up with

[rroback]

I can't even imagine what you go through Angelos. Having been studying aerospace engineering ( switch to biomed...) but knowing I've been taking tons of math, but still have linear algebra, differential equations, and infinte series, math just drives me nuts. I've been also studying my first programing language, fortran ( yuck) and the thought of programming loops and writing bug free code is just awful( i wish I could sucessfully do either). I don't envy you, but you do impress me. Long live Spartan RC.

Rhett

[spork]

Here is a little taste of what you will be putting yourself into in terms of maths:

Kalman filter http://en.wikipedia.org/wiki/Kalman_filter

Rotation matrix http://en.wikipedia.org/wiki/Rotation_matrix

PID control loop http://en.wikipedia.org/wiki/PID_controller

None of that stuff is as scary as it sounds. You would need a PID controller (or better yet a state-space controller), and certainly familiarity with rotation matrices, but I tend to steer clear of Kalman filters. I agree they have their place, but more often than not, I feel they simply complicate a problem that doesn't need the complication.

The real problem with using this data stream to make an autopilot is not the math or the programming; it's the inherrent limitations of the sensors. The accelerometers and gyros are great at interpreting the high frequency motions, but they drift. They can tell me if I'm accelerating up (in body axes) or down; but they can't tell me how high I am. They can tell me if I'm rolling right or left, but they can't tell me if I'm upside down (although one can play some tricks with averaging the gravity vector to assist in the absolute orientation - but not yaw).

Accelerometers and gyros are "relative" sensors by their very nature. To make a respectable auto pilot you need to integrate their data with absolute sensors (such as pressure altimeters, GPS, vision, compass...) We instrument NASCAR vehichles in exactly this way to get a 2 cm resolution 5 times/second on each car. When we're running with gyros and accels alone we can only coast for about 10 seconds before the errors begin to drift out of our acceptable range. And these IMU's (gyros and accels) costs 10's of thousands. The good news is that they're coming down in price. It looks like we'll see MEM's (micro-electronic-machine) technology surpass the ring-laser gyros in 2 or 3 years. Already some fiber-optic gyros are outperforming ring-lasers. But even with the very best inertial sensors it's unlikely that we'll get away from the requirement to augment with absolute sensors.

Incidentally, one of my flying buddies does integrate GPS and inertial sensors in an autopilot he designed for his UAV's. You can see some of his stuff on www.spyplanes.com

[EricTheRed]

Angelos and Rick, excelent discusion and background in the issues and possible soultions regarding the use of sensors to acheive a true auto pilot system. However, I was more interested in utilizing the sensors as a stepping stone to acheive a stable hover with regards to a know location. I agree that the silicon accelerometers by them selves are not the ultimate answer, however they could be a possible source of one type of input.

Great input and I look forward to any future ideas in this area. I just wanted to throw out an idea and see where it went.
-Eric

[spork]

If you're looking to stabilize a hover you could do a lot with a basic IMU. As long as you don't care if the position of that hover drifts over time.

[fogger]

Hey guys,

Off topic, but it sounds like you're the folks to ask. I'm intereted in trying to add accelerometer capability to the eagle tree micro logger for use in quantifying 3D helicopter performance. Now I know I could just buy the full blown eagle tree data logger system and buy their accelerometer, but I'm thinking a lot of people might be interested in adding this functionality to the far cheaper micrologger, and anyway that's more of a challenge :)

So my EE buddy is looking at a mems acc. to accomplish this task, but I'm wondering if any of you know if this can be done with an off the shelf, very small and lightweight acelerometer, so we don't waste our time re-inventing the wheel...

Any feedback would be great.

Thanks,
-Fog

[spork]

Sure, as long as you're not hoping to recreate the flight path very accurately, any accelerometer will do. I think there are plenty of chips available these days that will output accel as a voltage or digitally.

Just type "accelerometer" into www.digikey.com. That gives 219 hits.

Looks like the ADXL321JCP-ND might be a place to start. It's a two-axis accel with analog output. It reads to +/- 18G and is available in single unit quantity for $8.60

AD22284-A-R2CT-ND reads +/- 35G in two axes for $15.75

[ssozonoff]

Hi,

How about one of these...

http://www.sparkfun.com/commerce/images/Main-6DOF-v2-2.jpg

http://www.sparkfun.com/commerce/product_info.php?products_id=8193#

Then you just need the maths :wink:

Serge

[Angelos]

The IMU is not the issue. The software is as it requires a fair bit of computational power. Incidentally the Sparkfun IMU is the worst one I have seen. The measurements are far too noisy for making a good performance system.

-Angelos

[ssozonoff]

Hi Angelos,

Thanks for your comments, seems you have been there and done that already.

Sure am looking forward to seeing what you come up with...

Serge

[bladebreaker]

Wow, interesting thread. Interesting read. I'm glad there are people like you that can understand this stuff because it is WAAAAAY over my head!

Tip :noteworthy

[ssozonoff]

Incidentaly Angelos,

What would it take to adapt this (circuit) to work with the AP2000i?

http://www.recherche.enac.fr/paparazzi/wiki/images/thumb/0/0b/Ir_sensor_bot_small.jpg/180px-Ir_sensor_bot_small.jpg

http://www.recherche.enac.fr/paparazzi/wiki/index.php/Sensors

Thanks,
Serge

[staplegun]

ssoz

The AP2000i uses the FMA Infrared sensor for flight stabilization

[Angelos]

If you can run it of 3.3V then most likely you can connect it to the AP-2000i without any mods. Just the corret wiring. However, you'll probably find that it is cheaper to get the FMA sensor. We have designed an IR sensor too but since FMA cut the sensor price to about half from what it used to be, there is no benefit in marketing out own.

-Angelos

[Daniel Wee]

I actually embarked on such a project a while ago and actually having a Kalman filter is not superflous but rather essential. The thing is that you will need pretty high precision both in your computational algorithm, as well as in your hardware (from sampling resolution to low noise floor). The reason for this is because you will be integrating the data stream in order to maintain an artificial reference point (like an artificial horizon). This is true even if you will only be seeking to maintain a hover.

The gyro's all have some kind of drift and your software will need to nullify the drift over time, and also maintain integrate the gyro data to give you the estimated absolute movement. This combined with the accelerometer data will allow you to calculate actual movement.

The other problem I ran in to was computational power. I built my test controllers around the fastest available PIC and Atmel controllers but even then, I had to count cycles. Everything was coded in assembly for maximum optimization. In the end, I ran into so many unexpected problems, such as noise in the accelerometers which was more than I had imagined - which could have come from the power system (this was an electric heli) - on a 12-bit A/D sampler.

What finally killed the project for me was the fact that some company was coming out with affordable non-IR based stabilizing systems, which was basically what I wanted in the first place. IIRC this was the Robbe Heli Command which promised to do everything I needed.

This is not to discourage you but to help you realize the extent of such a project. If you should embark on it an make progress, I'm sure we'd all be keen to hear of your development.

Daniel

[spork]

The gyro's all have some kind of drift and your software will need to nullify the drift over time...

I'm curious as to how the software can nullify the gyro drift over time without an absolute sensor (since the drift cannot be characterized - by definition).

[Daniel Wee]

I know exactly what you're thinking - puzzled me for a while too. The gyro is not working on it's own to resolve this problem. The Kalman filter takes inputs from the accelerometer as well which, if I understand correctly, averages over time to a null.

That is the beauty of the Kalman filtering, when implemented correctly. The success of this approach depends on the quality of the input data stream - noise, stability etc. Fixed bias can easily be dealt with through calibration but dynamic bias (such as arising from thermal drift) will have to be dealt with dynamically.

Many systems, such as CARVEC, basically solves the problem simply with a 6DOF (Gyro+accelerometer) approach without the need of absolute position sensors, such as magnetometers. I considered employing magnetometers but even those are prone to interference and to local magnetic flux variations.

Because of this, understanding Kalman filtering is mandatory for such projects. I initially tried to do it without having to delve into the higher maths but you just can't do it that way. Any error is magnified (cumulative) through the integration process, and you either end up with a runaway situation or oscillations.

I also forgot to mention that you will need to implement some kind of floating point library to deal with the precision required in the calculations. This will further load your processor.

Daniel

[spork]

Because of this, understanding Kalman filtering is mandatory for such projects.

Hmmm..... that's what my M.S. is in. Still it strikes me there are some "gaps". Imagine for example you're trying to maintain a stationary hover. If the yaw gyro is drifting it will simply drift in yaw. The Kalman filter can't help here. Similarly, flying a coordinated turn for an extended period will also fake out the Kalman filter.