I am talking about drift, not accuracy. What I see can be described in two ways. Start the FreeIMU_quaternion sketch with the IMU board motionless. Start FreeIMU cube and align the board relative to the screen and make it motionless. Press the h key. In a few minutes the cube drifts more than 45 degrees alot in yaw but some in pitch and roll as well. Another symptom is after moving the board quickly the cube moves to the new position quickly and then drifts rapidly to another.
I used the term "unacceptable: because with the amount of drift I am observing, the IMU would not be useable in any application.
The reason I asked if you would post a video of a properly calibrated FreeIMU is to see if possibly this has something to do with the ArduIMU. In posting such a video, if you could also perform the calibration as I (and others) are unclear as to how to actually move the board during the calibration process?
Those are synthoms of unaligned sensor's axes, not uncalibrated magnetometer!
The FreeIMU library assumes that sensors are aligned (eg: acc X axis same direction of magn X axis) but that's not the case for the ArduIMU! So, you will have to align them in the software. Try replacing the following line:
AHRSupdate(val * M_PI/180, val * M_PI/180, val * M_PI/180, val, val, val, val, val, val);
with the following one:
AHRSupdate(val * M_PI/180, val * M_PI/180, val * M_PI/180, val, val, val, -val, -val, val);
I'm uploading a video of a calibrated IMU right now.
Here is a video. Watch it in HD.
I see it stabilize but it starts drifting again as soon as it is moved to a new orientation. Still very good performance and your support to ArduIMU is much appreciated! Thanks
My application requires good yaw (heading) performance so I would like to try to reduce the drift. Do you or anyone else have any papers, links, or other sources of information on gyro calibration algorithms?
In terms of GPS, heading accuracy is usually quite good (assuming some movement) and the update rates are 10+Hz on some units. I am going to look into adding GPS to FreeIMU but need to do research on it first.
Thanks again for the help in getting FreeIMU running on ArduIMU.
I don't have much experience in gyroscope calibration.. an initial work on temperature compensation was started on here: http://code.google.com/p/itg-3200driver/issues/detail?id=9
However, I wouldn't know what else to suggest.. You may wanna get in touch with Seb Madgwick, I'm sure he'll be able to point you to good calibration papers.
Please, I'd really appreciate if you could keep us posted on your work.
Thanks for the link. I have been gathering gyro error and calibration information and have drawn some initial conclusions to guide my work. A month ago I knew basically nothing about IMUs, etc. and I have been drinking from a fire hose since. I may be way off base on some of this so be forewarned.
I will post my progress as you requested with the first installment below.
Main gyro error sources are scale factor, bias, and noise, with the first two being subject to temperature changes and aging. In my case, the heading drift (and probable error) I am seeing is unlikely due to temperature since I have had the IMU powered up for days and it must clearly be at temp. steady state. Therefore, temperature characterization of scale and bias are of lower priority.
There is a form of bias calibration already in FreeIMU where 3 samples are taken on power up. Interestingly, I cannot find any delay time for the MPU60x0 sensors to stabilize (spec is 30mSec typical) before doing the zerogyro(). A delay does exist for the ITG3200. While more than 3 samples may be an interesting experiment, the delay time in my case is not an issue, again since the IMU has been powered for a long time. I have added a 100mSec delay in my code for future reference and, unless it is in there and I missed it, you may want to do the same.
Scale factor calibration would seemingly provide performance improvement but requires a rate table to do it. I have found a paper that describes a self-calibration process but it needs study it to determine feasibility. I am in the process of building a stepper motor fixture for testing the IMU error and response time and may use it and my own stepper control code as a rate table to gauge the benefit of scale calibration.
An alternative to accurate gyro calibration for minimal heading drift and higher accuracy is GPS which has been another subject of consideration. I need to learn if there is a benefit (and method) to using both GPS and the magnetometer for this purpose. It seems GPS is the highest priority as the ArduIMU is already GPS enabled.
I know Sebastian was thinking about using a audio turntable (you know for playing LPs) since they seem to provide good speed accuracy.. may be something interesting to hack. :-)
Would you comment on tuning of the two gain factors twoKpDef and twoKiDef? My application requires the best yaw/heading performance I can achieve even at the expense of pitch and roll. I find if I zero out the above factors I see much improved yaw drift and stability (locking into an angle after a quick movement). Pitch and roll drift are slightly negatively affected but, as I say, I really don't care much about those values.
fyi... my application involves measuring accuracy of the path of a boat traveling at between 30 and 36mph. Specifically, this is for competitive water skiing in a slalom (i.e. one ski) course where the boat is required to be accurately on a heading and centered in a row of buoys spaced about 9 ft. apart for a distance of about 1000 feet. This translates to about 23 seconds of accurate operation of the system which can be reset on the next pass thru the course.
The slalom course is located very accurately on the water surface because the buoys are all surveyed in to a tolerance of about +/- 1 inch. The first step is to measure the boat heading w.r.t. the accurately known course heading, i.e. assure the boat is parallel and on a straight line to the course. Next we will try to "locate" the boat on the specific line thru the center of the course and measure how close to center the boat is on the specific heading. This location process may be laser and/or video based (video cameras are required on each end of the course now where judges visually monitor the boat path straightness and centering)
All of that describes why only yaw/heading is important. In actuality, roll and pitch measure how smooth the water is and that is of secondary importance and easily judged by visual means.
What is wrong here? I cannot get either the ArduIMU code or a 2 variations of the FreeIMU code to work satisfactorily.
Here are links to 3 videos as follows. In each case the initial position was set/zeroed and then some pure yaw movement followed by a pitch up and then down. The last video shows some roll as well.
ArduIMU Code.swf = ArduIMU running the latest ArduIMU code but outputting quaternions in the format for freeIMU_cube (modified but with no GPS attached yet)
ArduIMU with FreeIMU PI gains = 0.swf Is the FreeIMU code for the MPU60x0 library to run on ArduIMU. The PI gains have been set to zero
ArduIMU with FreeIMU PI gains = default.swf same as above but with PI gains as default in FreeIMU.
None of these are giving satisfactory yaw performance and nowhere near yaw-lock. Note the jitter and wild excursions of the base ArduIMU code. Is something wrong with my board since I would think performance overall would be better since people are flying things with the ArduIMU code setup. FreeIMU is using the magnetometer for correction but the yaw drift is still quite bad. Note: for FreeIMU I have run the latest calibration procedure multiple times but can never get the output shown in the FreeIMU blogs.