ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Imu with magnetometer, read absolute position

asked 2021-08-27 12:59:22 -0500

Marcus Barnet gravatar image

updated 2021-08-28 11:27:53 -0500

Mike Scheutzow gravatar image

I'm using Xsens Mti-300 with AHRS in order to get information about the current heading of my robot.

I wrote a ROS Node in C++ that is able to convert the quaternion to YAW angle in degrees and it works fine since I can correctly read the yaw angle while I rotate the robot in any direction and the readings are accurate since it gives the same yaw value when I come back to known positions.

For example, when I power on the system, the initial position is +100°, then if I rotate the robot randomly and I come back to the initial position, I can read again +100°, so it works very fine.

The problem is that if I power off the system and I start it again, the readings from the magnetometers change.

It's like if the IMU get a new heading values every time I power it on while I would like to get absolute positions.

Is there a way to solve this problem?

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted
1

answered 2021-08-28 08:42:36 -0500

Mike Scheutzow gravatar image

What you are describing is standard behavior for the sensor_msgs/Imu orientation field - it reports the delta from the power-on orientation. The source of this orientation value is probably not the magnetometer, but that's just one reason it's not an absolute compass heading.

Your IMU may report a magnetometer output with a sensor_msgs/MagneticField msg. You can in theory convert this to a magnetic North compass reading, but you should not expect it to be very accurate. Many things in the environment will disrupt magnetic field lines.

edit flag offensive delete link more

Comments

Thank you for your answer. I tried to read the /imu/mag topic and I converted the vector to yaw angles but I think the output is not accurate since the noise introduced by the DC motors used for the motor locomotion. Is there a way to get the absolute orientation? What are the techniques used in this case?

Marcus Barnet gravatar image Marcus Barnet  ( 2021-08-28 09:28:59 -0500 )edit
1

By "absolute orientation" do you mean get robot pose in a map? In our indoor environment, we use lidar scan to match a pre-existing map (conceptually similar to amcl, but we don't use amcl.)

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-08-28 10:22:45 -0500 )edit

Yes, I mean the possibility to be able to retrieve the absolute orientation in degrees compared to a fixed reference (I.e. the earth magnetic field) in an outdoor environment in order to implement a gps based navigation. To be more accurate, I have a set a gps waypoint and I need to calculate the initial orientation of the vehicle in order to make it navigate towards the first waypoint (it may happen that the vehicle needs to be rotated of XX degrees in order to make the front bumper points towards the first GPS waypoint).

Marcus Barnet gravatar image Marcus Barnet  ( 2021-08-28 10:37:35 -0500 )edit

If you are outside (away from building wiring and equipment), and the robot wheel motors are off, I think the best you can do is average the converted-readings from mag and hope for the best.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-08-28 11:09:49 -0500 )edit

This is not a good option since the motor are ON all the time and I need to check the orientation multiple times during the navigation.

Marcus Barnet gravatar image Marcus Barnet  ( 2021-08-28 11:19:18 -0500 )edit
0

answered 2021-11-11 06:42:40 -0500

Please note that the MTi-300 is an Attitude and Heading Reference System (AHRS), which means that it can produce sensor-fused estimates of orientation (Roll/Pitch/Yaw, Quaternion or Rotation Matrix) directly. You can simply use Xsens MT Manager to enable one of those outputs. Unless you have enabled the vru_general filter profile or AHS feature, the Yaw angle output will then be based on the magnetic field directly after you power up the device.

If you are facing magnetic disturbances nearby your sensor then it is also possible to recalibrate the magnetometers of your MTi-300. This will improve the accuracy of your MTi-300's Yaw output, but it will also apply to the calibrated magnetic field data output. For more information on that, please see: https://tutorial.xsens.com/video/magn...

edit flag offensive delete link more

Comments

Unfortunately, I already tried to run the calibration for the magnetometer but this didn't solved the problem. Moreover, the calibration requires to rotate the sensor in 3D, but this is not possible since the sensor is mounted on a 100KG tracked robot and so we cannot rotate it. We also purchased an additiona xsens sensor, model 680g with RTK and still we are not able to get an absolute heading by using the general_rtk filter.

Marcus Barnet gravatar image Marcus Barnet  ( 2021-11-12 06:28:45 -0500 )edit
1

Hi Marcus, For the magnetic calibration, a couple 2D rotations would also be sufficient (e.g. only around the Yaw axis). What matters in the end is that the X-Y magnetic field readings correspond to the Earth's magnetic field, excluding the disturbances caused by the vehicle itself.

The MTi-680G is a GNSS/INS device that only uses the magnetic field for its Yaw estimation if the GeneralMag filter profile is selected. With the General filter profile, the Yaw output will be initialized at 0 degrees during power-up and it will automatically become East-referenced based on GNSS data (outdoors, if moving at a sufficient velocity).

stevenxsens gravatar image stevenxsens  ( 2021-11-12 07:12:39 -0500 )edit

What do you mean with "sufficient velocity"? Our robot moves at max 0.5 m/s, is this velocity enough to get the correct heading correction from GNSS? What I noticied is that when I start the system, the heading is zero, then I need to make the robot move randomly for 5 or 10 minutes to get an heading value which seems to be suitable. However, even in this case, it seems like the heading is not correct at 100%. Is anything wrong with my procedure?

Marcus Barnet gravatar image Marcus Barnet  ( 2021-11-12 08:10:40 -0500 )edit
1

Hi Marcus, That depends on how accurate your GNSS data is. If you are working with standard precision GNSS data (which is accurate down to approx. 1 meter) then 0.5 m/s is not sufficient to determine an accurate heading. (Note that, depending on the type of vehicle, heading does not always equal course-over-ground.) If you are applying RTK corrections (which will result in position data at centimeter-accuracy) then it could be sufficient. In general for slowly moving vehicles we recommend to at least include magnetometers to estimate the heading. An alternative is to use a dual-antenna setup which is immune to magnetic disturbances and provides heading even when the vehicle is standing still.

stevenxsens gravatar image stevenxsens  ( 2021-11-15 03:22:19 -0500 )edit

Can you please give me more information about the dual antenna configuration? We are using RTK corrections through the 4-pin connector placed on the back of the 680g xsens sensor. We are looking for centimeters accuracy and unfortunately the maximum velocity we can get is 0.5 m/s. Moreover, I think we cannot use the magnetomer since there are the DC motors that introduce noise on the sensor estimations. At the moment, we are using general_rtk filter and we need to obtain an obsolute heading value. Thank you!

Marcus Barnet gravatar image Marcus Barnet  ( 2021-11-15 04:34:44 -0500 )edit

Hello Marcus, Unfortunately, the MTi series of products currently do not support a dual antenna configuration, so I cannot help you further there... However we are happy to analyse the data produced by your MTi and to advise on configuration settings. In that case it would be best to contact support@xsens.com for further support.

stevenxsens gravatar image stevenxsens  ( 2021-11-15 09:51:30 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2021-08-27 12:59:22 -0500

Seen: 1,071 times

Last updated: Aug 28 '21