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

what to choose between IMU and GYRO

asked 2018-06-18 07:19:08 -0600

kesuke gravatar image

hi ,

i have some troubles with the navigation stack ,i'm working with the wheel encoder and it seems that the odometry is drifting ( when rotating ) so i'm looking to add another sensor like an IMU or GYRO compatible with ros but i'm new in ros and i don't know what to choose so i'm wondering if you have any advices ?

thanks ,

edit retag flag offensive close merge delete


Gyro is part of IMU that read robot angle velocity. So choosing IMU or gyro is even not right question.

achmad_fathoni gravatar image achmad_fathoni  ( 2018-06-18 08:52:37 -0600 )edit

thanks for answering i saw somewhere gyro sensor that's why i'm confused , so which IMU sensor is working fine with ros ?

kesuke gravatar image kesuke  ( 2018-06-18 09:14:01 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2018-06-19 12:30:49 -0600

updated 2018-06-19 12:41:14 -0600

If you're working in a solely planar environment and only looking for yaw, a gyro would be nice, that is all the turtlebot has.

This listing gives you a non-exhaustive list of drivers available as a jump off point.

If you find a hobby IMU from adafruit / similar vendors, chances are there's a simple minimum example for reading values somewhere you can wrap in ROS in 30 minutes, many themselves will have unsupported ROS drivers from other users.

edit flag offensive delete link more


thanks for answering

kesuke gravatar image kesuke  ( 2018-06-20 02:28:16 -0600 )edit

If you think this is the right answer, please click the check so that the topic can be closed

stevemacenski gravatar image stevemacenski  ( 2018-06-20 12:44:53 -0600 )edit

answered 2018-06-19 15:56:02 -0600

updated 2018-06-20 03:34:55 -0600

Anyway, the drift problem is not ROS related... is an universal issue in navigation. If your localization system does not take into account external references and only uses self-motion related measurements (called propioceptive, such as encoders , gyros or IMU), your localization will always drift, sooner or later. So the observation you say that "the wheel odometry is drifting" is not a problem, it is a fact.

That's why ancient sailors were very interested in knowing the stars. Stars were their external references. In robotics, you need some exteroceptive sensors (for instance cameras or lidars) to establish external references and cancel the odometry drift. In the context of ROS navigation, packages such as amcl or gmapping do this job according to different approaches and try to localize within a map, which is used/built as the required external reference.

A practical way to measure how good/bad is your wheel odometry is to drive the robot on a known square of , for instance, 5m side, while keeping all odom poses in rviz, (rviz set Fixed Frame to odom at Global Options). Once the square travel is finished, please take a screenshot of the rviz window, and share it, so we can evaluate how good or bad is your wheel odometry.

edit flag offensive delete link more


thanks for your answer , i'm using a hokuyo laser and i have also a camera (asus xtion pro ) and i used them to build map but i'm sure that wheel enconder are not good ,so do you think that with the laser sensor the amcl can find the position of the robot dispite the odometry is not good ?

kesuke gravatar image kesuke  ( 2018-06-20 02:28:05 -0600 )edit

You should quantify how much "not good" is your odometry, to see if its drift can be or not corrected by acml. I've added a practical way to do that in the answer.

Andreu gravatar image Andreu  ( 2018-06-20 03:32:28 -0600 )edit

Please also describe briefly your platform in terms of main dimensions, number of wheels, size of the wheels ... thanks!

Andreu gravatar image Andreu  ( 2018-06-20 03:40:03 -0600 )edit

thanks for answering , i have a robot with 2 wheel and each wheel has radius 10 cm ,it's like a big version of turtlbot the distance between wheels is 55 cm , it's seems that the odometry is working when moving forward but when the robot rotate in place

kesuke gravatar image kesuke  ( 2018-06-20 04:32:56 -0600 )edit

it's seems that the laserscan don't fall right on top of each other as described on the tutorial navigation tuning so i guess there is a problem whith the odometry and that's why i was looking for another sensor to provide the rotation of the robot , and by the way i used only amcl for

kesuke gravatar image kesuke  ( 2018-06-20 04:35:50 -0600 )edit

the localization , sould i use something like "robot_pose_ekf" package ?

kesuke gravatar image kesuke  ( 2018-06-20 04:39:53 -0600 )edit

I suggest to first hardly debug your wheel odometry, before going to amcl, or to decide to add more hardware in the scene. A good odometry will facilitate a lot other processes like amcl or gmapping. Two-wheel differential platform should provide a good wheel odometry.

Andreu gravatar image Andreu  ( 2018-06-20 04:43:03 -0600 )edit

@Andreu thanks for answering , i found a package named "laser_scan_matcher" it's seems that it gives position without odometry , i'm i wrong ?

kesuke gravatar image kesuke  ( 2018-06-20 04:55:26 -0600 )edit

Question Tools

1 follower


Asked: 2018-06-18 07:19:08 -0600

Seen: 1,149 times

Last updated: Jun 20 '18