handling clockwise laserscan
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 laserscanmatcher 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 laserscanmatcher 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.
Asked by hilmi_ica on 2023-04-04 15:41:08 UTC
Comments
Quick comment: I'm not a laser scanner expert (by far), but according to the documentation of sensor_msgs/LaserScan:
It's very likely nodes in packages like
laser_filtersassume producers ofLaserScanmessages 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
LaserScanmessages. Note theif Z is uppart 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.Asked by gvdhoorn on 2023-04-05 02:23:09 UTC
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.
Asked by gvdhoorn on 2023-04-05 02:24:20 UTC
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:
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:
Or need an extra package like invert_laser.
Asked by hilmi_ica on 2023-04-05 05:08:11 UTC
Again: I'm not an expert here.
I just wanted to draw attention to the fact that according to the
sensor_msgs/LaserScandocumentation, it appears the driver you mention is not producing compliant messages.And:
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.
Asked by gvdhoorn on 2023-04-05 06:23:40 UTC
@hilmi_ica The euler arguments to static_transform_publisher use radians, not degrees.
Asked by Mike Scheutzow on 2023-04-05 06:26:35 UTC
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.
Asked by gvdhoorn on 2023-04-05 06:28:33 UTC
@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_minand positiveangle_maxas well asangle_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.
Asked by hilmi_ica on 2023-04-05 10:03:40 UTC
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.
Asked by gvdhoorn on 2023-04-05 10:07:22 UTC
Sorry, what i mean is i don't think the driver has the invert parameter. Ok, i will try the node and keep you up to date!
Asked by hilmi_ica on 2023-04-05 12:20:31 UTC