Ethernet device throughput limits driver output
MattSYoung opened this issue · 5 comments
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
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.
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
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.
That feels like more of a problem for the Ouster client library than here
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.