-
Notifications
You must be signed in to change notification settings - Fork 16
How to reconnect within a short period of time? #18
Comments
Thanks for your message. We recommend to use the sick_scan_xd driver on https://github.com/SICKAG/sick_scan_xd, which reconnects automatically as soon as possible after network errors. |
@rostest Thanks for the reply. I would like to switch to the sick_scan_xd driver if I have more time, but my team has already implement the previous lib (sick_scan_base) in our codes and it works well except the reconnection time, so I'm wondering if there's a good way to perform a faster reconnection funtionality based on sick_scan_base? That would be really nice :) |
Can you give some more details or screenshots about connection losts, timeouts and the scanner you're using? Is it right that a reconnection is delayed due to waiting for a timeout after network errors? |
Sure. I added some log into sick_scan_base and output it in a file. here is the log content: ================================================================== Tue Feb 22 16:12:29 2022 ================================================================== Tue Feb 22 16:12:29 2022 ================================================================== Tue Feb 22 16:12:41 2022 ================================================================== Tue Feb 22 16:12:48 2022 ================================================================== Tue Feb 22 16:12:49 2022 ================================================================== Tue Feb 22 16:12:56 2022 ================================================================== Tue Feb 22 16:12:58 2022 ================================================================== Tue Feb 22 16:13:05 2022 ================================================================== Tue Feb 22 16:13:06 2022 ================================================================== Tue Feb 22 16:13:07 2022 |
Thanks for profiling! Some lidars require up to 30 seconds to get ready after disconnected standby (time to accelerate the motor, get a stable rotational speed and so on). Which lidar do you use? Can you post the driver messages during startup (i.e. from sick_generic_caller start until connection successfully established)? If the driver is waiting for the lidar to get ready, I'd expect some "waiting for ..." messages. Delays and possibly unnecessary reconnections can be caused by switching Cola-Ascii to Cola-Binary communication, too. In this case, a message "Waiting for timeout... communication mode is changed..." would appear. To avoid delays due to communication mode switching, it's recommended to set binary communication using SOPAS ET and save the scanner settings in its EEPROM. Please attach a log or screenshot of the driver messages during startup for further diagnosis. |
Sorry for this late reply. We're using SickTim561. And I'll paste the log in next chat box. |
new sick laser [Info],2022-03-31 17:35:33.848,24368,Func 'thread_loop': Current time:0 SOPAS - Stopped streaming scan data. [Info],2022-03-31 17:35:36.230,22284,Func 'thread_loop': Current time:2 SOPAS - Error stopping streaming scan data! ROS_INFO: Receiving: ROS_INFO: Sending : <Len=0023>sMN SetAccessMode 0x03 0xf4 0x72 0x47 0x44 CRC:<0xb3> ROS_INFO: Receiving: Error Access Mode ROS_INFO: Receiving: Command or Error message not defined
Current time: ROS_INFO: Receiving: ROS_INFO: Sending : <Len=0023>sMN SetAccessMode 0x03 0xf4 0x72 0x47 0x44 CRC:<0xb3> ROS_INFO: Receiving: Error Access Mode ROS_INFO: Receiving: Command or Error message not defined
Current time:21 ROS_INFO: Receiving: ROS_INFO: Sending : <Len=0023>sMN SetAccessMode 0x03 0xf4 0x72 0x47 0x44 CRC:<0xb3> ROS_INFO: Receiving: Error Access Mode ROS_INFO: Receiving: Command or Error message not defined
Current time:29 [Info],2022-03-31 17:36:07.318,1264,Func 'thread_loop': Current time:33 ROS_INFO: PANIC: Can not open ..\demo\scan.csv_tmp for writing. Check existience of demo dir. or patch code. =====> frame index: 11 grab_time: 1.64872e+12ms time_gap: 56 SOPAS - Stopped streaming scan data. [Info],2022-03-31 17:36:09.698,20788,Func 'thread_loop': Current time:[Info],2022-03-31 17:36:09.907,20788,Func 'set_looping_state' start. SOPAS - Stopped streaming scan data. [Info],2022-03-31 17:36:12.114,16132,Func 'thread_loop': Current time:38 ROS_INFO: PANIC: Can not open ..\demo\scan.csv_tmp for writing. Check existience of demo dir. or patch code. =====> frame index: 6 grab_time: 1.64872e+12ms time_gap: 53 SOPAS - Stopped streaming scan data. [Info],2022-03-31 17:36:14.492,22700,Func 'thread_loop': Current time:40[Info],2022-03-31 17:36:14.703,22700,Func 'set_looping_state' start. =====> frame index: 1 grab_time: 1.64872e+12ms time_gap: 2 |
Thanks for the log messages. The messages show some anomalies:
In case of driver or lidar issues, the driver displays further error messages before restarting. The message "=====> Start to reboot" is not part of sick_scan_base. Could it be possible that a restart is triggered erroneously from an external source? At a first glance, scanner and driver work normally and there is no obvious reason to restart the scanner. Can you check what triggers this "=====> Start to reboot" message?
A change in the SOPAS mode from binary to ascii communication normally happens after the scanner had been restarted. Maybe the scanner restarted due to network problems or a weak power supply?
Independent of this, writing jpg-files is for demonstration only. We recommend replacing this kind of pointcloud handling by a customized function. |
I'm now conducting reconnection by establishing a new connection, which cost me about 30s to wait.
Is there an official API to do this? And is it able to reduce the reconnecting time to less than 10s?
The text was updated successfully, but these errors were encountered: