ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Bad maps produced when using a rotating Lidar by gmapping

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

tsdk00 gravatar image

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

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

edit retag flag offensive close merge delete

Comments

@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)
br.sendTransform((x,y,z),(q0,q1,q2,q3),rospy.Time.now(),"base_link","laser_link")
tsdk00 gravatar image tsdk00  ( 2019-06-13 05:27:02 -0600 )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 image Geoff  ( 2019-06-13 17:40:39 -0600 )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>

<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"/>
</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(),
        "laser_link",
        "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)

tsdk00 gravatar image tsdk00  ( 2019-06-14 01:08:46 -0600 )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 image Geoff  ( 2019-06-14 03:11:12 -0600 )edit

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

tsdk00 gravatar image tsdk00  ( 2019-06-14 05:03:49 -0600 )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(),
        "laser_link",
        "top_plate")

Is there any solution to this?

tsdk00 gravatar image tsdk00  ( 2019-06-18 09:10:23 -0600 )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.

Geoff gravatar image Geoff  ( 2019-06-18 18:56:12 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
1

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

Geoff gravatar image

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

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

Question Tools

2 followers

Stats

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

Seen: 472 times

Last updated: Jun 14 '19