AP2000i suggestion for accelerometer input

[borneobear]

Is there no system that can link a GPS system to a stabalization system like the AP2000i? Changes in the GPS reading would initiate the AP2000i to do corrective positioning. Altitude will be up to the pilot though.

[spork]

There have certainly been such systems as one-offs. I have a friend that sells such a system currently for UAV's, but it costs thousands of dollars and is typically sold to universities and government agencies. Also, his current system doesn't obtain attitude directly from GPS (as that's unnecessary for the applications his UAV's are targeted for).

Obtaining attitude directly from GPS requires multiple GPS receivers and antennas, and carrier phase solutions.

[Daniel Wee]

The thing with a Kalman filter is it's ability to work out the error, or drift, if you like. It is true that it is an estimated error but as evidenced by systems already in use, it actually works. I know it feels very counter-intuitive, and hence the suggestions here to strap down using GPS, magnetometers, etc.

Can we throw off the Kalman filtered system - yes, especially for sustained violent movement. My understanding is that the Kalman filter will eventually work out the correct data ones the movement has stopped or stabilized. I remember reading a very good explanation of this on the web recently but could not find the reference just now.

You may want to look at the UAV Autopilot project on Sourceforge. Basically they are doing exactly what we want and they use a 5DOF sensor combination. You can buy one of these fairly cheaply these days, ready made (Sparkfun 5DOF IMU). The trick will be in the software. I intend to continue exploring this and hopefully come up with workable code. There will be quite a bit of tweaking involved to get it working just right but I think I can deal with that.

If that works, we can effectively include an artificial horizon into the OSD which will be amazingly cool. We should get more people working on this, especially those who are more competent than me in implementing a KF correctly.

Daniel

p.s. A successful Kalman implementation is just one step - it provides accurate vector data which then needs to be integrated to maintain a position. This is another avenue for (quantization) error in both the time domain and sampling resolution. Mainly because we are integrating sequential discrete samples - there will always be errors. Maybe an analogue integrator can be made to work in conjuction with the software integrator - I don't know but will cross that bridge when I get to it.

[spork]

The thing with a Kalman filter is it's ability to work out the error, or drift, if you like. It is true that it is an estimated error but as evidenced by systems already in use, it actually works. I know it feels very counter-intuitive, and hence the suggestions here to strap down using GPS, magnetometers, etc.

Are you explaining Kalman filtering to me???

My understanding is that the Kalman filter will eventually work out the correct data ones the movement has stopped or stabilized.

Not true. If you only have inertial sensors, GPS (without the multi-rx Tans Vector approach), and KF, you'll never solve for the error in yaw. That's just one example.

[Daniel Wee]

Actually I was not thinking about yaw. My main concern was attitude, and this is in relation to getting an artificial horizon into the OSD as per the discussion earlier in the thread. The KF will need an absolute update after a period of time to reset the accumulated error but I have read that this may be in the region of an hour or two based on the autopilot project at sourceforge.

I would not really bother to use an INS for direction heading/yaw unless you really cannot rely on the GPS (such as an indoor application). But if the GPS is available, you can save the need for an additional gyro and possibly a tri-axis magneto meter (for which you will need to know the local magnetic inclination and declination).

I can't say for sure just how significant the drift will be and I am guessing that this will depend on several factors including the quality of the sensors, thermal coefficient, vibrations etc. But if reasonable stability can be maintained for an hour or two, that would be more than sufficient since I don't think my batteries can last that long.

Right now I am trying to see about the implementation of a 1-D estimation system which will then be used for pitch and yaw. If successful, then the artificial horizon in the OSD will be trivial. I have ordered a 5DOF IMU for this purpose (2-axis gyro, 3-axis accelerometer). The outputs will need some low-pass filtering before being fed into the 10-bit ADC on a dsPIC30F4012 which will basically handle the estimator algorithm (and may handle the OSD - depending on whether there are enough cycles left.

The other thing I don't know is how the system will handle coordinated turns but the accelerometers should recognize that the platform is in a turn. I need to do a lot more thinking about this thing. Unfortunately it does not appear that many people are actually attempting a project along these lines (artificial horizon) at the moment. If successful this can be used to stabilize a helicopter, for example.

Daniel

[ssozonoff]

Here is another IMU I have found but not looked into closely yet.

http://www.xsens.com/index.php?mainmenu=products&submenu=machine_motion&subsubmenu=MTi

http://www.xsens.com/images/MTi_in_hand.gif
http://www.xsens.com/images/MTi%20OEM1.jpg

Serge