| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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 ,
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. http://wiki.ros.org/Sensors
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.
If you think this is the right answer, please click the check so that the topic can be closed
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.
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 ?
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
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.
Asked: 2018-06-18 07:19:08 -0600
Seen: 1,229 times
Last updated: Jun 20 '18
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Gyro is part of IMU that read robot angle velocity. So choosing IMU or gyro is even not right question.
thanks for answering i saw somewhere gyro sensor that's why i'm confused , so which IMU sensor is working fine with ros ?