ouster-ros
ouster-ros copied to clipboard
ouster-lidar
low latency point cloud
Hi, @kairenw I came across this package by KumarRobotics. It has very low latency (<0.2ms) compared to ouster_example (>3ms). can we incorporate it into this standard driver package
thanks
@shubham-shahh Thanks for pointing the package out, we have made several improvements to the current implementation of ouster_ros that should reduce the latency, these changes are not published yet but will be soon. I will close this ticket once the new improvements have been published.
@shubham-shahh A new release has been published which changes ROS nodes into nodelets. While this reduces latency it does not result in bigger change as it is claimed by the linked package. I did a small investigation and their decoder generates point clouds at a lower latency but with some caveats. So will maintain this ticket open for now and will get back to it ASAP.
@shubham-shahh A new release has been published which changes ROS nodes into nodelets. While this reduces latency it does not result in bigger change as it is claimed by the linked package. I did a small investigation and their decoder generates point clouds at a lower latency but with some caveats. So will maintain this ticket open for now and will get back to it ASAP.
Hi thank you so much for the update, I'll look at the new release, also, can you please name some caveats to be aware of before using the decoder?
Sure, when comparing the point cloud generated by the current ouster ros driver vs what the package in reference generates, the resulting point cloud that they generate is incomplete (missing substantial parts).
Sure, when comparing the point cloud generated by the current ouster ros driver vs what the package in reference generates, the resulting point cloud that they generate is incomplete (missing substantial parts).
Hi, does this have anything to do with, what they have mentioned here
@shubham-shahh I am not sure which part you are referring to in the document. In general I don't know exactly -yet- how their decode strategy would contribute to the missing the points in the point cloud generated by their decoder.
Hi, I'm the author of ouster_decoder. The decoding strategy is simple, just check if there's any jump in the frame and measurement id and erase anything in between.
The missing point cloud is probably due to the difference between legacy vs new format. That has been fixed.
Hi @versatran01, thanks for commenting. I haven't tried to run your package recently so my observation might be outdated. I will give it another try ASAP.
It currently doesn't work due to the catkin_package issue mentioned https://github.com/ouster-lidar/ouster_example/pull/420#issuecomment-1227322532
I made some quick hack to get it work in https://github.com/KumarRobotics/ouster_decoder/tree/fw2.4 but you just need to comment out those broken catkin_package lines in the ouster_ros package.
I guess the main idea (as written in readme) is to update the sensor_msgs/PointCloud2 message with each batch of incoming columns instead of converting the whole PCL pointcloud to the ROS message only after the scan is complete.
Yes, their implementation converts packets as they arrive rather than waiting for the frame to be ready/complete to start the conversion. It makes total sense but we haven't had the capacity to address it yet.
Yes, their implementation converts packets as they arrive rather than waiting for the frame to be ready/complete to start the conversion. It makes total sense but we haven't had the capacity to address it yet.
any possible disadvantage because of this approach?
Yes, their implementation converts packets as they arrive rather than waiting for the frame to be ready/complete to start the conversion. It makes total sense but we haven't had the capacity to address it yet.
any possible disadvantage because of this approach?
Not that I can think of.
The only thing is when I tried their decoder it seemed that their published point cloud was missing certain amount of points when comparing it to the point cloud published by ouster driver. But they have other things in place too. So I can't say the approach itself to blame about missing points.
Yes, their implementation converts packets as they arrive rather than waiting for the frame to be ready/complete to start the conversion. It makes total sense but we haven't had the capacity to address it yet.
any possible disadvantage because of this approach?
Not that I can think of.
The only thing is when I tried their decoder it seemed that their published point cloud was missing certain amount of points when comparing it to the point cloud published by ouster driver. But they have other things in place too. So I can't say the approach itself to blame about missing points.
I just want to note it has been a while since I have tried their code. So they may no longer have the issue about missing points in their current implementation.