The detection results on rviz are very stuck

[504115681]

Thank you for open sourcing this excellent work!
When I use the Velodyne16 lidar data in gazebo to test the algorithm, the detection results on rviz are very stuck, as shown in the video below:

gazebo1.mp4

In addition, the terminal keeps printing (I ignore it for now):

Failed to find match for field 't'.
Failed to find match for field 'reflectivity'.
Failed to find match for field 'ambient'.
Failed to find match for field 'range'.

Some changes are as follows:

1. Modify the lidar hardware parameters in "default.yaml":

sensor_horizontal_resolution: 2048

sensor_vertical_resolution: 64

sensor_vertical_field_of_view_degrees: 33.22222

sensor_horizontal_resolution: 720
sensor_vertical_resolution: 16
sensor_vertical_field_of_view_degrees: 30

2. Modified the lidar topic and tf in "play_doals_data.launch".

 <!-- <remap from="pointcloud" to="/os1_cloud_node/points" />
 <remap from="~pointcloud_corrected" to="/pointcloud" />
 <param name="odom_frame_id" value="map" />
 <param name="lidar_frame_id" value="os1_lidar" /> -->

 <remap from="pointcloud" to="/velodyne_points" />
 <remap from="~pointcloud_corrected" to="/pointcloud" />
 <param name="odom_frame_id" value="odom" />
 <param name="lidar_frame_id" value="velodyne" />

What else do I need to modify? I would be grateful for any help!

[504115681]

The CPU of my computer is i7-10750H, which is about the same performance as AMD-4800U. I downloaded the small_town_simulation sequence in DOASL for testing, but it is still stuck. The results are as follows:

gazebo2.mp4

[504115681]

I downloaded hauptgebaeude_sequence_1 in DOASL for testing. This sequence performed very smoothly without any lag, which is so strange! The video is as follows:

gazebo3.mp4

[Schmluk]

Hi @504115681
Many thanks for your interest! That is very strange, we haven't really had problems being 'stuck'. Few pointers that may hoepfully help you resolve your issues:

• The visualization (including the entire point cloud) is published after a frame is processed, so if no new visualizations appear the system is still processing or waiting to process the next frame.
• Some irregularities can arise if the max integration distance is not set and a very large extent pointcloud is received, as the entire volume will be integrated before moving to the next frame. This can be expensive and take some time (see computation time results for fixed and open max integration range in the paper)
• It could also be related to the tf's not being received, as the system waits for the transform of the pointlcouds to arrive.
• In the past I had issues with ROS subscribers getting slow for long queue sizes, in your videos you can see the small time lag of the published (most recent processed) pose by dynablox and the simulated robot pose, indicating that not all frames are being processed in real-time. However, this lag was usually negligible in our experiments.

W.r.t. Failed to find match for field 't': This is printed by the lidar undistortion, not by dynablox, and is not an issue (unless you need the cloud to have these fields later)

[504115681]

Hi @504115681 Many thanks for your interest! That is very strange, we haven't really had problems being 'stuck'. Few pointers that may hoepfully help you resolve your issues:

• The visualization (including the entire point cloud) is published after a frame is processed, so if no new visualizations appear the system is still processing or waiting to process the next frame.
• Some irregularities can arise if the max integration distance is not set and a very large extent pointcloud is received, as the entire volume will be integrated before moving to the next frame. This can be expensive and take some time (see computation time results for fixed and open max integration range in the paper)
• It could also be related to the tf's not being received, as the system waits for the transform of the pointlcouds to arrive.
• In the past I had issues with ROS subscribers getting slow for long queue sizes, in your videos you can see the small time lag of the published (most recent processed) pose by dynablox and the simulated robot pose, indicating that not all frames are being processed in real-time. However, this lag was usually negligible in our experiments.

W.r.t. Failed to find match for field 't': This is printed by the lidar undistortion, not by dynablox, and is not an issue (unless you need the cloud to have these fields later)

Thank you for your help! Its a problem with TF, everything works fine now!

[JoLichtenfeld]

Hi @504115681 ,
I am experiencing the same issues when running the small_town_simulation sequence. Other DOALS sequences run well.
How did you solve the tf problem?
In my case it seems to be caused by lidar_undistortion with the warning Waited 2.500s, but still could not get the TF from os1_lidar to map.

--EDIT--
The freezing was caused by the lidar_undistortion node. Since the time field of the point clouds in the small_town_simulation.bag is always zero, we don't need undistortion, so I just commented out the node in the play_doals_data.launch (the remapping is required, though). By doing so the bag file can be replayed.

However, the motion_detector throws a lot of warnings of type W0207 17:46:07.966684 519085 motion_detector.cpp:217] Could not get sensor transform, skipping pointcloud: Lookup would require extrapolation 0.009000000s into the future. Requested time 129.410000000 but the latest data is at time 129.401000000, when looking up transform from frame [os1_sensor] to frame [map].
This might be due to the rosbag tf messages being occasionally out of order?
I checked the bag header time stamps for all messages and some are dated earlier then the previous one. But I'm not sure if this an issue when replaying the bag.