handling clockwise laserscan

asked 2023-04-04 15:41:08 -0500

hilmi_ica gravatar image

Hey guys! I am beginner at ROS or even at the programming as a whole. I encountered a problem when trying to do a localization by using laser_scan_matcher as the odometry with a 2D Lidar (SICK NAV310). With the launch file:

<launch>

  <param name="/use_sim_time" value="false"/>

  <node pkg="tf" type="static_transform_publisher" name="base_link_to_cloud" args="0.0 0.0 0.0 0.0 0.0 0.0 base_link cloud 100" />

  <node pkg="laser_scan_matcher" type="laser_scan_matcher_node" 
    name="laser_scan_matcher_node" output="screen">
    <remap from="scan" to="/sick_nav_3xx/scan"/>
    <param name="fixed_frame" value = "odom"/>
    <param name="base_frame" value = "base_link"/>
    <param name="publish_tf" value="true"/>
    <param name="publish_odom" value="true"/>
    <param name="use_alpha_beta" value="true"/>
    <param name="max_iterations" value="10"/>
  </node>

</launch>

Which results in error:

[ WARN] [1680068632.770143301]: Error in scan matching
:err: Strange FOV: -6.278822 rad = -359.750011 deg

Here's the laserscan topic:

header: 
  seq: 2593
  stamp: 
    secs: 1680328713
    nsecs: 700240135
  frame_id: "cloud"
angle_min: -3.1415927410125732
angle_max: 3.1415927410125732
angle_increment: -0.004363323096185923
time_increment: 8.695651922607794e-05
scan_time: 0.125
range_min: 0.0
range_max: 100.0

So, i tried to limit the lasercan angle by laser_filters package. Which results in bigger FOV (in term of negative value) but still an error:

[ WARN] [1679891634.121426056]: Error in scan matching
:err: Strange FOV: -3.139409 rad = -179.874876 deg

So, i thought something wrong with the driver so i discuss with the developer in this link. So, we invert the data acquisition of the laserscan as we thought the problem was the rotation of the lidar is clockwise rather than conventional counterclockwise. With results in:

header: 
  seq: 114
  stamp: 
    secs: 1680591868
    nsecs: 283500194
  frame_id: "cloud"
angle_min: 3.141592264175415
angle_max: -3.141592264175415
angle_increment: -0.004366354551166296
time_increment: 8.695651922607794e-05
scan_time: 0.125
range_min: 0.0
range_max: 100.0

Which is inverted but still give the same error:

[ WARN] [1680591897.618700189]: Error in scan matching
:err: Strange FOV: -6.283184 rad = -359.999928 deg

Then i limit the angle and still give the same result:

header: 
  seq: 26
  stamp: 
    secs: 1680592184
    nsecs: 103201073
  frame_id: "cloud"
angle_min: 1.5697046518325806
angle_max: -1.569704294204712
angle_increment: -0.004366354551166296
time_increment: 8.695651922607794e-05
scan_time: 0.125
range_min: 0.0
range_max: 100.0

The laser_scan_matcher error gives:

[ WARN] [1680592326.291168626]: Error in scan matching
:err: Strange FOV: -3.139409 rad = -179.874876 deg

Hope anyone can help! Thanks!

For more information in the discussion with the driver's developer. You can visit this link.

edit retag flag offensive close merge delete

Comments

Quick comment: I'm not a laser scanner expert (by far), but according to the documentation of sensor_msgs/LaserScan:

angles are measured around the positive Z axis (counterclockwise, if Z is up) with zero angle being forward along the x axis

It's very likely nodes in packages like laser_filters assume producers of LaserScan messages comply with this, and can't really deal with input data that doesn't.

I see the SICK developers have already tried to help you. I would perhaps suggest to make sure their driver does in fact produce compliant LaserScan messages. Note the if Z is up part in the documentation I quoted. They might just be able to rotate their TF frame 180 degrees (so Z is down) and have the driver produce compliant messages.

gvdhoorn gravatar image gvdhoorn  ( 2023-04-05 02:23:09 -0500 )edit

See #q283793 for an older Q&A about a similar topic btw. That was a custom developed laser scanner, but the same issue(s) were encountered by the OP there.

gvdhoorn gravatar image gvdhoorn  ( 2023-04-05 02:24:20 -0500 )edit

According to this, for the CW lidar it needs a negative angle_increment with ang_min > ang_max. That is why we invert the data acq:

header: 
  seq: 114
  stamp: 
    secs: 1680591868
    nsecs: 283500194
  frame_id: "cloud"
angle_min: 3.141592264175415
angle_max: -3.141592264175415
angle_increment: -0.004366354551166296
time_increment: 8.695651922607794e-05
scan_time: 0.125
range_min: 0.0
range_max: 100.0

But still got the error. So as in #q283793, Do i need to invert it with tf package as example edit the static tf in the launch file to:

<node pkg="tf" type="static_transform_publisher" name="base_link_to_cloud" args="0.0 0.0 0.0 0.0 0.0 180 base_link cloud 100" />

Or need an extra package like invert_laser.

hilmi_ica gravatar image hilmi_ica  ( 2023-04-05 05:08:11 -0500 )edit

Again: I'm not an expert here.

I just wanted to draw attention to the fact that according to the sensor_msgs/LaserScan documentation, it appears the driver you mention is not producing compliant messages.

And:

According to this, for the CW lidar it needs a negative angle_increment with ang_min > ang_max.

please note that Q&A is over 12 years (!) old. Many things (could) have changed in the mean time. I would not take whatever is claimed in such old Q&As at face value. Make sure to understand what is written in the question and answers and see whether it is still relevant.

gvdhoorn gravatar image gvdhoorn  ( 2023-04-05 06:23:40 -0500 )edit

@hilmi_ica The euler arguments to static_transform_publisher use radians, not degrees.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2023-04-05 06:26:35 -0500 )edit

Or need an extra package like invert_laser.

that node seems to do what is needed yes. But shouldn't the SICK driver authors actually do that in their driver?

They could make it a ROS parameter if they don't want to do it by default.

gvdhoorn gravatar image gvdhoorn  ( 2023-04-05 06:28:33 -0500 )edit

@gvdhoorn So, what you're saying is i need to invert again the last edited laserscan. But, the initial lasercan topic already results in negative angle_min and positive angle_max as well as angle_increment.

@gvdhoorn No, i don't think so. If there is a parameter that invert the laserscan, they would've told me to did that. But they told me to invert it by myself as in the last comment in this discussion.

hilmi_ica gravatar image hilmi_ica  ( 2023-04-05 10:03:40 -0500 )edit

No, i don't think so

you don't think what?

Fact remains the SICK driver seems to publish non-compliant data (ie: sensor_msgs/LaserScans which don't follow the documentation/standards).

Either you work-around it by using the node you found, or you report this and have the SICK driver authors/maintainers fix their driver. Feel free to point to this ROS Answers Q&A.

gvdhoorn gravatar image gvdhoorn  ( 2023-04-05 10:07:22 -0500 )edit