Hi Gary,
I saw your question about horizontal drift. I will get back to you in a few days.
Best regards,
Bill

Hi Gary,
Here is my answer to your question. My answer is too long for one comment, so I will break it up into parts:

Hi Gary,

I read the posting at the link you gave me, but not the build log, (I could not find it), but in any case, I think I know what is going on....

The core of the DCM algorithm estimates attitude from gyro signals. So far, so good. To compensate for gyro drift, it needs at least 2 reference vectors. An accelerometer is used as a reference for vertical.

Ideally, we would like a vertical sensor that responds to gravity only, but that is physically impossible. An accelerometer responds to gravity minus acceleration, which happens to be the total of the aerodynamic forces, divided by mass. So, unless you somehow account for the acceleration, you will get the effect that you describe. There are several things you can do about it:

1. Use another reference for horizontal velocity, such as visual flow.

2. Estimate the acceleration and compensate the accelerometer signals for it. This is what we do for airplanes in MatrixPilot, and we have it working rather nicely. We estimate centrifugal acceleration from gyro information and airspeed. We estimate forward acceleration from GPS. In principle, you should be able to estimate acceleration in a multicopter, but you will need to take a different approach than the one you use for an airplane. I started to work on the problem this winter, but got sidetracked. I hope to take another look at it this summer.

(to be continued) - bill

3. Lower the gains in the roll-pitch PI drift compensation feedback loop. The magntitude of the effect that you describe depends on the loop gain. The larger the PI gains, the larger the effect. When you use uncompensated accelerometer signals in either an airplane or a multicopter, if the gains are too high, you can get into a situation in which the measurement-control-physics loop winds up having a net positive feedback gain, and you get into a runaway situation. When I was debugging the pitch control of MatrixPilot on an airplane, I called this a "death dive". The plane would follow a nice parabolic trajectory, until I fixed the problem. If you can lower the PI gains, you will still have some error, but you won't get into a runaway situation.

The key to being able to lower the PI gains is to first lower the uncompensated drift rate of the gyros. In MatrixPilot, we recently came up with a way to get the raw drift of the gyros down to less than 0.003 degrees per second (0.18 degrees per minute). It turns out that much of the gyro drift is due to noise, and can be lowered by oversampling the signal. In MatrixPilot, we are presently sampling at 8,800 samples per second for each sensor, and using an "integrate and dump" technique to consolidate the data for the 40 Hz computation rate. 220 samples are added and divided by 220 for each pass of the DCM algorithm. This is approximately equivalent to running the DCM at 8,800 Hz.

As I mentioned, quads and helis are on my list, I hope to get something up and running this summer. I know that a couple members of the UAVDevBoard community have written stabilization code for helis and quads, and that it works rather well. So, I think the problem can be solved.

Best regards,
Bill

Hi Gary,

Feel free to repost my comments.

Best regards,

Bill

Hi Gary,
Well sure, you can use the accelerometers to reduce horizontal drift, why didn't you say so. ;-)
You can fuse the GPS, gyro, and accelerometer information into an IMU-based estimate of position and velocity. I recently got that working for airplanes. It provides position and velocity estimates at the servo frame rate. Adapting it for helis and multicopters is on my list of things to do. That should not be too hard to do. You might want to look at my recent blog postings.
Best regards,
Bill