Bugfix issue #174 #178
Bugfix issue #174 #178
Conversation
|
Has this code been tested on a sensor? If so, which one? And was it tested with strongest, last, and dual-return modes? |
|
The code has been tested on a VLP-16 on strongest return mode. |
| raw_azimuth_diff = raw->blocks[block+1].rotation - raw->blocks[block].rotation; | ||
| azimuth_diff = (float)((36000 + raw_azimuth_diff)%36000); | ||
| // some packets contain an angle overflow where azimuth_diff < 0 | ||
| if(raw_azimuth_diff < 0)//raw->blocks[block+1].rotation - raw->blocks[block].rotation < 0) |
There was a problem hiding this comment.
Could I ask what's the purpose of this part? I don't think there will be an angle overflow here.
@sts-thm @JWhitleyAStuff
There was a problem hiding this comment.
This pull request fixed the issue linked above. Please refer to #174 (comment). If you do still have any questions feel free to ask away.
There was a problem hiding this comment.
Thanks for reply. I understand the change of driver.cc, which you mentioned in the issue. But I couldn’t understand the change of rawdata.cc. It will be nice if you can explain a little, thanks.
There was a problem hiding this comment.
The packages of the velodyne in certain modes specify the azimuth only for every second group of points (16 or 32, depending on the velodyne). The azimuth update for the group of points in between is calculated as half of the difference between the previous group's azimuth and the next group's azimuth. However if the azimuth 0° is inside your package the difference will be the reflex angle (> 180°) and not its complement, which we would need.
There was a problem hiding this comment.
In the case azimuth 0° is inside the packet, let's say the previous group's azimuth is 359°, the next group's azimuth is 1°.
azimuth_diff = (float)((36000 + raw->blocks[block+1].rotation - raw->blocks[block].rotation)%36000); is 2°, which I think is what we need?
This pull request should be able to fix issue #174.