# Engineering Challenges Ahead for Robot Teamwork in Dynamic Environments
## 3 Teamwork Challenges
### Middleware Support  
A multi-robot system, as any other distributed system, benefits from middleware that hides the complexities of distributed computing in heterogeneous environments and, thus, eases the job of the developer of a distributed application. In general, middleware for robotic applications needs to satisfy the same basic requirements as any middleware in a distributed computing system, i.e., to simplify the application design by making transparent the low-level details of the underlying hardware, software, communication, sensing, and actuating activities. Moreover, middleware facilitates the integration of new technologies, and it improves software maintenance and evolution, as well as software re-use across multiple development efforts, thus reducing application development costs. Taking up experiences with agent reference models (e.g., FIPA and its offspring NAWG (FIPA P2P Nomadic Agents WG (P2 PNA WG6), [[http://www.fipa.org/subgroups/P2](http://www.fipa.org/subgroups/P2) PNA-WG.html]([http://www.fipa.org/subgroups/P2](http://www.fipa.org/subgroups/P2) PNA-WG.html))) and agent platform implementations (see the FIPA web page at [[http://www.fipa.org/resources/livesystems.html](http://www.fipa.org/resources/livesystems.html)]([http://www.fipa.org/resources/livesystems.html](http://www.fipa.org/resources/livesystems.html)) for an (outdated) list of publicly available FIPA compliant implementations of agent platforms), as well as with popular general-purpose middleware systems, many middleware architectures specifically for multi-robot systems were proposed in the literature. We point the reader to surveys such as [23; 24]. Key challenges are as follows:  
* Do we need specialized middleware for robot teamwork, or can we build on existing standards for general middleware architectures? * Are the robot devices capable of running a heavyweight middleware in terms of processing and storage capacity? * How important are quality of service guarantees for the application at hand? There are a variety of models underlying middleware for multi-agent coordination. Middleware frameworks such as Orocos [25], CLARAty [26], and MIRO [27] use event-based behavior coordination. The events are triggered by either communication or timer events that are mostly realized as remote procedure calls. This results in an insufficient decoupling between the initiator and receiver of an event. Orocos and MIRO rely on heavyweight architectures, i.e., CORBA [28] and Ice [29], respectively. In contrast, CLARAty which was developed for communication of NASA rovers, explicitly handles unreliable communication and can operate in either centralized or decentralized mode. The most common communication concept of robot middleware is publish-subscribe due to its higher degree of decoupling. Examples are RoboFrame [30], Spica [31], and ROS [32]. RoboFrame and Spica were designed explicitly for distributed computing in multi-robot systems. They are capable of dealing with unreliable communication, as for example encountered in RoboCup soccer tournaments where standard WiFi communication channels often suffer from bandwidth limitations and packet losses due to interferences among the many WLANs at the competition site. While the robot software framework ROS 1 had limited support for distributed multi-robot applications, the new ROS 2 includes a middleware based on the popular data distribution service (DDS) (Data Distribution Service, OMG, [[https://www.omg.org/spec/DDS/](https://www.omg.org/spec/DDS/)]([https://www.omg.org/spec/DDS/](https://www.omg.org/spec/DDS/))). Nevertheless, there are several open issues related to middleware support for robot teamwork that need more research. A truly flexible middleware toolbox would be needed that enables the designer of a teamwork application to configure the middleware by selecting the specific set of components that matches best the application requirements.