Ask Your Question
0

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
1

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

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 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

Your Answer

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

Add Answer

Question Tools

Stats

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

Seen: 326 times

Last updated: May 27 '11