fix: lower packet loss to near-zero levels #178
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Type
Related Links
Description
This PR lowers the chance of packet loss occurring for all supported LiDARs by minimizing the number of mutex locks in the UDP receiver thread.
The UDP receiver thread was losing packets before, mainly because of scheduling:
This is mostly mitigated by moving the
mt_queue
buffer from between the hardware interface and decoder to between the decoder and pointcloud/packets publishers. In other words, the queue is moved from the high-frequency part of Nebula (up to 36kHz for OT128) to the low-frequency part (10Hz or whatever the sensor framerate is set to).The below figure shows the number of points in an unfiltered pointcloud (as a proxy for the number of packets received) for the baseline and fixed ("queue_only") implementations. The sensor tested was OT128 in dual return & high resolution mode.
The benchmarking setup was as follows (every run was repeated 3 times):
ros2 bag record -s mcap --max-cache-size 5000000000 /pandar_points
to cores 8-11ros2 topic echo /pandar_points --field header
taskset to core12 + 2i
for instance iThe plot was generated from the concatenated rosbags.
ℹ️ This PR applies to all Hesai, Velodyne, and Robosense sensors.
⚠️ I am not sure at the moment whether this change would benefit Continental sensors as well (HW monitor and other functions handled in decoder, packet rate unknown to me), so I skipped them for now. @knzo25 have you observed packet loss on Radars so far?
ℹ️ #169 (Aeva Aeries II) already uses a similar approach and should be immune to packet loss
Pre-Review Checklist for the PR Author
PR Author should check the checkboxes below when creating the PR.
Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.
Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.
CI Checks