SLAM Maps Branch Off

[dean24-up]

ISSUE TEMPLATE ver. 0.4.0

1. Which TurtleBot3 platform do you use?

   • [ X ] Burger
   • [ ] Waffle
   • [ ] Waffle Pi

2. Which ROS is working with TurtleBot3?

   • [ ] ROS 1 Kinetic Kame
   • [ ] ROS 1 Melodic Morenia
   • [ X ] ROS 1 Noetic Ninjemys
   • [ ] ROS 2 Dashing Diademata
   • [ ] ROS 2 Eloquent Elusor
   • [ ] ROS 2 Foxy Fitzroy
   • [ ] etc (Please specify your ROS Version here)

3. Which SBC(Single Board Computer) is working on TurtleBot3?

   • [ ] Intel Joule 570x
   • [ ] Raspberry Pi 3B+
   • [ X ] Raspberry Pi 4
   • [ ] etc (Please specify your SBC here)

4. Which OS you installed on SBC?

   • [ ] Raspbian distributed by ROBOTIS
   • [ ] Ubuntu MATE (16.04/18.04/20.04)
   • [ ] Ubuntu preinstalled server (18.04/20.04)
   • [ X ] etc (ROS Noetic Image distributed by ROBOTIS)

5. Which OS you installed on Remote PC?

   • [ ] Ubuntu 16.04 LTS (Xenial Xerus)
   • [ ] Ubuntu 18.04 LTS (Bionic Beaver)
   • [ X ] Ubuntu 20.04 LTS (Focal Fossa)
   • [ ] Windows 10
   • [ ] MAC OS X (Specify version)
   • [ ] etc (Please specify your OS here)

6. Specify the software and firmware version(Can be found from Bringup messages)

   • Software version: [x.x.x]
   • Firmware version: [x.x.x]

7. Specify the commands or instructions to reproduce the issue.

   • HERE

8. Copy and Paste the error messages on terminal.

   • HERE

9. Please describe the issue in detail.

Issue and Examples We're following the instructions for running SLAM in the emanual here: https://emanual.robotis.com/docs/en/platform/turtlebot3/slam/#run-slam-node

When we try to map with SLAM, the Turtlebot tends to run for a few minutes then stop mapping. SLAM will continue to track the Turtlebot when the map stops updating, but it will drive into unmapped area and no new walls/open space will be mapped. After a minute or so, SLAM usually starts mapping again on its own, but the position of the map will shift (it'll create a new branch of the map).

Here's a few examples: ^ This is a map of a long straight walkway with couches and chairs. The first branch occured 2 min 20 sec into the scan. SLAM stopped mapping at 4 min 20 sec, and resumed at 4 min 50 sec, but with a new branch. It took about 10 min 40 sec for us to scan from one end to the walkway to the other.

^Another map of the same walkway.

Troubleshooting This issue is similar to #430, but we weren't able to fix it using those recommendations. We examined odometry output as we controlled the turtlebot using teleoperation, and the angular velocity reported in the odometry data was very close to what was reported in the teleoperation commands and what we observed with the physical movement of the robot. We also ran the timesync between the remote PC and the Turtlebot3 recommended in #430 and it showed the two were on different timezones, but we weren't sure what the results meant.

We tried to see if we could calibrate the odometry and the gyro using these instructions: http://wiki.ros.org/turtlebot_calibration/Tutorials/Calibrate%20Odometry%20and%20Gyro but we didn't have the necessary packages installed to run it and we're not sure if/how we can get them.

We also ran the first three troubleshooting tests here: https://wiki.ros.org/navigation/Troubleshooting The results are as follows:

1. The laser scans from each previous rotation lined up with the current rotation.
2. The map moved back and forth a fair amount when the Turtlebot was a few feet from the wall, but it stabilized as it got closer. The final map of the wall looked fine, and it didn't move when we backed the Turtlebot away from the wall.
3. This is the scan we took of a hallway:

[ROBOTIS-Will]

Hi @dean24-up

Thank you for reporting the issue. This might have to do with the incorrect odom pose while moving the TurtleBot3 which I found in ROS2 Foxy. Did you upload the OpenCR firmware on the RPi using the opencr_update.tar.bz2 file from the eManual?

FYI, in case of mapping a relatively large area, it is recommended to use the cartographer which creates sub maps and then join them accordingly.

We'll look into this and see if we can find the cause of this issue. Thank you.

[dean24-up]

Hi @ROBOTIS-Will

Thanks for the quick response! Yes, we did use the opencr_update.tar.bz2 file from the eManual.

[ROBOTIS-Will]

@dean24-up

Thanks for the update. We're investigating this issue as there is a similar case during ROS2 simulation.