search

SICKAG / sick_scan_xd

Based on the sick_scan drivers for ROS1, sick_scan_xd merges sick_scan, sick_scan2 and sick_scan_base repositories. The driver supports both Linux (native, ROS1, ROS2) and Windows (native and ROS2).
Apache License 2.0
105 stars 86 forks source link

Driver after version 2.4.2 changes Cola Configuration of the LMS511 sensor permanently #103

Closed Kaju-Bubanja closed 2 years ago

Kaju-Bubanja commented 2 years ago

We are using the LMS511 with an old legacy software and a new software which uses this sick_scan_xd driver with the newest version 2.6.6. Now before when developing we used 2.4.2 and we could use the new software and the old one at the same time and in parallel. But now with the new driver the old software loses the datastream, also after the sick_scan_xd driver was stopped. I tried to find the exact point when this happend, so I checked out 2.4.2, because that was working for sure. I also tried 2.6.4, but there the sensor exhibited the same behaviour. I can't compile 2.4.2, because I would have to use an old ros version and downgrading the whole environment would be a pain. But I looked trough the changes between 2.6.6 and 2.4.2 and saw some things which seem to confirm my theory, that the newer driver versions permanently change some settings on the sensor, which makes the old software unable to receive the data. Namely this code snippet:

// Check Cola-Configuration of the scanner:
// * Send "sRN DeviceState" with configured cola-dialect (Cola-B = useBinaryCmd)
// * If lidar does not answer:
//   * Send "sRN DeviceState" with different cola-dialect (Cola-B = !useBinaryCmd)
//   * If lidar sends a response:
//     * Switch to configured cola-dialect (Cola-B = useBinaryCmd) using "sWN EIHstCola" and restart
if (checkColaTypeAndSwitchToConfigured(useBinaryCmd) != ExitSuccess)
{
  ROS_WARN_STREAM("SickScanCommon::init_scanner(): checkColaDialect failed, restarting.");
  ROS_WARN_STREAM("It is recommended to use the binary communication (Cola-B) by:");
  ROS_WARN_STREAM("1. setting parameter use_binary_protocol true in the launch file, and");
  ROS_WARN_STREAM("2. setting the lidar communication mode with the SOPAS ET software to binary and save this setting in the scanner's EEPROM.");
  return ExitError;
}

am I correct that this is a newish behaviour of the driver? And is there a way to disable this config setting of the driver? Because before it was working fine and I could use the old and the new software at the same time, now only the new software works after running the driver.

rostest commented 2 years ago

Thanks for your feedback. Binary Cola communication (Cola-B) is recommended in general. Therefore sick_scan_xd switches to Cola-B after start.

If possible, please switch to binary cola communication in the legacy software. After that, the old and new driver can use the same protocol (i.e. Cola-B). This way it should be possible to use both versions.

If the legacy software does not support Cola-B, you can switch to Cola-Ascii before exiting sick_scan_xd using the following commands:

rosservice call /sick_lms_5xx/ColaMsg "{request: 'sMN SetAccessMode 3 F4724744'}" # switch to authorized client
rosservice call /sick_lms_5xx/ColaMsg "{request: 'sWN EIHstCola 0'}" # switch to Cola-A
rosnode kill sick_lms_5xx # exit sick_scan_xd

This way the sick_scan_xd driver switches to Cola-A before exiting and the legacy software should run as before. When starting the sick_scan_xd driver again, there will be a short delay due to switching to binary cola communication.

Kaju-Bubanja commented 2 years ago

Perfect, that must be it. I will try that and report back

Kaju-Bubanja commented 2 years ago

I just learned that our legacy software already works with Cola-B mode, so that can't be the problem. Are there other settings which the driver changes? Could you update it to only temporarily change settings, so that when rebooting the sensor it uses the settings which were on it before running the driver? Also I am using ros2 so I couldn't try the command. I tried: ros2 service call /sick_lms_5xx/ColaMsg "{request: 'sMN SetAccessMode 3 F4724744'}" but get The passed service type is invalid

rostest commented 2 years ago

Thanks for the follow up. ROS-2 services require a slightly different syntax with an additional service type parameter, e.g. ros2 service call /sick_lms_5xx/ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sMN SetAccessMode 3 F4724744'}". If the legacy software uses Cola-B communication, switching to Cola-A at sick_scan_xd exit won't help.

We compared the SOPAS start sequence of version 2.6.6 and version 2.4.2 and found 2 differences:

Most likely, the echo filter setting affects the legacy software. The legacy software might expect 1 echo, but receives 5 echos after running sick_scan_xd. Setting <param name="filter_echos" type="int" value="2"/> <!-- FREchoFilter settings: 0: first echo, 1: all echos, 2: last echo --> in the launchfile (sick_lms_5xx.launch) should help. With filter_echos=2, only the last echo is transmitted.

You can query the echo filter setting by ros2 service call /sick_lms_5xx/ColaMsg sick_scan/srv/ColaMsgSrv "{request: 'sRN FREchoFilter'}" and check the number of echos in the pointcloud using rostopic echo /cloud -n 1|grep height -A 1 -B 10. In case of filter_echos= 2 (i.e. last echo), the pointcloud height is 1, e.g.:

header: 
  seq: 7328
  stamp: 
    secs: 1663230243
    nsecs: 609255313
  frame_id: "cloud"
height: 1
width: 1141

With filter_echos=1 (all echos, i.e. 5 echos for the LMS-511), pointcloud height is 5, e.g.:

header: 
  seq: 172
  stamp: 
    secs: 1663230665
    nsecs:  70713996
  frame_id: "cloud"
height: 5
width: 1141

Please configure <param name="filter_echos" type="int" value="2"/> in the launchfile and retry.

Kaju-Bubanja commented 2 years ago

Yes, it was the echo parameter which after the change crashed the legacy software. Thank you for troubleshooting