I am trying to read in data from a lidar throughrange_sensor interface, change to Velodyne format and then publish to ROS.
When reading in the data for a lidar set to 10Hz, the data consists of only 120 degrees rather than 360. While it is possible to fix this issue by setting frequency to -1, this would impact the accuracy of simulated lidar scan (no shift due to time)?
Is there a way to publish all 360 degrees from recent observations, or is a custom buffer of some sort required… Thanks!
Correct, you would need to use a custom buffer to collect a full 360 scan based on the elapsed time.
The API only provides the data from the current frame.
Data from the current frame - does this imply that the lidar data is only collected on each render frame? Eg. is the 120 degrees of scan received from the API exactly the same timestamp, or is there an internal implementation that calculates the slight offset in collection time for each scan based on rotation rate?
If there isn’t, would it be possible to manually access range / lidar information calculated on a physics time step. I am trying to timestamp each individual point cloud point in a ROS message, which seems like a common use case. To have only several separate scans on render frames for a full rotation would lead to significant accumulated error in the data points wrt. time for a moving object.
Lidar is collected per PhysX step, at a single timestamp, The slight offsets for the scan that occur during a step are currently not taken into account.
The amount of data (number of rays) returned is based on the rotation rate of the lidar as well as the framerate of the simulation. If the rate is faster and the framerate slower, the scan should be larger. All of the rays computed during that physics step for the scan would have the same effective timestamp.
We are working on exposing more apis for RTX lidar (And possibly the PhysX range sensor lidar) that will provide per ray timestamp information. But currently its not computed for the range sensor extension