Costmap Laser "Smearing"

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

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?

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

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

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

Comments

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 ( 2011-05-28 02:59:14 -0600 )edit

Alas, it was a mis-aligned time-stamp. All is fixed. Thanks.

mjcarroll ( 2011-05-31 09:59:09 -0600 )edit

add a comment

1 Answer

Comments

Question Tools

Stats

Related questions

Costmap Laser "Smearing" edit

1 Answer

Comments

Question Tools

Stats

Related questions

Costmap Laser "Smearing"