Posted by @dennis-thevara:
I’m currently using MiR robots (200 and 500 to be precise) to carry out several delivery tasks using RMF. There are occasional times when the robots enter their own E-Stops due to collisions with dynamic obstacles, or minor hardware faults. In these situations, what is the best way to pass the information about the current state of the robot from the vendor system back to RMF so that it can be accounted for in RMF-Web and all other tracking systems?
I see that the cpp implementation of the Fleet Adapter code has an IssueTicket class whose docstring mentions that it is used for issue tracking. Is there a python binding available for this?
Chosen answer
Answer chosen by @dennis-thevara at 2023-01-03T14:45:19Z.
Answered by @aaronchongth:
Hello! You are right, that would be the ideal way of handling such a scenario. The binding is available, you can find it here, rmf_ros2/rmf_fleet_adapter_python/src/adapter.cpp at main · open-rmf/rmf_ros2 · GitHub.
Posted by @aaronchongth:
Hello! You are right, that would be the ideal way of handling such a scenario. The binding is available, you can find it here, rmf_ros2/rmf_fleet_adapter_python/src/adapter.cpp at main · open-rmf/rmf_ros2 · GitHub.
This is the chosen answer.
Posted by @dennis-thevara:
Thanks for the quick response! I think this should be exactly what we need, I’ll experiment with it and reach out again if I have questions.
Posted by @dennis-thevara:
Hi! I wanted to follow up on this query with an update and a question. I was successfully able to get the state from the robot to reflect properly within the adapter and the data on the fleet_state_update and fleet_log_update websockets. This is also being accurately reflected in real time on RMF Web. However, if the robot is engaged in a task (delivery in this case), the task state continues to report underway while the robot is immobile and reporting an error, instead of one of the several states enumerated in task_state.json. What is the best way to update the task state in order to complete this feedback pipeline?
I have experimented with the Interruption class by calling RobotUpdateHandle::interrupt when the robot state is set to Error, but this doesn’t modify the task state in RMF Web or in the websocket data. Perhaps I am using this incorrectly, or this is not the intended mechanism for updating a task state based on robot state.
I have also been looking into the action executor, but my understanding is that I shouldn’t be creating a new one when a delivery task is underway, but instead interfacing with whichever executor is active for that task. Is there a way to access this? I had updated my fleet adapter code to include the instantiation of an action executor exactly the same way as the _updater_inserter in the rmf_demos_fleet_adapter code, but it doesn’t seem to set an action executor during launch. I’ve tried to verify by logging a debug statement after the function call, which prints correctly for the RMF Demos adapter, but not mine.
Edited by @dennis-thevara at 2023-02-01T08:25:16Z
Posted by @aaronchongth:
Hello @dennis-thevara! Am I right to assume that you would like the tasks to fail when the robot has an issue?
If so, alongside creating an IssueTicket as mentioned in our discussion above, you would need to cancel or kill the task as well, depending on your use case and preference. rmf_ros2/rmf_fleet_adapter/include/rmf_fleet_adapter/agv/RobotUpdateHandle.hpp at main · open-rmf/rmf_ros2 · GitHub
Regarding Interruption, it is used for interrupting the control RMF has over the robot, for example, when we want to teleoperate the robot, and prevent the fleet adapter to continue to send commands to the robot while we handle it.
Posted by @dennis-thevara:
Hello @aaronchongth! Yes one of the responses I want is for the task to be cancelled for which cancel_task will work, but I would also like to be able to specify states like blocked or delayed in certain situations such as a dynamic obstacle that blocks a node on the node graph but then is cleared away, allowing for the robot to reach the destination and complete the task.
Basically curious if there is a generic task state override, similar to the override_status method made available by the RobotCommandHandle, where I can assign to the currently executing task one of the valid task states in the task_state.json enum.
Thank you for the clarification on Interruption as well, it should come in handy for manual control overrides.
Posted by @aaronchongth:
The allowed statuses are these enums,
robot state: rmf_api_msgs/rmf_api_msgs/schemas/robot_state.json at main · open-rmf/rmf_api_msgs · GitHub
task state: rmf_api_msgs/rmf_api_msgs/schemas/task_state.json at main · open-rmf/rmf_api_msgs · GitHub
I believe what you are looking for at the moment is not supported. If I understand correctly, you would like a more granular status update regarding what the robot is encountering, a warning of sorts but with the robot still continuing with it’s task. I would then suggest to just log this encounter, where the logs can be monitored through the robot or task state.
Posted by @dennis-thevara:
Hi, yes I’ve seen those enums. You’re right that I’d like to have a more specific task status update but only within the allowed states listed in the enum.
For example, if a waypoint on the navgraph is blocked, I have the robot state set to Error as per the robot state enum. At the same time, I’d like to set the currently executing task from underway to blocked, which is one of the valid states in the task states enum. Since this is not supported at the moment, I’ll go by your recommendation to use logs instead, but perhaps the RMF team could consider adding this interface to the RobotCommandHandle as a new feature at some point if it sounds useful.
Thank you for your help!
Posted by @aaronchongth:
There is currently support for setting blocked to action executions, which are custom user-defined actions for robots, rmf_ros2/rmf_fleet_adapter/include/rmf_fleet_adapter/agv/RobotUpdateHandle.hpp at main · open-rmf/rmf_ros2 · GitHub, but not for the default navigation commands. It could certainly be added from the TaskManager side and subsequently in the RobotUpdateHandle as well. Since this might be useful for your use case and possibly many others, would you like to implement and contribute it upstream?
Posted by @dennis-thevara:
My team and I were considering the possibility that we’d have to implement this feature. We could certainly explore that and see if we can get it to work. I’ll keep you posted if we’re able to put it together soon.