Closed RFRIEDM-Trimble closed 3 years ago
What’s the suggestion?
Set a timeout on the socket for listening to a response. From what I understand, if a TCP command is issued, we always expect a response. Right now I don't see a timeout being enforced for data to arrive. I'm currently working another small feature in the driver, but can look into a fix for this soon. Let me know if you think a timeout makes sense.
That should probably be targeted to the ouster client library that this simply uses from the ouster_example repo. Overall, I don't think there's a way from the driver to block other attempts at connections.
Ok I can submit my PR there, and then those chances can get pulled in here. Correct, unless the code in the Ouster unit itself changed.
@RFRIEDM-Trimble I
think I am encountering this.
The drivers last log is ;
[ouster_driver-1] [INFO] [1628168637.955023318] [ouster_driver]: Activating Ouster driver node.
and it hangs there. before that, I get these;
[ouster_driver-1] WARNING: No data_format found.
[ouster_driver-1] WARNING: No lidar_origin_to_beam_origin_mm found.
The ouster does not handle simultaneous TCP connections to the same driver well. It queues responses and only serves one connection at a time. If a user accidentally has a TCP connection already open to an ouster, say from doing manual configuration, or running two drivers, the ouster accepts both TCP connection but doesn't respond to any commands in
do_tcp_cmd
to the ROS2 driver.Thus, the driver hangs and doesn't start up the rest of the topics. No warning is given to the user of this condition. The timeout should still apply if the TCP connection is accepted but no data is returned.
To reproduce: Start a netcat session with the ouster and leave that running. Then, start the ROS2 driver.