Issues about fleet_adapter_template implementation

[Villy01]

Hi, I'm working on a project using rmf_deployment_template. I'm using Ubuntu 24 LTS and ROS2 Jazzy. I'm trying to deploy an adapter for my robot fleet via fleet_adapter_template. I managed to implement a working adapter, but I'm encountering some issues.

• At the start of the adapter, the robots are added to the fleet, they are assigned an ID, and then a task is launched to send the robots to a charging station. Is it possible to modify or remove this last operation? The problem specifically lies in the fact that the parking task is executed as if it were navigation to a point. The robot moves correctly towards that point, but it doesn't connect properly to the docking station because it doesn't approach in the right direction.
• When I try to launch a task, for example, a delivery task, without selecting a robot, I can see from the logs that the task dispatcher starts the procedure to search for a robot and my robot sends its cost estimate, but then the task is never assigned. When I try to launch a task and manually assign it to the robot, however, it is executed without issues.

[xiyuoh]

Hi @Villy01 !

For your question regarding docking, there are 2 things you can do, depending on what your intended behavior is:

1. You can set the finishing request of your fleet to nothing to have them do nothing as an idle behavior, i.e. before and after tasks they will not automatically go to a specific waypoint to park or charge. You can also choose to set the request to park, and provide the parking waypoint name (example for tinyRobot1). This ensures that your robot navigates to a location you've chosen, instead of the docking station, and park there when not performing any tasks.

2. If you'd like to have it charging while idle, leave the finishing request as charge, and on your navigation graph, add a dock_name property to the charger waypoint. In your fleet adapter, you can implement a docking logic and trigger it for any waypoint with the dock_name property populated. We've implemented examples in our rmf_demos_fleet_adapter as well as fleet_adapter_mir. Let me know if you have further questions!

   Edit: I wanted to add that your robot will likely need to charge at some point anyway, so regardless of what the configured finishing request is, implementing a docking logic is the recommended way to go.

As for the task assignment issue, it'd help to provide some logs, videos/screenshots, commands, steps to reproduce, etc. in order for us to understand what's going on on your end and debug accordingly.

[xiyuoh]

One thing I noticed about the way you're retrieving nav_status is the lack of an identifier for individual navigation commands, which is likely the reason why your adapter is mistakenly reporting command completed to RMF. Consider this scenario:

• You sent a task for robot to travel from waypoint A to waypoint C, and the path to get there would be A-B-C.
• RMF will send navigation commands to each waypoint one by one: to A, then to B (after robot reaches A), and finally to C (after robot reaches B).
• In this case, RMF sends the navigation command to waypoint A where the robot is very near to, and the adapter reports is_command_completed() = True to RMF.
• RMF will then send the robot to waypoint B. However, since there are no identifiers for navigation commands to A/B/C, nav_status() will keep returning COMPLETED from the previous call for waypoint A. When the fleet adapter receives a navigation command to waypoint B, it would be immediately be marked as completed, even though the robot has not started moving.
• RMF would continue to send subsequent navigation commands until the task is supposedly completed, but the robot is actually still at the initial waypoint.

It might be helpful to refer to the way we track navigation commands by creating a cmd_id for each navigate and execute_action command in the rmf_demos_fleet_adapter - it allows us to differentiate between navigation commands to the robot. If your robot API itself has some kind of identifier that is similar to MiR's mission_queue_id (an identifier tagged to every mission posted to the robot), you can use that directly too.

Please update your adapter implementation and let me know if it works!

[Villy01]

I perfectly understood the case you described. I tried to implement a solution similar to the one you proposed, but the APIs of my robot do not handle the assignment of an ID for received commands.

In the two examples you sent me—the MiR example and the demo—the robots have this mechanism integrated into their APIs. Additionally, in the demo, there is also a fleet manager.

I was wondering, therefore, whether a system for managing IDs for each command is necessary for the adapter to function correctly, considering that it was not required for the Humble version.

And if it is necessary, why is there nothing in the template that refers to this?

[xiyuoh]

You are free to implement similar mechanism even if your robot API does not offer identifiers, off the top of my head the two approaches you can go with:

• Track goal instead of an in-built identifier, and only mark navigation as complete if the new navigation goal pose matches (or is very near to) the goal returned by nav_status(), or
• Track your own self.robot_status, and add a new enum IDLE = 5 under NavigationStatus to be used only within RobotClientAPI. With this you can toggle self.robot_status to IDLE once the previous command has been marked completed, then update it to MOVING when the robot starts performing the next command. You can use this status as a condition before returning True for subsequent calls to is_command_completed().

The main difference between Humble and Jazzy fleet adapters are the use and demonstration of the EasyFullControl library. While this library is compatible with Humble, we only officially released binaries from Iron onwards. The Humble demos fleet adapter also stores a current_cmd_id to ensure that we accurately track the progress of commands relayed to robots.

We don't add this to the template because as you can see different robots offer different APIs that require their own logics; we wouldn't want to restrict the way users implement their is_command_completed() callback. Managing identifiers is not always necessary, e.g. depending on update interval frequencies, some robots have their own IDLE status that is updated before the next navigation command is received, eliminating the need for such tracking. However, we do demonstrate with examples as shared above to showcase various ways to implement.

With that said, I agree that it'd improve clarity to highlight this in a comment within the template, and I'm happy to add a note in. Other than that, let me know whether similar or new issues come up after testing with these suggestions.

[xiyuoh]

Re: my previous comment

With that said, I agree that it'd improve clarity to highlight this in a comment within the template, and I'm happy to add a note in.

I notice the template already mentioned that the callback should return the completion status of the last command, so I won't be updating with any additional note.

[Villy01]

Thanks for the clarification and the advice! I just had to slightly modify RobotClientAPI, saving the current_goal, to keep track of the last assigned command.
The only issue that came up is that in the dashboard, in the task section list, the task status changes from queued when assigned to completed when it’s actually finished, but it no longer goes through the executing state. Do you happen to have an explanation for this?

Furthermore, I still have the issue where, when I don’t assign the task directly to the robot, it makes an offer but is never selected. I also noticed that if I send a direct task to the robot after a while, it executes it immediately.

I’ll send you some logs from different pod. In this case, I started the adapter, created a new task without assigning it directly to the robot, waited for a while, and then sent a new task, assigning it directly to the robot. The second task started immediately, while the first one never got assigned to the robot. Maybe you can give me some insights. Thanks a lot for all the support!

• task dispatcher
• fleet adapter