Open koenlek opened 10 years ago
bit-pirate
commented
10 years ago 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! :smile:
koenlek
commented
10 years ago I might have a look at a PR at some point, but that will likely not be before mid August.
koenlek
commented
10 years ago I found out that it does seem to generate some noise. As on mapping a very large map with GMapping + Gazebo, with the settings as in my first pose, after a large loop, walls do not perfectly align. I guess this means that odometry is just modelled to be very accurate (I heard odometry by the Kobuki base is very accurate in reality), and a bit of noise is generated by libgazebo_ros_kobuki.so (part of http://wiki.ros.org/kobuki_gazebo_plugins). Ideally, it would be nice if the noise could be set to some non-default value (e.g. zero noise for a perfect simulation as a baseline comparison in experiments). In that case it should be configurable here (in the kobuki_controller plugin block): https://github.com/yujinrobot/kobuki/blob/indigo/kobuki_description/urdf/kobuki_gazebo.urdf.xacro
My thesis finishes soon, so I won't have the time to add this, but maybe someone else is interested? At least 'the issue' is well documented now...
stonier
commented
9 years ago I wonder if that noise is being contributed by the 3d sensor plugin.
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 = 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 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.