You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
I'm using a VLP-32C which has non-column data (each column actually has data at -4.2, -1.4, 1.4, and 4.2 degrees +/- the nominal column azimuth). Additionally, the data is not evenly spaced vertically either.
The vertical data is easy enough to fix (instead of evenly spacing sin/cos in the FillCosSin() based on some step, define the step per vertical row index). But for the column spacing, this is now dependent upon the row that it's in.
An example of where this is used is in the CreateAngleImage in DepthGroundRemover: the code uses the consines and sines vectors per row. I think it assumes even spacing on columns?
What do you think should be the approach for sensors like the VLP-32C, which does not have a column with an exactly same azimuth for every point? I think that #33 is incorrect, since it doesn't handle the uneven vertical spacing or the varying azimuths per column.
The text was updated successfully, but these errors were encountered:
You can use the uneven spacing in the columns by using a sensor config. See how the configs are created. A span can be created from an arbitrary vector or you can use a file with your config.
As for the rows, I see no issue here. When projecting the points provided by the lidar (or reading the angles and range directly) you will just map those to different rows. The image would still be complete.
I have worked in a similar fashion with the sensor in question and have seen no issues with this.
Hello,
I'm using a VLP-32C which has non-column data (each column actually has data at -4.2, -1.4, 1.4, and 4.2 degrees +/- the nominal column azimuth). Additionally, the data is not evenly spaced vertically either.
The vertical data is easy enough to fix (instead of evenly spacing sin/cos in the FillCosSin() based on some step, define the step per vertical row index). But for the column spacing, this is now dependent upon the row that it's in.
An example of where this is used is in the CreateAngleImage in DepthGroundRemover: the code uses the consines and sines vectors per row. I think it assumes even spacing on columns?
What do you think should be the approach for sensors like the VLP-32C, which does not have a column with an exactly same azimuth for every point? I think that #33 is incorrect, since it doesn't handle the uneven vertical spacing or the varying azimuths per column.
The text was updated successfully, but these errors were encountered: