Running lego_loam_bag with Livox Mid-360 crashes with exit code -11

[shimuajie]

Dear Author,

It's my great honor to use your open-source navigation framework!

After recording a point cloud bag with the Livox Mid-360 lidar, I attempted to build a map by running:
ros2 launch lego_loam_bor lego_loam_bag_mid360.launch

No matter how I adjust the parameters, the process consistently crashes with the following error:
[ERROR] [lego_loam_bag-1]: process has died [pid 42516, exit code -11, cmd '/root/dddmr_navigation/install/lego_loam_bor/lib/lego_loam_bor/lego_loam_bag --ros-args --params-file /root/dddmr_navigation/install/lego_loam_bor/share/lego_loam_bor/config/loam_bag_mid360_config.yaml'].

I have also tried using point cloud bags from GitHub (official/test bags), but the same error persists.

Could you please provide some guidance or suggestions to resolve this issue?

Thank you very much for your time and help!

Here are my parameter settings.

bag_reader:
ros__parameters:
use_sim_time: true
bag_file_dir: "/root/bag8"
point_cloud_topic: "/livox/lidar"
odometry_topic: "/odom"
skip_frame: 2

lego_loam_ip:
ros__parameters:
use_sim_time: true
# leishen16
laser:
odom_type: "laser_odometry" #wheel_odometry/laser_odometry
baselink_frame: "base_link"
num_vertical_scans: 32
num_horizontal_scans: 1000
vertical_angle_bottom: -7.0 # degrees
vertical_angle_top: 52.0 # degrees
scan_period: 0.1 # seconds

imageProjection:
    segment_valid_point_num: 5
    segment_valid_line_num: 2
    segment_theta: 60.0                      # decrese this value may improve accuracy
    minimum_detection_range: 0.5
    maximum_detection_range: 100.0            # point cloud within this range will be used to project image
    distance_for_patch_between_rings: 1.0    # patch ground between rings within this range, i.e. ring0 and ring1 is smaller than 1 meter, patch them
    stitcher_num: 3                          # for non-repetitive scan lidar use 2~4 (i.e. mid360)
    trt_model_path: ""                       # provide trt engine for yolo
    projected_image_stack_size: 1            # Stack this number of image for yolo11n to inference as time elapsed yolo (only work when TRT is loaded)
    
    ground_fov_bottom: -0.2617994 # -15deg
    ground_fov_top: -0.087266 # -5deg
    ground_positive_start: 0.0
    ground_positive_stop: 3.1415926
    ground_negative_start: 0.0
    ground_negative_stop: -3.1415926

lego_loam_fa:
ros__parameters:
use_sim_time: true
featureAssociation:
edge_threshold: 0.1
surf_threshold: 0.1
nearest_feature_search_distance: 3.0

mapping:
    to_map_optimization: true

lego_loam_mo:
ros__parameters:
use_sim_time: true
mapping:

    distance_between_key_frame: 1.0
    angle_between_key_frame: 1.0

    enable_loop_closure: true

    surrounding_keyframe_search_num: 20
    history_keyframe_search_radius: 12.0
    history_keyframe_search_num: 5
    history_keyframe_fitness_score: 0.5
    
    ground_voxel_size: 0.3
    ground_edge_threshold_num: 50

bag8.zip

[shimuajie]

In addition, I also have a Leishen C16 lidar, and it can run mapping normally with this lidar.

[tsengapola]

issue48.mp4

Check this out:

<launch>

  <!--name argument is not required, because it will overwrite all node name in the exec-->
  <node pkg="lego_loam_bor" exec="lego_loam_bag" output="screen" respawn="false">
    <param from="$(find-pkg-share lego_loam_bor)/config/loam_bag_mid360_config.yaml" />
  </node>

  <node pkg="rviz2" exec="rviz2" output="screen" respawn="false" args="-d $(find-pkg-share lego_loam_bor)/rviz/lego_loam.rviz">
  </node>

  <!--- TF -->

  <node pkg="tf2_ros" exec="static_transform_publisher" name="sensor2baselink"  args="0.3 0 0.38 0.0 0.0 0 base_link livox_frame" />

</launch>

Config:

bag_reader:
  ros__parameters:
    use_sim_time: true
    bag_file_dir: "/root/dddmr_bags/bag8"
    point_cloud_topic: "/livox/lidar"
    odometry_topic: "/odom"
    skip_frame: 2

lego_loam_ip:
  ros__parameters:
    use_sim_time: true
    # leishen16
    laser:
        odom_type: "laser_odometry"         #wheel_odometry/laser_odometry 
        baselink_frame: "base_link"
        num_vertical_scans: 32
        num_horizontal_scans: 1000
        vertical_angle_bottom: -7.0          # degrees
        vertical_angle_top: 52.0            # degrees
        scan_period: 0.1                   # seconds

    imageProjection:
        segment_valid_point_num: 5
        segment_valid_line_num: 2
        segment_theta: 60.0                      # decrese this value may improve accuracy
        minimum_detection_range: 0.5
        maximum_detection_range: 100.0            # point cloud within this range will be used to project image
        distance_for_patch_between_rings: 1.0    # patch ground between rings within this range, i.e. ring0 and ring1 is smaller than 1 meter, patch them
        stitcher_num: 3                          # for non-repetitive scan lidar use 2~4 (i.e. mid360)
        trt_model_path: ""                       # provide trt engine for yolo
        projected_image_stack_size: 1            # Stack this number of image for yolo11n to inference as time elapsed yolo (only work when TRT is loaded)
        
        ground_fov_bottom: -0.2617994 # -15deg
        ground_fov_top: -0.087266 # -5deg
        ground_positive_start: 0.0
        ground_positive_stop: 3.1415926
        ground_negative_start: 0.0
        ground_negative_stop: -3.1415926

lego_loam_fa:
  ros__parameters:
    use_sim_time: true
    featureAssociation:                              
        edge_threshold: 0.1
        surf_threshold: 0.1
        nearest_feature_search_distance: 3.0

    mapping:
        to_map_optimization: true

lego_loam_mo:
  ros__parameters:
    use_sim_time: true
    mapping:

        distance_between_key_frame: 1.0
        angle_between_key_frame: 1.0

        enable_loop_closure: true

        surrounding_keyframe_search_num: 20
        history_keyframe_search_radius: 12.0
        history_keyframe_search_num: 5
        history_keyframe_fitness_score: 0.5
        
        ground_voxel_size: 0.3
        ground_edge_threshold_num: 50

Do you use our docker image?

[shimuajie]

Yes, I am using your Docker image. I have completely copied your launch file and YAML configuration file verbatim, but still cannot build the map. When I run the program with GDB, it shows the following error:

Thread 1 "lego_loam_bag" received signal SIGSEGV, Segmentation fault.
0x00007ffff7e5b4b8 in ImageProjection::zPitchRollFeatureRemoval() () from /root/dddmr_navigation/install/lego_loam_bor/lib/libimage_projection.so

(gdb) bt
#0 0x00007ffff7e5b4b8 in ImageProjection::zPitchRollFeatureRemoval() ()
from /root/dddmr_navigation/install/lego_loam_bor/lib/libimage_projection.so
#1 0x00007ffff7e6a0cd in ImageProjection::cloudHandler(std::shared_ptr<sensor_msgs::msg::PointCloud2_<std::allocator > >) () from /root/dddmr_navigation/install/lego_loam_bor/lib/libimage_projection.so
#2 0x000

[tsengapola]

Do you mind provide a bag file that can reproduce the issue? I use bag8.zip but everything works fine.
And also, please build by RelWithDebInfo to provide more crash info.

[shimuajie]

Hi, I compiled with RelWithDebInfo mode and got the detailed crash log as follows:

Thread 1 "lego_loam_bag" received signal SIGSEGV, Segmentation fault.
0x00007ffff7e54e70 in ImageProjection::zPitchRollFeatureRemoval (this=0x555555baf7a0) at /usr/include/c++/11/bits/stl_vector.h:1043
1043 operator[](size_type __n) GLIBCXX_NOEXCEPT
(gdb) bt
#0 0x00007ffff7e54e70 in ImageProjection::zPitchRollFeatureRemoval (this=0x555555baf7a0)
at /usr/include/c++/11/bits/stl_vector.h:1043
#1 0x00007ffff7e633c4 in ImageProjection::cloudHandler (this=this@entry=0x555555baf7a0,
laserCloudMsg=std::shared_ptr<sensor_msgs::msg::PointCloud2<std::allocator >> (use count 2, weak count 0) = {...}) at /root/dddmr_navigation/src/dddmr_lego_loam/lego_loam_bor/src/imageProjection.cpp:390
#2 0x00005555555b8903 in main (argc=, argv=)
at /root/dddmr_navigation/src/dddmr_lego_loam/lego_loam_bor/src/lego_loam_bag_node.cpp:204

This is another larger bag file of mine, and I still cannot get it to work (the program crashes with the same segmentation fault as before).
https://pan.quark.cn/s/e59dd54665f4

[tsengapola]

OK, let's follow my step:

docker pull tsengapola/dddmr:issue48

Then run:

#!/bin/bash

xhost +local:docker

docker run -it \
    --privileged \
    --network=host \
    --env="DISPLAY" \
    --env="QT_X11_NO_MITSHM=1" \
    --volume="/tmp:/tmp" \
    --volume="/dev:/dev" \
    --name="dddmr_issue48" \
    tsengapola/dddmr:issue48

In the container, run:

cd dddmr_navigation
source install/setup.bash
ros2 launch lego_loam_bor lego_loam_bag_mid360.launch

Then click resume.

[shimuajie]

Thank you for your help. I have successfully built the map. Wish you all the best.

[shimuajie]

Hello, why not use the odometry output by LeGO-LOAM for navigation, instead of using external odometry?

[tsengapola]

In theory, yes, it can be used for navigation.

Below are our experience:

When the robot meet the no feature environment such as wall or bushes on both sides, lidar odometry will get virtual slip (lidar think, it is not moving). Therefore, leverage different sources for navigation can make a robust integration. Especially, for ground robot, the wheel odometry is easily accessed.

In addition, the local planner is based on MPC, it relies on stable state estimation (linear and angular speed), it might jitter when features are occluded/highly dynamic when using lidar odometry.

[shimuajie]

Hello, I am using a Thunder C16 radar for mapping. No matter how I adjust the parameters, I still find that the Z-axis drift is very severe, and the ground appears layered and extremely chaotic. I have called the Go2 odometry, but it does not seem to help at all. Could you please teach me how to fix this?

https://pan.quark.cn/s/8d3e0c1afa99

[shimuajie]

[shimuajie]

Everything works fine for navigation except that the mapping is quite messy. I plan to integrate FastLIVO2 for mapping later and add RGB color information to the point cloud. But right now I'm really curious about where the problem actually lies.

[tsengapola]

I think the loop is not closed, creating two ground layer. Try to increase history_keyframe_fitness_score to say 2.0.
Also, when doing the mapping, please check the pose_graph topic to see if the loop closure get detected and triggered.