Describe the bug
When setting cut_angle parameter to 2*Pi, the very first point cloud that is published has more points than expected (it consumes the first UDP packet from the next lidar rotation). The next point cloud counts are correct, but they are shifted by one UDP packet (the point cloud starts with the second UDP packet of the rotation and ends with the first UDP packet from the next lidar rotation).
I have presented this behavior in the video. VLP16 with 0.4 azimuthal resolution is located in the cube. Cube changes its position every 0.5 seconds.
To Reproduce
I am working in simulation, so it may take time to set up the environment. I can provide a PCAP file.
Expected behavior
The driver in the cut at specific angle mode should track the azimuth delta between packets, and check whether the next packets would exceed the value of the cut_angle parameter.
Please complete the following information:
Describe the bug When setting
cut_angleparameter to 2*Pi, the very first point cloud that is published has more points than expected (it consumes the first UDP packet from the next lidar rotation). The next point cloud counts are correct, but they are shifted by one UDP packet (the point cloud starts with the second UDP packet of the rotation and ends with the first UDP packet from the next lidar rotation).I have presented this behavior in the video. VLP16 with 0.4 azimuthal resolution is located in the cube. Cube changes its position every 0.5 seconds.
velodyne_cut_angle_bug.webm
To Reproduce I am working in simulation, so it may take time to set up the environment. I can provide a PCAP file.
Expected behavior The driver in the
cut at specific angle modeshould track the azimuth delta between packets, and check whether the next packets would exceed the value of thecut_angleparameter.