Figure 5.12: Three separate interaction protocols that are part of the (extended) Ricart-Agrawala’s algorithm; A: probing of inter-dependant agents, B: discovery of the resource owner (owner information is sent as broadcast), C: the message flow when performing the actual lock-ing algorithm. Failure handllock-ing is embedded into default transitions (which are not depicted) andSdenotes the conversation initiator’s role andRthe recipient’s role (reprinted by permis-sion from Springer Customer Service Centre GmbH: Springer Nature (Roehr and Herfert2016)
© Springer International Publishing Switzerland 2016).
maximising the reuse software. The reference system as introduced in Chapter2is a hetero-geneous multi-robot team which requires support for amd64 and ARM-based systems. Partic-ularly the use of ARM-based system requires a custom workflow to support the deployment of the software architecture. To create and unify the workflow for the system architectures in use, a packaging solution has been developed based on Debian’s binary packaging format.
The resulting toolkitautomated packaging for autoproj (apaka)(Roehr and Willenbrock2018;
Roehr, Willenbrock, and Joyeux 2018) enables the automated generation of binary Debian packages to ease maintenance of reconfigurable multi-robot system. Package releases can be created and transparently installed and used in Debian-based operating systems. Establishing a shared, standardised software basis is important for multi-robot systems and the packaging system allows the synchronisation of a software state across multiple systems. It facilitates the (re)distribution of a software stack and allows to create a verifiable, reproducible software in-stallation. As a result it contributes to the robustness of a multi-robot system.Apakatackles a software maintenance problem not limited to robotics and enables framework maintainers to create and manage software releases by reusing existing know-how from the Debian commu-nity. This packaging solution has been successfully applied in the context of robotic field test-ing by Sonsalla, Cordes, L. Christensen, Roehr, et al. (2017b) and complements the standard workflow inRock(Roehr, Willenbrock, and Joyeux2018) and D-Rock (DFKI GmbH Robotics Innovation Center2018).
Figure 5.13: Interdependencies of bundles: hierarchical function design is achieved by mod-ularising functionalities. Component network templates and generically implemented actions are collected in so-called bundles. This approach leads to standardisation and facilitates the reuse of component network templates.
one. The context of planetary space exploration requires some default functionality for au-tonomous operation: activation and use of a distributed communication system as outlined in Section 5.2 and the provision of simultaneous localisation and mapping as basis for au-tonomous navigation and exploration abilities. The actual performance of the control architec-ture is illustrated in Chapter6. This section details elements which are particularly relevant for achieving reconfigurability and establishing control loops involving multiple robots.
5.4.1 Hierarchical Model-driven Design
The organisation model outlined in Chapter3introduces the usage of agent types as one means to deal with the combinatorial challenge. The consideration of agent types is also fundamen-tal for the development of the software for the multi-robot team since it allows to maximise reuse and minimise maintenance. A team of robots might be heterogeneous, but robots might still share the same code basis. To facilitate the reuse of component networks, e.g., such as the components networks describing the communication system and autonomous navigation approaches SLAM, Rock’s hierarchical design approach is adopted. The general functional decomposition is based on the design of intra-robot component networks; the term compo-nent refers here to the use of Orocos RTT modules. Each compocompo-nent network represents a user-modelled dataflow which provides a desired functionality and can be designed as general template to enable a particular functionality. While each component in the network can be enabled, disabled or reconfigured, so can the complete component network be dynamically enabled and disabled. Therefore, each component network is characterised by the overall data flow as well as the individual parametrisation of its components. Hence, any reconfiguration or re-parametrisation of a single component can be considered a new component network.
The design of a monolithic and static dataflow setup, as it is often the case for implementations with ROS, is avoided and the use of component network templates increases the flexibility to react to hardware changes and perform software reconfiguration. The set of networks is collected in so-called bundles (see also (Joyeux and Rehrmann2012)). A robot-type agnostic set of bundles, e.g., as depicted in Figure5.13, guarantees a high degree of reusability.
Table 5.5:Operation modi for reconfiguration.
Operation mode Description
cooperative master and slaves, all agents active and communicating uncooperative master and slaves, slaves inactive and not communicating continuous Maintain power connection to agent b during a coalition
structure change:
{{a},{b, c}} → {{a, b, c}} → {{a, b},{c}}
disruptive Cut power and data connection to agent b during a coali-tion structure change:
{{a},{b, c}} → {{a},{b},{c}} → {{a, b},{c}}
5.4.2 Controlling Reconfiguration
Physical reconfiguration is a transition between two coalition structures and it requires a se-quence of actions to join atomic agents and split composite agents. Different operation modi as shown in Table5.5 have to be considered for a reconfiguration, where the desired opera-tion modus combines cooperaopera-tion and continuity. But a cooperative approach requires active support of the participating agents to establish a coalition, which might not always be avail-able. The continuous availability of power for devices might either be a safety or an essential operational requirement, since some agents require an external power source. Due to failing components or no available power a continuous operation of an agent might not be achieved during all transitions.
Uncooperative reconfiguration
A (mainly) uncooperative reconfiguration process is encountered when an immobile payload has to be attached to a manipulating agent. For an uncooperative reconfiguration the roles of an active master and one or more passive slave agents can be identified. A slave agent can behave uncooperatively if it is an autonomous agent with another agenda, or it is unable to support reconfiguration. The former situation might also arise in a fully cooperative team settings, when the slave agent has not been informed about the reconfiguration. The latter can be due to permanent or temporally missing capabilities of the slave agent. The master has to attach one of its interfaces to a compatible interface on the slave agent in order to physically join both systems. Hence, the master agent requires sufficientDegrees of Freedom (DoFs)in order to perform an uncooperative reconfiguration. The generaluncooperative joincan be separated into the steps listed in Table5.6, when the slave agent at least remains stationary.
To initiate an uncooperative reconfiguration the master has to detect the slave and the slave’s interface to which should be docked. If this interface cannot be accessed directly, additional actions have to be considered in order to make it accessible, e.g., by changing the pose of the slave of removing any obstructing structures. The final docking step joins the interfaces and establishes the mechanical link, as well as the power and data link if possible. When the slave is a single atomic agent the reconfiguration ends with the uncooperative join. An optionally, subsequent split might be required when the slave is a composite agent. This split can be either cooperative or uncooperative. Acooperative splitcan be performed, when the power and data connection between both, now connected agents can be successfully established. The split can be triggered by the separating slave agent, e.g., commanding to open a female interface.
Table 5.6:Action sequence for an uncooperative reconfiguration.
# Action description
1 master detects pose of slave 2 master approaches slave
3 master detects pose of slave’s target docking interface 4 master actively repositions slave (optional)
5 master docks an interface to the slave’s target docking interface
An uncooperative split has to be performed when the power and data connection cannot be established or can only be partially used, e.g., a redundant rescue system that is part of the reference systems’ EMI design can still be used to power the bottom interface. The rescue system is a hardware feature (available for theEMI in TransTerrA), so that an uncooperative split might only be optionally available.
Uncooperative reconfiguration is considered for the reference systems by the pickup of a pay-load through the master robot SherpaTT. The target interface is the male, top interface of a payload. SherpaTT’s manipulator is used for pickup of payloads. Male interfaces are equipped with visual markers to facilitate the detection and to support a visual servoing process, which allows to attach the master robot’s manipulator. General, a payload is assumed to reside within the manipulator’s workspace. Ideally it is also within the field of view of the camera when the visual servoing process starts; otherwise an object search has to be initiated first. The visual servoing process guides the manipulator to a predefined reference position which is relative to the target interface. The docking can be completed with a blind docking action from this known relative pose. Blind docking as last step is required, since the field of view and the focus of a camera is limited. Chapter6provides further details on the setup and performance of the visual servoing process.
Cooperative reconfiguration
Cooperative reconfiguration can be performed with two active agents. Depending upon the DoFof both agents, one or even both agents can actively contribute to the approach. The use of a shared scene script for the cooperative reconfiguration as provided in Table5.7can avoid the need for long negotiation phases. Such a script is similar to the uncooperative reconfigu-ration. It involves the assignment of a master and a slave role to manage the process. Step 4 in this scene script accounts for some flexibility to allow the slave to command the master for repositioning. Firstly, agents might differ in their ability to reposition with different accuracy and precision due to theirDoFs, e.g., we used the legged system CREX for the docking ap-proach in (Roehr, Cordes, and F. Kirchner2014) due to a better pose control. Secondly, agents might differ in their sensing abilities either due to missing sensors or due to a limited field of view. Step 5 of a cooperative reconfiguration might involve uncooperative reconfiguration as substeps, e.g., pick up or rather extraction of payloads from an agent coalition.
Cooperative reconfiguration takes advantage of the distributed communication architecture, since agents have to communicate to command or take orders. The control approach which has been evaluated with the reference systems assumes an already performed consensus of the master and slave role in a cooperative reconfiguration.
Table 5.7:Action sequence for a cooperative join.
# Action description
1 master detects pose of slave
2 master approaches slave or directs slave to approach master 3 master detects pose of slave’s target docking interface
4 master/slave repositions or directs slave/master to reposition 5 master docks an interface to the slave’s target docking interface
Handling of reconfiguration effects
Chapter6evaluates a reconfiguration of the reference systems (see also Figure6.19). The ma-nipulator of the robot SherpaTT features a camera to use a visually guided docking process to attach to payloads. The manipulator’s camera is blocked, however, as soon as the manipulator attaches to a payload. Therefore, all payload modules are equipped with an additional camera in the bottom interface, so that visual guidance can still be used to dock the payload module to other interfaces.
To continue docking with an already attached module, two agents have to establish a data and a power connection. These connections are ideally created transparently as soon as the interfaces are brought together (and locked) so that no higher-level control layer has to be-come active; this feature is part of theEMIdesign by Wenzel, Cordes, and F. Kirchner (2015).
Additionally, software reconfiguration has to be triggered. For a continued support of visual docking, a new component network has to be activated which embeds the camera of the newly attached device. Therefore, an identification of the connected device is required and the set of configuration parameters, including camera calibration parameters and dimensions of the module, have to be known in order to prepare the new component network. A significant part of the data flow network which represents the functionality to perform visual servoing remains unchanged. Only the image provider and camera related configuration parameters change. The static part of the data flow network can therefore be modelled as template. The template is fully parametrised and instantiated as soon as the attached camera is known. To pick a payload up, first the bottommost camera attached to the end effector is identified. Sub-sequently associated configuration parameters for the camera are looked up from a database.
Finally, the data flow network with the camera related parametrisation is activated.
For the selected scenario the camera parameters have been previously shared with the master, here the robot SherpaTT, which attaches to the payload. A fully generalised implementation requires to request this information from the attached agent after the power and data link have been established.
Error handling Reconfiguration comes with a risk of failure and introduces additional points of failures. For instance, attaching the manipulator to a payload was not free from failure.
Firstly, reconfiguration failed during the mechanical docking process. Secondly, spontaneous outage and loss of the data link occurred after the manipulator attached to the payload. The error handling strategy involved to power down and power up the attached payload to recover from this error; this could be done by using the power management system which connects all EMIs. Hence, the following local failure handling routine become part of the reconfiguration process:
(a) poll for the availability of the new agent and wait for a maximum of 60 s, (b) restart (power off/on) the attached module when no agent can be contacted.
This special error handling routine was sufficient to deal with the observed faults.
Coalition structure changes represent transitions between two stable organisation states. Such change is a point of failure in any reconfigurable multi-robot system. While failures such as the one described above can be completely avoided by quality assurance processes, a need for general failure handling strategies remains. Apart from a set of local, domain specific failure handling routines this thesis has, however, focused on the implementation of nominal capabilities needed for operation.