-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Fixes for flaky WPF test #3785
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes for flaky WPF test #3785
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -217,7 +217,10 @@ WaypointFollower::followWaypoints() | |
| feedback->current_waypoint = goal_index; | ||
| action_server_->publish_feedback(feedback); | ||
|
|
||
| if (current_goal_status_.status == ActionStatus::FAILED) { | ||
| if ( | ||
| current_goal_status_.status == ActionStatus::FAILED || | ||
| current_goal_status_.status == ActionStatus::UNKNOWN) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Exposed that as a parameter in #3787 that defaults to 15 min There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @AlexeyMerzlyakov do you think we should remove this bit and instead use #3787 as the temp work around? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @AlexeyMerzlyakov I meant only the addition of 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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
Yes, this should be removed for UNKNOWN stage, if we will treat UNKNOWNS as errors. Thanks for the notice! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yup that works for me! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed in 85b6b71 |
||
| { | ||
| nav2_msgs::msg::MissedWaypoint missedWaypoint; | ||
| missedWaypoint.index = goal_index; | ||
| missedWaypoint.goal = goal->poses[goal_index]; | ||
|
|
@@ -324,6 +327,7 @@ WaypointFollower::resultCallback( | |
| current_goal_status_.status = ActionStatus::FAILED; | ||
| return; | ||
| default: | ||
| RCLCPP_ERROR(get_logger(), "Got unknown result from BT"); | ||
AlexeyMerzlyakov marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| current_goal_status_.status = ActionStatus::UNKNOWN; | ||
| return; | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.