Ask Your Question

Bad maps produced when using a rotating Lidar by gmapping

asked 2019-06-13 03:47:14 -0500

tsdk00 gravatar image

updated 2019-06-14 01:12:43 -0500


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. image description

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"?>
  <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)"/>

Kindly let me know how it can be corrected ? image description

edit retag flag offensive 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()
tsdk00 gravatar imagetsdk00 ( 2019-06-13 05:27:02 -0500 )edit

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 gravatar imageGeoff ( 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"/>
    <parent link="top_plate"/>
    <child link="laser_link"/>

<joint name="base_top_joint" type="fixed">
    <origin xyz="0.003 0 0.274" rpy="0 0 0"/>
    <parent link="base_link"/>
    <child link="top_plate"/>

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

    br.sendTransform((0.150,0, 0.097),

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)

tsdk00 gravatar imagetsdk00 ( 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.

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

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

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

1 Answer

Sort by ยป oldest newest most voted

answered 2019-06-13 04:31:08 -0500

Geoff gravatar image

updated 2019-06-13 17:39:33 -0500

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.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2019-06-13 03:47:14 -0500

Seen: 22 times

Last updated: Jun 14