Closed lidarmansiwon closed 11 months ago
Since the timestamp of ouster is the time since it was started, it is necessary to deal with this on the ouster driver side.
Change the timestamp_mode below. https://github.com/ouster-lidar/ouster-ros/blob/master/launch/sensor.launch#L22-L27
Thank you for your answer. Thanks to you, I timed it equally.But I have a question. Currently, I'm trying to proceed with the slam in real time through the ouster, imu, but it's not working. If you record the data and run it as a bagfile, it will be a slam, but is this package only available as a bag file?
I found new information while I was looking for a way. If you change 5 of the function in the picture below to rclcpp::SensorDataQoS() , the pointcloud callback function turns and exchanges data, but the slam does not proceed. If you do ros2 topic echo /cloud_deskewed as evidence, it proceeds at first, and soon, the value stops without ros time flowing. On the other hand, the bag file has a function of 5 so that slam is achieved. Is there anything you know about this situation?
This package has only been tested with rosbag. (This package was developed as a hobby, and buying sensors for fun is a bit too expensive!)
There were no warnings when you use ros2 topic echo
or outputted the terminal in li_slam_ros2?
Based on what I hear, this might be a problem related to QoS.
https://docs.ros.org/en/humble/Concepts/Intermediate/About-Quality-of-Service-Settings.html
This issue has been inactive for a while and will be closed for housekeeping. If it's still relevant, please feel free to reopen it with a new comment. Thank you for your contribution.
Hello, I am currently trying to run this package. As shown in the picture below, there is a time difference between imu and ouster. So, in the picture below if (imuQueue.empty() || t_f > timeScanCur || t_b < timeScanNext) Problem occurs in conditional statement. Is there a way to correct this? imu time = 1689176983.31 ouster time = 2946.97