Replies: 1 comment
-
I believe the only situations where it should return
This has caused confusion for users in the past, so in the next major iteration of the API we'll make the meaning of the return value more clear. In the meantime it's best to track the published task state of the task if you need feedback on whether it's been cancelled/killed successfully. The cancellation process is asynchronous so this function can't give an immediate feedback on the outcome anyway. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
My task json is :
{'category': 'compose', 'description':{'category': 'load_unload', 'phases': [{'activity': {'category': 'sequence', 'description': {'activities': [{'category': 'go_to_place', 'description': {'waypoint': '靠墙点位'}}, {'category': 'perform_action', 'description': {'category': 'load_unload', 'description': {'task_id': '6F22ED8008DB52D38778AFC8B5779094', 'waypoint': '靠墙点位'}, 'unix_millis_action_duration_estimate': 120000}}]}}}]}}
I execute self.update_handle.submit_direct_request() to submit the task
Then RMF provides the scheduled path.
After the robot reaches the destination, the callback function is called
Then I call the following function periodically, the frequency is 10hz.
One question here: Do I need to call self.update_handle.unstable_declare_holding() periodically, for example once per 0.1 second?
or just call that function once?
After several minutes, I execute self.update_handle.cancel_task() or self.update_handle.kill_task() as follows:
Sometimes, cancel_task or kill_task will fail. (the 'killed' parameter given in callback on_kill is False)
Sometimes they will succeed.
Could you please explain whey cancel_task/kill_task fails? That is in what kind of scenario, cancel/kill will fail?
Beta Was this translation helpful? Give feedback.
All reactions