Reduced Yaw Drift / Fast Gyro Sampling with the UDB / MatrixPilot from Pete Hollands .
[Note: Apologies for the low sound volume in this video. Please turn your volume up.]
This is a demonstration of the reduced Yaw Drift which is possible when sampling the gyros at 30,000 times / second (Thanks to William Premerlani for this R&D and code). Using QGroundControl and the MatrixPilot MAvlink implementation, I show a real time graph of the resulting negligble yaw drift in the UDB IMU.
In the demo I do refer to the accelerometers quite a bit. I should really have been focussing on the gyros. It is the high sampling of the gyros, and the integration of the resulting data which leads to the low yaw drift. So please ignore my comments about the accelerometers.
Demonstration uses Revision 790 of MatrixPilot_mavlink branch at this address
code.google.com/p/gentlenav/
@ionut, have not tried in flight yet. I suppose there are three sets of additional conditions which would be interesting. 1) Tests with engine vibrations, 2) 3D twisting in 3 axis (my demo was twisting only around the Z axis) 3) a combination of both of those (real flight).
But, I would not expect to see much improvement for the UDB flying a plane. It's already super, and of course the gyro drift is most accurately corrected by using the wind-corrected GPS heading. Magnetometers also work but seem to be less accurate.
So I expect this improved gyro drift to be of most impact for Helis and Quads in the future. It may also improve camera targetting.
Hi ionut,
I expect the high sampling rate will solve the problem recently discussed by Ryan, and will dramatically improve dead-reckoning accuracy for quads and helis.
For the existing MatrixPilot code for fixed wing aircraft, I do not think there will be any noticeable improvement in performance. However, the lower residual drift rate and improved noise attenuation does open the door for possible further modifications to MatrixPilot that will ultimately result in improved precision of attitude estimation, especially in situations that lead to slight pitch errors right now, such as a high-speed hand launch.
Best regards,
Bill
Pete/Bill, I'm really interested in dead-reckoning for a current project, and the level of drift you demonstrate here would be fantastic. Can you answer few questions?
What is your method for sampling the gyro and calculating the angle? Do you sum the gyro output over an interval, then subtract the null and multiply by a scalar? At what interval do you calculate your angle? (I assume you don't do it every sample).
Also, when a motor and ESC are connected to the controller, do you see an increase in noise and drift? Do the ucontroller and the ESC/motor run off the same battery pack? (I'm just wondering if noise from the motor will affect the gryo readings). What gyros are you using?
Thanks for the excellent info.
Nathan
Increasing the sample rate is a well known method to increase performance when working with unlinear sensor data such as gyros. But there will always be gyro drift because of sample rate, adc conversion etc.
The real test starts when you add vibrations and/or quick motions. Then all those small errors starts adding up and become noticeable.
Hi Nathan,
As John has pointed out, oversampling is a well known method for improving A/D performance. See, for example, a MicroChip application note on the subject. I have used the technique in many projects over the past 35 years.
In this case, I am using a technique called "integrate and dump" for the decimation filter. In MatrixPilot, calculations are executed at 40 Hz. In between calculations, the new A/D service routine is simply adding each sample to a running total. This amounts to integration. Then, when the calculations require actual data, the running totals are divided by the number of samples that contributed to the total to produce an average.
For computations that integrate the values, this amounts to integration over all samples. For computations that use the values in other ways, think of the values as average values.
We do subtract out the "offsets" which we measure shortly after power up. This oversampling technique gives us extremely accurate measures of the offsets, which is why Peter was able to demonstrate an uncompensated yaw drift rate of 0.25 degrees/minute.
I have not yet tested for the effects of electronic interference, I will report back after I do those tests.
By the way, this oversampling technique in MatrixPilot has not yet been released in trunk, we want to do some test flights as part of our verification process. It will be released soon.
Best regards,
Bill
William:
Have you tried interpolation between sample points? By looking at the timing and curve of sample points, you could try and estimate points ( bezier or some other simple vector math ) in between for improved results. Something like the AVCS vector calculations used in high end Futaba R/C gyros.
Is there any reason the sampling has to be 30KHz? Our AVR is sampling about as fast as it can, which is about 2Khz (20MHz clock with 6 ADC channels)
Thanks
Roy
@John,
I have not tried interpolation yet. That is an interesting idea that should further improve the accuracy during rapidly changing conditions. I like it. I assume what you have in mind is to fit a straight line to the points, so you would report out the mean and the slope? I like it.
@Roy,
You can use whatever sample rate you want, its just a question of how much performance you would like to have. In my opinion, 30kHz provides better resolution and noise attenuation than 2kHz. That said, we ran MatrixPilot at around 1kHz for a long time, that seemed to work ok. But 30kHz will work so much better.
@Everyone:
Unless you have an ideal antialiasing filter, with perfect behavior, errors from sensor noise and vibration will be present in the samples, which can be taken out by oversampling.
Best regards,
Bill
169 members
5 members
165 members
1023 members
73 members
© 2017 Created by Chris Anderson. Powered by
You need to be a member of DIY Drones to add comments!
Join DIY Drones