IEEE Robotics & Automation Magazine - June 2020 - 164

control. Path planning and collision avoidance are computed
onboard each UAV (Figure 5).

164

Waypoint Selection Mode
When operating under the waypoint selection mode, our
command center displays many of the features that are common to other mission planners, such as the one in Figure 4. In
this mode, each robot is controlled individually: the operator
clicks on the map and selects the desired robot from a pop-up
menu, generating a target waypoint. This is repeated for every
robot, resulting in individual goals [Figure 3(c)]. The waypoint command generated is sent to the UAV closest to the
ground station and then propagated throughout the fleet.
While the mission planning strategy is centralized around the
user sending commands, communication is decentralized to
ensure tolerance to link and robot failures [24]. With our
infrastructure, each waypoint can also be attributed to any
other UAV, since the list is shared among the fleet. This is a
task allocation optimization problem, and there are several
solutions in the literature, for instance [25], which ensures
that a goal not reached by its associated robot will be put back
in an active list of goals for another robot to pick.
At any time during the mission, the user may clear the
waypoint list, triggering the fleet to switch to its hovering
state until further instructions arrive. The user may also
dynamically change the waypoints, even if the targeted UAV
has not yet reached its goal. By doing so, a fast operator can
act as if he or she is teleoperating all of the UAVs simultaneously. However, dynamic individual control requires constant
monitoring and input. Therefore, cognitive resources are a
limitation on swarm size, as each additional robot receives
less individual attention, may be neglected, and may become
ineffective for part of its exploration time [26]. Furthermore,
additional operator tasks, such as communicating with
human teammates, increase the operator's cognitive load
[27], leading to slower deployment of robots.

Self-Deployment Mode
In the more autonomous mode, the operator identifies several hotspots that may be worth exploring. This control
mode exploits concepts from computational geometry to
implement enhanced autonomy within the fleet. The locations received from the operator are shared across the whole
fleet, and each robot computes a minimum convex polygonal region of interest [Figure 3(e)]. This region is then split
into cells to be distributed among the swarm members, a
process known as surface tessellation. Some applications,
such as search and rescue and sensor-network deployment,
already use similar approaches [28]. To provide uniform
coverage of the area to be explored, we select the Voronoi
tessellation, for which cells contain all points that are geometrically closer to their center. For deploying robotic
teams, the initial positions can be taken as seeds to the tessellation problem. A possible implementation consists of
creating a frontier (line) halfway between each seed (that is,
robot) and merging these lines into polygon edges. Distributed computation of the Voronoi tessellation was extensively
studied for multirobot deployment [29]. We use the sweeping line algorithm (Fortune's algorithm), which is one of the
most efficient ways to extract cell lines from a set of seeds
[30]. We then cut the open cells using the user-defined convex polygonal boundary. From this point on, each robot has
knowledge of its Voronoi cell's limits. To reach a uniform
distribution of robots in the area, we use a simple gradient
descent toward the centroid of each cell [28]. If one of the
robots is not yet in the region of interest, it takes a random
location goal inside the zone and becomes a seed for the
uniform deployment as soon as it enters the region. Each
robot recomputes the tessellation following updates on the
relative position of its neighbors; an approach that is robust
to both packet loss and dynamic inputs. The operator can
change the shape and location of the region of interest at any
time, and the robots adapt accordingly.

Figure 5. German astronaut Matthias Maurer wearing eye-tracking
glasses (Pupil Labs) while conducting an exploration mission.
He holds a tablet running the mission planner and observes
the UAVs' reactions to input. In the background, team members
offer suggestions during familiarization training and stand by to
assume manual control of the UAVs in case of an emergency.
(Source: ESA; used with permission.)

Operator Cognitive Load
Controlling larger numbers of robots is likely to increase the
cognitive load of the operator [31]. Cumulative cognitive
load might be a function of the attention required to supervise the robots [32], a robot's performance and autonomy
when left unattended [33], and the need to manage dependencies among robots when they must coordinate to perform a task [34], in addition to other mission requirements,
such as communication with teammates. The field of HSI
specifically addresses the tension between a central element
of control and a decentralized system [35]: a human operator issues commands to a swarm that may dynamically
organize its configuration and the interdependencies
between its robots. In the literature, most HSI studies are
conducted in simulation. However, human behavior in realworld applications differs from that in simulations [36], suggesting that the operator's cognitive activities might also
differ contextually. To avoid the issue, we conducted experiments with physical robots.

IEEE ROBOTICS & AUTOMATION MAGAZINE

JUNE 2020

IEEE Robotics & Automation Magazine - June 2020

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - June 2020