Posted by @osama-z-salah:
Before proceeding, is there an existing issue or discussion for this?
Description
How can I modify the is_command_completed method in the RMF Fleet Adapter’s RobotClientAPI to handle scenarios where the robot fails to complete a task? Currently, the method returns True if the last command was completed and False otherwise, but this doesn’t account for situations where the robot aborts a task. I need a way to notify the fleet adapter that the task has been aborted so that the robot can either return to parking or attempt the task again, instead of indefinitely waiting for the command to complete. Any suggestions on how to implement this?
Implementation Considerations
No response
Alternatives
No response
Additional information
No response
Posted by @Yadunund:
I’ve moved this ticket to the discussion board as it’s the right place to discuss such questions.
How can I modify the is_command_completed method in the RMF Fleet Adapter’s RobotClientAPI to handle scenarios where the robot fails to complete a task?
I guess you’re referring to the RobotClientAPI in rmf_demos_fleet_adapter. If so, this is a wrapper around a hypothetical fleet manager’s API. It is not something meant to be universal and can be modified as you see fit.
I need a way to notify the fleet adapter that the task has been aborted so that the robot can either return to parking or attempt the task again, instead of indefinitely waiting for the command to complete. Any suggestions on how to implement this?
It’s unclear to me what the robot is doing when it reports that it has aborted the task so are many ways to accomplish what you have asked. I assume you already have a way to be notified when the robot aborts a task.
- If the robot aborts a navigation request, you can implement the
CommandExecution in your NavigationRequest callback such that the okay() API returns false upon notification from the robot that the navigation request was aborted.
- If the robot aborts a custom action being performed via the
PerformAction, similar to the point above, the ActionExecution::okay() method should be implemented such that upon detecting the abort status from the robot, it returns false.
Posted by @osama-z-salah:
Thank you for your insights!
My fleet manager can notify me if a navigation or action task is aborted, still running, or completed successfully. I’m using the Python binding of rmf_adapter, and to ensure that the okay() API returns false when the robot reports that a navigation request has been aborted Should I modify the implementation of okay() in EasyFullControl.cpp, or is there a different approach I should take?
Posted by @Yadunund:
No, you never have to modify anything in EasyFullControl.cpp or any other implementation in the rmf_fleet_adapter library. The EasyFullControl class is an API that you use to implement your own fleet adapter. The rmf_demos_fleet_adapter does this. All you have to do is update the implementation of your fleet adapter to appropriately return the right value form the okay() call. Eg. in rmf_demos_fleet_adapter, you would update rmf_demos/rmf_demos_fleet_adapter/rmf_demos_fleet_adapter/fleet_adapter.py at 95b7335068bab6b31fcaeb6bdd582b2492fddfa0 · open-rmf/rmf_demos · GitHub
Posted by @osama-z-salah:
Understood, but I noticed that all the functions you’re referring to, like finished() or override_schedule(), are being used directly from EasyFullControl.cpp in the rmf_demos_fleet_adapter. These functions are just called as-is, and you don’t control what they return. So, how am I supposed to handle the return value in the okay() API?
Posted by @osama-z-salah:
@Yadunund In the RMF Fleet Adapter, I’m trying to simulate task failures and handle aborted tasks in the CommandExecution object. Specifically, I want to modify the okay() method in the CommandExecution object so that it returns False when a task is aborted, indicating that the task has failed.
However, I encountered the following error:
AttributeError: 'rmf_adapter.easy_full_control.CommandExecution' object attribute 'okay' is read-only
What I Tried
I initially attempted to modify the okay method directly by dynamically assigning a new method to execution_instance.okay, but this failed because the okay attribute is read-only in the rmf_adapter.easy_full_control.CommandExecution object, which is likely due to its definition in the C++ layer of the RMF adapter, exposed to Python via bindings.