I am using gazebo , rviz and slam_toolbox for mapping. But the issue is that the obstacles seems to be moving with the robot and the mapping is incorrect and a big delay why? There is only 2 squared obstacles but the mapping feels like the object is moving with it. The odom looks drifted far away.
Hi @jaj , thank you for your post!
Can you please let us know which commands you are running? Also, how are you controlling the robot while you are mapping? Thank you for clarifying!
Usually, we notice drifting when there is high CPU load or slow down in the odom TF publishing.
We noticed from your screenshot that you are running in a simulation on a VM. Do you have hardware acceleration enabled?
Best,
Shehab
Hi @jaj, checking in on this issue. Were you able to find a fix? We would be curious to learn the resolution.
If you are still debugging, sending a full terminal output would be helpful. Additionally, a tool like htop can be helpful to check CPU load/memory usage.
Thanks!
Anna
1 Like
Hi Shehab, thank you for the response.
Here is our setup and the information you asked for:
System setup
-
Raspberry Pi 4 Model B
-
Ubuntu Server 22.04
-
Not running in a VM
Accessing the Pi remotely using VNC Viewer
Gazebo + RViz are running on the Raspberry Pi
1- How we run the system
We launch the Gazebo simulation and robot bringup using:
ros2 launch my_bot launch_sim.launch.py
2- We control the robot manually during mapping using the laptop keyboard with teleop:
ros2 run teleop_twist_keyboard teleop_twist_keyboard \
–ros-args -r cmd_vel:=/diff_drive_controller/cmd_vel_unstamped
3- We launch SLAM Toolbox in online async mapping mode using:
ros2 launch slam_toolbox online_async_launch.py \
slam_params_file:=/home/jaj/dev_ws/src/my_bot/config/mapper_params_online_async.yaml
The SLAM YAML file in use is:
mapper_params_online_async.yaml
located at:
/home/jaj/dev_ws/src/my_bot/config/
Key frames used in the configuration:
map_frame: map
odom_frame: odom
base_frame: base_footprint
scan_topic: /scan
Mapping behavior
The robot is driven manually using keyboard teleoperation while mapping.
We observe that in RViz the map appears to move with the robot, which looks like drifting.
Thank you for your help.
Best regards,
jaj
Hi Anna, thank you for checking in.
We are still debugging the issue and have not fully resolved it yet. The system is running on a Raspberry Pi 4 (Ubuntu Server 22.04), accessed remotely via VNC (not a VM). We are running Gazebo, RViz, and SLAM Toolbox on the Pi while manually driving the robot using keyboard teleoperation.
We will try your suggestion and monitor CPU and memory usage using htop while running SLAM to see if load or timing issues are contributing to the behavior. We’ll also collect relevant terminal output during testing and share an update once we have more information.
Thank you for the helpful advice.
Best regards,
jaj
Hi @jaj ,
Thank you for your reply.
Please refer to the stretch_simulation package for the recommended system requirements for running a Stretch simulation with ROS2 here: stretch_ros2/stretch_simulation at humble · hello-robot/stretch_ros2 · GitHub
The Raspberry Pi 4 might not have the specs for GL rendering of the lidars and cameras (if you’re using the cameras), and might slow down the CPU enough to cause the odom issues that you are experiencing.
Please let us know what you find following @hello-garv’s suggestions for monitoring system resources.
Best wishes,
Shehab
Hi Shehab, thank you for the update.
We followed Anna’s suggestion and monitored system resources with htop while running Gazebo + RViz + slam_toolbox on the Raspberry Pi 4. During mapping, CPU usage becomes very high (all 4 cores ~95–98%) and load average reaches ~9+. The highest CPU processes are ign gazebo gui, ign gazebo server, and rviz2. This seems consistent with your point that the Pi may not have enough resources for GL rendering and simulation, which can lead to TF/odom timing issues and the drifting behavior we see.
3 Likes