Fleet Management

Applications with more than one robot in operation at the same time in a shared environment often need some means of fleet management to ensure no crashes or deadlocks occur. PlatformPilot comes with several tools for fleet monitoring and management.

Note

Fleet management is a complex task, not exactly defined and often dependent on the exact application. These tools have been tested in a limited number of scenarios and should be considered experimental. Setting them up should be done by trained experts.

Third-party fleet managers can always use one of PlatformPilot’s command interfaces described at Programmer’s Manual which allow fine-grained monitoring and control of the platform.

Topology

The fleet manager runs on a dedicated PC that can be reached over the network by all robots. The robots then connect to the fleet manager which keeps track of the connected robots. The robots periodically send status updates (pilot.Beacon) which the fleet manager collects and aggregates. The server sends back a list of all registered robots and their basic information (pilot.RadarScan). User interfaces connected to one of the robots will use this information to show the other robots as well.

Fleet managers

There are three types of fleet managers suited for different tasks and differing on the level of control they exert.

AirControl
is the most basic form of fleet management. It only manages the data exchange as described above.
Supervisor
is a passive fleet manager. The robots plan and move on their own when receiving orders. The Supervisor keeps track of planned trajectories and sends back notifications about conflicts. The robots can take the information into account when planning and also pause movement when a conflict arises.
Tower
is an active fleet manager. Goals are sent to the Tower which then performs scheduling, conflict resolution and path planning, before sending the complete path to the robot. It also orders the robots to stop when necessary.

All flavours are contained in the pilot-core installation package. See Installation for installing.

Setup

Control PC

After installation, navigate into the Pilot home folder (usually ~/pilot/) and create a directory config/air. Any custom configuration should be placed in this folder. After that, start the process with one of the following commands:

./run_aircontrol.sh
./run_supervisor.sh
./run_tower.sh

depending on which variant you want to use.

Robot

In the Pilot home folder (usually ~/pilot/) create a file config/local/pilot_proxy_map+ with one of the following contents:

[
        ["AirControlProxy", "127.0.0.1:6766"]
]

[
        ["SupervisorProxy", "127.0.0.1:6767"]
]

[
        ["TowerProxy", "127.0.0.1:6768"]
]

where you substitute the actual IP address. PlatformPilot will connect to the remote PC at the next start.

Usage

A few things to note:

  • Path planning in a fleet management setting is always done based on a Road Map.
  • Only robots with the same grid map and the same road map are considered to be in the same environment. Conflicts between robots in different environments will not be detected.
  • Robots are identified by their ID which can be found in the robot’s pilot.PilotState message on topic platform.pilot_state. The ID of a robot is bound to the software process and changes on a Pilot restart.

AirControl

Only basic information exchange as described above.

Topics

Supervisor

When using the Supervisor, goals are sent to the robots which then plan their own path, just like in single robot mode. The robots send their position and path to the Supervisor (as part of the Beacon) which keeps track of roadmap elements that are blocked (robot is located there) and/or reserved (robot wants to use it in its path). When the Supervisor detects a conflict, i.e. a robot that tries to reserve a roadmap element that is already reserved or blocked, it sends a negative Clearance message until reservation of the complete path is possible. The robot pauses movement until it receives a positive Clearance.

The Supervisor also regularly sends an overview of blocked and reserved roadmap elements to the robots which then can use it to plan differently in order to prevent conflicts. Whether and how this happens can be configured on the robot with the config key fleet_mode of the RoadMapPlanner module.

Topics

Tower

When using the Tower, goals are sent to the Tower directly which does the path planning and only sends the finished path to the robots. The robots don’t do path planning on their own.

When a goal is set for a robot, the Tower plans a path from the robot position and then tries to reserve every roadmap element on the path for this robot, taking existing reservations into account. The path is only sent to the robot, once all conflicts have been resolved and all obstacles removed. Otherwise, the Tower will periodically retry to schedule the goal.

Reservations can be non-conflicting, for example driving a road in the same direction, but most combinations are in conflict. Every discovered conflict is analyzed for resolvability. A conflict can be resolved by

  • pausing the other robot before it enters the required section
  • waiting until the other robot has left the required section, if it was moving anyway, or
  • sending the other robot away (to a randomly selected non-conflicting station) if it is standing there.

A robot can only pause or send away another robot if it has a higher priority than the other robot. By default, all robots have priority 0. Priorities can be assigned to robots by the set_priority method (see below) and temporarily increased or decreased for one goal via the pilot.goal_options_t parameter in the set_goal_station method. The total priority is the sum of robot priority and the goal priority. Robots that are sent away temporarily gain the same priority as the robot that sends them away, so that they can recursively send away robots that are in their way.

Note

A robot is only considered an obstacle if it was moved to its current location by the Tower. This means that after the initial connection, a robot has to be given at least one goal in order to properly participate in traffic management.

Topics

Methods

These methods of the Tower module can be called through one of the interfaces described at Programmer’s Manual. The preconfigured user neo-erp has the permissions needed to execute them.

void set_goal_station(Hash64 robot_id, string name, goal_options_t options, Hash64 job)

Sets the given station name as the goal of the robot with this ID. The path will be sent to the robot once it was planned free of conflicts.

void stop(Hash64 robot_id, goal_options_t options)

Cancels the current goal of the robot and sends it to stop at the next map node on its path.

void set_priority(Hash64 robot_id, int priority)

Sets the priority of this robot as an arbitrary integer.