LMS4xxx Enable and Disable laser beam

[visiont3lab]

I was wondering if there is the possibility to enable and disable the (red) laser beam. We would like to only enable it for measuring and then disable it until a new measure will come. Is this possible? We are using ROS2 foxy.

[michael1309]

This feature is currently not supported. But you can try the following way. If this way does not work, we will have to reproduce it here and might try to provide a solution during next month (September 2022).

Stop the laser: ros2 service call /ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sMN LMCstandby'}" Reactivate it: ros2 service call /ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sMN LMCstartmeas'}"

[visiont3lab]

I tried the proposed solution and it does not seem to have any effect. The laser beam is still active and the measurement are given as usual.

This is the service call

In my case I have a namespace /scan3
ros2 service call /scan3/ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sMN LMCstandby'}"

This is the answer:

waiting for service to become available...
requester: making request: sick_scan.srv.ColaMsgSrv_Request(request='sMN LMCstandby')

response: sick_scan.srv.ColaMsgSrv_Response(response='sAN LMCstandby \x00')

I was also checking the [telgram pdf](https://cdn.sick.com/media/docs/7/27/927/technical_information_telegram_listing_ranging_sensors_lms1xx_lms5xx_tim2xx_tim5xx_tim7xx_lms1000_mrs1000_mrs6000_nav310_ld_oem15xx_ld_lrs36xx_lms4000_en_im0045927.pdf) on page 34 and it does not seem to be a problem related to the client authorization. I have also tried to replace **sMN** with **sAN** but in the latter case nothing happen.

I am running the bottom configuration **sick_lms_4xxx_l3.launch** file by using the following command

ros2 run sick_scan sick_generic_caller sick_lms_4xxx_l3.launch --ros-args --remap __ns:=/scan3

<?xml version="1.0"?>

Am I missing something?

[michael1309]

All in all the driver accepts your service call. But I guess we forgot a "0" as an argument (see manual cited)

Please try again with ros2 service call /scan3/ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sMN LMCstandby 0'}"

[visiont3lab]

I have the same result as before.

ros2 service call /scan3/ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sMN LMCstandby 0'}"
requester: making request: sick_scan.srv.ColaMsgSrv_Request(request='sMN LMCstandby 0')

response:
sick_scan.srv.ColaMsgSrv_Response(response='sAN LMCstandby \\x00')

The laser beam and the measurements are still provided and the service call does not seem to have any effect. I am aligned with the master version.

[michael1309]

This would have been the implementation I would have chosen here as well. Shutting down the complete measuring process to switch off the laser is probably not an alternative. I would suggest that you ask SICK support if switching off the laser in measurement mode is possible at all. If this is possible and you provide us with this information, we would be happy to look at it.

[visiont3lab]

I have spoken with the SICK support and we found the issue. On page 19 of the Laser4000 pdf it says that the laser can have different control mode: I was using Free running and in this mode the laser beam cannot be swtiched off. By choosing Software mode we have been able to use the commands

ros2 service call /scan3/ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sMN LMCstartmeas'}"
ros2 service call /scan3/ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sMN LMCstandby'}"

for switching the laser on or off.

[michael1309]

Great news! Thanks for sharing this information. Can we close the ticket by using this method?

[visiont3lab]

Yes we can close it!

[visiont3lab]

Hi, I am testing the procedure and sometimes (1 time out 20) the laser stop working and print the following error message.

[INFO] [1664378353.254454731] [sick_scan]: Sending  : <STX><STX><STX><STX><Len=0014>sMN LMCstandby CRC:<0x65>
[INFO] [1664378353.257858447] [sick_scan]: Receiving: <STX>sAN LMCstandby \x00<ETX>
[INFO] [1664378353.257929150] [sick_scan]: SickScanServices: Request "sMN LMCstandby" successfully sent, received reply "sAN LMCstandby \x00"
[INFO] [1664378353.257944418] [sick_scan]: SickScanServices: request: "sMN LMCstandby"
[INFO] [1664378353.257952333] [sick_scan]: SickScanServices: response: "sAN LMCstandby \x00"
[WARN] [1664378358.257924167] [sick_scan]: Timeout during waiting for new datagram
[ERROR] [1664378358.257996873] [sick_scan]: Read Error when getting datagram: 1
[ERROR] [1664378358.258078115] [sick_scan]: ## ERROR SickScanMonitor::checkState(): read timeout after 5.00023 sec, timeout (5 sec) exceeded.
[ERROR] [1664378358.258095338] [sick_scan]: ## ERROR in sick_scan_xd: restarting scanner after read timeout
[WARN] [1664378358.258108683] [sick_scan]: Disconnecting TCP-Connection.
[ERROR] [1664378358.258188342] [sick_scan]: Tcp::readInputData: Read 0 bytes, connection is lost!

By software I am sending the following messages

# Start
auto laser4xxx_beam_request = std::make_shared<sick_scan::srv::ColaMsgSrv::Request>();
laser4xxx_beam_request->request = "sMN LMCstartmeas";
laser4xxx_beam_srv_->async_send_request(laser4xxx_beam_request);   

# Stop 
auto laser4xxx_beam_request = std::make_shared<sick_scan::srv::ColaMsgSrv::Request>();
laser4xxx_beam_request->request = "sMN LMCstandby";
laser4xxx_beam_srv_->async_send_request(laser4xxx_beam_request);

I am not sure if this error is related to some configuration with the SOPAS. Do you have any idea?

[rostest]

Thanks for reporting. After initialization and switching into measurement mode, sick_scan monitors and checks for lidar datagrams. If the no datagrams are received for 5 seconds, a possible network error is diagnosed. In this case the the TCP connection is closed.

We recommend to stop the driver after sending "sMN LMCstandby" to the lidar. Use rosnode kill sick_scan or killall sick_generic_caller to stop sick_scan. Restart the driver to activate the lidar.

If stopping and restarting the driver is undesirable, you can increase the timeout in the launchfile. Set parameter read_timeout_millisec_default to e.g. 24 hours (24*3600*1000=86400000 milliseconds): <param name="read_timeout_millisec_default" type="int" value="86400000"/>. Monitoring can be disabled by setting <param name="message_monitoring_enabled" type="bool" value="false" />. Since network errors are not detected in this case, it's best to keep message monitoring activated.

[rostest]

Closed due to inactivity. @visiont3lab Please feel free to reopen this issue in case of further questions or problems.

[manuelrucci7]

I am reopening this issue because we are using the laser timestamp provided by the LaserScan Message. The issue is that from the time we start using this time we are experiencing error in receiving the laser data. To be precise after the switch on of the laser beam (sMN LMCstartmeas) the timestamp seems incorrect for a while, then it gets more and more accurate after a few seconds. We can't keep the laser always on, so we have to switch it on and off for each acquisition but we need the provided timestamps to be correct. Do you know if the startmeas or standby commands have same effects on the timestamp?

We are working on master (tag: 2.9.1). The commands that we sent to the laser are

# Start
auto laser4xxx_beam_request = std::make_shared<sick_scan::srv::ColaMsgSrv::Request>();
laser4xxx_beam_request->request = "sMN LMCstartmeas";
laser4xxx_beam_srv_->async_send_request(laser4xxx_beam_request);   

# Stop 
auto laser4xxx_beam_request = std::make_shared<sick_scan::srv::ColaMsgSrv::Request>();
laser4xxx_beam_request->request = "sMN LMCstandby";
laser4xxx_beam_srv_->async_send_request(laser4xxx_beam_request);

[rostest]

I suspect the laser needs some time after measurement start ("sMN LMCstartmeas") to get ready (adjust spinning etc.). You can query the device state using SOPAS command "sRN SCdevicestate". I would expect correct timestamps after switching from state busy to state ready.