Rosanswers logo

After adding the Razor 9DOF IMU from Sparkfun, the resulting Odometry actually seems to have gotten worse as shown in the two videos below:

  1. Wheels-only Odometry, IMU disabled, analog Gyro disabled: https://youtu.be/ibY_HCBGm6U

  2. Wheels + IMU, analog Gyro disabled: https://youtu.be/mPiKbtP5szM

Both show the robot's position with respect to the /odom frame as calculated by robot_pose_ekf. If the odometry was perfect (i.e. no error) then the position of the walls as seen by the Neato XV-11 LIDAR would remain in the same place as the robot is moved around.

The wheels-only odometry has a long-term drift as the TurtleBot is rotated continuously (via joystick telop). In the short term, though, it is pretty accurate and can probably be improved further by fine tuning the scaling parameters.

The wheel+IMU odometric position gyrates pretty significantly per turn but there is no long term drift.

When localizing with AMCL, adding the IMU will likely produce worse results because Localization can compensate for long term odometric drift but the short term gyrations will throw it off.

I did calibrate the IMU as described in the wiki page, including the Magnetometer (Section 7.1.3). The calibration_magn_use_extended parameter is set to true.

I'm looking for suggestions on how the improve the results of the wheels+IMU odometry. Thanks.

Also, here's the Matlab Analysis of the Magnetometer configuration data. I'm not sure how this is supposed to be interpreted. Please let me know if something's wrong.

image description

Originally posted by sakumar on ROS Answers with karma: 26 on 2016-03-10

Post score: 0


1 Answer 1


Rosanswers logo

So the problem was in the Mag calibration. I redid the calibration procedure while the IMU was mounted on the Turtlebot. I picked up the Turtlebot and moved it around in all directions as in the instructions. The "Ellipsoid Center" values came out significantly different:

Standalone Calibration Results:

const float magn_ellipsoid_center[3] = {138.402, -65.8241, -12.1968};
const float magn_ellipsoid_transform[3][3] = {{0.847013, -0.00538074, 0.00712010}, {-0.00538074, 0.865221, 0.00961725}, {0.00712010, 0.00961725, 0.999017}}

Results when mounted on the Turtlebot:

const float magn_ellipsoid_center[3] = {135.215, 4.24598, 5.24594};
const float magn_ellipsoid_transform[3][3] = {{0.820361, -0.0188837, 0.0166510}, {-0.0188837, 0.831140, 0.0388830}, {0.0166510, 0.0388830, 0.990194}};

Notice the changes in the Y and Z values of the Ellipsoid Center.

After this, the combined results of Wheels + IMU odometry were much better than wheels-only.

Other things to note:

  • Experiment with positioning the IMU to minimize interference.

  • Verify the ellipsoid center values -- the IMU node prints out the values on startup -- at least twice they were not correct (missing one digit). Not sure why that happened.

  • The instructions say to modify the Arduino firmware with these values. I found that it was sufficient to change the parameters in the launch file (my_razor.yaml) -- no need to modify the firmware.

Edited to add: I had noted above that the ellipsoid_center or ellipsoid_transform values were getting corrupted on the readback from the IMU (after calibration configuration was sent to the IMU). Suspecting that it may be a serial line buffer overflow type of problem I added a few rospy.sleep(1) while writing these values from imu_node.py. Happy to report that that seems to have done the trick. The read-back values are no longer corrupted. Most definitely a hack, and perhaps specific to my particular IMU but it works!

Originally posted by sakumar with karma: 26 on 2016-03-12

This answer was ACCEPTED on the original site

Post score: 0


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.