0
$\begingroup$

Rosanswers logo

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?


Originally posted by mjcarroll on ROS Answers with karma: 6414 on 2011-05-27

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by tfoote with karma: 58457 on 2011-05-27

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by mjcarroll on 2011-05-31:
Alas, it was a mis-aligned time-stamp. All is fixed. Thanks.

Comment by mjcarroll on 2011-05-28:
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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.