IEEE Robotics & Automation Magazine - June 2020 - 163

Safety Features
In a remote-operation scenario for planetary exploration,
sudden changes in the environment may arise too quickly for
the operator to send each robot a timely command. To cope
with bursts of wind, for instance, we use a virtual GPS fence-
the geofence-according to limits set before takeoff [Figure 3(g)].
Additional layers of safety are required to cope with communication and human errors. For example, when setting a goal,
the destination's distance is verified to be reachable in fewer
than 30 s (for example, fewer than 300 m if the UAV maximum velocity is 10 m/s). This verification is done on input,
before sending the command, and again by the receiving
robot. As the robots generate their own trajectories, they can
use the known locations of their neighbors to avoid each
other by applying a decentralized collision-avoidance algorithm [17]. To minimize risk of collision, we also flew UAVs
at different altitudes.
For each robot, the potential sources of failure increase
with its mechanical, communication, and instrumentation
complexity. If a robot self-detects an imminent failure, it can
upload its current state and mission role to the fleet's shared
memory using a mechanism derived from the virtual stigmergy for larger data [18]. Its identity will then be accessible
so that another available unit can take over its mission. To
achieve system-wide robustness, we wrapped a consensus
strategy around the various critical steps of the mission.
Before takeoff and before accepting user inputs, all members
of the team verify that enough units are available and ready to
execute the next task. If a UAV does not get acknowledgment
from its expected number of neighbors, it hovers, waiting up
to two minutes for the missing teammate(s) to arrive. If the
issue is not resolved, the hovering drone will broadcast a

message to let the team know that the next step cannot be
processed in the current state. Then, the robot will either
remain in its current state or proceed to the landing zone,
according to the operator's preference. In this regard, the
operator is also considered a member of the fleet, and if the
link is broken, the same procedure will be triggered. The
safety mechanisms discussed in this section are illustrated
in Figure 3(g).
Operator Command and Control
A command center for exploration missions must ease the
optimization of strategic allocation of field resources, situational awareness, and collaboration among team members.
For deployed robotic systems, the command center design is
adapted to the robots' level of autonomy. Most space missions
fall between teleoperation and fully autonomous missions,
having several scripted behaviors as well as high-level commands [19]. Specific to robot teams, novel interaction modalities have been studied for shared autonomy using gesture
control [20], voice [21], and even full-body motion [22];
however, map-like interfaces are popular for critical scenarios
as they are familiar and leverage operators' existing skills [23].
For UAVs, a map-based interface is commonly referred to as a
mission planner: an application running on a ground station
monitoring the fleet. Currently available commercial mission
planners (such as DroneDeploy, DJI Go, and QGroundControl, among others) integrate maps and point-and-click waypoint selection to ease route design for operators.
Figure 4(a) provides a screenshot of the QGroundControl
mission planning software. As shown in Figure 4(b), our
interface is also based on a map service integrated in a browser control panel. This interface allows the operator to monitor
detailed aspects of each robot (battery level, current state, and
position) and send general instructions (for example, "Take
off" or "Go home") or specific commands related to the fleet
control mode (such as waypoint selection or fleet deployment). In all scenarios, the command center acts as a member
of the swarm, showing the other members' states and sending
updates to the virtual stigmergy data; there is no centralized

QGROUNDCONTROL

Each robot's memory contains two tables. The "neighbors"
table includes the virtual machine state and sensor output,
such as GPS (confidence and coordinates), networkdevice state (link quality), and battery level. The "mission"
table includes mission-relevant information, such as the
next goal(s) or the locations of landmarks of interest. Both
tables are reliably shared across the robot team through
Buzz's virtual stigmergy. In a nutshell, when a piece of
data is required by an individual robot, the team agrees on
who has its latest version, and the requester receives the
updated value through the shortest network path available
(that is, the one with fewest hops). This strategy optimizes
the use of the bandwidth, allowing the fleet to rely on
long-range-transmission devices with low data rates. In
previous experiments [16], we stressed our communication architecture and demonstrated that our consensus
strategy and information-sharing protocol were resilient
with up to 80% packet loss. Field tests showed that we can
rely on interrobot, one-hop links of more than 600 m
using 800-900-MHz radios (Digimesh Xbee S3B Pro
modules). The relations among the communication
device, Buzz virtual machine, ROS, and localization system are illustrated in Figure 2.

(a)

(b)

Figure 4. The mission planner screenshot. (a) A popular
interface, QGroundControl, with five waypoints defined for a UAV
route. (b) Our web-based minimal interface with a waypoint
popup menu (individual waypoint control).

JUNE 2020

IEEE ROBOTICS & AUTOMATION MAGAZINE

163

IEEE Robotics & Automation Magazine - June 2020

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