search

SICKAG / sick_safetyscanners

ROS driver for SICK safety laser scanners
https://www.sick.com/de/en/opto-electronic-protective-devices/safety-laser-scanners/c/g187225
Apache License 2.0
61 stars 59 forks source link

No sensor data after sensor restart #98

Closed robertwil closed 2 years ago

robertwil commented 2 years ago

Hi, we have the use case that sometimes the Microscan has to be restarted but the ROS driver will keep running. In this case we do not receive any data afterwards. As far as I understood the driver is separated in a Configuration part via TCP when we tell the scanner where to send the data and the continuous data receiving via UDP. I would guess that the scanner "forgets" where to send the data at restart while the driver is continuously waiting for it. Is this so far correct ?

Is there any possibility inside the existing driver to overcome this issue ? E.g. some watchdog+reconnect after data was not received for some time ?

Do you think this can be also "solved" by setting the scanner to continuously output data to a fixed IP in the safety designer ? Or could this lead to issues if there is then also a request with the same IP/Port ?

lenpuc commented 2 years ago

Hi,

yes the sensor will always send to the via safety designer configured addresses after a restart, the ROS driver overwrites these settings and writes a configuration for the session to the driver.

In the existing driver a reconnect is not implemented, and is currently no planned.

The latter would need to be tested, I am not sure if the sockets from the driver and everything in the driver will handle a restarted microscan correctly. There might be issues with diverging package numbering etc.

dbojadzic commented 2 years ago

Hi, I'm having the same issue. Upon restarting the laserscanner the ROS node stays alive but receives no data. If there is any known fix or workaround for this, except manually crashing the ROS nodes, please let me know.

lenpuc commented 2 years ago

Hi, currently there is no feature in place for handling this. So there is no correct workaround provided.

However, if you are in need for this feature maybe you can provide a pull request. I am happy to review them.