Rviz unable to visualize lidar map created by slam_toolbox

[iCaran]

• Operating System:
  • Ubuntu 24.04
• Installation type:
  • via APT
• ROS Version
  • ROS2 Jazzy
• Laser unit:
  • RP Lidar A1M8

I am running Ros2 Jazzy on Ubuntu 24 on a Raspberry Pi 5. I have attached an RPLidar A1M8 to it. I want to use it to create a map of my environment, for that, I'm using the Slam_Toolbox.

But I encounter some errors while trying to visualize the map in Rviz2.

Here's my process:

Terminal 1:

$ ros2 launch rplidar_ros rplidar.launch.py
[INFO] [launch]: All log files can be found below /home/kookaburra/.ros/log/2024-09-22-15-08-45-610837-kookaburra-desktop-5562
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [rplidar_composition-1]: process started with pid [5576]
[INFO] [static_transform_publisher-2]: process started with pid [5577]
[INFO] [static_transform_publisher-3]: process started with pid [5578]
[INFO] [throttle-4]: process started with pid [5579]
[throttle-4] /opt/ros/jazzy/lib/topic_tools/throttle: error while loading shared libraries: libthrottle_node.so: cannot open shared object file: No such file or directory
[ERROR] [throttle-4]: process has died [pid 5579, exit code 127, cmd '/opt/ros/jazzy/lib/topic_tools/throttle messages /scan 1.0 --ros-args -r __node:=throttle_scan'].
[static_transform_publisher-3] [WARN] [1726997926.155586386] []: Old-style arguments are deprecated; see --help for new-style arguments
[static_transform_publisher-2] [WARN] [1726997926.157821367] []: Old-style arguments are deprecated; see --help for new-style arguments
[rplidar_composition-1] [INFO] [1726997926.305743382] [rplidar_composition]: RPLIDAR running on ROS 2 package rplidar_ros. SDK Version: '1.12.0'
[static_transform_publisher-2] [INFO] [1726997926.402724278] [static_transform_publisher]: Spinning until stopped - publishing transform
[static_transform_publisher-2] translation: ('0.000000', '0.000000', '0.000000')
[static_transform_publisher-2] rotation: ('0.000000', '0.000000', '0.000000', '1.000000')
[static_transform_publisher-2] from 'base_footprint' to 'laser'
[static_transform_publisher-3] [INFO] [1726997926.402725130] [static_transform_publisher_odom]: Spinning until stopped - publishing transform
[static_transform_publisher-3] translation: ('0.000000', '0.000000', '0.000000')
[static_transform_publisher-3] rotation: ('0.000000', '0.000000', '0.000000', '1.000000')
[static_transform_publisher-3] from 'odom' to 'base_footprint'
[rplidar_composition-1] [INFO] [1726997928.845191442] [rplidar_composition]: RPLIDAR S/N: 73B3ED95C4E493CAA5E69EF0E2634B6E
[rplidar_composition-1] [INFO] [1726997928.845341371] [rplidar_composition]: Firmware Ver: 1.29
[rplidar_composition-1] [INFO] [1726997928.845373094] [rplidar_composition]: Hardware Rev: 7
[rplidar_composition-1] [INFO] [1726997928.848253258] [rplidar_composition]: RPLidar health status : '0'
[rplidar_composition-1] [INFO] [1726997928.848555599] [rplidar_composition]: Start
[rplidar_composition-1] [INFO] [1726997929.405372516] [rplidar_composition]: current scan mode: Sensitivity, max_distance: 12.0 m, Point number: 7.9K , angle_compensate: 2, flip_x_axis 0

Ignore the libthrottle_node.so warning, I was trying to create a throttled /scan topic with less frequency (i thought of trying to start with 1/sec), so as to try to not overwhelm my Pi5, but even with Ros2 topic_tools properly installed and the libthrottle_node.so in the correct place, for some reason I keep getting this error.
If someone could help me with that it would be great help.

Terminal 2:

ros2 launch slam_toolbox online_sync_launch.py
[INFO] [launch]: All log files can be found below /home/kookaburra/.ros/log/2024-09-22-15-09-10-479666-kookaburra-desktop-6034
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [sync_slam_toolbox_node-1]: process started with pid [6054]
[sync_slam_toolbox_node-1] [INFO] [1726997951.501227834] [slam_toolbox]: Node using stack size 40000000
[sync_slam_toolbox_node-1] [INFO] [1726997951.522998663] [slam_toolbox]: Configuring
[sync_slam_toolbox_node-1] [INFO] [1726997951.581808183] [slam_toolbox]: Using solver plugin solver_plugins::CeresSolver
[sync_slam_toolbox_node-1] [INFO] [1726997951.582326270] [slam_toolbox]: CeresSolver: Using SCHUR_JACOBI preconditioner.
[INFO] [launch.user]: [LifecycleLaunch] Slamtoolbox node is activating.
[sync_slam_toolbox_node-1] [INFO] [1726997951.657294195] [slam_toolbox]: Activating
[sync_slam_toolbox_node-1] Registering sensor: [Custom Described Lidar]

Terminal 3:

$ ros2 run rviz2 rviz2
[INFO] [1726997966.952009172] [rviz2]: Stereo is NOT SUPPORTED
[INFO] [1726997966.952122268] [rviz2]: OpenGl version: 3.1 (GLSL 1.4)
[INFO] [1726997967.015361690] [rviz2]: Stereo is NOT SUPPORTED
[INFO] [1726997976.687578020] [rviz2]: Trying to create a map of size 49 x 57 using 1 swatches
[ERROR] [1726997976.719929643] [rviz2]: rviz/glsl120/indexed_8bit_image.vert
rviz/glsl120/indexed_8bit_image.frag
 GLSL link result : 
active samplers with a different type refer to the same texture image unit

This is the error part, when I open Rviz2, and subscribe to the /map topic, for the first second, a map begins to take shape, and then this error happens and the map stops to update any further. I have checked by scanning the /scan topic after the crash, and it is fine, it's rviz which is having trouble visualizing the map. See the image below:

I have done:

export QT_QPA_PLATFORM=xcb
export LIBGL_ALWAYS_SOFTWARE=1

due to some suggestions I read online while trying to debug this issue, but these don't seem to work. I'm not sure if all of this is important, but here are my slam_toolbox params for the lidar, as i read that maybe decreasing the resolution may help with the issue:

slam_toolbox:
  ros__parameters:

    # Plugin params
    solver_plugin: solver_plugins::CeresSolver
    ceres_linear_solver: SPARSE_NORMAL_CHOLESKY
    ceres_preconditioner: SCHUR_JACOBI
    ceres_trust_strategy: LEVENBERG_MARQUARDT
    ceres_dogleg_type: TRADITIONAL_DOGLEG
    ceres_loss_function: None

    # ROS Parameters
    odom_frame: odom
    map_frame: map
    base_frame: base_footprint
    scan_topic: /scan # /throttled_scan
    use_map_saver: true
    mode: mapping #localization

    # if you'd like to immediately start continuing a map at a given pose
    # or at the dock, but they are mutually exclusive, if pose is given
    # will use pose
    #map_file_name: test_steve
    #map_start_pose: [0.0, 0.0, 0.0]
    #map_start_at_dock: true

    debug_logging: false
    throttle_scans: 1
    transform_publish_period: 0.02 #if 0 never publishes odometry
    map_update_interval: 5.0
    resolution: 0.05
    max_laser_range: 12.0 #for rastering images
    minimum_time_interval: 0.5
    transform_timeout: 0.2
    tf_buffer_duration: 30.
    stack_size_to_use: 40000000 #// program needs a larger stack size to serialize large maps
    enable_interactive_mode: true

    # General Parameters
    use_scan_matching: true
    use_scan_barycenter: true
    minimum_travel_distance: 0.5
    minimum_travel_heading: 0.5
    scan_buffer_size: 10
    scan_buffer_maximum_scan_distance: 10.0
    link_match_minimum_response_fine: 0.1  
    link_scan_maximum_distance: 1.5
    loop_search_maximum_distance: 3.0
    do_loop_closing: true 
    loop_match_minimum_chain_size: 10           
    loop_match_maximum_variance_coarse: 3.0  
    loop_match_minimum_response_coarse: 0.35    
    loop_match_minimum_response_fine: 0.45

    # Correlation Parameters - Correlation Parameters
    correlation_search_space_dimension: 0.5
    correlation_search_space_resolution: 0.01
    correlation_search_space_smear_deviation: 0.1 

    # Correlation Parameters - Loop Closure Parameters
    loop_search_space_dimension: 8.0
    loop_search_space_resolution: 0.05
    loop_search_space_smear_deviation: 0.03

    # Scan Matcher Parameters
    distance_variance_penalty: 0.5      
    angle_variance_penalty: 1.0    

    fine_search_angle_offset: 0.00349     
    coarse_search_angle_offset: 0.349   
    coarse_angle_resolution: 0.0349        
    minimum_angle_penalty: 0.9
    minimum_distance_penalty: 0.5
    use_response_expansion: true

I found a question exactly similar to mine, but it has no responses.
https://stackoverflow.com/questions/77907899/error-while-visualizing-map-from-slam-toolbox-on-rviz

[iCaran]

i dont think it's my pi specific either, i tried

export ROS_DOMAIN_ID=0
export ROS_LOCALHOST_ONLY=0
export ROS_MASTER_URI=http://<pi-ip>:11311
export ROS_HOSTNAME=<laptop-ip>

and then ran rviz on my ubuntu 22, ros humble, i7-gtx1650 laptop. I subscrivbed to /map there and i got the exact same behaviour and result, the same partial map formation and freezing on rviz and the same error on the terminal

[fujitatomoya]

@Yadunund can you assign yourself to this?

[Yadunund]

@iCaran there are a number of things that could cause this so let's try to isolate the problem.

• it would be great if you could provide a minimal reproducible example. ie, write a simple python/cpp script that publishes an occupancy map which when you subscribe to on RViz leads to this error. Please put this in a public Github repo. This will help us debug

  • During this process it would be good to know if this problem happens only on ARM based architectures like the RPi or even x86/AMD64 ones.

• Are you also running RViz on the RPi? What is the display display manager used?

• What RMW implementation were you using? Was the same exported in all three terminals?

i dont think it's my pi specific either, i tried

export ROS_DOMAIN_ID=0
export ROS_LOCALHOST_ONLY=0
export ROS_MASTER_URI=http://<pi-ip>:11311
export ROS_HOSTNAME=<laptop-ip>

and then ran rviz on my ubuntu 22, ros humble, i7-gtx1650 laptop. I subscrivbed to /map there and i got the exact same behaviour and result, the same partial map formation and freezing on rviz and the same error on the terminal

• It's strongly recommended to not mix ROS distros. if you run Jazzy on the Pi, please also run Jazzy on your laptop.
• ROS_MASTER_URI and ROS_HOSTNAME are only used in ROS 1 and have no effect with ROS 2 systems.

[iCaran]

Hi, sorry for the delayed response, but here's an update:

I've created a minimal reproducible example as requested. You can find the code in this repository: https://github.com/iCaran/SimpleRvizMapVisualizationTest. This is a ROS 2 package that publishes a simple occupancy grid, which when visualized in RViz, results in the same error I reported.

Testing Environments

I tested this on two systems:

1. Raspberry Pi 5 running Ubuntu 24 with ROS 2 Jazzy.
2. Laptop running Ubuntu 22 with ROS 2 Humble.

The results were nearly identical on both platforms. However, there was a slight difference in the reported OpenGL version:

• Raspberry Pi 5 error:

  [INFO] [1728230864.027825491] [rviz2]: Stereo is NOT SUPPORTED
  [INFO] [1728230864.027933543] [rviz2]: OpenGl version: 3.1 (GLSL 1.4)
  [INFO] [1728230864.075937684] [rviz2]: Stereo is NOT SUPPORTED
  [ERROR] [1728230881.860686592] [rviz2]: rviz/glsl120/indexed_8bit_image.vert
  rviz/glsl120/indexed_8bit_image.frag GLSL link result: active samplers with a different type refer to the same texture image unit
  

• Laptop error:

  Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
  [INFO] [1728236109.461400971] [rviz2]: Stereo is NOT SUPPORTED
  [INFO] [1728236109.461575845] [rviz2]: OpenGl version: 4.6 (GLSL 4.6)
  [INFO] [1728236109.527414202] [rviz2]: Stereo is NOT SUPPORTED
  [ERROR] [1728236154.682309578] [rviz2]: Vertex Program: rviz/glsl120/indexed_8bit_image.vert Fragment Program: rviz/glsl120/indexed_8bit_image.frag GLSL link result: 
  active samplers with a different type refer to the same texture image unit
  

Answers to Your Questions

1. Are you also running RViz on the RPi? What is the display manager used?

   • Yes, I am running RViz on the Raspberry Pi 5. The display manager is gdm3 with Xwayland and Mutter as the window manager.
   • On my laptop, I'm also using gdm3 with Xwayland.

2. What RMW implementation were you using? Was the same exported in all three terminals?

   • I am using the default Fast DDS (rmw_fastrtps_cpp) on both devices.
   • Yes, the same RMW implementation was used and sourced in all three terminals for both systems.

Let me know if you need any further information or testing. Thanks!

[Yadunund]

@iCaran I haven't had a chance to run your example yet but coincidentally I had to the chance to run slam_toolbox on a RPi 4 running Jazzy. Everything was installed via binaries. I was able to successfully subscribe to the occupancy grid/map on my other PC also running jazzy binaries. All systems running GDM3 as well. Will see if I can get my hands on a Pi 5 to reproduce.

[koa-ellie]

@iCaran did you solve your problem because I'm facing the same problem as yours

[koa-ellie]

No updates on this issue? @Yadunund

[iCaran]

@koa-ellie I haven't been able to solve it yet actually, but for my case, I've begun to think it may not be a big deal, or the real problem so to say. Since im using slam_toolbox, upon later research i found that the problem in my case more likely is that I've incorrectly setup my odometry and slam isnt recieving it well. That's why the map stops forming. So I'm midway trying to fix that, I'll update when I'm done.

Sure the graphics issue remains as is, but I'm trying to get my odom right first, cause I think that, that is the actual issue, not the OpenGL error.
I'll keep this thread updated.

Edit: @koa-ellie could you please confirm if your odom is correctly configired?