Hey all,

This is still really strange to me. The costmap timeout is actually designed
to add safety... enforcing that the robot will not move if there is too much
latency in between transforms in your system. It certainly shouldn't allow
the robot to command velocities outside of the user-specified limits. I've
seen the transform timeout a lot in systems with heavy load and have never
seen the robot do anything like what has been described. I'll take another
look at the code around the transform timeout stuff, but I'll admit that I'm
still pretty perplexed by this whole thing. I'm glad that everything is
working now, but I would love to figure out what was going on... it just
doesn't feel like this could be caused by transform timeouts.

Hope all is well,

Eitan

On Fri, Jun 25, 2010 at 11:12 AM, Christian Verbeek <
verbeek@servicerobotics.eu> wrote:

> I have to look on the velocity values again. I did not verify if the
> values are in their boundaries now. But I did not see the
> backward-driving any more. It was 100% reproducible when the movement
> started in a position where the robot would have to turn 180° in order
> to find free space. The same situation now is mastered by the local
> planner superbly.
>
> So it really seems that the CostMap timeout broke something in the
> overall behaviour.
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>