Gazebo | Ignition | Community
Ask Your Question

Laser returns from objects not in the laser plane

asked 2014-11-14 10:02:59 -0600

RoboticJustin gravatar image

updated 2014-11-14 10:03:44 -0600

I am using lidar simulation in Gazebo with a Husky model. I have placed the lidar sensors above the body of the husky. I can drive the robot around and see returns off obstacles placed in the gazebo world. However, I get erroneous returns in the laser scan that are consistent with the X and Y dimensions of the collision block for the body of the robot, even though the lidar is at 0.35m and the top of the husky (Z location) is no more than 0.25m.

I am wondering if anyone has run across this and has a solution before I dig into the source for the laser scan.

My environment:

  • Ubuntu 14.04 LTS 64-bit running in a Vmware virtual machine
  • ROS Indigo
  • Gazebo 2.2.3 (the one that was automatically installed with ROS)
  • The husky models and simulations are based on the tutorials on the ClearPath website.

Some images of RVIZ and Gazebo output here:

  • husky1.png shows the nominal behavior (two side-facing lidars dectect a few obstacles placed in the world). The lidar sensors are represented by the two cylinders above the body of the husky.
  • husky2 and 3 were taken after adding some decay to the lidar scans to show the the bad returns around the robot as I manually drive it forward. The bad returns define a box that is consistent with the x and y dimensions of the collision box for the robot body, even though the lidar is in a plane above the robot body.
  • husky4 shows that the lidar returns are in a plane well above the body of the husky.
  • husky5 is the gazebo client view with collision boxes turned on. You can see that the collision box for the body does not intersect with the lidar sensors or their collision boxes.

Some things I have found out:

  • The erroneous returns seem to occur during acceleration and deceleration, when the husky tips slightly. I can also get them to appear consistently if the husky is leaning against something, although in the latter case, the husky is sliding ever so slowly down the obstacle, so it may be related to motion and not incline. I think it more likely has to do with inclination because I also see the returns when I manage to tip the robot over.
  • if I remove the collision box for the body, I start getting bad returns off the wheels instead.
  • if I make the minimum range of the lidar about 1m (much larger than the husky), the phantom returns go away. You would expect this, but I need the closer returns for my application.
  • the returns are not 100% bad. If you plot the laser scan data, they are an apparently random mixture of bad returns off the body and "correct" returns off the obstacles.
edit retag flag offensive close merge delete


Could you turn on visualization of the lasers in Gazebo, and post a picture? The hokuyo model has an example of how to turn on laser visualization.

nkoenig gravatar imagenkoenig ( 2014-12-01 11:46:31 -0600 )edit

3 Answers

Sort by ยป oldest newest most voted

answered 2014-11-25 16:12:04 -0600

RoboticJustin gravatar image

updated 2014-11-25 16:14:21 -0600

I spent some time digging into this. I upgraded to Gazebo 4.0.2, installed from source, so I could do some debugging on it. I did not track the problem down 100%, but here's what I learned:

When the husky model tilts even slightly, the AABB bounding boxes for the rays gets very tall. This causes ODE to see potential collisions because the basic bounding boxes of elements of the robot and of the rays from the sensor collide. The potential collisions are passed down (ultimately) to the dCollide() function, which resolves the collision function to the function for colliding a trimesh with a ray since the Husky body is made up of mesh objects. I suspect that there is a bug in the collision algorithm that is causing the false collisions.

For my own application, I merely patched the ODEMultiRayScan class so that it ignores collisions with elements that are part of the robot itself. Since these collisions are ignored, the potential collisions with other obstacles are seen correctly, so you get a full scan with collisions off of obstacles and the ground plane. I know this is a hack, but it's far simpler than trying to debug the mesh collision algorithms, and the simplifying assumption (lidar is known to not collide with the robot body) is sufficient for my application.

edit flag offensive delete link more


Very interesting and detailed observations. I observed the same issue when using a customized Turtlebot model. Don't have time to verify if this still happens in latest Gazebo, but maybe @nkoenig or @hsu can advise if this has been worked on or if a issue should be opened on Bitbucket.

Stefan Kohlbrecher gravatar imageStefan Kohlbrecher ( 2014-11-28 01:55:07 -0600 )edit

Are you using a ray sensor of type `ray` or `gpu_ray`? Also, dCollide only interacts with the collision objects, which are simple shapes (boxes and cylinders) for husky.

nkoenig gravatar imagenkoenig ( 2014-12-01 11:52:49 -0600 )edit

I just encountered the same problem with our own robot model in gazebo 6. Exactly as in your case, it happens when the robot is tipping slightly during acceleration and deceleration phases. We are using a sensor of type ray. Our collision objects are boxes. I have no idea yet how to fix this -- significantly reducing the height of our collision boxes did not help, only completely deleting them (which is undesirable) causes the wrong echoes to disappear.

tlind gravatar imagetlind ( 2015-08-05 14:55:37 -0600 )edit

Same issue for me using Gazebo 7. As it might help others: I only have the issue with the `ray` sensor, not with `gpu_ray` (unfortunately I cannot use gpu for other reasons).

Felix Widmaier gravatar imageFelix Widmaier ( 2018-08-08 05:05:10 -0600 )edit

answered 2018-08-08 05:16:25 -0600

I have the same issue but only with the CPU-based laser plugin, with the GPU Laser plugin, everything is good.

So in case you have a GPU available, simply switch the plugin by changing sensor type ray to gpu_ray and plugin filename from to (parameters are the same).

edit flag offensive delete link more
Login/Signup to Answer

Question Tools



Asked: 2014-11-14 10:02:59 -0600

Seen: 1,996 times

Last updated: Nov 25 '14