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
I noticed the pointRange is computed in by float pointDistance which is an expensive operation as it requires computing a square root for each point (and there may be over 2 million points per second with Ouster OS1-128).
But the raw data from the lidar already has the range, so it is not necessary to recompute it again.
I suggest making the PointType a template parameter for pointDistance, and do a template specialization for PointOS1 to use the raw range reading directly without recomputing it.
Likewise the horizon angle is redundantly computed by an expensive call to atan2, which is not necessary, because the raw data from the lidar contains this information already in the raw UDP packets, both for Velodyne and Ouster lidars. Unfortunately using pcl::PointXYZI causes this information to be lost, requiring it to be recomputed. For Ouster lidars specifically, the horizon angle does not change between frames, and the driver always outputs all the points (even points without valid range readings), so it is possible to compute the horizon angle from the index of the point. However, the angle is not stored in PointOS1 so it may be more difficult to get the data from raw lidar data. But then atan2 is much slower than sqrt so it may be worth it.
atan2 typically costs 100 cycles, so high resolution lidars producing 2.6 million points per second (e.g. Ouster OS1-128 in 2048 mode) will be starting to be a significant performance penalty.
The text was updated successfully, but these errors were encountered:
You are right about all the things you mentioned there. This part of the code is simply copied from LeGO-LOAM, which uses a range image for segmentation. I agree that the projection function here can significantly be improved.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I noticed the
pointRange
is computed in byfloat pointDistance
which is an expensive operation as it requires computing a square root for each point (and there may be over 2 million points per second with Ouster OS1-128).But the raw data from the lidar already has the range, so it is not necessary to recompute it again.
The
PointOS1
defined at https://github.com/ouster-lidar/ouster_example/blob/master/ouster_ros/include/ouster_ros/point_os1.h contains a usefulrange
field which contains the raw range reading.I suggest making the
PointType
a template parameter forpointDistance
, and do a template specialization forPointOS1
to use the raw range reading directly without recomputing it.Likewise the horizon angle is redundantly computed by an expensive call to
atan2
, which is not necessary, because the raw data from the lidar contains this information already in the raw UDP packets, both for Velodyne and Ouster lidars. Unfortunately usingpcl::PointXYZI
causes this information to be lost, requiring it to be recomputed. For Ouster lidars specifically, the horizon angle does not change between frames, and the driver always outputs all the points (even points without valid range readings), so it is possible to compute the horizon angle from the index of the point. However, the angle is not stored inPointOS1
so it may be more difficult to get the data from raw lidar data. But thenatan2
is much slower thansqrt
so it may be worth it.atan2
typically costs 100 cycles, so high resolution lidars producing 2.6 million points per second (e.g. Ouster OS1-128 in 2048 mode) will be starting to be a significant performance penalty.The text was updated successfully, but these errors were encountered: