ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Nav2 ComputePathToPose throws tf error because goal stamp is out of tf buffer

asked 2022-02-28 21:35:36 -0600

Andyblarblar gravatar image

So this is an issue I've been wragling with for a few weeks now and I can't tell if its an intentional design decision or not.

My bot in ign gazebo is using waypoint_follower and dwb on Galactic. When I send it a goal pose from rviz, it successfully begins to navigate. After 10s however, it will fail to transform the goal pose with [transformPoseInTargetFrame]: Extrapolation Error looking up target frame: Lookup would require extrapolation into the past. Requested time 5.093000 but the earliest data is at time 5.600000, when looking up transform from frame [base_footprint] to frame [map] .

After much tinkering with the nav2 source, I finally found these lines in PlannerServer::computePlan() to be the culprate:

 RCLCPP_INFO(this->get_logger(), "start goal has time of: %d", start.header.stamp.sec); 
    // Transform them into the global frame
    geometry_msgs::msg::PoseStamped goal_pose = goal->goal;
    RCLCPP_INFO(this->get_logger(), "goal time has time of: %d", goal_pose.header.stamp.sec); 
    if (!transformPosesToGlobalFrame(action_server_pose_, start, goal_pose)) {

The info logs added by me. What seems to happen is that the goal pose I set in rviz has a constant timestamp throughout the life of the navigation, which will cause the above tf error in transformPosesToGlobalFrame when that timestamp is no longer in the tf_buffer (10s in the costmap).

now to the actual question: is this intentional? It seems like this would be a huge issue (and indeed it is for me) as it doesnt look to have any adjustable timeout. I could make the tf buffer larger, but that just kicks the issue down the line. I've tried to just update the goals timestamp, but that causes the bot to endlessly loop around the goal for some reason. I'm really at a loss of what to do and it's halting any other work.

Some more logs demenstrating the issue using the RCLPP_INFO statements above: (start goal here is the current pose, and thus sim time)

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2022-07-13 18:30:34 -0600

Ronoman gravatar image

I don't have an answer to whether this is intentional behavior or not, but I have opened an issue on the Nav2 repo:

In the meantime, setting the goal's timestamp to 0 resolves the problem. A timestamp of 0 will allow TF2 to use the most recent available transform, instead of forcing a transform at a specific time. To allow RViz input of a goal, I remapped RViz's /goal_pose to /rviz_goal, and added a node to subscribe to this new topic and republish a goal to /goal_pose with a 0 timestamp.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2022-02-28 21:11:00 -0600

Seen: 217 times

Last updated: Feb 28 '22