Skip to content

Add isWithinPathTrackingBounds node#5983

Merged
SteveMacenski merged 8 commits intoros-navigation:mainfrom
mini-1235:feat/tracking_error_node
Feb 26, 2026
Merged

Add isWithinPathTrackingBounds node#5983
SteveMacenski merged 8 commits intoros-navigation:mainfrom
mini-1235:feat/tracking_error_node

Conversation

@mini-1235
Copy link
Collaborator


Basic Info

Info Please fill out this column
Ticket(s) this addresses #5037
Primary OS tested on (Ubuntu, MacOS, Windows)
Robotic platform tested on (Steve's Robot, gazebo simulation of Tally, hardware turtlebot)
Does this PR contain AI generated software? (No; Yes and it is marked inline in the code)
Was this PR description generated by AI software? Out of respect for maintainers, AI for human-to-human communications are banned

Description of contribution in a few bullet points

Description of documentation updates required from your changes

Description of how this change was tested


Future work that may be required in bullet points

For Maintainers:

  • Check that any new parameters added are updated in docs.nav2.org
  • Check that any significant change is added to the migration guide
  • Check that any new features OR changes to existing behaviors are reflected in the tuning guide
  • Check that any new functions have Doxygen added
  • Check that any new features have test coverage
  • Check that any new plugins is added to the plugins page
  • If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists
  • Should this be backported to current distributions? If so, tag with backport-*.

Co-authored-by: silanus23 <berkantali23@outlook.com>
Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>
@mini-1235
Copy link
Collaborator Author

Feb.24.2026.Video.mp4

For reference, I am setting the position error to 0.2, and it immediately fails if the error is >= 0.2

<root BTCPP_format="4" main_tree_to_execute="NavigateToPoseWBoundsCheck">
<BehaviorTree ID="NavigateToPoseWBoundsCheck">
<Sequence>
<ComputePathToPose goal="{goal}" path="{path}" planner_id="{selected_planner}" error_code_id="{compute_path_error_code}" error_msg="{compute_path_error_msg}"/>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What other details do you think we should include here? In this kind of use case, do people typically plan only once / replan only when an obstacle is detected / or replan continuously like in the default behavior tree?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth thinking of VDA5050 connection in here. As far as I know it's planning system waits for the message and then resend a new goal. In addition the previous PR it has been decided as just fail OK.
Other than these when obstacle detected it would better replan for the sake of smaller tracking errors

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think failing the navigation task makes sense for demo purposes. This is a small demo tree anyway :-)

I actually have use for this with a client immediately in that way!

@codecov
Copy link

codecov bot commented Feb 24, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines Coverage Δ
...ition/is_within_path_tracking_bounds_condition.hpp 100.00% <100.00%> (ø)
...ition/is_within_path_tracking_bounds_condition.cpp 100.00% <100.00%> (ø)

... and 23 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>
getInput<double>("max_position_error_left", max_position_error_left_);
getInput<double>("max_position_error_right", max_position_error_right_);
getInput<double>("max_heading_error", max_heading_error_);
getInput<nav2_msgs::msg::TrackingFeedback>("tracking_feedback", tracking_feedback_);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we get this each tick? I think this makes sense in the main tick function. I think this may tick anyway each iteration but it would be good to make this clear.

We should also check the case that the tracking_error isn't set yet at all

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, brain fart :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also check the case that the tracking_error isn't set yet at all

Not sure if we need to explicitly check for that and log an error / return failure if tracking_error hasn't been set yet. If we did, I would likely need to skip the first tick of this node in the demo, since FollowPath is ticked after the condition node. I think it may be reasonable to treat it as an empty tracking feedback instead (i.e., 0 position error and 0 heading error) (?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to at least make that an explicit policy, ie

// If not set yet (like on starting to track), pass as initialization should always be within tracking bounds
if (!getInput<nav2_msgs::msg::TrackingFeedback>("tracking_feedback", tracking_feedback_)) {
  return SUCCESS;
}

That way someone in the future can argue with it if they disagree. Right now that is hidden

<root BTCPP_format="4" main_tree_to_execute="NavigateToPoseWBoundsCheck">
<BehaviorTree ID="NavigateToPoseWBoundsCheck">
<Sequence>
<ComputePathToPose goal="{goal}" path="{path}" planner_id="{selected_planner}" error_code_id="{compute_path_error_code}" error_msg="{compute_path_error_msg}"/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think failing the navigation task makes sense for demo purposes. This is a small demo tree anyway :-)

I actually have use for this with a client immediately in that way!

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>
Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>
Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>
Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>
Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>
Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>
@SteveMacenski SteveMacenski merged commit 19a1240 into ros-navigation:main Feb 26, 2026
15 of 16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants