Pose relative to initial pose of the lidar sensor.

[JereKnuutinen]

Thank you for this amazing work and for making it open-source! I am new in ROS and I have a question regarding how to get the pose at each frame relative to the initial pose of the lidar sensor, (initial pose 4x4 I)? Is /robot/dlo/odom_node/pose topic relative to what? Also when I test with my own bag that contains 363 pointcloud frames, I only get 359 poses when using rostopic echo /robot/dlo/odom_node/pose. Is this intentional?

[kennyjchen]

Hi @JereKnuutinen -- thanks for the interest in our work! Yes, the topic /robot/dlo/odom_node/pose is the LiDAR sensor's pose relative to its initial position.

There may be a few reasons why you aren't seeing the same number of poses as are point cloud frames. If you are using our start-up procedure via an IMU, the first X seconds of data (default 3) is discarded until gravity and biases are calibrated for. Another reason may be that some frame are being processed too slowly for some reason (long GICP optimization time, slow processor, etc), and since the subscriber only has a queue size of 1, if the processing time exceeds the LiDAR frame rate, the next frame would be dropped. If this is the case, you can try increasing the queue size (at the risk of not providing the system with the most up-to-date sensor data), decreasing playback speed, or finding ways to increase processing speed (i.e., increase voxelization). Let me know if that helps.

[JereKnuutinen]

Thanks for your fast reply. It seems that the reason is that at the beginning the first three frames are not processed indeed. If I use rostopic echo /robot/dlo/odom_node/pose/header, I get the following output:

`seq: 0 stamp: secs: 1681908846 nsecs: 135304192 frame_id: "robot/odom"

seq: 1 stamp: secs: 1681908846 nsecs: 234621440 frame_id: "robot/odom"

seq: 2 stamp: secs: 1681908846 nsecs: 335826688 frame_id: "robot/odom"

seq: 3 stamp: secs: 1681908846 nsecs: 435209984 frame_id: "robot/odom"

seq: 4 stamp: secs: 1681908846 nsecs: 534959104 frame_id: "robot/odom"`

and if I echo my lidar data I get:

`rostopic echo /synced_pc_lidar_2/header seq: 0 stamp: secs: 1681908845 nsecs: 835490048 frame_id: "velodyne1"

seq: 0 stamp: secs: 1681908845 nsecs: 935071488 frame_id: "velodyne1"

seq: 0 stamp: secs: 1681908846 nsecs: 35755776 frame_id: "velodyne1"

seq: 0 stamp: secs: 1681908846 nsecs: 135304192 frame_id: "velodyne1"

seq: 0 stamp: secs: 1681908846 nsecs: 234621440 frame_id: "velodyne1"

seq: 0 stamp: secs: 1681908846 nsecs: 335826688 frame_id: "velodyne1"

seq: 0 stamp: secs: 1681908846 nsecs: 435209984 frame_id: "velodyne1"

seq: 0 stamp: secs: 1681908846 nsecs: 534959104 frame_id: "velodyne1"`

As we can see that the after three first lidar frames timestamps start to match. . However, in my dlo.yaml file I have put imu and gravity Align to false like this:

dlo:

version: 1.4.3

adaptiveParams: true

imu: false gravityAlign: false

odomNode: odom_frame: odom child_frame: base_link

mapNode: publishFullMap: true publishFreq: 1.0 leafSize: 0.25

So I have no idea why this is happening. I also played my bag with rate=0.1 so my system should be cable of handling the incoming messages.

[kennyjchen]

Ah, so the first frame will return since it's checking if the system has initialized, and then the second frame will be the first target frame and will return after setting it as so (since you can't align using just one frame).

Besides the first two frames though, I'm not seeing any other dropped frames on my test data. Perhaps it could be a system-specific or data-specific issue?

[JereKnuutinen]

Yes, there might be some issues with the data since I convert ros2bag to rosbag. Thanks for your help!