Compass heading from IMU magnetometer data

[rbi...@cox.net]

Hi Guys,

 

    I have another IMU related question; which I shall ask kinda tongue-in-cheek, just because I can’t resist it.  But, I would appreciate a serious answer.

 

    I’m investigating the utility of a magnetic compass in a steel structure building environment.  Until now, I had thought it pretty useless since readings tend to have huge errors, up to +/- 180 degrees.  However, perhaps an angle averaged over a sufficiently long distance of travel will give enough accuracy to assist a poor lost robot in localizing itself.  Looks pretty good so far.

 

    Most current IMUs have a built in magnetometer.  My particular unit (UM7) provides just raw 3-axis magnetometer readings.   I convert them to a compass heading in my code.  While studying my data it occurred to me that I might not be producing heading to ROS standards.

 

    So, I thought:  aircraft (my experience) read in degrees with North reading zero and increasing with clockwise rotation.  So do boats, many land vehicles and every map I’ve ever seen with numeric directions.  So, what would ROS do?  I’m guessing radians with zero degrees East and counterclockwise. Right?

 

    Assuming “right”, I have a follow-up question.  Consider, 20 years from now, if a human was walking along a Northbound street with a robot friend, and the human wanted to go to the East side of town but had lost track of turns and didn’t know what direction he was going.   He asks the robot what (numeric) heading they were on.  What does the robot answer?   And what direction would the human turn at the next intersection?

 

    Or perhaps the robot is so smart (really intelligent robots are always 20 years in the future; it’s been that way for 50 years) that it thinks “This human believes in an arbitrary and antiquated direction system, I must convert the correct direction to degrees, North and clockwise”.

 

Thanks,

Alex

 

[Mike Purvis]

My recent update to REP-103 reinforces that ROS is an ENU system, and therefore any absolute orientations should be relative to a frame where X-positive points level and due east: http://www.ros.org/reps/rep-0103.html#coordinate-frame-conventions

Most of the discussion about this can be reviewed here: https://github.com/ros-infrastructure/rep/pull/88

As for the business of "mixing in" mag data with an existing IMU, there are at least two reasonable ways of doing it. First is to chuck your IMU's built-in orientation estimate and start over from the raw gyro, accel, and mag data, feeding it all into imu_filter_madgwick. This is how Jackal's built-in IMU works— the main bummer from an architecture standpoint is that the madgwick package contains GPL code, so it must run in its own process and can't be directly linked to the rest of Jackal. A new BSD-licensed library using this method would be very welcome.

Along similar lines is imu_pipeline/imu_filter. 

The second broad approach is to zero out only the yaw component of your IMU's orientation estimate, and replace just that part with a separate mag-based heading estimate. A package that does this is imu_compass.

Hope that helps.

Mike

--
You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drive...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/D20642D82B884733884931C186BA65BE%40DDT3.
For more options, visit https://groups.google.com/d/optout.

[Chad Rockey]

Google has a nice implementation of IMU fusion (with and without mag) available under apache v2.  I've always wanted to see a ROS wrapper for it:

https://android.googlesource.com/platform/frameworks/native/+/jb-mr1.1-dev/services/sensorservice/Fusion.cpp

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/CACsJT9O2QVP8zedNzTdbUsCtkzu3rV1%2BQ27mXNm%2Bu4ttuWvPMw%40mail.gmail.com.

[rbi...@cox.net]

Hi Mike,

 

    Thanks for pointing me to your imu_compass code.  While it doesn’t solve my problem, it was very instructional to a Kalman newbie like myself to better understand a simple one dimensional filter applied to a real task.   BTW,  I like your code; very easy to follow.

 

    I’m also happy to report that your code worked just fine with the UM7 and the driver that I modeled on your UM6 driver.

 

    And I note that imu_compass conforms to the standard in that North is 90 degrees. (well, 1.57 radians anyway)  (sigh..;-)  The comments in the github link were interesting.  I’ll wait until you update your UM6 driver to the final standards and I’ll make the UM7 the same. 

 

    I found that your filter was quite effective at smoothing the high frequency components of noise, but had little effect on the low frequency local magnetic deviations induced by the structural steel in my test environment (roughly 10 second period,  actually over about 20 feet of travel). 

 

    I think I am stuck with using long term averaging to get some idea of the actual heading.  I find that averaging the mag data over a distance of about 100 feet of straight travel can reduce the error to about +/- 20 degrees or so.  This still isn’t too impressive, but should be enough to disambiguate orthogonal hallways

 

Thanks,

Alex

 

From: Mike Purvis

Sent: Friday, April 24, 2015 7:34 AM

To: ros-sig...@googlegroups.com

Subject: Re: [ros-sig-drivers] Compass heading from IMU magnetometer data