Revert double spin

[mini-1235]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	#4567
Primary OS tested on	Ubuntu
Robotic platform tested on	(Steve's Robot, gazebo simulation of Tally, hardware turtlebot)
Does this PR contain AI generated software?	No
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

• Revert double spin, this has been solved in the latest release
• Change spin some to spin all, to make sure the node has the latest message update

Description of documentation updates required from your changes

None

Description of how this change was tested

Tested in different node's unit tests

---

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-*.

[mergify]

@mini-1235, 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).

[mini-1235]

CI failing:
Error computing cache key: template: cacheKey:1:79: executing "cacheKey" at <checksum "/opt/overlay_ws/lockfile.txt">: error calling checksum: open /opt/overlay_ws/lockfile.txt: no such file or directory

I don't think this is related to this PR

[SteveMacenski]

Must have been a weird CircleCI fluke. I just retriggered and worked fine.

Spin_some will process any messages in the queue from before the spin was started, whereas the spin_all will spin over any messages received after it started processing. I think that's an OK choice as long as there's a timeout (which you have set) so it doesn't go indefinitely.

We could also set the timeout used to be the same as the loop rate duration

navigation2/nav2_behavior_tree/include/nav2_behavior_tree/bt_action_server_impl.hpp

Line 195 in 7603938

blackboard_->set<std::chrono::milliseconds>("bt_loop_duration", bt_loop_duration_); // NOLINT

so that we never processed for longer than the optimal BT looping rate, in the worst case. This is also in milliseconds, so I think the only update would be to replace the 50 with the variable.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
...r_tree/plugins/action/controller_selector_node.hpp	100.00% <ø> (ø)
...tree/plugins/action/goal_checker_selector_node.hpp	100.00% <ø> (ø)
...vior_tree/plugins/action/planner_selector_node.hpp	100.00% <ø> (ø)
.../plugins/action/progress_checker_selector_node.hpp	100.00% <ø> (ø)
...ior_tree/plugins/action/smoother_selector_node.hpp	100.00% <ø> (ø)
...lugins/condition/is_battery_charging_condition.hpp	100.00% <ø> (ø)
...ree/plugins/condition/is_battery_low_condition.hpp	100.00% <ø> (ø)
...avior_tree/plugins/decorator/goal_updater_node.hpp	100.00% <ø> (ø)
...r_tree/plugins/action/controller_selector_node.cpp	100.00% <100.00%> (ø)
...tree/plugins/action/goal_checker_selector_node.cpp	100.00% <100.00%> (ø)
... and 6 more

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mini-1235]

We could also set the timeout used to be the same as the loop rate duration

navigation2/nav2_behavior_tree/include/nav2_behavior_tree/bt_action_server_impl.hpp

Line 195 in 7603938

blackboard_->set<std::chrono::milliseconds>("bt_loop_duration", bt_loop_duration_); // NOLINT

so that we never processed for longer than the optimal BT looping rate, in the worst case. This is also in milliseconds, so I think the only update would be to replace the 50 with the variable.

Ok!