Allan Variance (plots and code)
Based on the sample data provided by Loris I have written some code to produce an Allan Variance plot of the data. The program source code is ISO C++98, and should compile with any standards-compliant compiler. G++ 4.4 tested, I expect MSVC 2k8 or higher to also handle the file just fine.
This particular program is somewhat specific to the data provided by Loris. It expects 16x oversampled sums, in integer ADC counts. The code performs the floating-point division back to native counts itself. Just compile and link the program in one command:
$ gcc -o allan_variance allan_variance.cpp
To run the program, provide it with a data file and the sampling interval. The data file must be provided as a list of whitespace-separated ADC samples, with six channels per entry. The first three channels are treated as x, y, and z axis gyros, and the remaining three channels are ignored.
Prior to actually using the data file, I massaged it somewhat. The original file has some weird line endings, something like \r\r\n. So I piped it through dos2unix and removed the blank lines with sed.
Over the entire sample period, the noise is dominated by white noise in the sensor, not by bias drift. I expect that the bias drift won't show up until the data stream is much longer, on the order of half an hour or so. Gnumeric was used to produce the plot.
This particular program is somewhat specific to the data provided by Loris. It expects 16x oversampled sums, in integer ADC counts. The code performs the floating-point division back to native counts itself. Just compile and link the program in one command:
$ gcc -o allan_variance allan_variance.cpp
To run the program, provide it with a data file and the sampling interval. The data file must be provided as a list of whitespace-separated ADC samples, with six channels per entry. The first three channels are treated as x, y, and z axis gyros, and the remaining three channels are ignored.
Prior to actually using the data file, I massaged it somewhat. The original file has some weird line endings, something like \r\r\n. So I piped it through dos2unix and removed the blank lines with sed.
Over the entire sample period, the noise is dominated by white noise in the sensor, not by bias drift. I expect that the bias drift won't show up until the data stream is much longer, on the order of half an hour or so. Gnumeric was used to produce the plot.
- Attachments:
-
-
realtime_samples_variance.gnumeric, 31 KB -
allan_variance.cpp, 3 KB
-
Replies to This Discussion
-
Permalink Reply by Jonathan Brandmeyer on -
The only problem is that your estimator is producing a bad estimate for the psi gyro bias. The changes in phi and theta after the motor starts aren't that bad, considering the hardware. Considering the slope of your psi estimate, it looks like your estimator started off with a bad gyro bias estimate, and never converged to a good one. You might try letting it converge for a min or so before starting the motor.
I'm afraid that I cannot comment on how well your firmware's DCM-based method will work in the end My experience is primarily in the domain of Kalman Filtering, although I would expect that at rest any remotely competent algorithm should be able to get a pretty good initial attitude and bias estimate with the accelerometer and magnetometer. Since the DCM method has been flight proven, it is at least competent.
You should probably go with a mechanical solution, anyway. Get some of those really soft vibration-damping rubber push-through "pins" used to mount computer case fans to their case and use those to mount the IMU to the vehicle frame. If that isn't enough, then add weight to the IMU board in addition to the dampers.
-
Permalink Reply by Loris on -
I don't have magnetometers so the estimator cannot cancel the yaw bias. I think the problem comes from a bad offset compensation.
I don't really like the roll and pitch estimation. Sometimes the difference is around 3°. For a plane it is ok but for a quadrotor I don't know. As you can see, from 500 to 800s, the vibrations change a little bit the roll and pitch offset.
Do you think the atmega328 has enough processing power to perform EKF?
-
DeveloperPermalink Reply by Doug Weibel on -
There was a post from someone who claimed EKF on the 328. I didn't have time to check it out when it was posted. No idea what update rate he was using....
I have seen similar (but worse) results to what you see (from 500 to 800s) due to vibration from a badly balanced prop at high RPM. I don't know that switching to EKF will solve it. You will still have bad data being input to the filter due to these gyros sensitivity to vibration. In my case I was able to eliminate it in the airframe by balancing the prop and mounting the IMU on a layer of foam. Everybody working on heli's (single rotor) seems to agree that you really can't get a decent solution without higher end gyros. I would think you could get a quadrotor to have less vibration than a large heli, so progably can make a quad work with this board. Obvioulsy Jose has had success.
-
Permalink Reply by Loris on
-
I uploaded sample datas : http://code.google.com/p/easy-imu-pilot/source/browse/trunk#trunk/T... The format is csv.
The bigger one is 200 000 samples at 107Hz so around 30 minutes. I also uploaded 50 000 samples at 160Hz (using a TX buffer) so around 5.5 minutes of data. I didn't change the gyros offset so the long term stability is quit good because the average is less than 0.5°/s.
The variance is 0.10 - 0.11 ADC steps (for both gyros and acceleros). It means a variance of 0.11°/secs for gyros and 0.001 m/s² for acceleros.
-
Permalink Reply by Jonathan Brandmeyer on
-
I'll get to analyzing this data later this evening. To what extent are these traces oversampled?
-
Permalink Reply by Jonathan Brandmeyer on
-
So, first, the results with the long data trace. There is an error in your data stream near time 180,000 such that it looks like a gyro value is missing, and the remaining samples are off by one. So, I just truncated the data at that point.
For reference, I also included a plot where the samples were integer right-shifted by two bits, and then floating-point divided by four. The data is essentially identical.
I don't see how you came up with a variance of 0.11 counts, since I came up with roughly three times that value. Maybe one of us has a bug in our code :) As for interpreting the graph... I expected to see a sharper transition from white noise to bias instability. Perhaps the gyro was still heating up? The shape of the curve is similar in the 50k sample graphs, but appears to be trending towards a lower minimum. What do "a plait" and "en biais" mean?
-
Permalink Reply by Jonathan Brandmeyer on
-
I found a critical bug in my Allan Variance computation that was throwing off the plots. Here is the Allan Variance plot produced by Loris's 200k sample stream (truncated at 180k samples).
Thank you so much for donating your test data. Now, we have an industry standard measure of the gyro's bias stability.
-
Permalink Reply by Loris on
-
Hi,
I found a variance of 0.11 using the variance function of matlab. (after I divided by 16 the sample).
"a plat" means with almost 0° of roll and 0° of pitch and "en biais" means with a lot of roll and pitch.
"en biais prob" means that the table moved during the experiment so they are some bad datas.
To sum up, the biais stability is good (only white noise) during 4 secs?
-
Permalink Reply by Jonathan Brandmeyer on
-
It means that the bias stability is 0.02 deg/s at an averaging time of 4-5 seconds. So the bias stability can be modeled as a rate random walk at 0.02/sqrt(4) = 0.01 deg/s/sqrt(s). The white noise can be modeled as an angle random walk of 0.04 deg/sqrt(s). You can use those numbers to set up how much process noise you add to a kinematic EKF. Honestly though, since the bias stays within a one-sigma bound of about 0.04 deg/s, and it is appallingly unstable, you may as well just set a floor on the confidence of the gyro bias estimate rather than model it as a random walk.
You might also be able to use them to tune the Permerlani DCM from first principles, once you know what the uncertainty is in the vector observations being fed into it.
For comparison, ADXRS610 quotes (from the datasheet) a bias stability of 0.008 deg/s at an averaging time of 90 seconds, or about 0.0008 deg/s/sqrt(s). The overall bias variation is about 0.04 deg/s RMS at a constant temperature. So for that gyro you can get a bias estimate that is somewhat better than the overall variation in its bias by correlating vector observations over time.
-
Permalink Reply by shikha jain on
-
Jonathan
0.04deg/sqrt(s) value you are getting from allan variance plot. can we use this value directly in our EKF as process noise variance and do you have any idea about Recursive Implementation of Allan Variance?
-
Permalink Reply by Jonathan Brandmeyer on
-
I know why you got 0.11 and I got 0.33. It's because I plotted the deviation, not the variance. sqrt(0.11) ~= 0.33.
- ‹ Previous
- 1
- 2
- 3
- Next ›
Social Networking
Top Content
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.
Groups
-
Swiss Drone Group
10 members
-
UK Ardupilot Group
110 members
-
Andropilot Users Group
182 members
-
ArduCopter User Group
1289 members
-
ArduCopter Evolution Team
140 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
