AMRNAV-6708 AMR7 placing pallet#76
AMRNAV-6708 AMR7 placing pallet#76VladyslavHrynchak200204 wants to merge 0 commit intoAMRNAV-6557_Fix_flickering_visualizationfrom
Conversation
VladyslavHrynchak200204
added
bug
| if(is_active(current_handle_) && is_cancel_requested()){ | ||
| postponed_handle_ = handle; | ||
| info_msg("Postpone goal"); | ||
| return; |
There was a problem hiding this comment.
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.
| onActionCompletion(); | ||
| action_server_->handle_postponed(); | ||
| return; | ||
| } |
There was a problem hiding this comment.
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.
I can make postponed_handle_ as queue of postponed goals, or we can postpone only one goal as we have now.
jplapp
left a comment
jplapp
left a comment
There was a problem hiding this comment.
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 |
VladyslavHrynchak200204
force-pushed
the
AMRNAV-6708-AMR7-placing-pallet
branch
from
dae9cda to
eb850ab
Compare
2 participants
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