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
95 stars 85 forks source link

Software PLL issues and configuration for LMS4xxx #232

Closed manuelrucci7 closed 8 months ago

manuelrucci7 commented 9 months ago

Problem description

We are using an LMS4xxx and we have set Laser in Software mode (using sopas) to be able to switch on and off the laser according to our need. However, we have notice this warning:

[WARN] [1699952842.940003742] [sick_scan]: 400 of 28578224 packets dropped (0.0 perc.), maxAbsDeltaTime=0.000
[WARN] [1699952842.940072885] [sick_scan]: More packages than expected were dropped!!
Check the network connection.
Check if the system time has been changed in a leap.
If the problems can persist, disable the software PLL with the option sw_pll_only_publish=False  !
[WARN] [1699952907.894838182] [sick_scan]: Timeout during waiting for new datagram

This is our configuration file:

<launch>
    <arg name="hostname" default="192.168.124.103"/>
    <arg name="cloud_topic" default="cloud"/>
    <arg name="frame_id" default="L3"/>
    <node name="sick_lms_4xxx" pkg="sick_scan" type="sick_generic_caller" respawn="false" output="screen" required="true">

        <!-- default values: -->
        <!--
          <param name="scanner_type" type="string" value="sick_tim_5xx" />
          <param name="min_ang" type="double" value="-2.35619449" />
          <param name="max_ang" type="double" value="2.35619449" />
          <param name="intensity" type="bool" value="True" />
          <param name="skip" type="int" value="0" />
          <param name="time_offset" type="double" value="-0.001" />
          <param name="publish_datagram" type="bool" value="False" />
          <param name="subscribe_datagram" type="bool" value="false" />
          <param name="device_number" type="int" value="0" />
          <param name="range_min" type="double" value="0.05" />
        -->
        <param name="scanner_type" type="string" value="sick_lms_4xxx"/>

        <!-- -20 deg Up -->
        <!--<param name="min_ang" type="double" value="-0.34906585"/>-->

        <!-- +35 deg  Buttom -->
        <!--<param name="max_ang" type="double" value="0.34906585"/>-->

        <param name="min_ang" type="double" value="-0.34906585" />
        <param name="max_ang" type="double" value="0.34906585" />

        <param name="use_binary_protocol" type="bool" value="true"/>
        <param name="range_max" type="double" value="3.5"/>
        <param name="range_min" type="double" value="0.3"/>
        <param name="intensity" type="bool" value="True"/>

        <param name="hostname" type="string" value="$(arg hostname)"/>
        <param name="cloud_topic" type="string" value="$(arg cloud_topic)"/>
        <param name="frame_id" type="str" value="$(arg frame_id)"/>
        <param name="port" type="string" value="2112"/>
        <param name="timelimit" type="int" value="5"/>
        <param name="min_intensity" type="double" value="0.0"/> <!-- Set range of LaserScan messages to infinity, if intensity < min_intensity (default: 0) -->
        <param name="sw_pll_only_publish" type="bool" value="true"/>
        <param name="use_generation_timestamp" type="bool" value="true" />

        <param name="start_services" type="bool" value="True" />                  <!-- Start ros service for cola commands, default: true -->
        <param name="message_monitoring_enabled" type="bool" value="True" />      <!-- Enable message monitoring with reconnect+reinit in case of timeouts, default: true -->
        <param name="read_timeout_millisec_default" type="int" value="5000"/>     <!-- 5 sec read timeout in operational mode (measurement mode), default: 5000 milliseconds -->
        <param name="read_timeout_millisec_startup" type="int" value="86400000"/>   <!-- 120 sec read timeout during startup (sensor may be starting up, which can take up to 120 sec.), default: 120000 milliseconds -->
        <param name="read_timeout_millisec_kill_node" type="int" value="250000"/> <!-- 150 sec pointcloud timeout, ros node will be killed if no point cloud published within the last 150 sec., default: 150000 milliseconds -->
        <param name="client_authorization_pw" type="string" value="F4724744"/>    <!-- Default password for client authorization -->

    </node>

</launch>

In this setup, the read_timeout_millisec_kill_node parameter causes the ROS node to restart if no pointcloud is received within 25 seconds. This situation arises when the laser stops. After restarting, the software enters PLL mode and generates a warning. This error does not occur when the laser is in free-running mode.

Questions

  1. Do you think this have an impact on the timestamp generated by the software pll?

  2. There is a way to disable the timeout? (all the timeout, timer_kill_node, timeout_startup and timeout_default?

  3. What is the correct way to use the software pll? How this parameters should be set:

        <param name="sw_pll_only_publish" type="bool" value="true"/>
    <param name="use_generation_timestamp" type="bool" value="true" />

Note

We are using ROS2 humble and this is commit of sick_scan_xd we are using:

sick_scan_xd
commit d3fb67d703866a8e0f22650bbd1178f43bac511e (HEAD -> master, tag: 2.10.2, origin/master, origin/HEAD)
rostest commented 9 months ago

Thanks for your feedback and sorry for the late reply. sick_scan_xd converts the lidar timestamp to the ROS system time using a Software PLL. The difference between the lidar timestamp and the ros timestamp when receiving the scan data is computed and a linear regression between lidar and ros time is continously calculated. See https://github.com/SICKAG/sick_scan_xd/blob/master/doc/software_pll.md for details.

If a TCP packet is delayed due to network traffic, the distance between lidar and ros timestamp can differ from the values calculated so far. In this case, the packet is not used to adjust the Software PLL. If this happens occasionally like 400 of 28578224 packets dropped (0.0 perc.), it will have very little or no impact on the timestamps generated. If this happens often, this indicates too high network traffic and may cause inaccurate timestamps.

The default settings, i.e. both sw_pll_only_publish and use_generation_timestamp set true, are correct and should not be modified unless for special applications.

To disable all timeouts, you can disable message monitoring and set all timeouts to max values: 

<param name="message_monitoring_enabled" type="bool" value="False" />         <!-- Enable message monitoring with reconnect+reinit in case of timeouts, default: true -->
<param name="read_timeout_millisec_default" type="int" value="2147483648"/>   <!-- 5 sec read timeout in operational mode (measurement mode), default: 5000 milliseconds -->
<param name="read_timeout_millisec_startup" type="int" value="2147483648"/>   <!-- 120 sec read timeout during startup (sensor may be starting up, which can take up to 120 sec.), default: 120000 milliseconds -->
<param name="read_timeout_millisec_kill_node" type="int" value="2147483648"/> <!-- 150 sec pointcloud timeout, ros node will be killed if no point cloud published within the last 150 sec., default: 150000 milliseconds -->