Ouster-128, 6 axis IMU on LIO-SAM

[Yuanmou1212]

你好，我查看您这份代码，跟踪imuType将需要quaternion部分的IMU计算都按照相同的方式排除掉了。（基于lio-sam ros2 branch进行的修改）但在我的rosbag里， （ouster-1-128）起点总是飘忽，有时候启动方向错了，就直接带崩图 。 当启动方向正确时，运动不到100米就开始z方向上的移动，导致点云起飞或者钻地。 我的params.yaml的部分信息：

Sensor Settings

sensor: ouster                               # lidar sensor type, either 'velodyne', 'ouster' or 'livox'
N_SCAN: 128                              # number of lidar channels (i.e., Velodyne/Ouster: 16, 32, 64, 128, Livox Horizon: 6)
Horizon_SCAN:  1024                             # lidar horizontal resolution (Velodyne:1800, Ouster:512,1024,2048, Livox Horizon: 4000)
downsampleRate: 1                            # default: 1. Downsample your data if too many
# points. i.e., 16 = 64 / 4, 16 = 16 / 1
lidarMinRange: 1.0                           # default: 1.0, minimum lidar range to be used
lidarMaxRange: 1000.0                        # default: 1000.0, maximum lidar range to be used
imuType: 0   # 0 means 6 axis imu, 1 means 9 axis imu
# for our Ouster OS1-128
extrinsicRot:    [-1.0,  0.0,  0.0,
                   0.0, -1.0,  0.0,
                   0.0,  0.0,  1.0 ]  # OS-1-128, x and y are reversed, z is the same   . R_lidar_imu  rotate imu to lidar
extrinsicRPY: [ -1.0,  0.0,  0.0,
                0.0,  -1.0,  0.0,
                0.0,  0.0,  1.0 ] #if acceleration and attitude have the same coordinate , same as the "extrinsicRot". R_imu_lidar  rotate lidar to imu

这样的报错依次出现 Message Filter dropping message: frame 'laser_data_frame' at time 1121.020 for reason 'discarding message because the queue is full'

[lio_sam_imuPreintegration-3] [ERROR] [1713445968.597919217] [lio_sam_imuPreintegration]: Could not find a connection between 'lidar_link' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees.

[lio_sam_imuPreintegration-3] [ERROR] [1713445970.234711798] [lio_sam_imuPreintegration]: Lookup would require extrapolation into the past. Requested time 1117.569728 but the earliest data is at time 1117.891844, when looking up transform from frame [base_link] to frame [lidar_link]

[rviz2-7] [INFO] [1713445659.368645001] [rviz2]: Message Filter dropping message: frame 'laser_data_frame' at time 1116.920 for reason 'the timestamp on the message is earlier than all the data in the transform cache'

[YJZLuckyBoy]

@Yuanmou1212 你可以尝试使用最新的liorf-ros2分支运行一下建图，看看有没有问题

[Yuanmou1212]

@Yuanmou1212 你可以尝试使用最新的liorf-ros2分支运行一下建图，看看有没有问题

感谢回复。好的，我尽快试一下 刚刚尝试了lio-sam的ros1 版本，同样的params.yaml 设定（ 只有一个根据报错更改的地方 lidarFrame: "lidar_link" 在ROS2, lidarFrame: "base_link" 在ROS1）, ROS1 都可以运行，因此怀疑LIO-SAM的ROS2是不是有BUG没修好。 请问您能大致指出liorf-ros2 修改了什么吗？

[YJZLuckyBoy]

@Yuanmou1212 你可以尝试使用最新的liorf-ros2分支运行一下建图，看看有没有问题

感谢回复。好的，我尽快试一下 刚刚尝试了lio-sam的ros1 版本，同样的params.yaml 设定（ 只有一个根据报错更改的地方 lidarFrame: "lidar_link" 在ROS2, lidarFrame: "base_link" 在ROS1）, ROS1 都可以运行，因此怀疑LIO-SAM的ROS2是不是有BUG没修好。 请问您能大致指出liorf-ros2 修改了什么吗？

lio-sam的ros2版本我没有试过，这个好像是网友维护的，liorf-ros2算法层面上没有做修改，只是把liorf改成了ros2的版本，目前在ros1中提到的几个数据集上测试是没有问题的

[Yuanmou1212]

@Yuanmou1212 你可以尝试使用最新的liorf-ros2分支运行一下建图，看看有没有问题

还得请教一下，我尝试编译liorf-ros2,但遇到cv_bridge 的问题，我的ROS2是humble版本的： 能找到pc中的cv_bridge $ apt show ros-humble-cv-bridge Package: ros-humble-cv-bridge Version: 3.2.1-1jammy.20240217.061328 Priority: optional Section: misc.....

$ dpkg -l | grep ros-humble-cv-bridge ii ros-humble-cv-bridge 3.2.1-1jammy.20240217.061328 amd64 This contains CvBridge, which converts between ROS2 Image messages and OpenCV images.

sudo apt-get install ros-humble-cv-bridge 0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded.

Cmakelists.txt文件没有修改， find_package(cv_bridge REQUIRED)， 已经存在。

opencv也有 $ pkg-config --modversion opencv4 4.5.4

/opt/ros/humble/share 中有cv_bridge 文件， /opt/ros/humble/include 中有cv_bridge.h 重装ros-humble-cv-bridge 也尝试过了，没有解决问题。 请问该代码在您的pc上是否经历过类似问题。

[Yuanmou1212]

@Yuanmou1212 你可以尝试使用最新的liorf-ros2分支运行一下建图，看看有没有问题

还得请教一下，我尝试编译liorf-ros2,但遇到cv_bridge 的问题，我的ROS2是humble版本的： 能找到pc中的cv_bridge $ apt show ros-humble-cv-bridge Package: ros-humble-cv-bridge Version: 3.2.1-1jammy.20240217.061328 Priority: optional Section: misc.....

$ dpkg -l | grep ros-humble-cv-bridge ii ros-humble-cv-bridge 3.2.1-1jammy.20240217.061328 amd64 This contains CvBridge, which converts between ROS2 Image messages and OpenCV images.

sudo apt-get install ros-humble-cv-bridge 0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded.

Cmakelists.txt文件没有修改， find_package(cv_bridge REQUIRED)， 已经存在。

opencv也有 $ pkg-config --modversion opencv4 4.5.4

/opt/ros/humble/share 中有cv_bridge 文件， /opt/ros/humble/include 中有cv_bridge.h 重装ros-humble-cv-bridge 也尝试过了，没有解决问题。 请问该代码在您的pc上是否经历过类似问题。

解决了： cmakelist.txt 中 给set加上cv_bridge set(ros2_lib "rclcpp;rclpy;std_msgs;sensor_msgs;geometry_msgs;nav_msgs;pcl_msgs;pcl_conversions;visualization_msgs;tf2;tf2_ros;tf2_eigen;tf2_sensor_msgs;tf2_geometry_msgs;cv_bridge") #I just add cv_bridge

以及 mapOptimization.cpp 中的Vector(6)， 都写成gtsam::Vector(6)。这是一个gtsam编译时的报错。

编译成功，运行结果很稳定。Ouster-1-128, 内置6轴imu。 在M2DGR 数据集的 street03 结果也很稳定，起步时没有跳变。（测试另一款lio-sam-ros2-humble时有上下跳变）

[CantLooseToAMoose]

@Yuanmou1212 你可以尝试使用最新的liorf-ros2分支运行一下建图，看看有没有问题

还得请教一下，我尝试编译liorf-ros2,但遇到cv_bridge 的问题，我的ROS2是humble版本的： 能找到pc中的cv_bridge $ apt show ros-humble-cv-bridge Package: ros-humble-cv-bridge Version: 3.2.1-1jammy.20240217.061328 Priority: optional Section: misc..... $ dpkg -l | grep ros-humble-cv-bridge ii ros-humble-cv-bridge 3.2.1-1jammy.20240217.061328 amd64 This contains CvBridge, which converts between ROS2 Image messages and OpenCV images. sudo apt-get install ros-humble-cv-bridge 0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded. Cmakelists.txt文件没有修改， find_package(cv_bridge REQUIRED)， 已经存在。 opencv也有 $ pkg-config --modversion opencv4 4.5.4 /opt/ros/humble/share 中有cv_bridge 文件， /opt/ros/humble/include 中有cv_bridge.h 重装ros-humble-cv-bridge 也尝试过了，没有解决问题。 请问该代码在您的pc上是否经历过类似问题。

解决了： cmakelist.txt 中 给set加上cv_bridge set(ros2_lib "rclcpp;rclpy;std_msgs;sensor_msgs;geometry_msgs;nav_msgs;pcl_msgs;pcl_conversions;visualization_msgs;tf2;tf2_ros;tf2_eigen;tf2_sensor_msgs;tf2_geometry_msgs;cv_bridge") #I just add cv_bridge

以及 mapOptimization.cpp 中的Vector(6)， 都写成gtsam::Vector(6)。这是一个gtsam编译时的报错。

编译成功，运行结果很稳定。Ouster-1-128, 内置6轴imu。 在M2DGR 数据集的 street03 结果也很稳定，起步时没有跳变。（测试另一款lio-sam-ros2-humble时有上下跳变）

I have translated your Issue in Google translator, so correct me if I am wrong. But you did get liorf running using only Ouster1-128 and its internal IMU, right? Can you maybe share your config file, when I try it I get serious issues.

[Yuanmou1212]

@Yuanmou1212 你可以尝试使用最新的liorf-ros2分支运行一下建图，看看有没有问题

还得请教一下，我尝试编译liorf-ros2,但遇到cv_bridge 的问题，我的ROS2是humble版本的： 能找到pc中的cv_bridge $ apt show ros-humble-cv-bridge Package: ros-humble-cv-bridge Version: 3.2.1-1jammy.20240217.061328 Priority: optional Section: misc..... $ dpkg -l | grep ros-humble-cv-bridge ii ros-humble-cv-bridge 3.2.1-1jammy.20240217.061328 amd64 This contains CvBridge, which converts between ROS2 Image messages and OpenCV images. sudo apt-get install ros-humble-cv-bridge 0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded. Cmakelists.txt文件没有修改， find_package(cv_bridge REQUIRED)， 已经存在。 opencv也有 $ pkg-config --modversion opencv4 4.5.4 /opt/ros/humble/share 中有cv_bridge 文件， /opt/ros/humble/include 中有cv_bridge.h 重装ros-humble-cv-bridge 也尝试过了，没有解决问题。 请问该代码在您的pc上是否经历过类似问题。

解决了： cmakelist.txt 中 给set加上cv_bridge set(ros2_lib "rclcpp;rclpy;std_msgs;sensor_msgs;geometry_msgs;nav_msgs;pcl_msgs;pcl_conversions;visualization_msgs;tf2;tf2_ros;tf2_eigen;tf2_sensor_msgs;tf2_geometry_msgs;cv_bridge") #I just add cv_bridge 以及 mapOptimization.cpp 中的Vector(6)， 都写成gtsam::Vector(6)。这是一个gtsam编译时的报错。 编译成功，运行结果很稳定。Ouster-1-128, 内置6轴imu。 在M2DGR 数据集的 street03 结果也很稳定，起步时没有跳变。（测试另一款lio-sam-ros2-humble时有上下跳变）

I have translated your Issue in Google translator, so correct me if I am wrong. But you did get liorf running using only Ouster1-128 and its internal IMU, right? Can you maybe share your config file, when I try it I get serious issues.

Yes, I only use Ouster and internal IMU. pls check this. I guess extrinsicRot is the problem in your case. tip: reliability_policy for me has to be "best effort" to work real-time on my ouster lidar. other datasets do not need this.