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

Costmap Laser "Smearing"

asked 2011-05-27 11:01:46 -0500

mjcarroll gravatar image

We are having a reoccuring issue with move_base's costmap.

The obstacles detected by the laser scan tend to get "smeared" through the costmap.

The obstacle stays constant in the body frame of the robot (setting the laser persistance on rviz to a higher number like 1 or 2 shows that the obstacle doesn't "move" relative to the body frame of the robot), yet it can create an "arc" of occupied cells in the costmap.

Does anybody have any insight into this problem?

edit retag flag offensive close merge delete

1 Answer

Sort by ┬╗ oldest newest most voted

answered 2011-05-27 17:33:57 -0500

tfoote gravatar image

Two things I can think of cause this. A timing issue. If data is incorrectly timestamped it will be transformed incorrectly. This could also be caused by an incorrect frame_id though if it looks right in the base link, it's more likely the former.

The second option is simply that your odometry is not accurately reporting the rotation of the vehicle. If it under reports or over reports it will cause smearing like this.

edit flag offensive delete link more


The odometry is coming from an EKF that we wrote, and we found that the Microstrain had some "settling" time to it. Doing hard iron calibration seemed to remove most of that. The frame_id is correct. Any hints on calibrating out the timing issue? This was what we were thinking was a cause.
mjcarroll gravatar image mjcarroll  ( 2011-05-28 02:59:14 -0500 )edit
Alas, it was a mis-aligned time-stamp. All is fixed. Thanks.
mjcarroll gravatar image mjcarroll  ( 2011-05-31 09:59:09 -0500 )edit

Question Tools


Asked: 2011-05-27 11:01:46 -0500

Seen: 417 times

Last updated: May 27 '11