0
$\begingroup$

Rosanswers logo

I'm experiencing an issue where if the robot drives too close (unknown distance) to a static or dynamic obstacle then the laser scanners will not properly detect the obstacle, and thereby no lethal pixels will be inserted into the local costmap. When the robot enters this distance, then any previous locations of said obstacle will be deleted from the local costmap, and this will inevitably result in collision, as the robot cannot detect the obstacle. The behaviour is similar to dead zones of a camera. Visualisation is done in RViz.

The mobile platform is equipped with two SICK S300 laser scanners, placed in diagonal corners, to provide 360° coverage. To use and unify the two laser scanners the following two packages are use: cob_sick_s300 and cob_scan_unifier Documentation

Currently I'm running Melodic (Ubuntu 18.04), but I've also tested this on Kinetic (Ubuntu 16.04) with the same issue.

Picture of the issue can be seen below. The two small green semicircles just above the robot is a dynamic actor provided by Gazebo, and these are seen by teb_markers from the teb_local_planner (which I assume is also based on laser scan data).

image description

EDIT (to go with the solution explained below):

What I initially did was to create a unify_scans.yaml and unify_scans.launch to unify the data into one topic. These files look like the following:

unify_scans.yaml

loop_rate: 20.0
input_scans: ['laser_front/scan','laser_back/scan']

unify_scans.launch

<?xml version="1.0"?>
<launch>
  <!-- Arguments -->
  <arg name="name" default="laser_unified" />
  <!-- <arg name="scan_1" default="/laser_front/scan" /> -->
  <!-- <arg name="scan_2" default="/laser_back/scan" /> -->

  <!-- Start nodes -->
  <!-- If rosparam is put inside the node, it will become private and adopt a namespace with the node "name" first.
       In this case the param "/input_scans" from the yaml-file, becomes "/laser_unified/input_scans"-->
  <rosparam command="load" file="$(find neo_bringup)/config/unify_scans.yaml"/>
  <node pkg="cob_scan_unifier" type="scan_unifier_node" name="$(arg name)" respawn="false" output="screen">
    <remap from="scan_unified" to="/$(arg name)/scan"/>
  </node>

  <node pkg="tf" type="static_transform_publisher" name="scan_combined_broadcaster" args="0 0 0 0 0 0 /base_link /scan_combined 10" />
</launch>

Doing this enabled me to provide only one topic for the local costmap obstacle layer, as seen on the following:

costmap_local.yaml (a part of the file)

  obstacle_layer:
    observation_sources: laser_scanner
    laser_scanner: {sensor_frame: base_link, data_type: LaserScan, topic: /laser_unified/scan, marking: true, clearing: true, expected_update_rate: 9.0}

Originally posted by KimJensen on ROS Answers with karma: 55 on 2020-05-01

Post score: 1


Original comments

Comment by gvdhoorn on 2020-05-19:
You have sufficient karma to attach screenshots to this question directly.

Please do so, to prevent retention issues with your screenshot host from making links go stale.

Comment by KimJensen on 2020-05-26:
I previously did not have enough karma to attach screenshots, but thanks for point out, that I now have enough! The screenshot has been attached to the issue now.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

After trying every method which I could think of, I noticed that the remapping of laser scan information from two individual topics (/laser_front/scan and /laser_back/scan) to one unified topic (/laser_unified/scan) for unknown reasons resulted in this issue. I noticed this through simply looking at the effect of the change in RViz.

Instead of trying to unify two independent topics into one, then I found out that it is possible to assign both topics separately into the local costmap obstacle layer. This seems to be more computational heavy, but resolves the issue. The code will look like this:

costmap_local.yaml (a part of the file)

obstacle_layer:
    observation_sources: laser_scanner_front laser_scanner_back
    laser_scanner_front: {data_type: LaserScan, topic: /laser_front/scan, marking: true, clearing: true, expected_update_rate: 9.0}
    laser_scanner_back: {data_type: LaserScan, topic: /laser_back/scan, marking: true, clearing: true, expected_update_rate: 9.0}

Originally posted by KimJensen with karma: 55 on 2020-05-19

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by KimJensen on 2020-05-19:
If anyone can explain why unifying the laser scans would result in this issue, then please let me know! Thanks.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.