-
Notifications
You must be signed in to change notification settings - Fork 0
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
AMRNAV-6708 AMR7 placing pallet #76
AMRNAV-6708 AMR7 placing pallet #76
Conversation
if(is_active(current_handle_) && is_cancel_requested()){ | ||
postponed_handle_ = handle; | ||
info_msg("Postpone goal"); | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If current_handle_ is active and requested to cancel the goal, we store it in postponed_handle_ to handle that after we successfully cancel our previous goal.
@@ -242,6 +243,7 @@ class TimedBehavior : public nav2_core::Behavior | |||
result->total_elapsed_time = elasped_time_; | |||
action_server_->terminate_all(result); | |||
onActionCompletion(); | |||
action_server_->handle_postponed(); | |||
return; | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After we cancel our goal, we call handle_postponed() to handle goals, which we received during cancelling previous goal
if(is_active(current_handle_) && is_cancel_requested()){ | ||
postponed_handle_ = handle; | ||
info_msg("Postpone goal"); | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can make postponed_handle_ as queue of postponed goals, or we can postpone only one goal as we have now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this works but I want to avoid duplicating the concept of "preemption". This is sending a new goal, while the action server already has a goal.
In which category do we fall here? Do we cancel the old goal first, or do we already send a new one? The latter would be preemption so you could try to implement that instead ? (see comment // TODO(orduno) #868 Enable preempting a Behavior on-the-fly without stopping
In concept of "preemption" we receive new goal -> save in pending_handle_ -> set preempt_requested_ = true -> if (action_server_->is_preempt_requested()) we aborting and stopping our current goal -> send preempting goal . But when i implemented my concept of "postponed goal" i never received a message "Received a preemption request for %s, we have two ways to implement that: 1 - avoid preemption concept and use my - when we have goal to cancel, we wait until it cancels and postpone new goal, then start to handle it. 2 - use concept of preemption but improve it -> if current goal is active -> we received new goal -> new goal store in queue -> run new goal from queue if we cancel, abort, finished successful previous goal |
dae9cda
to
eb850ab
Compare
Basic Info
Description of contribution in a few bullet points
Reason for change:
AMR7 placed a pallet not quite next to the pallet inside the bin leave between them too much space. We call DriveOnHeading, after 2s we fail because of and cancel it.
After that we run another DriveOnHeading which fails because we don`t wait until previous call DriveOnHeading stops. This cause this issue.
Changes in this PR:
Receive terminate_all for first DriveOnHeading -> accept new goal for second DriveOnHeading -> add new goal to postponed_handle_ -> terminate_all for first DriveOnHeading -> call handle_postponed() after we terminate goals successful -> handle postponed_handle_ goal