Adapt GoalUpdater to update goals as well

[tonynajjar]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	(add tickets here #1)
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)

---

Description of contribution in a few bullet points

Description of documentation updates required from your changes

---

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

[tonynajjar]

@SteveMacenski as usual, still a draft but what do you think of the idea? Do you have a preference for a standalone node? GoalUpdatedCondition checks both goal and goals in the same node.

[codecov]

Codecov Report

Attention: Patch coverage is 92.85714% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...avior_tree/plugins/decorator/goal_updater_node.cpp	92.00%	2 Missing ⚠️

Files with missing lines	Coverage Δ
...avior_tree/plugins/decorator/goal_updater_node.hpp	100.00% <100.00%> (ø)
...avior_tree/plugins/decorator/goal_updater_node.cpp	95.74% <92.00%> (-4.26%)	⬇️

... and 2 files with indirect coverage changes

[SteveMacenski]

I know its a conversational draft, so obviously the main block in tick still needs the goals version.

I'm not opposed to having this BT node be goal(s). I'm less certain about the introduction of a new PosesStamped message type used only for this application. I imagine the context of use would be for NavigateThroughPoses or similar, so shouldn't those be updated as well to use that [1] (among possibly others)?

Also, food for thought, this seems like a good geometry_msgs improvement rather than a nav2_msgs improvement to add PosesStamped. Maybe we should file a ticket over there and ask @tfoote if he's open to that contribution

[1] https://github.com/ros-navigation/navigation2/blob/main/nav2_msgs/action/NavigateThroughPoses.action#L3

[tonynajjar]

I merged #4791 into this branch to be able to test in CI. Let's come back to reviewing this PR what's the first one is merged for more clarity

[mergify]

@tonynajjar, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[mergify]

@tonynajjar, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[SteveMacenski]

OK sounds good - that will make this diff much smaller and more concise to the change srequired

[SteveMacenski]

I think this can now be rebased for only the changes required to the sp. BT nodes

[mergify]

@tonynajjar, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[mergify]

@tonynajjar, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[SteveMacenski]

Small change and then we can merge! Update the jazzy backport too and I'll do the pair