Gazebo Odometry Error
tadityasrinivas 1 ●4 ●5 ●6 updated 2014-08-13 15:34:58 -0500 I am working with the turtlebot simulator. I have subscribed to the topic /Odometry to read the message on it. I compute the difference between the location in this message and the ground truth location of the robot. I subscribe to the /gazebo/model_states topic to obtain the ground truth location (the "mobile_base" component of the message). This is the plot of the difference (2D euclidean distance) between the Odometry message and ground truth location: (the sample number increases linearly with time, so the x-axis is proportional to simulation time) Are there parameters that can be tweaked to reduce this level of accuracy? The problem is that the odometry seems to be accurate within a few centimeters, which is unrealistic. This limits what we can study using the simulated model. edit retag flag offensive close merge delete Commentsdid you try adding noise ?bvbdort( 2014-08-13 15:50:54 -0500 )editCould you please describe how to?tadityasrinivas( 2014-08-13 16:10:36 -0500 )edit generate gaussian noise with current odometry as mean and variance as you want. Check zero mean gaussion here https://github.com/ros-planning/navig... also for your case take a look at ftp://ftp.taygeta.com/pub/c/boxmuller.c bvbdort( 2014-08-14 03:18:33 -0500 )editadd a comment Be the first one to answer this question! Please start posting anonymously - your entry will be published after you log in or create a new account. Add Answer Question Tools Follow 2 followers subscribe to rss feed Stats Asked: 2014-08-12 12:44:06 -0500 Seen: 594 times Last updated: Aug 13 '14 Related questions amcl_pose vs odom/pose Using Gazebo 5 to simulate a robot, how do I add more noise/drift to the transforms/odometry ? Husky model in Gazebo What is the default behavior of the odometry display in Rviz? ho
Sign in Pricing Blog Support Search GitHub This repository Watch 23 Star 40 Fork 52 yujinrobot/kobuki Code Issues 19 Pull requests 0 Projects 0 Pulse Graphs New issue Gazebo simulates perfect odometry for the kobuki base #328 Open koenlek opened this Issue Jun 11, 2014 · 4 comments Projects None yet Labels None yet Milestone No milestone Assignees No one assigned 3 participants koenlek commented Jun 11, 2014 I found that the odometry information published on the /odom topic by Gazebo provides perfect odometry information. This can be easily verified by setting gmapping to fully rely on odometry. Just set these gmapping parameters (e.g. change them in turtlebot_navigation/launch/includes/gmapping.launch.xml): sigma = 0 linearUpdate http://answers.ros.org/question/189869/how-to-tweak-the-odometry-accuracy-in-gazebo/ = 10000 angularUpdate = 10000 srr =0 srt = 0 str = 0 stt = 0 If you now run e.g. the gmapping_demo.launch from turtlebot_gazebo, you will see that gmapping will map perfectly. Metrically, everything is consistent. rosrun tf tf_echo /map /odom will return a transform of zero between the frames all the time. The main reason why normally gmapping does not return a perfectly metrically consistent map, is because in fact, the correction by the https://github.com/yujinrobot/kobuki/issues/328 laser scan matcher just slightly messes up something that was actually perfect. To my knowlegde, gazebo generates odometry data for /odom based on this plug-in: libgazebo_ros_kobuki.so Although I am not fully sure about that... I can imagine that this is a serious limitation on how realistic the overall simulation is. For the experiments of my msc thesis, I think real world experiments now are a must. N.B. I used the turtlebot packages in this example as I only use kobuki as part of the turtlebot. Probably, some of the kobuki tutorial/example launch files will also allow to easily reproduce this bug. The turtlebot packages are at least not causing the bug, according to my reasoning. Yujin Robot member bit-pirate commented Jun 27, 2014 Good comment. The odometry should contain some error as it would be in real life. I remember parameters being used to specify how bad odometry should be. Not sure though, when anyone here gets around looking deeper into this issue. A PR from your side would be highly appreciated! 😄 koenlek commented Jul 1, 2014 I might have a look at a PR at some point, but that will likely not be before mid August. koenlek commented Sep 2, 2014 I found out that it does seem to generate some noise. As on mapping a very large map with GMapping + Gazebo,
view ♦ ♦ | Report Content as Inappropriate ♦ ♦ Again on odometry error Hi, http://player-stage-gazebo.10965.n7.nabble.com/Again-on-odometry-error-td15860.html I'm actually having the opposite problem of other previous users, that is the odometry error is null, at least for PeopleBot and Pioneer2DX (in Gazebo 5.2), so the position given by "PositionProxy" and "TruthProxy" are basically the same even after moving the robot for several minutes. Different gazebo odometry is the behaviour of the Pioneer2AT instead, which has a realistic error. I wonder, is the odometry error related in some way to the CPU speed, so for some users it's big and for others (like me) null? Is there a way to set up the error "level"? gazebo odometry error Where should I look in case I want to modify the code to fix it? Thanks, Nicola -- ------------------------------------------ Nicola Bellotto University of Essex Department of Computer Science Wivenhoe Park Colchester CO4 3SQ United Kingdom Room: 1N1.2.8 Tel. +44 (0)1206 874094 URL: http://privatewww.essex.ac.uk/~nbello------------------------------------------ ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642_______________________________________________ Playerstage-gazebo mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo Jordi Polo Carrés Reply | Threaded Open this post in threaded view ♦ ♦ | Report Content as Inappropriate ♦ ♦ Re: Again on odometry error Curious enought, the only difference in the odometry code between Pionee2DX and Pioneer2AT is that Pioneer2AT reads the average data of the left wheels instead of one left