Pose relative to initial pose of the lidar sensor. about direct_lidar_odometry HOT 4 CLOSED

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

from direct_lidar_odometry.

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.

from direct_lidar_odometry.

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.

from direct_lidar_odometry.

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?

from direct_lidar_odometry.