ouster_ros output 64channel of points for OS-1-16 lidar???

[HappySamuel]

Hi

I found that the ouster_ros is outputting a lot of points, which is equivalent to 64channel of points (131072 points/scan) even though i am using a OS-1-16 lidar. Which suppose to have maximum 32768 points/scan (in 2048 mode). A lot of them are zeros points, which eventually will consume a lot of spaces when recording the rosbag. Please consider to add some parameters that will allow your consumers to select either 16 channel or 64 channel, so that the ouster_ros is outputting data correctly.

Besides, I suggest to consider to use NAN value instead of Zeros, as there is pcl::removeNaNFromPointCloud in pcl library. Friendly to your consumer.

Best,
Samuel

[PaulKrush]

I second that.
Please don't even send the zeros down the wire(ethernet). This is 75% reduction in network traffic out of the gate. It sure looks like there is room to have a reduced sized packet format as well.
BTW, great units!
Best, Paul

[bromeara]

So a switch for NAN might be nice since it seems to be a standard using PCL but as for the selecting 16 channel or 64 channel that seems like a pain from the implementation standpoint as right now the code works with 64 or 16 and they just came out with a 32 and the code for all of them is the same. It might be worth looking into rosbag record --bz2 or --lz4 or if you arent already just record the lidar_packets and imu_packets topic and then replay the bagfile with the os1 ros nodes running to get the recorded /os1_cloud_node/points topic rather than saving it in the less compact pointcloud2 format.

As far as the networking argument the OS1 requires a 1Gbps using 2048x10 I was getting 11 revolutions a second meaning that the current packets would only be taking up 14.2% of the bandwidth and excluding 75% of the channels would lead to the usage of 3.8% of the bandwidth so thats a 10% network traffic reduction which might be worth it if you were transmitting on a busy network but I have the sensor plugged directly into the computer consuming the UDP messages and the portability of being able to swap between 16/32/64 seems like a worthwhile trade-off.

But if you want to take the zeros out of the /os1_cloud_node/points topic there are many parts of the code you would have to edit but I would start with the batch_to_iter function found (here)[https://github.com/ouster-lidar/ouster_example/blob/master/ouster_client/include/ouster/os1_util.h].

[HappySamuel]

Hi @bromeara

Would you mind to share how to do the modification? Because i have no clue at all.

Best,
Samuel

[PaulKrush]

Taking the traffic off the wire is not something we as customers can do, but we can make that /os1_cloud_node/points topic not 4 times, but 10 times smaller, depending. I am hoping it gets done before I have to do it. It sure would be nice to have smaller bag files.

@HappySamuel bromeara just gave you the starting point, if you are a C++ developer, and are willing to take the time to understand this:
"But if you want to take the zeros out of the /os1_cloud_node/points topic there are many parts of the code you would have to edit but I would start with the batch_to_iter function found (here)[https://github.com/ouster-lidar/ouster_example/blob/master/ouster_client/include/ouster/os1_util.h]:

[HappySamuel]

Hi @PaulKrush

Here's my findout after i upgrade to firmware 1.13 for my ouster lidar OS1-16. There's propeller effect when i use lidar_mode with 2048x10 and 1024x20, while for the 1024x10 and 512x20 have no issue with this.

2048x10 - Propeller effect

1024x20 - Propeller effect

1024x10 - Normal

512x20 - Normal

I have tried to change all my ethernet cable to Cat7, and using gigabit network switch as well. But none of them can ressolve above issue. So i believe the reason of losing udp packet when transmitting the data from ouster lidar is due to the traffic. Which i believe it's only can be settle by ouster.

But i do hope that the number of pointcloud of /os1_cloud_node/points can be reduced at least 4 times smaller via the modification on ouster-ros code.

Here's the code i modify to not only transform the pointcloud to another frame but also eliminates the zeros points in the pointcloud.
filtered_pointcloud_transform.pdf

Here's the result.
2020-02-11-17-38-36.txt

Above is what i did (little tweak on others ppl code), but this create another topic and doesn't help on reducing bagfile size. The data flow become as below:
/os1_cloud_node/points (64 channel points) --> filtered_pointcloud_transform (node) --> /laser_3d/points (16 channel with non-zeros points)

To be honest, i am not good in C++, so i hope you can help on editing the ouster-ros code, which i believe can benefit to ouster community (especially for 16/32 lines users).

Best,
Samuel

[dmitrig]

Improving the data rate for lower-beam count devices is definitely on our radar. The missing data you're seeing is likely due to networking issues. Even if you're using a gigabit switch with the correct cable, you should check that you're negotiating a gigabit link with e.g. ethtool.