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.
Due to my limited understanding of these things i can't really contribute to the discussion but i have something on my mind i want to post here because i think it is the right place to laugh about it :) . Gyros and accelerometers are disturbed more or less by vibrations in their measurements (acc >> gyro). Would it make sense to put some microphone or piezo directly to the frame (or sensor pcb) to measure these mechanical vibrations - perhaps it would make it easier to sort out some errors from a real change in attitude by some sort of "substraction"; perhaps the filtering can be more adaptive to the ammount that is really needed by knowing the frequency of disturbance? Perhaps a sudden and sustained increase of mechanical noise could trigger some sort of failsave (RTH) or a warning (light/sound). That's circulating in my mind for some time now since i played with some of the mwii acc code.
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.
Sorry to be asking simple questions, but do we still use the Arduino IDE with this code? I got lost with the discussion about Python since I don't have/use that. Where should we download a version that should work for ArduIMUv3 and the Arduino 1.1 IDE. Thanks for the help!
Yes. The Python discussion was only for the calibration software. If you download the calibration software you will get everything you need, i.e. Python, Numpy, etc.
You may want to have a look at Visual Micro for Arduino, a plug-in for Visual Studio. The cool thing is that there is a way to get the full version of either VS 2010 or VS 2012 absolutely free from Microsoft. There is also a source level debugger available for Visual Micro.
Did you get it to work OK for you finally? Could you confirm the link for Arduino IDE download - is it :
how to get the latest on the FreeIMU site - I run Arduino on Windows not Linux and don't know what bzr is.