Ethernet device throughput limits driver output

ros-drivers / ros2_ouster_drivers

ROS2 Drivers for the Ouster OS-0, OS-1, and OS-2 Lidars

https://ouster.com/

Apache License 2.0

139 stars 79 forks source link

Ethernet device throughput limits driver output #78

Closed MattSYoung closed 3 years ago

MattSYoung commented 3 years ago

As discussed in Issue #74, the depending on what mode (512x10, 1024x10, 2048x10 etc) the Ouster is in, the data rate is different. This can cause problems on systems that have an ethernet connection limited to 100 Mbit/s, as in some higher resolution modes, the packet data from the Ouster can exceed this Mbit/s limit. Specific examples include:

An Ouster OS0-128 in 1024x10 mode will generate ~124 Mbit/s
An Ouster OS0-128 in 2048x10 mode will generate ~248 Mbit/s

When this issue occurs, the output rate of the /points topic will not reach the target 10 or 20 Hz, and (at present) the driver will provide no warning to the user.

I would like to add code to:

[ ] Calculate the expected packet rate, from the given LiDAR mode
[ ] Calculate the actual incoming packet rate
[ ] Compare expected vs actual packet rates and warn the user if the target rate is not being met

MattSYoung commented 3 years ago

I am going to pursue a solution to this internally for a variety of reasons, but I may circle back later and create a PR to push a solution upstream once I have one I'm happy with.

For now though, if anyone else experiences this issue, the best solution is to either use a virtual ethernet device (if replaying pcaps) or try upgrading your hardware if using a real Ouster LiDAR.

SteveMacenski commented 3 years ago

I think this ticket could be safely closed then. I don't think its the role of the ROS wrapper to identify when a user has insufficient networking bandwidth. That's mostly on the system designer or in the Ouster API itself to track and notify of insufficient resources. I don't think that's the right role for here

MattSYoung commented 3 years ago

Fair argument, but it would be nice if the driver at least warned you of the problem. Checking the incoming packet rate against an expected rate based on the mode (1024x10 etc) would be an acceptable way to do that.

SteveMacenski commented 3 years ago

That feels like more of a problem for the Ouster client library than here

MattSYoung commented 3 years ago

Yes, you could certainly make that case. However the Tins driver bypasses all of the client code, because it's using Tins instead or raw_socket. So if I want packet rate debugging with the Tins driver I will likely have to implement the checking inside the OusterDriver or maybe the SensorX objects.