EasyFullControl fleet_adapter_mir and cart delivery PerformAction plugin

[xiyuoh]

This PR:

• Added note that marks MiRFleet adapter as inactive
• Switches MiR fleet adapter to use the EasyFullControl API
• Creates standard RMF missions from the fleet adapter via MiR's REST API calls so that users don't have to manually add them on the hardware. This also allows us to automatically create more missions on the MiR required by RMF in the future. Mission definitions can be found in rmf_missions.json.
• Various improvements on the fleet adapter, such as using mission queue IDs to monitor mission/task completion, better localizing process when switching maps to a new level, and an expanded list of RMF missions that help robots get to a MiR position more accurately instead of only relying on coordinates
• Adds a plugin system for MiR custom actions. Plugins can be defined and configured inside mir_config.yaml
• Adds a CartDelivery perform action plugin that helps users to integrate delivery tasks with RMF. Users will need to create their own pickup and dropoff missions and specify the mission names inside mir_config.yaml. This plugin includes a task script for users to submit dispatch_pickup tasks. Remaining cart delivery related missions required by RMF can be automatically created on hardware during runtime by parsing rmf_cart_missions.json.

One major flaw in this fleet adapter is the is_charging function inside robot_adapter_mir.py. As far as I know and after checking with vendors, there doesn't seem to be a MiR API that we can use to check whether the robot has begun charging. The MiR status provides a mode_id and state_id, currently there's no known state/mode for charging. Will experiment with hardware to verify this.

Tested on hardware with MiR200 and MiR250:

• Standard RMF mission creation (rmf_missions.json)
• Fleet adapter able to launch and run
• MiR able to perform patrol tasks and map switch
• RMF cart delivery mission creation (rmf_cart_missions.json)
• MiR able to perform delivery tasks

[xiyuoh]

Update from MiR vendor: no available indication of when the robot has started charging. There is no existing state_id or mode_id meant for that data. Using mission status text is currently the only way to verify whether charging has started.

[mxgrey]

There are a lot of excellent designs in this PR. Using the json files to define the MiR missions, and then loading and configuring them at startup is fantastic.

This PR presents a huge improvement over the previous state of the fleet adapter. There's only one problem: The current approach to plugin support does not actually support plugins. Instead the only way a downstream user can integrate or customize their own actions is to fork the source code of this repository and edit it.

At first I considered accepting this as a temporary limitation, merging the PR as-is, and then improving the situation later. However, I'm concerned that early adopters of these changes will end up being punished with a diverging code base after forking as needed. That makes it difficult for them to take in improvements that we're going to make in the future and it also discourages downstream users from contributing anything upwards.

I also feel that the gap to support plugins from where this PR is right now is actually not very large. The key thing will be understanding how to use importlib to load a module and then getattr to instantiate a class from that module. I left a few tips in my inline comments, but let's talk about this more in person when we have a chance.

[xiyuoh]

After our previous discussion, I've refactored the way we are creating MirAction objects in this new plugin system. They are now

• Only created when a task comes in with the performable action, and destroyed when the task is completed
• Created via an ActionFactory, and is tracked in the RobotAdapter under self.current_action
• More accurate plugin system with the use of importlib to import the relevant modules

[xiyuoh]

Thanks for the meticulous review @mxgrey ! I've gone through another round of refactor, with the following changes:

• Import action plugins and any supporting modules only once at startup. Each plugin's ActionFactory is instantiated once, and the adapter stores these factories in a dictionary. The dictionary key is the plugin_name as opposed to the suggested action name, as each plugin/ActionFactory could support multiple actions.
• Using an ActionContext to store important handles needed throughout the plugin.
  After some thought, I decided to create the ActionContext at startup and exclude execution. This is because the ActionFactory may need access to some of the ActionContext members (e.g. access to MirAPI for creating missions) before a perform_action() is called.
• At startup, the ActionFactory ensures that the imported config file contains a list of supported actions, otherwise it raises an error (55b8877). Depending on whether an action missions JSON filepath is provided, it will create the plugin-related mission on the robot. This mission creation step was previously inside the MirAction.init(), which meant that the adapter had to check for existing missions at every perform_action() call.
• Raise errors if plugin-specific keys are not provided in the rmf_cart_delivery config: 55b8877
• Added ActionFactory.supports_action() and implemented in rmf_cart_delivery
• Splitting CartDelivery into CartPickup and CartDropoff. I think it would be a better demonstration of what you mentioned about a single plugin supporting multiple actions.
• Adding cancellation behavior to dispatch_delivery. This ensures that if the delivery task is cancelled in the middle of a cart pickup, the robot will dropoff the cart before ending the task.
• Some fixes to the existing CartPickup and CartDropoff logic
• Minor fixes and improvements to address review comments: a153c8d, cecab1e, 9610e97
• Better documentation (30d58ff). The links provided to the new docs in README are pointing to the main branch, which doesn't exist right now. Here are the newly added mir_missions.md and mir_actions.md.

[mxgrey]

This PR is looking very good and getting super super close.

I left just a few more items of feedback which I think should be pretty straightforward to address. After those are done we should be fully ready to merge.

[mxgrey]

Awesome, thanks for all the massive iterating.

This is without question the most professional and modular RMF fleet adapter known to exist. As we work on the next generation of Open-RMF's SDK we'll definitely want to take advantage of lessons learned in this effort to figure out how to lift as much of this upstream as we can.

Great job bringing this to completion 🎉

[xiyuoh]

Thanks Grey, really appreciate the detailed review! I've updated with the changes mentioned since they're small and quick to add in. I'll have to trouble you to look at 45ac09a that I just pushed, it happens to remove the exception message with the grammar mistake.

Edit: missed out 3045bcc