# Acceleration compensation: flight testing

Team,

I have recently performed flight tests on a major change in the way acceleration is accounted for in performing roll-pitch drift compensation from accelerometer measurements. The theory behind the idea was recently published in a discussion on this website. Since then, I have made a couple of refinements to the idea, the latest version is documented here.

Implementation in MatrixPilot is shown here. There is one slight "tweak" in the implementation that is not covered in the theory paper: although in principle the new method can provide yaw drift information, in the implementation I have used it for roll and pitch only.

I put off posting a blog entry until I had flight test data, which I now have. The above picture is from one of several recent test flights with a UAVDevBoard running MatrixPilot on an EasyStar, that shows that the idea works. What is shown is a comparison of the GPS track and the "dead-reckoning" computation. The yellow arrows indicate the wind direction and the plane icons indicate the attitude of the plane. The fact that the two tracks match rather closely is an indication that the estimated attitude matches the actual attitude, otherwise there would be a large discrepancy.

A major advantage of the new method is that it does not require a model for computing aerodynamic forces, nor does it make any of the approximations that previous methods do. It is based on kinematics only, and does not make any approximations. Therefore, it will provide accurate acceleration compensation for any platform, including quads, cars, motorcycles, baseballs, anything you want to attach an IMU to. (For anything but fixed wing, it does require a magnetometer.)

Now, some more pictures.

The next picture is taken from a portion of the flight in which the EasyStar flew in a tight circle for several minutes. Both GPS and dead-reckoning tracks are plotted. Two out of many revolutions are shown. It is during circling flight that it is particularly critical that acceleration be correctly accounted for. As can be seen, GPS and dead-reckoning match, indicating that attitude estimate is correct.

The final picture is the track of the entire 20 minutes of one of the test flights, in which I did my best to "break" the algorithm.

Best regards,

Bill

Views: 3611

Tags: IMU, UDB, acceleration, centrifugal

Comment by Roy Brewer on May 6, 2012 at 10:37am

Bill,

Great work, as always. I have some suggestions for improving the efficiency of the calculation:

- Work in the body axes - that is, transform the GPS velocity into the body axes, instead of transforming the accelerometer reading into earth-axes. This saves one transform (the one in eq 6 of the paper).

- Subtract the GPS velocity from the sensed accelerometer value. This gives the sensed gravity vector (ignoring noise, sensor imperfections, etc.). Then take the cross product of this with the estimated gravity vector - i.e. the bottom row of DCM. This calculation could then be used as the error vector, eliminating the concerns of quadratic data in eq 4 and the need to "normalize" in eq 5.

Yes, the calculations technically would be done in the body axes instead of the earth axes, but mathematically this approach is equivalent.

Also, I think the same technique could be performed using (3-D) optical flow sensors (with suitable care to account for coordinate system misalignment).

- Roy

Comment by William Premerlani on May 6, 2012 at 4:42pm

Hi Roy,

Its great to hear from you, as always. I am glad that you are interested in this topic, and have given it some thought...

Regarding doing the computations in the earth frame versus doing them in the body frame...

Because the gyro/accelerometer update rate is much greater than the GPS reporting rate, there is a distinct improvement in accuracy by doing the calculations in the earth frame. That is because, in the earth frame, the integral of the rotation matrix times the accelerometer readings are compared with changes in velocity.

However, in the body frame, we need the integral of the transpose of the rotation rate times the instantaneous acceleration. Except the GPS does not report instantaneous acceleration, it reports change in velocity over finite time periods. We might be tempted to use the average acceleration computed from GPS change in velocity, but in the body frame, that leads to an approximation that dilutes the accuracy of the calculation.

So, it is much better to do the computations in the earth frame.

I revised my report to include an appendix with some math that shows the computations can be done exactly in earth frame, but only approximately in the body frame. So, if you would like to study the math, read the appendix in this revised report.

Best regards,

Bill

Comment by dusl on August 28, 2012 at 12:18am

good

Comment by Dave Whittington on September 27, 2012 at 10:36am

Bill,

Thanks so much for your expertise and help to us APM folks with probably the most sophisticated DIY autopilot code - especially in the area of attitude computation with wind. One question I have is whether GPS signal blackouts for a "short" time will confuse this new attitude code.

Thanks again

Dave

Comment by William Premerlani on September 28, 2012 at 5:56pm

Hi Dave,

With this new acceleration compensation code, you do need to use an alternate approach during GPS blackouts.

For fixed wing, aircraft, my recommendation is to use the older method for acceleration compensation using the last known value of air speed if there is no air speed sensor, or the actual air speed if there is a sensor.

For multicopters, there are a couple of approaches you could use, perhaps Tridge or Jonathan might comment if they read this, they have implemented this technique. There are several things you could do during GPS blackouts:

1. You could turn off the roll-pitch feedback loop during the blackout. This would work if the blackout period is short.

2. You could extend the "delta time" in the computation to include the blackout, continue to perform the integral of the accelerometer measurements, and complete the computation when the next GPS velocity measurement becomes available. This would work if the blackout period is not too long.

3. You could leave the acceleration compensation out of the computations. (This is equivalent to the previous approach used by ArduCopter.) For implementation, you simply set the GPS change in velocity used in the computations to zero.

Best regards,

BIll

Comment by Dave Whittington on September 29, 2012 at 5:39pm

Bill,

Thanks for your response. During the GPS blackout, is it primarily just the wind estimation that will suffer or will it feed into the general attitude signals as well?

On another subject, is there a way to estimate angle of attack and sideslip angle from the data coming from the APM 2.5 code?

Dave

Comment by William Premerlani on September 29, 2012 at 6:26pm

Hi Dave,

First, a disclaimer: I am not familiar with the APM code, so the final word should come from the Ardu team. The following is based on how MatrixPilot operates:

One of the effects of GPS blackout will depend on whether or not you have a magnetometer. Without a magnetometer, an extended GPS blackout will impact yaw attitude estimation.

Regarding angle of attack and sideslip angle, I think in order to get any sort of accuracy, you would need a dynamic model of your aircraft. Then you could estimate sideslip and angle of attack from airspeed, acceleration, and rotation rate.

Otherwise it would be difficult to make accurate estimates, because of the wind. The wind estimation algorithm assumes zero angle of attack and zero side slip.

Best regards,

Bill

Developer
Comment by leonardthall on January 19, 2013 at 7:05pm

So to summarize what you have said here Bill,

1. GPS black out will result in similar performance to what we have already for a copter.

2. Magnetometer is used to correct the yaw during blackout but is supplemented when we have GPS.

Three questions:

How will Magnetometer errors impact this algorithm?

How this algorithm handle GPS errors for a copter in hover?

Can anything here be used to improve or supplement the inertial navigation we are working on? (improved yaw measurement for example)

Thanks for your work Bill! And nice to finally meet you!

Leonard

Comment by William Premerlani on January 20, 2013 at 9:41am

Hi Leonard,

Nice to meet you, too.

I have not thought about this algorithm for a while. I think that the ArduCopter team, including Tridge, Randy, and Jonathan Challinger, are carrying this work forward. If they notice this they might comment, if not you might want to contact them. They would be in the best position to answer your questions. I think that they have this algorithm working, and they have made some improvements, including incorporating barometer information. Also, I think they have done some work in the areas relating to your questions. For example, I think they have done some work to compensate for magnetometer errors, as well as for handling loss of GPS.  They have developed a dead-reckoning algorithm that will work fairly well during loss of GPS, although I think it works only for fixed wing, but not multicopters.

Best regards,

Bill

Comment

Join DIY Drones

1

2

3

4

5

6

7

8

9

10

## Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here

203 members

54 members

88 members

24 members

720 members