Can failure of costmap to meet its update rate make getRobotPose fail?

[corot]

Ok, this is something rather mysterious I cannot understand, probably not a bug, but is bugging me quite a lot:

First, I have noticed that on all move_base components robot pose is get by calling Costmap2DROS::getRobotPose. That's fine, but... could somehow this method fail if the costmap is strugling to keep its update rate? I know this don't make sense because the map is updated in a separated thread, and the tf listener used to transform the robot pose into costmap frame has also his own thread.... but the fact is that I have this problem with global costmap / global planner:

[/move_base/move_base  WARN 1470136638.285557852]: Map update loop missed its desired rate of 1.0000Hz... the loop actually took 1.573 seconds
[/move_base/move_base  WARN 1470136638.285557852]: Unable to get starting pose of robot, unable to create global plan
     .........many more..................
[/move_base/move_base  WARN 1470136638.285557852]: Unable to get starting pose of robot, unable to create global plan
[/move_base/move_base  WARN 1470136638.285584956]: Unable to get starting pose of robot, unable to create global plan
[/move_base/move_base  WARN 1470136638.285606660]: Unable to get starting pose of robot, unable to create global plan
[/move_base/move_base  WARN 1470136638.285620901]: Unable to get starting pose of robot, unable to create global plan
[/move_base/move_base  WARN 1470136638.285633567]: Unable to get starting pose of robot, unable to create global plan
[/move_base/move_base  WARN 1470136638.496970706]: Could not get robot pose, cancelling pose reconfiguration
[/move_base/move_base  WARN 1470136643.497352621]: Costmap2DROS transform timeout. Current time: 1470136643.4973, global_pose stamp: 1470136643.1959, tolerance: 0.3000
[/move_base/move_base  WARN 1470136643.497717177]: Could not get robot pose, cancelling pose reconfiguration
[/move_base/move_base  WARN 1470136648.997126127]: Costmap2DROS transform timeout. Current time: 1470136648.9971, global_pose stamp: 1470136648.6959, tolerance: 0.3000
[/move_base/move_base  WARN 1470136648.997166981]: Could not get robot pose, cancelling pose reconfiguration
[/move_base/move_base  WARN 1470136651.843847579]: Costmap2DROS transform timeout. Current time: 1470136651.8438, global_pose stamp: 1470136651.5292, tolerance: 0.3000
[/move_base/move_base  WARN 1470136652.297406428]: Could not get robot pose, cancelling pose reconfiguration

And I also get similar problems with the local planner and local costmap.

Moreover, I have moved the getRobotPose to move_base.cpp and to dwa_local_planner_ros.cpp and... ❗ ❗ ❗ ❗ I fixed the problem on global planner and local planner respectively!!! For the global planner I also managed to fix the problem by reducing update rate to something ridiculously low, like 0.2Hz.

So I'm puzzled, really. Makes any sense all this? Could be that somehow tf listener don't get updated during costmaps updates? I have noticed that move_base_node.cpp runs ros:spin(); instead of ros::MultiThreadedSpinner, what makes a bit more plausible my wild guess.

Thanks!

[spmaniato]

Interesting. @corot I had experienced similar (same?) issues, but had attributed them to running the nav stack on a weak SBC (see #437) Are you seeing this in simulation or on a real robot? Are the computational resources limited, like in a SBC?

[corot]

In both, but slightly different. On Stage I have a weird issue with the footprint trailing behind of the tf tree and robot model, what could indicate that the costmap truly struggles to keep path, because it's him who provides the footprint. So I just ignore it by now and concentrate on the real robot..

We use a i7-4770S (quadcore, 3.9GHz), 16 GB RAM, so we have plenty of computational power for move_base needs.

[corot]

Ok, tentative fix for the big problem (global planner failures) PRequested: #520

[mikeferguson]

Fix about to be merged into lunar. Merge into I+K requires a bit of PR update, which I imagine will happen shortly.

[bochen87]

Hello, this somehow has not made it into Indigo or Kinetic as of yet. What's the timeline for this to be merged? Would be interested in this fix as we're sometimes facing similar issues.