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

Problem with slam_toolbox / Map and Laserscan do not align

asked 2021-10-25 13:55:38 -0500

Mirko Sertic gravatar image

updated 2021-10-26 09:19:16 -0500

lucasw gravatar image

Hi there!

I am running ROS Melodic on an Raspberry PI 1 Type B to pimp my dusty Roomba 5xx. Writing the driver and using the Roomba Open Interface was the easy part. I also mounted a YDLiDAR X4 on the Roomba, which also works quite well in my stack. However, there are some problems where I need some hints about how to further debug what is going on while using slam_toolbox.

I took the slam_toolbox online_sync configuration as a baseline, and did some tests to generate a map while driving the robot around. Visualization with RViz shows some strange effects. The laserscan does not align with the map, and it also takes some seconds to get a new odom->map transform, and sometimes the transform seems to be skewed. See the attached screenshot, the red arrow is the current position and odometry, red dots are the laserscan, and the map from slam_toolbox is the background.

image description

I also observed a correlation between map updates and odom publication intervalls. Publishing odometry with 10 hertzs leeds to better results than publishing with 20 herzt, which is from my point of view counter-intuitive. In both cases I observed smaller or larger skews as seen in the RViz screenshot.

I really don't know whats going on here, so I am really thankful for all kinds of help. Things I have already checked:

  • Odometry seems to be ok. It has a larger drift while rotating the robot on the spot, but as far as I have observed there are no huge jumps, it seems to be continous. I also use the Roomba wheel encoders to calculate position and rotation, as the build-in odometry seems to be inacurate.
  • I tested the robot in different rooms. It definitely works better in edgy, feature-rich rooms without small obstacles, so sensor noise might be an issue here.
  • The Raspbery Pi is outdated, but CPU and RAM are not maxed out. The first version of the driver was written in Python, which worked, but was very CPU intense. The current version is written in CPP, which works better, and I can run my driver, the ydlaser driver and the slam_toolbox note on the Pi without running into cpu or memory problems. I do not plan to generate maps for large environments, as this might be too much to this little SoC.
  • There are no errors in the log file. However, if I increase the odom publish interval further, I am getting some transform timeout errors, and in extreme cases errors regarding the scan_buffer maxed out.
  • There must be a bug in my driver or assumptions(likely) or configuration(maybe), but I really want to understand the situation causing this skew to know how and where to fix it.

Thank you all for your time, and please let me know if you have hints or suggestions to point me in the right direction.

Mirko

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-03-29 04:37:54 -0500

Mirko Sertic gravatar image

After some testing, I'd like to share my insights with the community.

It seemed odometry was buggy. In fact, calculated velocities where buggy. Exporting the odometry over time and visualising it gives showed me some errors (Sorry, I can't attach a screenshot yet).

Right after a direction change issued by a cmd_vel command velocities were calculated wrong, resulting in some odd spikes for a very short period of time. After a few ms, everything normalized again.

So just as a note to me and maybe others: plotting your data really helps to get a clue what want wrong.

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2021-10-25 13:49:29 -0500

Seen: 669 times

Last updated: Mar 29 '22