The Pluggable Distributed Resource Allocator (PDRA): a Middleware for Distributed Computing in Mobile Robotic Networks

03/30/2020 ∙ by Federico Rossi, et al. ∙ NASA 0

We present the Pluggable Distributed Resource Allocator (PDRA), a middleware for distributed computing in heterogeneous mobile robotic networks. PDRA enables autonomous agents to share computational resources for computationally expensive tasks such as localization and path planning. It sits between an existing single-agent planner/executor and existing computational resources (e.g. ROS packages), intercepts the executor's requests and, if needed, transparently routes them to other nodes for execution. PDRA is pluggable: it can be integrated in an existing single-robot autonomy stack with minimal modifications. Task allocation decisions are performed by a mixed-integer programming algorithm, solved in a shared-world fashion, that models CPU resources, network bandwidth, and latency requirements, and minimizes overall energy usage or maximizes reward for completing optional tasks. Simulation results show that PDRA can reduce energy and CPU usage by over 50 representative multi-robot scenarios compared to a naive scheduler; runs on embedded platforms; and performs well in delay- and disruption-tolerant networks (DTNs). PDRA is available to the community under an open-source license.



There are no comments yet.


page 1

page 4

page 8

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Multi-robot systems have been increasingly investigated in domains where single-robot missions have dominated for decades, including space, underwater and subterranean exploration. Heterogeneous architectures are especially promising: for instance, heterogeneous robots can explore rough terrains or caves with a multitude of mobility modals (e.g., drones, rovers, climbers), and orbiter-lander architectures can enable agile science and share communication and computation resources in planetary exploration.

Crucially, mobile multi-robot systems can share computational tasks, especially if they have heterogeneous computation capabilities – for instance, a ground rover can offload expensive computations to an orbiting asset, or to a nearby “base station”. Previous work [1, 2] has shown that computation sharing in robotic systems with heterogeneous computing capabilities (e.g. Mars exploration scenarios) can lead to significantly increases in system-level performance and science returns.

Realizing this computation-sharing paradigm within a multi-robot system requires not only algorithmic tools to allocate tasks (e.g., automated planning and scheduling tools), but also software architectures that enable transparent sharing of computational workflows through available communication channels. Furthermore, it is especially desirable for such architectures to allow seamless integration with existing mission executives and existing robotics software libraries (e.g., the Robot Operating System, or ROS, ecosystem), thus enabling existing autonomy architectures to adopt computation sharing with minimal changes.

Fig. 1: PDRA high-level architecture (green box) and supporting processes.

To realize this paradigm, in this paper we propose a plug-in middleware to transparently distribute computational tasks across a network of agents with time-varying network connectivity. The middleware is called the Pluggable Distributed Resource Allocator (PDRA) and it is designed to:

  • offer easy integration with existing planning and execution systems and existing computation computation libraries.

  • be compatible with ROS (in particular with the ROS actions library) and also easily portable to other development environments (e.g., the F-Prime flight software framework [3]);

  • operate in both time-invariant networks and Delay/Disruption Tolerant Networks (DTNs);

  • be open-source and available to the robotics community;

To allocate tasks to robotic agents, we propose a novel mixed-integer linear programming task allocation algorithm designed for networks with

periodic connectivity (e.g. orbiter-rover and data muling scenarios). We show that the algorithm can solve task allocation problems with tens of agents and hundreds of task in seconds, even on embedded computing platforms. For networks with non-periodic network connectivity, the PDRA architecture can readily accommodate other existing scheduling and task allocation algorithms.

Our implementation of PDRA is available under the permissive Apache open-source license at

I-a Literature Review

A number of middleware for robotic systems support distributed or concurrent processing, communication, and message passing between agents. Examples of middleware are the popular ROS, its successor ROS2, ZeroMQ, F-prime, Lightweight Communications and Marshalling (LCM) and MOOS-IvP. However, these middlewares do not automatically redirect tasks among the agents based on their availability, connectivity and state, relying on the agents’ executives to select available computation resources. Also, crucially, many of these middlewares require continuous connectivity between agents, where communication disruptions might make certain cooperative behaviors unreliable or non-functional. In contrast, the proposed PDRA seamlessly handles intermittent connectivity when paired with a suitable transport layer (e.g., DTN [4]).

At its core, the proposed approach relies on a task allocation mechanism that maps processing tasks to agents. A number of such task allocation algorithms for networked vehicles have been proposed in the literature within the AI planning, scheduling and robotics communities [5, 6, 7, 8, 9, 10, 2]. However, existing task allocation algorithms generally require tight integration with the agents’ scheduler/executive to implement the proposed task allocation; conversely, PDRA “plugs in” to existing single-agent scheduler/executives, enabling easier integration in existing systems. In addition, to the best of our knowledge, no existing algorithm simultaneously captures heterogeneous computation capabilities, periodically time-varying communication links, task precedence constraints, and optional tasks. Some existing planning and execution architectures for robotics can be adapted to offer capabilities similar to PDRA, the most popular being ROSPlan [11]. However, these frameworks have been mostly designed for continuous communication settings and centralized task allocation scheme. Conversely, PDRA targets applications that require intermittent communication and decentralized task allocation.

I-B Organization

The rest of this paper is organized as follows. In Section II, we formally define the problem that PDRA sets out to solve. In Section III, we provide a detailed description of the PDRA system architecture. Section IV describes the proposed MILP-based task allocation strategy for periodically-connected networks. Section V explores the performance of PDRA and of the proposed task allocation algorithm through agent-based experiments, including experiments with delay-tolerant networking and a human-in-the-loop demonstration. Finally, in Section VI, we draw conclusions and discuss directions for future research.

Ii Problem Statement

Consider a set of mobile robots with known, time-varying communication links between them, called Contact Plan

. A contact plan specifies a set of time windows when pairs of robots can communicate, and the corresponding estimated available bandwidth. Each robot executes its own

Software Network, i.e., a set of mandatory and optional computational tasks whose dependencies can be represented by a directed forest graph (an example is shown in Figure 3). Robots can cooperatively execute the tasks in their software networks by sending requests, input and output data across the nodes in the network, as long as all resource and temporal constraints are satisfied.

Ii-a Assumptions

We assume that:

  • Computational tasks are pure functions, that is, the output of a computational tasks depends exclusively on its inputs, and has no side effects and no state associated with it.

  • On each robot, an existing single-robot planning/execution process (denoted as an autonomy brain) dispatches computational tasks based on the software network through an inter-process communication (IPC) mechanism.

  • The software network that is dispatched by each robot is known to all robots (either statically or through a real-time consensus mechanism, discussed in Section IV-E).

  • Each robot is able to execute a (possibly empty) subset of the computational tasks by calling a set of local conputational resources. Each resource typically can fulfill one of the tasks in the software network.

  • The time and energy cost required to perform a given task on a given robot are known at execution time. If the time and energy cost are not known a priori, a real-time consensus mechanism is available to inform all robots of each robot’s costs.

  • The contact plan is known to all robots in advance.

  • A communication middleware is available to transport messages between the agents. The communication middleware can employ a store-and-forward mechanism and does not need to support acknowledgements.

Ii-B Goal

The goal of PDRA is to provide (1) an execution engine and (2) a distributed resource allocation system that, together, enable tasks to be transparently shared by robotic nodes. The following properties are the focus of PDRA’s architecture:

  • Distributed: PDRA should require no central server and work with intermittent communication links.

  • Optimized: PDRA should allocate tasks to agents (and their resources) so as to (approximately) optimize a given cost function, e.g., minimize energy use or maximize the number of optional tasks completed.

  • Pluggable: PDRA should be integrated with existing autonomy brains, existing robotic framework (in particular, ROS), and existing computational resources (e.g., ROS packages) with minimal effort, thus maximizing code re-usability.

  • Layered: PDRA should enforce, to the extent possible, layering in an agent’s protocol stack. In other words, PDRA should not be responsible for instantiating network transport services which, instead, should be provisioned from the network layer. Rather, PDRA should leverage existing networking layers such as TCP-IP and DTN.

Iii System Architecture

Figure 1 presents the high-level architecture of PDRA. Each robot runs an autonomy brain and several processes (e.g. ROS nodes) that provide computational resources. Additionally, two processes responsible for orchestrating task sharing across different nodes are also instantiated. We term them the dispatcher and the resource-obligation matcher, or ROC. The system also assumes the presence of a controller that provides the ROC with a consistent world view of the system state and tasks to be executed (discussed in Section IV-E), and a networking transport layer that handles inter-agent communications (discussed in Section III-A5).

The unit of information of PDRA is a dispatchable (akin to a packet in networking), which contains information about the task that must be executed and about the requesting agent. Dispatchables also contain metadata, namely a unique identifier and a time-to-live. Two types of dispatchables are defined, obligations and results. Obligations encapsulate a task to be sent over the network (i.e., the inputs to a pure function). Results are created in response to an obligation once the corresponding computational task is executed, and contain the output of the computation and the identity of the agent that completed the task.

PDRA also defines the concept of chained obligations that allow an agent’s autonomy brain to dispatch entire computational pipelines (e.g. the sequences of tasks shown in Figure 3) as a collection of dependent obligations whose inputs are the outputs of its predecessor. E.g., consider two tasks and such that the inputs to are the outputs of . Assume also that robot needs and performed, and its ROC indicates that should execute . Then, ’s autonomy brain dispatches and to its PDRA, which encapsulates them in a chained obligation and sends them to . , in turn, executes and generates a result for . As soon as the result of is computed, ’s PDRA creates a new obligation for and process it through its own dispatcher, eliminating an unnecessary round-trip between and . This feature is particularly useful in a DTN environment, where connectivity is dynamic and there are no guarantees as to when two nodes will be in contact.

Next, we provide a succinct description of all elements in PDRA.

Iii-a Dispatcher

The dispatcher is the main process for the execution engine of PDRA. It provides a set of front-end interfaces that intercept requests for computational tasks from the autonomy brain; a corresponding set of back-end interfaces that forward computation requests to on-board computational resources; one thread for a forwarder; a second thread for an acceptor; and a communication handler.

Iii-A1 Dispatcher Front-End

The dispatcher front-end is a shim layer that interfaces the dispatcher with the robot’s autonomy brain, effectively intercepting the autonomy brain’s calls to computational resources and re-routing them through the PDRA dispatcher. Specifically, requests for computational resources from the autonomy brain are transformed to obligations and sent to the forwarder; results from the acceptor are translated to the IPC protocol understood by the autonomy brain and delivered to it. By transparently replacing and mimicking the IPC mechanism understood by the autonomy brain, the front-end makes PDRA pluggable, i.e. it allows PDRA to be added to an existing single-agent autonomy brain with minimal integration effort. In our open-source implementation, we provide a dispatcher front-end for ROS actions. Similar interfaces can be build for ROS services or any other IPC protocol. The front-end also implement a timeout system: if no result is received for a given obligation after a given amount of time, the front-end reports to the autonomy brain that the computational task has failed. This prevents processing delays or lost packets from disrupting the operations of single-agent autonomy brains designed under the assumption of reliable IPC — a critical consideration due to possible network delays and disruptions present in DTNs.

Iii-A2 Dispatcher Back-End

The dispatcher back-end is another shim layer that interfaces the dispatcher with the robot resources, and its function is complementary to the front-end’s. The back-end receives obligations from the dispatcher front-end, translates them to the IPC protocol understood by the computation resources, and sends them to the resource. When a result is received from a computational resource, the back-end transforms it to a dispatchable result and sends it to the acceptor. In our open-source implementation, we provide a dispatcher back-end for ROS actions.

Iii-A3 Dispatcher Forwarder

The forwarder is responsible for receiving dispatchables from the front-end and routing them to the appropriate resource back-end or to the communication handler. Both obligations and results are processed by the forwarder, albeit using different logic. For obligations, the forwarder first determines where the obligation needs to be processed by consulting the ROC. If it determines that the obligation should be processed locally, then the forwarder sends it to the corresponding resource. Alternatively, the obligation is routed to the communication handler. If the requested resource is not known to the ROC, the forwarder attempts to execute it locally by sending it to the corresponding resource. If the ROC believes that a dispatchable should not be executed (e.g., an optional task can’t be scheduled within the system’s computational capabilities), the forwarder sends a result signaling execution failure to the acceptor. Results processed by the forwarder are sent directly to the communication subsystem, since a result intended for the local agent is never processed by the forwarder (only the acceptor handles it).

Iii-A4 Dispatcher Acceptor

The acceptor’s functionality is complementary to the forwarder’s. The acceptor receives dispatchables from the back-end and from the communication handler, and determines whether they should be delivered to the autonomy brain or routed to the forwarder for further processing. Obligations enter the acceptor exclusively from the communication handler. Therefore, the acceptor sends them to the forwarder which, in turn, will route them to the applicable computational resource. Note that, prior to performing this operation, the forwarder will consult the local ROC to ensure that this task should be performed locally (as it also does for obligations generated by the agent’s own autonomy brain). If the ROC believes the obligation should not be performed locally, the forwarder will route the obligation back to the communication subsystem. This ensures that PDRA is resilient to agents disagreeing on the overall task allocation: e.g., if robot sends an obligation to robot for processing, but ’s ROC believes the obligation should be processed elsewhere, will simply forward the obligation to the robot designated by its ROC. In pathological cases, obligations may be passed among agents in a cycle: to mitigate this, unfulfilled obligations are discarded after the time-to-live specified in their metadata. Results arriving from local resources or from the communication handler are also processed by the acceptor and delivered to the autonomy brain. Prior to that, however, the acceptor checks that no chained (dependent) obligations are present in the result. If that is the case, new dependent obligations are created and routed to the forwarder for further processing.

Iii-A5 Communication Handler

The communication handler is the interface between PDRA and the networking transport layer that is used to transfer data across agents. The transport layer is responsible for transferring raw packets between agents; the communication handler translates packets into dispatchables and vice versa. The communication handler can interface with a variety of inter-robot communication mechanisms including ROS channels, raw TCP sockets, DDS, and/or DTN. In our open-source implementation, we provide communication handlers both for ROS channels (for operations on static networks) and for JPL’s Interplanetary Overlay Network (ION) implementation of DTN [4] (for operations on dynamic networks).

Iii-B Resource-Obligation Matcher

The Resource-Obligation Matcher (ROC) allocates tasks to agents based on the agents’ computational capabilities, on the available network bandwidth and latency between the agents, and on the software network. The interface between the ROC and the dispatcher is a dynamically updated look-up table that specifies where each task should be executed. In Section IV, we propose a MILP-based task allocation algorithm designed for networks with periodic or static connectivity that can return optimal task allocations in under a second for systems with dozens of agents and hundreds of interdependent tasks. The algorithm is implemented in a distributed fashion through a shared-world approach where each agent shares relevant information about its state with all other agents, similar to our prior work in [2].

The light coupling between the ROC and the dispatcher allows the integration of other task allocation algorithms. For networks with time-varying communication links that do not exhibit periodicity, we advocate for the use of the MILP-based algorithm presented in [2], which captures arbitrary time-varying communication networks at the price of increased computational complexity. A variety of other task allocation approaches are also available, including auction algorithms [8, 9] (although capturing bandwidth and throughout constraints in auction algorithms is challenging) and AI planners [5, 6, 7, 10].

Iii-C Simulation and Supervision

Fig. 2: Simulation framework and visualization for PDRA. Left: the overall system view shows agents’ locations and battery levels, network link bandwidths, tasks allocated to agents, and tasks being performed. Right: the single-agent view allows manipulation of the computational capabilities and location (a proxy for network bandwidth) of individual agents.

We developed a set of agent-based simulation and supervision tools to assess the performance of PDRA. The simulation framework allows users to create and edit scenarios with varying number of agents with heterogeneous computational capabilities, and change communication bandwidths between agents, through the grapical user interface (GUI) shown in Figure 2. The GUI also enables real-time monitoring of task allocation and execution, and it was successfully used with non-expert users in a human-in-the-loop demonstration at the 2019 ICAPS conference, described in Section V-D.

Iv Allocating tasks in a mobile robotic network

In this section, we propose a task allocation algorithm suitable for multi-agent systems with periodic or static network connectivity. First, we describe a centralized implementation. Next, in Section IV-E, we show how the algorithm can be used in a distributed system through a shared-world approach.

The goal of the algorithm is to allocate computational tasks to agents while satisfying constraints on:

  • Logical dependencies between tasks: certain tasks require as input the outputs of other tasks;

  • Maximum latency of data products: the inputs to a task must be delivered to the agent performing it within a maximum latency from the moment they are computed;

  • Maximum computational load of computing agents;

  • Maximum throughout of communication links.

We cast the problem as a mixed-integer linear program (MILP) in a network flow framework. Namely, data products transmitted from a task to another are modeled as a network flow with an origin at the agent performing the parent task and a destination at the the agent performing the child task.

The key modeling assumption of the task allocation algorithm is that the average available throughput on communication links is approximately constant over a representative time period . With this assumption, the problem is modeled through a time-invariant graph, where nodes represent agents, edges represent communication links, and binary decision variables capture the allocation of tasks to agents.

Iv-a Problem Parameters

The problem is parameterized by the following properties:

  • , the time period of interest;

  • , the set of computational tasks to be allocated in the time period of interest;

  • , the set of tasks that require task ’s data products as inputs. Tasks are denoted as children of ;

  • , the size of the data product of task , in bits;

  • , the set of required tasks that must be executed;

  • , the set of optional tasks;

  • , the reward for planning the execution of optional tasks ;

  • , the set of available agents;

  • , the set of pairs of agents that can directly communicate through a radio link;

  • , the computational load (i.e., the average fraction of a CPU core, averaged over the time period ) required to perform task once on agent ;

  • , the average power required to perform task once on node over time , in W;

  • , the computational load (i.e., the fraction of a CPU core) required to encode one bit of information per second on the outbound stream on link ;

  • , the computational load to decode one bit of information per second from the inbound stream on ;

  • , the energy (in J/bit) required to encode and transmit one bit per second on the outbound stream on link ;

  • , the energy (in J/bit) required to decode one bit per second from the inbound stream on link ;

  • , the maximum available throughput (in bits/s) on the radio link ;

  • , the light-speed latency of link (in s);

  • , the maximum computational load of node (i.e., the number of CPU cores available at node );

  • is the maximum acceptable latency (in s) for the data products of task required by task .

Iv-B Optimization Variables

The optimization variables are:

  • , a matrix of Boolean variables of size by . is set to 1 if task is assigned to agent and otherwise;

  • , a matrix of real-valued variables of size by . is the amount of data products of task (in bits per second) transmitted on link and that will be used as input by task ;

  • , a matrix of real-valued variables of size by . is the amount of bandwidth used by data products of task on link (irrespective of the destination).

The variables keep track of data products separately according to the requiring child task; this enables the proposed model to to (i) capture the average latency of the data products to multiple destinations (as discussed in Section IV-D2) and (ii) represent logical dependencies between tasks by considering the requiring task as an “information sink”. However, identical data transmitted on the same link should not be duplicated, irrespective of the destination. Variables capture the fact that, in a practical implementation, different data flows containing the same underlying data product are de-duplicated and transmitted once per communication link.

Iv-C Optimization Objective

The optimization objective is the weighted sum of two terms capturing (i) a reward for completing optional tasks and (ii) the power required to solve the problem. The individual cost functions can be captured as follows.

  • Maximize the sum of the rewards for completed optional tasks:

  • Minimize the power cost of the problem:


The optimization objective can then be expressed as , where is the relative weight of the two reward functions.

Iv-D Problem Formulation

The problem can be posed as a mixed-integer linear program as follows.

subject to:

Equation (2b) ensures that all required tasks are allocated. Equation (2c) ensures that optional tasks are allocated at most once. Equation (2d) (discussed in Section (IV-D1)) ensures that nodes only execute a task if they have access to the data products of its pre-requisites. Equation (2e) ensures that the variable is an upper bound on the data throughput used by data products of task . Equation (2f) enforces that the computational capacity of each node is not exceeded. Equation (2g) ensures that the transmissions on a link do not exceed the available bandwidth. Finally, Equation (2h) (discussed in Section IV-D2) guarantees that data products are delivered to dependent tasks within a maximum acceptable latency.

Iv-D1 Prerequisites

Equation (2d) ensures that a copy of the data product of task is created at the node where task is performed, and it is consumed at the node where task is performed. At other nodes, information can be relayed, but neither created nor destroyed.

Iv-D2 Latency

Equation (2h) ensures that the average latency of data products of task used by task is smaller than . The latency for the data products of task destined for task on a given path is . If data products are sent on multiple paths , with path carrying a fraction of the data product, the average latency is:

The flow captures the sum of path flows on all paths carrying data products of for task . The overall amount of flow on all paths is the size of the data product divided by the time period . Accordingly, the average latency can be rewritten as

in accordance with Equation (2h).

Iv-E Distributed Implementation

Solving Problem (2) requires knowledge of global information from all agents, namely the network bandwidths, the agent’s computational capabilities, the set of tasks that should be allocated, and task computational loads, power requirements, and rewards.

In order to achieve a truly distributed resource allocator, we advocate for a shared-world approach where agents share global information with each other through a message-passing protocol (e.g., gossip or flooding [12]). Each agent maintains a world model containing an up-to-date representation of the global system state, and solves Problem (2) based on its world model.

For many applications, only a moderate amount of communication is required to build a world model at execution time. If the type of agents that will participate in PDRA is known before deployment, the agents’ computational capabilities can be parametrized by a small number of bits (corresponding, e.g., to battery level). The set of tasks to allocate can also be generally represented in a compact fashion; for instance, agents executing the software network shown in Figure 3 only need to transmit one bit of information to inform others of whether they want to allocate tasks in the “science” task chain. Finally, bandwidth on radio links is typically negotiated by the communication protocol among a limited number of options; for instance, the 802.11g WiFi specification allows up to eight possible bandwidths, and the Zigbee specification only provides a single bandwidth.

Nevertheless, networking disruptions can cause the agents’ world models to temporarily disagree, which may result in inconsistent task allocations. The design of PDRA is relatively robust to such inconsistencies: whenever an agent receives an obligation that its ROC believes should be processed by another agent, the obligation is simply forwarded to the agent designated by the ROC. Pathological cases where obligations are forwarded in a cycle are prevented by endowing obligations with a maximum time-to-live.

Iv-F Discussion

A few comments are in order.

The proposed task allocation algorithm is designed for networks with time-invariant and periodic connectivity (e.g., scenarios where an orbiter periodically overflies agents, or where a vehicle periodically visits agents). In particular, the computational loads, bandwidths, and energy costs can be interpreted as time-averaged quantities over the time period . When a solution to the task allocation problem is executed with the PDRA, tasks are dispatched and messages are exchanged in order of arrival; while computation nodes and communication links may be temporarily oversubscribed, if the time period  is chosen to be a multiple of the communication network’s period, the average CPU usage and network throughput will match those prescribed by Problem (2). Numerical experiments in V-C show that PDRA and the ROC perform well over a network with periodic connectivity and equipped with a delay-tolerant networking layer, employing a traveling agent as a “data mule” to share computational loads across agents that can never communicate instantly. We emphasize that the proposed algorithm is not suitable for networks with time-varying, non-periodic connectivity. In these scenarios, we advocate for use of the scheduling algorithm proposed in [2], which explicitly captures the network’s time-varying nature at the price of significantly increased computational cost.

V Experiments

V-a Experiment Setup

We assessed the performance of the PDRA and of the proposed task allocation algorithm on a variety of scenarios where robots with limited computation capabilities (inspired by JPL’s PUFFER robot [13]) execute the software network in Figure 3. All agents must perform the “housekeeping” task chain (top). Selected agents can also perform optional tasks in the “science” task chain (bottom). Agents are aided by a “base station” equipped with a powerful and efficient CPU; the base station’s computational resources must be shared among all agents. Bandwidths between agents are determined based on their locations and on a simple distance-based threshold model.

Fig. 3: Software network used in numerical experiments. All robots must perform “housekeeping” tasks in task chain (a). Selected robots can also perform optional tasks in the “science” task chain (b). Computational tasks that can be shared are represented in gray. Each task is characterized by its input, output, as well as the estimated durations when running in different robots. Output and input data volumes determine the duration of data transfer operations.

V-B Task Allocation Performance

First, we assessed the performance of the proposed task allocation algorithm by solving randomly-generated instances of Problem (2) with an increasing number of agents. For each instance, the number of agents (proportional to the number of tasks to allocate) was varied from 1 to 15 agents to assess the scalability of the proposed approach. The problem was solved on several computing platforms, specifically:

  • a modern Intel Xeon workstation equipped with a 10-core E5-2687W processor;

  • an embedded Qualcomm Flight platform equipped with a APQ8096 SoC;

  • a Powerbook G3 equipped with a single-core PowerPC 750 clocked at 500 MHz, the same processor (albeit with higher clock speed) as the RAD750 used on the Curiosity and Mars 2020 rovers [14].

The MILP was solved with the SCIP solver [15]. For each problem, we computed the time required for the solver to find and certify an optimal solution, and the quality of the best solution obtained after 10 seconds of execution. Results are shown in Figure 4.

Fig. 4: Left: Time required to solve Problem 2 as a function of number of agents. Right: Best solution found after 10s of execution.

On the modern Xeon architecture, the proposed task allocation algorithm is able to find and certify the optimal solution to problems with up to 12 agents in under 1, and it always finds the optimal solution within 10. The embedded Qualcomm SoC is also able to solve problems with up to 6 agents to optimality in under 1, and it returns the optimal solution to problems with up to 12 agents in under 10. Finally, even the highly limited PPC 750 processor is able to compute the optimal solution to problems with six agents in under 10 – a remarkable achievement for a 20-year-old computing architecture.

V-C Agent-Based Simulations

Fig. 5: Numerical simulation setup. Ten agents, including a base station, are placed in a 2D environment. Agents have different battery levels, which influence the execution speed and energy cost of tasks. Link bandwidths are based on inter-agent distance; no communication is possible through hatched regions. Agents in dark shaded regions can collect, analyze, and store samples.

We assessed the end-to-end performance of the PDRA and of the proposed task allocation algorithm through detailed agent-based simulations. The simulation setup is shown in Figure 5 and uses the software network shown in Figure 3. Nine low-power robots were required to perform housekeeping tasks; robots in the dark shaded regions were also able (but not required) to collect, analyze, and store a sample. The robots were aided by a base station. We compared the proposed approach with 1. a selfish scenario where Problem (2) is used to determine which optional tasks should be performed and which optional tasks should be skipped, but agents are not allowed to share computational tasks (except for storing samples, which is performed by the base station), and 2. a naive scenario where each robot performs all available tasks on board (except for storing samples, performed on the base station).

We consider two scenarios: a time-invariant scenario where the network topology is fixed (Figure 5), and a delay-tolerant networking scenario where an agent periodically travels between two disconnected groups of agents (Figure 6). In the delay-tolerant scenario, we set the planning time period to equal one full cycle of the traveling agent.

Fig. 6: Numerical simulations with delay-tolerant networking. A node travels between the two positions highlighted by the red arrow every 30. At no time does a direct link exist between the nodes on the left-hand side and on the right-hand side of the map.
Fig. 7: Time-invariant agent-based simulations: CPU usage, energy use, and reward for optional tasks obtained by PDRA, a naive task allocation algorithm that executes all available tasks on board, and a “selfish” version of PDRA that can skip optional tasks but not use computational assists.

Results are reported in Table I and Figures 7 and 8. In the time-invariant scenario, use of PDRA results in a 58% reduction in energy use and a nearly 50% reduction in CPU time compared to both the naive and the selfish approaches, together with a small increase in the reward for completed tasks. In the DTN scenario, Problem (2) is able to exploit the moving agent as a data mule: as shown in Figure 8, nodes in one cluster offload computational tasks to nodes belonging to the other cluster, even though no instantaneous communication link is available. PDRA routes obligations over the DTN networking layer, realizing the requested task allocation.

Collectively, these results show that PDRA can realize the promise of distributed computing in heterogeneous robotic networks, greatly reducing CPU usage and energy costs while increasing science returns, with minimal changes to existing planning/execution modules and existing computational resources.

CPU [] Energy [J] Taken Analyzed Stored


PDRA 1022 6042 24 24 24
Selfish 1992 14654 25 25 23
Naive 2004 14750 25 25 23


PDRA 1531 10545 19 18 17
Selfish 1892 14217 18 15 15
Naive 1957 14748 18 17 17
TABLE I: PDRA performance over a 6-minute agent-based simulation. Compared to both the naive and the selfish task allocation algorithms, PDRA is able to reduce energy use by 58% and CPU usage by almost 50%, even accounting for communications.
Fig. 8: Data flows in the DTN agent-based simulations. Edges denote messages exchanged between agents. Edge color identifies the agent whose data is transmitted. Agents in the left cluster are colored in red, and agents in the right cluster are colored blue. PDRA and ROC are able to use the moving agent as a data-mule, enabling nodes on the right-hand side of the graph to offload computational tasks and sample storage to the base station on the left, despite the lack of an instantaneous communication link.

V-D Human-in-the-loop demonstration at ICAPS

In order to stress-test the performance of PDRA, we performed a human-in-the-loop demonstration of the software at the 2019 ICAPS conference (Figure 9). The PDRA software and task allocation algorithm was deployed on nine Raspberry Pi 3 embedded computers, each representing a robotic agent, aided by a laptop acting as a base station and communicating through WiFi. A web-based interface allowed conference attendees to change the simulated location of the agents, affecting network bandwidths and the agents’ ability to collect samples, and their battery levels, affecting computational performance. The agents’ task allocation algorithms re-allocated tasks in real time in response to user inputs, and the operations of the system were displayed on a large screen. The demonstration qualitatively demonstrated the robustness of overall architecture in presence of a variety of (occasionally mildly adversarial) system states and network topologies, and showcased its ability to perform well on highly computationally constrained architectures.

Fig. 9: Top: Live demonstration of PDRA at the 2019 ICAPS conference. Bottom: system architecture. Attendees were invited to control the location and battery state of ten simulated agents through their portable devices. Each agent’s PDRA and ROC was executed on a dedicated Raspberry Pi, while a laptop represented the base station. The ROCs reallocated tasks in real-time in response to the attendees’ commands.

Vi Conclusions

In this paper we presented the Pluggable Distributed Resource Allocator (PDRA), a pluggable middleware that enables networked mobile robots to share computational tasks across a time-varying network and “plugs in” to existing single-agent schedulers/executives and computation resources, allowing easy integration in existing autonomy architectures.

A number of directions for future work are of interest. First, we plan to increase PDRA’s robustness to disagreements in the agent’s world models due to network disruptions at the plan execution level, and to integrate monitoring tools to identify disagreements. Second, we will study stochastic task allocation algorithms that are robust to disagreements in the world models and that can cope with unknown or partially-known contact plans. Third, we plan to extend PDRA’s applicability beyond pure functions to stateful computational tasks (e.g., SLAM), where transferring a computational tasks between agents incurs a sizable one-off communication cost. Finally, we will develop user interfaces for human supervision and operation of PDRA, which are key to increasing operator trust and fostering adoption of PDRA in real-world multi-robot exploration tasks.


The research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.


  • [1] J. V. Hook, T. Vaquero, M. Troesch, J.-P. de la Croix, J. Schoolcraft, S. Bandyopadhyay, and S. Chien, “Dynamic shared computing resources for multi-robot mars exploration,” in

    International Symposium on Artificial Intelligence, Robotics, and Automation in Space (i-SAIRAS 2018)

    , Madrid, Spain, June 2018, also appears at the 28th International Conference on Automated Planning and Scheduling (ICAPS) 2018 Workshop on Planning and Robotics (PlanRob), Delft, Netherlands.
  • [2] J. V. Hook, T. S. Vaquero, F. Rossi, M. Troesch, M. Sanchez-Net, J. Schoolcraft, J.-P. de la Croix, and S. Chien, “Mars on-site shared analytics, information, and computing,” in 29th International Conference on Automated Planning and Scheduling (ICAPS), Berkeley, CA, July 2019, pp. 707–715.
  • [3] Jet Propulsion Laboratory, “F-prime: A flight-proven, multi-platform, open-source flight software framework,” Available at, 2020.
  • [4] S. Burleigh, A. Hooke, L. Torgerson, K. Fall, V. Cerf, B. Durst, K. Scott, and H. Weiss, “Delay-tolerant networking: an approach to interplanetary internet,” IEEE Communications Magazine, vol. 41, no. 6, pp. 128–136, June 2003.
  • [5] A. Branch, M. M. Flexas, B. Claus, A. F. Thompson, Y. Zhang, E. B. Clark, S. Chien, D. M. Fratantoni, J. C. Kinsey., B. Hobson, B. Kieft, and F. P. Chavez, “Front delineation and tracking with multiple underwater vehicles,” Journal of Field Robotics (JFR), vol. 36, no. 3, pp. 568–586, 2019.
  • [6] E. Fernandez-Gonzalez, E. Karpas, and B. C. Williams, “Scottyactivity: Mixed discrete-continuous planning with convex optimization,” Journal of Artificial Intelligence Research, 2018.
  • [7] M. Saraoglu, F. Hart, A. Morozov, and K. Janschek, “Fault-tolerant path planning in networked vehicle systems in presence of communication failures,” IFAC-PapersOnLine, vol. 51, no. 23, pp. 82 – 87, 2018, 7th IFAC Workshop on Distributed Estimation and Control in Networked Systems NECSYS 2018.
  • [8] B. P. Gerkey and M. J. Mataric, “Sold!: Auction methods for multirobot coordination,” IEEE transactions on robotics and automation, vol. 18, no. 5, pp. 758–768, 2002.
  • [9] B. P. Gerkey and M. J. Matarić, “A formal analysis and taxonomy of task allocation in multi-robot systems,” The International journal of robotics research, vol. 23, no. 9, pp. 939–954, 2004.
  • [10] J. Benton, A. Coles, and A. Coles, “Temporal planning with preferences and time-dependent continuous costs,” in Twenty-Second International Conference on Automated Planning and Scheduling, 2012.
  • [11] M. Cashmore, M. Fox, D. Long, D. Magazzeni, B. Ridder, A. Carreraa, N. Palomeras, N. Hurtós, and M. Carrerasa, “Rosplan: Planning in the robot operating system,” in Proc. Int. Conf. on Automated Planning and Scheduling (ICAPS), 2015, p. 333–341.
  • [12] N. A. Lynch, Distributed algorithms.   Elsevier, 1996.
  • [13] J. T. Karras, C. L. Fuller, K. C. Carpenter, A. Buscicchio, D. McKeeby, C. J. Norman, C. E. Parcheta, I. Davydychev, and R. S. Fearing, “Pop-up mars rover with textile-enhanced rigid-flex pcb body,” in Robotics and Automation (ICRA), 2017 IEEE International Conference on.   IEEE, 2017, pp. 5459–5466.
  • [14] M. Bajracharya, M. W. Maimone, and D. Helmick, “Autonomy for mars rovers: Past, present, and future,” Computer, vol. 41, no. 12, pp. 44–50, Dec 2008.
  • [15] A. Gleixner, M. Bastubbe, L. Eifler, T. Gally, G. Gamrath, R. L. Gottwald, G. Hendel, C. Hojny, T. Koch, M. E. Lübbecke, S. J. Maher, M. Miltenberger, B. Müller, M. E. Pfetsch, C. Puchert, D. Rehfeldt, F. Schlösser, C. Schubert, F. Serrano, Y. Shinano, J. M. Viernickel, M. Walter, F. Wegscheider, J. T. Witt, and J. Witzig, “The SCIP Optimization Suite 6.0,” Optimization Online, Technical Report, July 2018.