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
Comments
Hi Bill,
Your research has been very helpful for us to performing swarm based flight.
I was trying to build a position/velocity estimator for the purpose of Navigation using UWB tags. After analysis, I found the velocity estimates were messing up. So, I calculated the velocity using data. What I found was that if I calculated the velocity without converting into the earth frame and there was a big difference :
After looking at the data, I found the erroneous pitch was the reason improper velocity estimation. Now I have implemented a DCM estimator to fix the issue. Earlier my estimator was a simple complimentary filter for attitude estimation.
Acceleration compensation in the Earth Frame was removed from MatrixPilot trunk (Master on Github) on 18th May 2013.
Brillant job. Thanks a lot William.
I went through the code in file AP_AHRS_DCM.cpp, it seems ArduCopter runs only this algorithm on APM2 for gyro drift compensation.
But it relys on GPS and my APM2 flys perfectly indoors (with GPS intalled, having not location fixed).
Anyone has idea? Is there anyother gyro drift compensation algorithm (without help of GPS) in the ArduCopter?
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
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
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
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?
Your expertise is much appreciated!!
Dave
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
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
good
-
1
-
2
-
3
of 3 Next