Posted by @samuelrawrs:
Currently cleaning tasks require a docker_config.yaml file that has to be filled in manually. Everytime you shift the points, you’ll have to edit the config file as well 
I made a python script to generate the yaml file from the building.yaml file but it still has several limitations (for now) like:
- needing to name your cleaning paths points as vertices: “<cleaning_zone_name>+_clean_0”, “<cleaning_zone_name>+_clean_1” and so on..
- needing to input building names, floors, cleaning zones, scaling as well as the xyz offsets
- only supporting one cleanerBot type at the moment
- yaml file looks abit messy but it works heh
I’ve been told that the long term plan that there is a “new” fleet adapter API that will do away the need for a docker_config file.
Would love to hear more about it @Yadunund !
Edited by @samuelrawrs at 2022-02-10T08:56:55Z
Posted by @Yadunund:
Hi @samuelrawrs
Thanks for raising this discussion and sharing your neat approach to deal with the problem.
The current implementation of the Clean task which relies on the DockRobot phase to trigger an external action was meant to be a temporary solution until a specific phase for cleaning was defined. The byproduct of this was the reliance on mock_docker.py and _docker_config.yaml file. The mock_docker script publishes a rmf_fleet_msgs/msg/DockSummary message which the fleet adapter receives for estimating the duration and battery drain of the robot while performing its cleaning. There are some ModeRequest/PathRequest mechanisms needed for the legacy full_control to command robots in simulation. This is kind of a misuse of the docking feature.
With the newly merged flexible task system, we’re allowing users to build up tasks (even at runtime) using “building blocks” of phases/events. Documentation on this is work in progress but @mxgrey has succinctly covered the parts that will be most relevant to you here
Here is an example of how you can submit a “composable task” for cleaning. As you can see, the task definition consists of one GoToPlace followed by one PerformAction event. The descriptions for these events can be found here while the schemas here. (The schemas is what you will need to follow when populating the json fields for the task request) If you look at the description for the PerformAction event, it can take in a time estimate and an optional location of where the robot will end up. This naturally replaces the whole DockSummary pipeline.
In the demo script, the description json is empty. But for your case, you can populate it with information that will be relevant to your cleaning. Eg. waypoints, speeds, suction power, etc. Then you will need to pass in an ActionExecutor to the RobotUpdateHandle of your fleet adapter. This function should basically validate/parse the category and description you populated here and accordingly ask the robot to do some action (in this case cleaning). Within that function’s definition, you should use the ActionExecution object that you get to update RMF on the progress of the cleaning (execution.update_remaining_time(~)) and finally call execution.finished() once the cleaning is complete. We have plans to allow users to submit updates on the trajectory of the robot during this action via the ActionExecution object, maybe via access to a Participant* object but this is left for future work. (Or perhaps you could help us with this and we can provide guidance along the way).
We’re currently making efforts to enhance the fleet adapters used to control the robots in our simulations and to better reflect ones that will be written in most practical deployments. Here’s a sneak peak of how it can be written to accommodate custom PerformActions (teleop in this case).
So in summary, with such composable tasks, especially PerformAction, users will no longer need to use the mock_docker or _docker_config.yaml files. It is strongly recommended to discontinue using the legacy Clean task as well.
Edited by @Yadunund at 2022-02-15T07:30:54Z