Supported Tasks in RMF

Clean Task:

清洁机器人在各种设施中越来越受欢迎。虽然清洁方式多种多样（吸尘、拖地、消毒等），因此清洁机器人的种类也很多，但它们的工作流程都相同。设施中的地板空间被划分为多个“区域”或子区域以进行清洁。每个区域都有机器人的起点和终点。在这些位置之间，机器人在执行清洁操作时会沿着特殊路径移动。

RMF 完全支持各种清洁机器人的集成。此外，RMF 可以根据能力和可用资源智能地将清洁工作分配给可用的清洁机器人，同时优化整体生产力。大多数清洁机器人都为每个区域预先配置了清洁程序，可以从给定的起点运行。 RMF 的目标是引导机器人到达这个起点，触发清洁程序的执行，然后在清洁完成后将机器人引导到等待路径点。 RMF 中设计了一个“清洁”任务来协调此行为。

本节的其余部分概述了将清洁机器人与 RMF 集成所需的步骤。rmf_demos 中的 airport_terminal 示例是一个有用的参考。它展示了两个品牌的清洁机器人的集成：CleanerBotA 和 CleanerBotE，它们分别在导航图 Graph 0 和 Graph 4 上运行。

Step 1: Defining waypoints for cleaning in Traffic Editor

需要在机器人的导航图中添加两个航点。第一个是机器人应启动其清洁程序的航点。在下图中，此点标记为“zone_1_start”。一旦机器人完成其清洁程序，RMF 将引导机器人返回此航点。连接到此航点的是航点“zone_1”，其“dock_name”属性设置为其名称。这是机器人完成清洁程序后最终到达的航点。在当前实现中，重要的是将这些航点的名称分别设置为“<zone_name>_start”和“<zone_name>”。当机器人从“zone_1_start”进入“zone_1”的通道时，车队适配器将请求机器人启动其对接（在本例中为清洁）程序。将“dock_name”参数设置为“zone_1”将导致车队适配器触发“RobotCommandHandle::dock()”函数。因此，用户实现该函数时应依次向机器人发出 API 调用，以开始清洁指定区域。清洁过程完成后，“RobotCommandHandle”应触发“docking_finished_callback()”。

Note: 为了触发DockPhase，车道的方向需要从<zone_name>_start到<zone_name>。

第 2 步：发布 DockSummary 消息

为了估计清洁过程中的资源消耗（这对于最佳任务分配规划至关重要），车队适配器需要机器人在清洁时将穿越的航点列表。此信息可在发布到 /dock_summary 主题的 DockSummary 消息中进行汇总。 mock_docker 节点负责发布此信息。它接受一个 yaml 配置文件，其中包含每个机队每个区域的航路点列表，用于填充 DockSummary 消息。对于 airport_terminal 演示，文件位于此处

步骤 3：配置舰队适配器以接受清理任务

舰队适配器需要配置为接受 Clean 类型的任务。否则，在任务竞标期间，它不会向调度程序节点提交此任务的竞标。如果正在使用旧版 full_control 适配器，则需要在适配器启动文件中将 perform_cleaning 参数设置为 true。对于较新的舰队适配器，应使用以下方式调用 FleetUpdateHandle::accept_task_requests() 方法： AcceptTaskRequest 回调，如果收到带有 TaskProfile.Description.TaskType.TYPE_CLEAN 的请求，则返回 true。

步骤 4：发送清理请求

如果上述步骤正确完成，则可以通过终端或 RMF_Demo_Panel 向 RMF 提交清理区域的请求。要从终端发送清理请求，请使用 RMF 获取工作区，然后：

ros2 run rmf_demos_tasks dispatch_clean -cs zone_1 -st 0 --use_sim_time

This will submit a request to RMF to clean zone_1. The --use_sim_time argument is only required when testing in simulation. For more information on sending a clean request:

ros2 run rmf_demos_tasks dispatch_clean -h

配送任务：

移动机器人的另一个常见应用是在设施内进行配送。配送通常涉及机器人前往取货地点，在那里装载物品，然后导航到卸货地点，在那里卸载物品。在取货和卸货地点，移动机器人可能必须与机械臂、传送带或其他自动化系统交互。我们将装载物品的系统称为“分配器”，将卸载的系统称为“摄取器”。

为了将这些系统与 RMF 核心系统集成，定义了一组 dispenser 和 ingestor 消息。尽管名称不同，但这些消息足够通用，可供执行类似操作的任何其他系统使用。

RMF 中设计了一个 Delivery 任务，用于引导移动机器人到达分配器所在的拾取位置。到达此处后，其 rmf_fleet_adapter 会发布 DispenserRequest 消息，工作单元会接收该消息并开始处理。装载成功后，分配器会发布状态为 SUCCESS 的 DispenserResult 消息。然后，rmf_fleet_adapter 会引导机器人到达摄取器所在的下车航点。在这里，确保了类似的消息交换。rmf_fleet_adapter 发布 IngestorRequest 消息，指示摄取器卸载其有效载荷。完成后，它会发布状态为 SUCCESS 的 IngestorResult 消息。

要了解如何设置带有分配器和摄取器的模拟，请参阅模拟

需要将舰队适配器配置为接受“交付”类型的任务。否则，在任务竞标期间，它不会向调度程序节点提交此任务的竞标。如果正在使用旧版“full_control”适配器，则需要在适配器启动文件中将 perform_deliveries 参数设置为“true”。对于较新的舰队适配器，应使用以下方式调用 FleetUpdateHandle::accept_task_requests() 方法： AcceptTaskRequest 回调，如果收到带有 TaskProfile.Description.TaskType.TYPE_DELIVERY 的请求，则返回 true。

要提交“Delivery”请求，可以使用“rmf_demos_tasks”中的“dispatch_delivery”脚本。

ros2 run rmf_demos_tasks dispatch_delivery -h
usage: dispatch_delivery [-h] -p PICKUP -pd PICKUP_DISPENSER -d DROPOFF -di DROPOFF_INGESTOR
                         [-st START_TIME] [-pt PRIORITY] [--use_sim_time]

optional arguments:
  -h, --help            show this help message and exit
  -p PICKUP, --pickup PICKUP
                        Start waypoint
  -pd PICKUP_DISPENSER, --pickup_dispenser PICKUP_DISPENSER
                        Pickup dispenser name
  -d DROPOFF, --dropoff DROPOFF
                        Finish waypoint
  -di DROPOFF_INGESTOR, --dropoff_ingestor DROPOFF_INGESTOR
                        Dropoff ingestor name
  -st START_TIME, --start_time START_TIME
                        Start time from now in secs, default: 0
  -pt PRIORITY, --priority PRIORITY
                        Priority value for this request
  --use_sim_time        Use sim time, default: false

循环任务：

可以提交“循环”任务，以请求机器人在两个航路点之间来回导航给定次数的迭代（循环）。与“清理”和“交付”任务一样，必须将车队适配器配置为接受“循环”请求。

要提交“循环”请求，可以使用“rmf_demos_tasks”中的“dispatch_loop”脚本。

ros2 run rmf_demos_tasks dispatch_loop -h
usage: dispatch_loop [-h] -s START -f FINISH [-n LOOP_NUM] [-st START_TIME] [-pt PRIORITY]
                     [--use_sim_time]

optional arguments:
  -h, --help            show this help message and exit
  -s START, --start START
                        Start waypoint
  -f FINISH, --finish FINISH
                        Finish waypoint
  -n LOOP_NUM, --loop_num LOOP_NUM
                        Number of loops to perform
  -st START_TIME, --start_time START_TIME
                        Start time from now in secs, default: 0
  -pt PRIORITY, --priority PRIORITY
                        Priority value for this request
  --use_sim_time        Use sim time, default: false

ChargingTask

这是一个自生成任务，由 RMF 车队适配器自生成。当满足充电条件时，机器人将被引导回充电站。用户可以通过在 traffic_editor 中将 is_parking_spot 设置为 true 来设置有效的充电站。

用户可以通过以下方式在 fleet_adapter.launch.xml 中配置充电条件：

充电阈值：<arg name="recharge_threshold" value="0.2"/>
完成请求：<arg name="finishing_request" value="charge"/>

请注意，目前 finishing_request 参数还支持：[charge, park, nothing]。这些被视为自动生成的任务。

调试

在某些情况下，当提交任务请求时，调度程序不会收到来自车队适配器的任何出价：

车队适配器未配置为接受由此函数确定的提交的任务类型。如果您使用的是 full_control 实现，则应在启动文件中使用这些参数指示哪些任务类型是可行的。否则，舰队适配器将不会竞标已提交的任务。终端中应发布一条消息，指出：[full_control-15] [INFO] [1617245135.071996222] [tinyRobot_fleet_adapter]：舰队 [tinyRobot] 配置为不接受任务 [Clean0]。如果您使用的是自定义车队适配器，请确保您正在调用FleetUpdateHandle::accept_task_requests()。
车队适配器无法处理请求，因为请求中的字段无效。例如，如果提交的loop请求的起始或结束航点在机器人的导航图上不存在，则不会提交出价。终端中将打印一条解释性消息，例如[full_control-15] [INFO] [1617245206.473805336] [tinyRobot_fleet_adapter]：车队[tinyRobot]在其导航图中没有配置命名航点[bad_waypoint]。拒绝带有task_id的BidNotice：[Loop1]
调度员接受出价的持续时间小于车队适配器计算和提交出价所需的时间。持续时间参数在此处指定。如果是这种情况，您仍应在终端中看到一些打印输出，突出显示车队适配器计算并提交了出价： [full_control-15] [INFO] [1617245621.881365568] [tinyRobot_fleet_adapter]：为 task_id 生成了 Loop 请求：[Loop2] [full_control-15] [INFO] [1617245621.881432804] [tinyRobot_fleet_adapter]：计划用于 [2] 个机器人和 [1] 个请求 [full_control-15] [INFO] [1617245621.886230967] [tinyRobot_fleet_adapter]：已提交 BidProposal 以适应机器人 [tinyRobot2] 的任务 [Loop2]，且成本为新值[45.222308]

单击此处了解如何开发对自定义任务的支持。

Programming Multiple Robots with ROS 2