Combine Lidar Segmentation API into getLidarData #2810
Merged
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.
Having separate APIs means that if we want the segmentation data corresponding to the point cloud, it has to be called just after
getLidarData
Even this is not foolproof, and might get mismatched data. Related issue #2409
Combining the 2 APIs seemed to be to a cleaner solution. Also add generic
findSensorByName
function in VehicleApiBaseA simple test-script -
For envs like Neighbourhood, I'm getting 30-40 out of 1000 mismatched entries (which isn't a lot actually)
Note: I haven't added the workaround for empty
segmentation
vecotr similar to what is there forpoint_cloud
inRpcLibAdaptorsBase
since rpclib/rpclib#152 has been fixed. I've opened #2812 for removing the workaround, hopefully they rebase cleanlyWith the removal of the workaround, checking whether the point_cloud is empty using
if not lidarData.point_cloud:
worksEdit: Well, after thinking about it a bit more, it somewhat makes sense that the segmentation API is a different one since this data won't actually be present in real life, therefore
sim
prefix. This problem can also be detected pretty easily, so if we want to keep the APIs separate, the first option could be to close this PR (or just use the last commit)Another could be to create a new Lidar sensor which has the segmentation info as well. This will also lead to the removal of collecting segmentation data in the normal Lidar sensor, which probably will improve performance (but will need to check how much it's affected)
Let me know whatever seems best