# 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="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 ?

edit retag close merge delete

@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?

br = tf.TransformBroadcaster()
(q0,q1,q2,q3)=quaternion_from_euler(r,p,y)

( 2019-06-13 05:27:02 -0500 )edit

I updated my answer with the specific transform to update.

( 2019-06-13 17:40:39 -0500 )edit

@Geoff So exactly I tried the same yesterday. This is how I defined my laser joint.

  <joint name="base_to_laser_joint" type="continuous">
<axis xyz="0 0 1" />
<origin xyz="0.150 0 0.097" rpy="0 0 0"/>
</joint>

<joint name="base_top_joint" type="fixed">
<origin xyz="0.003 0 0.274" rpy="0 0 0"/>
</joint>


The update rate for the laser sensor in Gazebo, I kept as 40. The transformation which I m publishing

(q0,q1,q2,q3)=quaternion_from_euler(0,0,position)
br.sendTransform((0.150,0, 0.097),
(q0,q1,q2,q3),
rospy.Time.now(),
"top_plate")


where position correspond to the joint position command. position = position + 0.01 So my graph looks like this now, it is much better but still makes some jump which ...(more)

( 2019-06-14 01:08:46 -0500 )edit

Most likely the remaining discontinuities are caused by the transform published via tf not 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.

( 2019-06-14 03:11:12 -0500 )edit

Cool, Thanx!!! I will definitely try and update my results.

( 2019-06-14 05:03:49 -0500 )edit

@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.

(q0,q1,q2,q3)=quaternion_from_euler(0,0,position)
br.sendTransform((0.150,0, 0.097),
(q0,q1,q2,q3),
rospy.Time.now(),
"top_plate")


Is there any solution to this?

( 2019-06-18 09:10:23 -0500 )edit

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.

( 2019-06-18 18:56:12 -0500 )edit

Sort by » oldest newest most voted

I played back your bag file, and as far as I can see you are not publishing the transform for the laser. You need to tell the ROS world that your laser sensor is rotating by publishing a transform for it. Ideally this should be published at exactly the same time a frame of laser data comes in, but you should be able to get away with just publishing at a rate faster than the scan rate of the laser.

If your laser itself (laser_link) is the bit that is rotating, then update the transform from top_plate to laser_link. If it is the top plate that is rotating then update the transform from base_link to top_plate.

more