Fixes for flaky WPF test

[AlexeyMerzlyakov]

• New RewrittenYaml ability to add non-existing parameters
• Prune distance fix for WPF test
• Treat UNKNOWN status as error in WPF
• Clear error codes after BT run
• Remove unnecessary setInitialPose() from WPF test

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	#3765
Primary OS tested on	Ubuntu 22.04
Robotic platform tested on	colcon test

---

Description of contribution in a few bullet points

The following problems described in #3765, were fixed:

Problem	Solution description
Problem1: No action	Return back BT action server timeout to 15 minutes: #3787
Problem1: No action	New RewrittenYaml ability to add non-existing parameters & prune distance fix for lower probability of recovery situations
Problem1: No action	Treat UNKNOWN status as error in WPF to avoid hangs when action goal was deleted
Problem2: Incorrect out-of-map status	Clear error codes after BT run
Problem3: Robot lost	Remove unnecessary setInitialPose() from testing

Verification status

Performed colcon test for nav2_waypoint_follower, nav2_behavior_tree and nav2_system_tests packages, touched in this PR. No regressions appear during the local testing.

Description of documentation updates required from your changes

• Describe new ability of RewrittenYaml in Iron->Jazzy MG

---

Future work that may be required in bullet points

• Remove Costmap Filter parameters YAML-s in favor of using new ability of RewrittenYaml to add new ROS-parameters. This will reduce boilerplate works to synchronize Costmap Filter parameters YAML-s with main one.
• Fix RCLCPP action 10-second timeout in either RCLCPP or make a workaround for Nav2

Both above items are subject of separate PR-s.

For Maintainers:

• Check that any new parameters added are updated in navigation.ros.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

[SteveMacenski]

Is this really a failed case if unknown from this timeout? Seems like we should instead temporarily increase the timeout back to 15 minutes (@pepisg ) while working through a potential patch to rclcpp to better keep actively processing goals around.

[pepisg]

Exposed that as a parameter in #3787 that defaults to 15 min

[SteveMacenski]

@AlexeyMerzlyakov do you think we should remove this bit and instead use #3787 as the temp work around?

[AlexeyMerzlyakov]

This PR is complementary with PR3787, that improves the situation and fixes some bugs, that 3787 does not. So both PR-s ought to be merged (moreover, new parameters in RewrittenYaml I plan to use to comb-up Costmap Filters system tests).

[SteveMacenski]

@AlexeyMerzlyakov I meant only the addition of || current_goal_status_.status == ActionStatus::UNKNOWN. I thought this line was to mask the unknown return type problem? If we increase the timeout, wouldn't that make it so we didn't see UNKNOWN? This logic treats UNKNOWN as a terminal condition failure, which I suppose is an interpretation. I could get behind that but:

If we keep this here should https://github.com/ros-planning/navigation2/pull/3785/files#diff-872945d6a63001626ab7379639b5b3d5f11982ea3bdf08da01e7f111a9c2dfecR279 be changed for incrementing new goals? You're treating UNKNOWN as a terminal condition in your change, so this doesn't make as much sense anymore as a potentially non-terminal condition, correct? Is there anywhere UNKNOWN is potentially set where its not terminal?

[AlexeyMerzlyakov]

This status is being treated as terminal one for WPF server in order to avoid infinite cycles whether for some reasons the goal got into "UNKNOWN" state. This is intended to fix/mask not only the case when the goal is getting after it was destroyed, but rather for any other potential problems. Briefly looking to RCLCPP and RCL code shows that UNKNOWN state might appear in case if goal was invalidated, destroyed, does not exists at the moment of if the transition was invalid or any other error occurred. So, receiving UNKNOWN goal for action server seems to be treated as problem state, if I got the RCLCPP / RCL intention correctly.

When I've wrote this change, I've also focused on BtActionNode server, receiving the result from downstream nodes. For this case, "UNKNOWN" status is being treated as error situation, and error is being thrown, interrupting normal operation.
From this point of view, looking on the UNKNOWN goal status as on error seems to be logical.

If we keep this here should https://github.com/ros-planning/navigation2/pull/3785/files#diff-872945d6a63001626ab7379639b5b3d5f11982ea3bdf08da01e7f111a9c2dfecR279 be changed for incrementing new goals?

Yes, this should be removed for UNKNOWN stage, if we will treat UNKNOWNS as errors. Thanks for the notice!
If we will agree on main idea, I will remove it in next update.

[SteveMacenski]

Yup that works for me!

[AlexeyMerzlyakov]

Fixed in 85b6b71

[SteveMacenski]

Beyond that last question, I think this is good to go!

[SteveMacenski]

@AlexeyMerzlyakov thanks so much for your time on this!