Is there a port of the FreeIMU firmware to the ArduIMU hardware? 

I have the ArduIMU board but would like to try FreeIMU code on it.

Views: 9693

Reply to This

Replies to This Discussion

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? 

Thanks.

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[3] * M_PI/180, val[4] * M_PI/180, val[5] * M_PI/180, val[0], val[1], val[2], val[6], val[7], val[8]);

 with the following one:

AHRSupdate(val[3] * M_PI/180, val[4] * M_PI/180, val[5] * M_PI/180, val[0], val[1], val[2], -val[6], -val[7], val[8]);


I'm uploading a video of a calibrated IMU right now.

Here is a video. Watch it in HD.

Thanks!! That was it. I had wondered about this as a problem but didn't know where in the code to fix it. I made the change to FreeIMU.cpp in getQ() by adding the second #elif i.e.:

#if IS_9DOM()
#if HAS_AXIS_ALIGNED()
AHRSupdate(val[3] * M_PI/180, val[4] * M_PI/180, val[5] * M_PI/180, val[0], val[1], val[2], val[6], val[7], val[8]);
#elif defined(SEN_10724)
AHRSupdate(val[3] * M_PI/180, val[4] * M_PI/180, val[5] * M_PI/180, val[0], val[1], val[2], val[7], -val[6], val[8]);
#elif defined(ARDUIMU_v3)
AHRSupdate(val[3] * M_PI/180, val[4] * M_PI/180, val[5] * M_PI/180, val[0], val[1], val[2], -val[6], -val[7], val[8]);
#endif

I recommend this be added to the library.

I am still seeing about 0.2 degree/sec of Yaw drift but will try calibrating again. I can't make out the numbers exactly but I think I can see this happening in your video as well. (thanks for the video!). Are you see this amount of residual drift in Yaw?

I will consult the MultiiWii project as you previously recommended for including GPS. Do you think that will correct the rest of the Yaw drift?
Yeah, some residual drift is expected. Also note that with time it will stabilize if you held the board still.

In theory we could get rid of it by better gyro calibration with thermal compensation but that's not something I'm very interested in right now since I'm pretty happy with what I do have. I'm not aware of any other open source project doing it better :-).
I doubt that having a GPS will improve heading accuracy much since it is a pretty low frequency and accuracy source of heading.. but I'm not really very experienced in GPS to say much about it.

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. :-)

Fabio,

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)

http://aquest-inc.com/Files/ArduIMU%20Code.swf

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

http://aquest-inc.com/Files/ArduIMU%20with%20FreeIMU%20PI%20gains%2...

ArduIMU with FreeIMU PI gains = default.swf same as above but with PI gains as default in FreeIMU.

http://aquest-inc.com/Files/ArduIMU%20with%20FreeIMU%20PI%20gains%2...

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.

RSS

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service