Why is the map underneath flying all over the place. Please look at the video link

edit

some general thoughts:

• I would start by looking at your odometry publisher and make sure the results are reasonable (e.g. if you drive straight for 1m, does the odometry match? If you turn 360deg?). in your video, it looks like your wheels are slipping quite a bit. most odometry nodes have a no-slip assumption.
• consider slowing things down (especially turning rates). this may help avoid wheel slippage, and will result in smaller changes in orientation between localization updates, meaning it will be easier for cartographer to register the scan data with the existing map.
• you may also want to consider some parameter tuning for cartographer.

Hi and thank you Well. this is an area that I am confused about (among other things :)) . Because I do not really have odometry. I am just transforming from the laser . This is probably my issue . I do have a magnetometer / accelerometer from which I can get approximate distance travelled but I have no idea how to addd this to the ROS stack.

the typical use case for cartographer is to have a tf tree that looks something like world -> map -> odom -> robot

by not updating the odom->map transform (typically this is done by reading wheel encoders to make some assumption of how far the robot has moved in x-y-theta), cartographer is presumably trying to understand why the obstacles in the map are moving around despite the robot "not having moved". as a result it is probably deciding that its map was "wrong" and is replacing it with a "new" map. hence the map moving all over the place in rviz.

you could try and implement an odometry publisher using your IMU (presumably a cheap MEMS chip), but uncorrected accelerometer data will probably be about as noisy as not having odometry at all. If you don't have wheel encoders, another approach could be to try and time motor commands and make assumptions on how far you think they have spun. Definitely less accurate than encoders, but less prone to unbounded drift than an IMU. Assuming the magnetometer is far enough away from your motors and other magnetic field interference, it could also be a good way to ground your orientation estimate, which would help cartographer quite a bit

depending on what you want to use your robot for, you could also consider running pure localization instead of SLAM. Define your map in advance, then localize within that map. Because the algorithm doesn't need to "decide" between updating the map and the robot pose, you may have more luck without odometry. AMCL is a popular approach for this: http://wiki.ros.org/amcl

Thank you so much @shonigmann. I have added the imu to the mix and have a topic /imu publishing correctly. I will report back after and see how this changes things. Yes The setup looks quite funny with the magnetometer propped up to keep it out of reach:)

Hello again. My imu experiment was a disaster. The only conclusion at the moment is that the (cheap as you said) device is dead or malfunctioning. I am getting widely varying values from it. But said that, I started getting the odom frame from cartographer and things improved quite a lot. FYI from cartographer.lua:

odom_frame = "odom", provide_odom_frame = true,

Would you have any clue why this would be ?

well, that's my unfamiliarity with cartographer shining through. Per the docs, enabling provide_odom_frame tells cartographer to publish its own (non-loop-closed) odometry estimate using purely the scan data. I couldn't tell you too much about what's going on under the hood (presumably there's a registration algorithm to differentiate between new features and transformed features (due to relative motion). In any case, the result is that you end up with the odometry being published by cartographer which allows it to make much more reasonable assumptions then when it thinks the robot is "sitting perfectly still" (no odom data) and the world is moving around it in crazy ways. I'm anthropomorphizing things a bit but hopefully that makes things a bit clearer.