Bad maps produced when using a rotating Lidar by gmapping
Hi,
I'm using a rotating LiDAR to map the given environment in gmapping. But due to the rotation of the laser scan, it is not able to produce an appropriate map of the environment.
Here is my bag file Bag. I recorded a video as well for visualization of Gazebo Video Here is my gmapping.launch file
<?xml version="1.0" encoding="UTF-8"?>
<launch>
<arg name="scan_topic" default="/scan" />
<arg name="base_frame" default="base_link"/>
<arg name="odom_frame" default="odom"/>
<node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher"></node>
<node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">
<param name="map_frame" value="map"/>
<param name="base_frame" value="$(arg base_frame)"/>
<param name="odom_frame" value="$(arg odom_frame)"/>
<param name="map_update_interval" value="5.0"/>
<param name="maxUrange" value="6.0"/>
<param name="maxRange" value="8.0"/>
<param name="sigma" value="0.05"/>
<param name="kernelSize" value="1"/>
<param name="lstep" value="0.05"/>
<param name="astep" value="0.05"/>
<param name="iterations" value="5"/>
<param name="lsigma" value="0.075"/>
<param name="ogain" value="3.0"/>
<param name="lskip" value="0"/>
<param name="minimumScore" value="200"/>
<param name="srr" value="0.01"/>
<param name="srt" value="0.02"/>
<param name="str" value="0.01"/>
<param name="stt" value="0.02"/>
<param name="linearUpdate" value="0.1"/>
<param name="angularUpdate" value="0.136"/>
<param name="temporalUpdate" value="-1.0"/>
<param name="resampleThreshold" value="0.5"/>
<param name="particles" value="100"/>
<!--
<param name="xmin" value="-50.0"/>
<param name="ymin" value="-50.0"/>
<param name="xmax" value="50.0"/>
<param name="ymax" value="50.0"/>
make the starting size small for the benefit of the Android client's memory...
-->
<param name="xmin" value="-1.0"/>
<param name="ymin" value="-1.0"/>
<param name="xmax" value="1.0"/>
<param name="ymax" value="1.0"/>
<param name="delta" value="0.05"/>
<param name="llsamplerange" value="0.01"/>
<param name="llsamplestep" value="0.01"/>
<param name="lasamplerange" value="0.005"/>
<param name="lasamplestep" value="0.005"/>
<remap from="scan" to="$(arg scan_topic)"/>
</node>
</launch>
Kindly let me know how it can be corrected ?
@Geoff Thanks for your reply. So my laser_link is attached to top_plate and top_plate to base_link. So writing a transform from any node like this should suffice, right?
I updated my answer with the specific transform to update.
In the future, when asking for clarification of a specific answer, please comment on that answer rather than your question.
@Geoff So exactly I tried the same yesterday. This is how I defined my laser joint.
The update rate for the laser sensor in Gazebo, I kept as 40. The transformation which I m publishing
where position correspond to the joint position command.
position = position + 0.01So my graph looks like this now, it is much better but still makes some jump which ...(more)Most likely the remaining discontinuities are caused by the transform published via
tfnot being in sync with the time data comes in. Remember, it takes time for the commanded position to be achieved. It would be better to use the reported position of the joint from Gazebo.Cool, Thanx!!! I will definitely try and update my results.
@Geoff I found the root cause in the jumps. When the gazebo node is launched so the robot_state_publisher forms the tf tree like odom-->base_link-->top_plate-->laser_link So when I launch the node (rotate_laser_node) containing this transform (as given below) from a node, so there is a conflict in the tf tree i.e one publishing from robot_state_publisher and other from rotate_laser_node due to which robot jumps abit.
Is there any solution to this?
Since you are using Gazebo, you should have Gazebo publish the state of that joint. Joint states need to be reported based on the actual state of the joint (which Gazebo knows, or if you are using hardware which hopefully your hardware driver knows) rather than what you are commanding.