How to slow down the process of MultiScan100 drivers to spare some computational power ?

[mmaeg]

Hello,

I am currently developing a SLAM program for navigation using a MultiScan100 Lidar. My program is working correctly, however it has difficulties to do real-time relocalization when the MultiScan100 is moving too fast (because the robot wearing the Lidar is moving). Indeed, sometimes, the program is losing the robot position because the mapping does not update quickly enough.

After an analysis of the problem, it appears that the time taken by the program to transform the scan of the Lidar into a map, and to localize in it was too long for real-time relocalization. To find what causes this too long treatment time, I have compared the current SLAM program with another one, already developed, similar to the current one, except for the Lidar used (in this case a pepperl-fuchs R2000) and the drivers for the Lidar. Accordingly, the other algorithms of the program (ICP, AMCL, and so on) are exactly the same. I precise that the SLAM program with the R2000 is perfectly working for real-time relocalization.

After comparison, I have observed that the problem was very probably coming from the fact that, the drivers for the MultiScan100 are continuously running, treating and publishing the scans of the Lidar, when the drivers of the R2000 are doing a small break between every publishment . Due to that, I think that the drivers of the MultiScan100 are consuming a lot of additional computational power , having the consequences of slowing the other algorithms of the SLAM.

Accordingly, to solve my problem, I would like to know could I bring the MultiScan100 drivers to do a break between every publishment to spare some computational power for the other parts of the SLAM program ? I have already tried to put some "usleep" command in the code (in the files "msgpack_exporter.cpp" and "ros_msgpack_publisher.cpp") to do this, but I have encountered problems doing this, because the program was not working anymore (I don't know why, however).

Thank you in advance for you understanding and your reply.

PS: During the comparison between the MultiScan100 and the R2000 programs, I have checked that the amount of data in the scans of the two Lidars were similar (in the case of the amount of data from MultiScan100 was more important than from R2000). The MultiScan100 publish less data per scan than the R2000 in my application, thus the treatment by the SLAM of one scan from the MultiScan100 should be faster than for the R2000. Moreover, I have used exaclty the same computer to do run the two SLAM programs, to avoid hardware differences.

[rostest]

Thanks for your feedback. The driver receives the scan telegrams from the lidar, converts them and publishes the point clouds using ROS messages or API callbacks. Thus the messages and their timings are triggerd by the scan telegrams. Additional delays in the process chain can result in message drops. If the CPU load is too high for realtime processing, the CPU load must be lowered by profiling and performance optimization, or by skipping some messages. Do you use ROS or the sick_scan_xd API?

Be aware, that multiScan generates segmented scans and point clouds. A fullframe scan (360 degree) consists of multiple segments, which cover a part of the fullframe scan. The driver publishes both the segmented and the (accumulated) fullframe point clouds. Use either segment OR full point cloud messages; for SLAM applications the fullframe point clouds are typically used. If you are using the sick_scan_xd API, the callback registered with SickScanApiRegisterCartesianPointCloudMsg is called with a segment_idx >= 0 for each scan segment, and with segment_idx := -1 for the complete 360 degree full scan. Ignore all messages with segment_idx >= 0 if you are only interested in fullframe point clouds. On ROS, you can subscribe to topic "cloud_unstructured_fullframe" to receive them. See https://github.com/SICKAG/sick_scan_xd/blob/develop/doc/sick_scan_segment_xd.md for further details.

[mmaeg]

Thank you very much for your reply.

I am using ROS1 on Ubuntu 18.04 for my SLAM program.

Currently, in my program, I only select the fullframe point clouds. I do not take any other point cloud published by the drivers. By the way, I have commented the code lines responsible for the publishment of the segmented scans, in order to spare more CPU load. However, it is not enough for my application.

If I have correctly understood the explanation you gave me about the process of the drivers, their timings are triggered by the scan telegrams, thus by the MultiScan100 itself. Accordingly, in theory, if the frequency of scan telegrams decrease, or if we ignore a part of the telegrams, it will slow down the drivers process. Are there parameters to decrease the frequency at which scan telegrams are sent by the Lidar ? Or, is it possible to bring the drivers to ignore a part of the scan telegrams, before processing them ?

Thank you in advance for your understanding and your reply.

[rostest]

Thanks for your feedback. Your understanding is correct. The scan frequency of a multiScan is fixed. Ignoring telegrams or scan data in the driver is currently not supported. Please contact the SICK support for feature requests.

[weinmalSICKAG]

The multiScan offers the interval filter.

The interval filter reduces the scan rate by the configurable reduction factor. If the reduction factor is set to three, for example, the output rate is reduced to one third. In this case only every third scan is output.

[rostest]

Thanks for the hint! We will add the setup to activate and configure the multiScan intervall filter via launchfile.

[mmaeg]

Thank you very much for your reply.

Thanks to your hints, I have been able to spare more CPU load, to optimize the performances of the SLAM program.