ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

Dead zone of SICK S300 laser scanner during simulation

asked 2020-05-01 07:32:19 -0500

KimJensen gravatar image

updated 2020-05-26 06:53:38 -0500

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}
edit retag flag offensive close merge delete

Comments

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.

gvdhoorn gravatar image gvdhoorn  ( 2020-05-19 02:00:58 -0500 )edit

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.

KimJensen gravatar image KimJensen  ( 2020-05-26 06:55:11 -0500 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2020-05-19 01:21:44 -0500

KimJensen gravatar image

updated 2020-05-19 01:22:45 -0500

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}
edit flag offensive delete link more

Comments

If anyone can explain why unifying the laser scans would result in this issue, then please let me know! Thanks.

KimJensen gravatar image KimJensen  ( 2020-05-19 01:23:59 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2020-05-01 07:32:19 -0500

Seen: 228 times

Last updated: May 26 '20