No UDP data output after 1.0.3 ROS2 driver restart

[SICK-YL]

Hello Sirs,

Customer used NANS3 core to do the AGV application,
They found when the IPC restart and ROS2 driver also restart, lidar did not transmitting UDP data and AGV will stop,
And they power cycle the lidar then issue fixed,
Maybe there are operating rules or parameters customer can modify,

Best Regard,
York

[puck-fzi]

Hi York,
can they ping the sensor after the power cycle? Or is it completely not reachable? Is there an error message on startup of the ROS 2 driver in the corresponding console output?

[SICK-YL]

Hi Puck,

They can ping the lidar after IPC power cycle, and they said no error message show up on ROS2 driver,
IPC can't receive lidar UDP data, if they power cycle the lidar than issue fixed.

[puck-fzi]

Okay, could you still provide the console output? Even though there is no error message, it still might help investigate what is happening. Screenshots of the console output would be sufficient.

It sounds like a network issue, with maybe something being blocked. I am not sure if it is on driver side or on laser scanner side though

[SICK-YL]

Hi Puck,

The console output message shown as attachment.
523592088630591497_SiCK_console_log.txt

[puck-fzi]

Dear York,

Thanks for the log; as you stated before, the bootup of the sensor looks right; the sensor's internal configuration and TCP commands seem to be working fine.

In a next step it would be good to see a wireshark log of the UDP data, especially the during the bootup, first the sensor should be sending data to the previous configured address which was configured before bootup. Then, it should be changed to a new address after bootup.

Something you could try is, to directly specify the host_udp_port, if this is set to the same address maybe the driver will receive the data.

Otherwise, the error might be deeper in the network setup; how is the communication setup between IPC and sensor? Are they directly connected?

[tryit084211]

Hi Puck

This is Tom from FARobot, as mentioned in another ticket, I am working with our team and York on this issue and I believe I can provide some detail on this issue to get the situation across

We have already checked out the wireshark data, and as you mentioned, at IPC reboot, first it shows some UDP data from LiDAR (which is from last successful TCP handshake before IPC reboot), and when driver started, the driver initiated another TCP handshake from host port 36104 to LiDAR port 2122, the handshake looks normal but LiDAR never send UDP data to host machine after the TCP handshake after reboot. There is only one warning I saw in wireshark log with warning sequence "Connection reset (RST)". We have already specify host_udp_port as 6060 in the driver when this happens, is this what you you are suggesting?

Also, about the communication setup, the IPC, two NANS3s and a network router are connected to the same network switch, each of them have configured their own static IP. Hope this helps on solving the issue.

Best,
Tom Liu

[puck-fzi]

We have already specify host_udp_port as 6060 in the driver when this happens, is this what you you are suggesting?

Yes, that was what I was suggesting.

I tried to recreate your issue; however, when I restarted my computer, I left the nanoScan3 running and then started the driver again. I get the TCP handshake and then UDP data on a new (the specified) port.

Could you let me know the exact version you are using of the ROS2 driver, base driver, and firmware? Then, I will try to recreate the same setup.

[tryit084211]

I tried to recreate your issue; however, when I restarted my computer, I left the nanoScan3 running and then started the driver again. I get the TCP handshake and then UDP data on a new (the specified) port.

One more detail I missed out to mention, the UDP data stop issue occurs to us after we restart the IPC multiple times (about 130~150 reboot cycle )

Could you let me know the exact version you are using of the ROS2 driver, base driver, and firmware? Then, I will try to recreate the same setup.

• Driver version
  • 1.0.3
• Base driver version
  • 1.0.2
• Firmware version
  • R0 1.93

[puck-fzi]

Thanks for the information; with that many cycle times between the issue occurring, it will be hard for me to recreate the exact same issue. If you have any more clues on anything that maybe does not start properly or any error logs, that might help.

For the setup, I will try to use the same system; that will take a few days since I need to get a different sensor with the correct firmware.