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/
Comments
I have not tried interpolation myself yet, so I do not know it the gain (if any) is worth the overhead. But if you consider what a gyro signal represent, I think interpolation makes sense. The way I see it, a gyro outputs an analog signal (with a theoretically infinite resolution) that represents rotation of an object. And since the object has mass we have rotation inertia. Meaning that if we look closely enough, the signal will always change gradually. And it is this gradual change (that the ADC is not capable of sampling), that I think interpolation can approximate.
Hi Roy,
Basically, you have it right.
However, the formula that you cite must make some assumptions about the magnitudes of the signals that we are trying to block, otherwise I would expect to see that in the formula, but it does not make any mention of the magnitude of the high frequency noise.
The problem is, the signal from vibration can be so very large, that even a properly designed anti-aliasing filter does not take it out, so it winds up aliasing into the signal.
One of the UDB users has recently reported that by using 32,000 samples per second, he was able to solve a vibration problem he was having with a glow-engine powered aircraft.
Finally, to your question about the anti-aliasing filter in the UDB, off hand I can only give you an approximate answer. I am in the process of reorganizing my notes and papers on the UDB, and I cannot find my notes on the analog anti-aliasing filters. My recollection is that it has two first order low pass filters. There is a first order low pass filter internal to the Invensense gyros, with a cutoff frequency of 100 Hz. There is also an RC filter between the gyros and the A/D. However, SparkFun accidentally swapped the R and the C, so the C sits right on the output pin of the gyro, so there is an RC filter with the R equal to the output resistance of the gyro. The capacitor is 0.1 microfards, my guess is the cutoff frequency is rather high, probably between 1000 Hz and 2000 Hz.
So, the gyros in the UDB have internal first order low pass filters with 100 Hz cutoff, and external low pass filters with about 1500 Hz cutoff.
Best regards,
Bill
Hi Roy,
At some point, you will run into diminishing returns as you raise the sampling rate. Limiting factors include other sources of error in the calculations, the time required for the sample and hold to settle, and CPU loading. In the case of MatrixPilot running on the UAV Devboard, we are using 16 bit integer arithmetic for most calculations, so that really is the main limiting factor.
In the case of the UAVDevboard running MatrixPilot, CPU loading is not an issue. At 32,000 samples per second, the CPU loading attributable to sampling was only 1%.
Here is how I selected 32,000 samples per second:
What I have in mind is quad and heli applications. Some members of the UDB team have measured heli vibrations in the 5,000 to 10,000 Hz range, so I wanted to go higher than that.
I tried various sampling rates from 1000 to 32000 Hz, and found that resolution and residual drift continued to improve as I raised the sampling rate.
One thing I looked at was the residual gyro offsets. The UDB has a 10 bit A/D converter, and most arithmetic is done with 16 bit integers. Raising the sampling rate increases the number of effective bits. At around 32,000 samples per second, I was seeing approximately 15 bits resolution, as evidenced by residual gyro offsets on the order of a single bit in 16 bits. So I decided to stop there.
The way I measured the residual offsets was by looking at the values of the integral terms in the PI drift controller. Once the PI controller achieves lock, the value of the integrator represents the residual gyro drift. I could see the residual drift dropping as I raised the sampling rate. When it approached zero, that was far enough.
Best regards,
Bill
Nathan,
Yes, I am subtracting the offset after the integration. The way it is implemented, the raw samples are simply summed and averaged all of the time. During power up, the offsets are computed from the "integrate and dump" values.
Best regards,
Bill
Nathan: The way I see it you still use "integrate and dump". By interpolating the sample data you get an estimated 20khz integration instead of 10khz. No idea how AVCS actually works, it is a Futaba "trade secret".
Regarding Arduino and ADC, are you using analogRead()? If so the MCU is spending 99% of the time waiting for the ADC. Use ADC interrupts and you can compute for example interpolation while the ADC circuit is busy sampling.
Bill, in the integrate and dump method, I think I will subtract the null after doing the integration, saving the time of doing it each sample, and possibly reducing numerical error. Is that how you do it? (that would be integrated_angle/total_points - null*total_points)
Also, I am using an ADXRS613 gyro, which I've heard is less prone to vibrational noise. Maybe I can get good drift performance without having to go all the way up to 30kHz. I'll let you know what I find. Thanks everyone for the info.
Nathan
Willam:
Of the top of my head I would look into some kind of simplified (integer math?) curve approximation feasible within the limits of the MCU. I would then iterate the algorithm between autopilot "refreshes" to get the maximum amount of interpolated sample points that time allows.
@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
-
1
-
2
of 2 Next