Grex Project

Towards Cooperative Behaviour between Multiple Unmanned Marine
Vehicles (MUMVs): Team Handling for the First Multi Vehicle Primitives
Matthias Schneider, Ilmenau University of Technology / Germany, schneider.matthias@tuilmenau.de
Thomas Glotzbach, Ilmenau University of Technology / Germany; Fraunhofer Center for Applied
Systems Technology, Ilmenau / Germany, thomas.glotzbach@tu-ilmenau.de
Thomas Güther, Ilmenau University of Technology / Germany, thomas.guether@tu-ilmenau.de
Peter Otto, Ilmenau University of Technology / Germany, peter.otto@tu-ilmenau.de
Abstract
The realization of cooperative behavior between Multiple Unmanned Marine Vehicles (MUMVs) is a
real challenge, due to the conditions of the marine environment. In this paper we show a basic team
handling design to enable already existing, single autonomous vehicles to participate in team
missions. We describe a two stage realization of the control software which takes care of the online
replanning, error handling and mission fulfillment within the given constraints of communication as
well as the limited access to the different vehicles.
1. Introduction
The cumulative industrialization and exploitation of the ocean leads to an increasing demand of
autonomous underwater vehicles. Within the GREX 1 research project, the aim is to implant
cooperative teams of Multiple Unmanned Marine Vehicles. Additional to the problems of navigation
and communication which need to be addressed, algorithms for cooperative behavior need to be
developed. Additionally, these algorithms, like presented in Aguiar and Pascoal (2009) within this
session, need to be translated in such a way that they can be realized within the coordinating software
that will run on the real vehicles at the end of the project.
To realize scenarios which require the participation of several unmanned marine vehicles or can only
be executed by one vehicle with great effort, several preconditions must be achieved. On the one
hand, the involved vehicles must fulfill several hard- and software requirements to participate in a
team. On the other hand, an intelligent team management is needed. Starting from the experiences
made during the first comprehensive tests with different vehicle models employed by the providers,
this paper presents the realization of an adequate team behavior and discusses it with selected
examples. The employed procedure requires an offline mission planning and the single autonomy
ability of the vehicles to follow a planned path. Using the presented concept, teams with large
numbers of single autonomous vehicles can be realized. The single steps of the team handling will be
presented by means of a coordinated path following and an algorithm to establish a formation.
The two-stage concept consists on the one hand of the Monitoring Module, which realizes the
functionalities of mission observation and planning. On the basis of the current maneuver and the
telegram-based communication, decisions are made which enable the vehicle to act as a team player.
These decisions are supported by embedded algorithms like ‘Coordinated Path Following’, Aguiar
and Pascoal (2007), or ‘Go To Formation’, Haeussler et al. (2009). The second level of the Team
1 GREX is the Latin word for herd, team, or swarm. The research project GREX is funded by the Sixth
Framework Programme of the European Community (FP6-IST-2006-035223). Participants of the GREXproject
are the following companies and institutions: ATLAS ELEKTRONIK GmbH (Germany), Centre of
IMAR at Department of Oceanography and Fisheries at the University of the Azores (Portugal), Ifremer
(France), Innova S.p.A. (Italy), Instituto Superior Tecnico IST - Lab: Institute for Systems and Robotics ISR
(Portugal), MC Marketing Consulting (Germany), ORANGE ENERGY Consulting (Portugal), SeeByte Ltd.
(United Kingdom), Institute for Automation and Systems Engineering of the Ilmenau University of Technology
(Germany). See GREX (2008) for further information.
165

Handler concept is realized by a Replanning Module, which administrates, executes and validates the
replanning commands. While we demonstrated the base functionalities of this concept in Glotzbach et
al. (2008), we will go further into detail now and explain the software realization of the team handler
and of the algorithms for the first realized and tested Multi Vehicle Primitives. With the already
realized functionalities, we are now able to simulate a complete mission from the beginning (vehicles
in the water at arbitrary positions) to the end (vehicles have completed their missions plans and wait at
defined positions for recovery). This mission will be presented using the developed high-level
simulator and employing the original software modules which will later also be used for the real
vehicles.
2. Basic conditions within the GREX research project
The main idea of the GREX project is to develop a middleware system which enables multiple
unmanned marine vehicles to act in a team to perform missions of higher complexity. The basic
modules of the mentioned system are shown in Fig.1. Only through the collaboration of the several
and specialized modules a team oriented behavior can be realized.
Fig.1: GREX middleware system
The Communication Module is responsible for the complete communication between several
vehicles. Team Navigation estimates the position of all team mates based on a complex estimator
structure, the spare position information of the other vehicles and the current track data, like described
in Engel and Kalwa (2007). The Team Handler Module realizes the complete management of a team
and enables the team oriented behavior on a single autonomous vehicle. Due to the use of different
and existing single autonomous vehicles within the GREX research project an Interface Module is
necessary which provides a communication link between the existing vehicle hardware and the GREX
components. Furthermore we have to deal with several constraints. On the one hand there are vehicles
which are able to perform single missions and limited replanning capability. On the other hand we
have the underwater communication with very low bandwidth and high rate of information loss. To
handle these different constraints and provide a save team operating software as well as mission
replanning an intelligent team handling concept is necessary.
3. Multi System Mission Control
Based on the defined structure of the Multi Vehicle Primitives, introduced in Glotzbach et al. (2008),
we are able to provide a conceptual framework to handle teams of multiple unmanned marine
vehicles. The main part of this proposal, the Team Handler core, is shown in Fig.2.
166

Fig.2: Main parts of the Team Handler core
This core provides the basic functionality to handle multi vehicle mission scenarios, including
strategies to adapt the level of autonomy during the mission execution based on external events, and
consists of three main parts which are described in the following chapters. The highest level of the
internal build-up is realized with state machines which were triggered by telegrams. These structures
constitute the base of information flow between the several GREX modules as well as between the
several vehicles within one mission scenario. The telegram types including the build-up of the
structure are predefined. This minimizes the occurrence of an error through modified messages caused
by module or communication failures.
3.1. Data Management
The first part of the Team Handler structure is represented by the Data Management. This passive
object stores the information of all vehicles which take part in a mission as well as the mission
information itself to provide several data for coordination and replanning purposes.
Fig.3: Data management structure
The information has to be stored on every GREX vehicle and will be loaded after the Team Handler
module is started. The basic structure of this module is shown in Fig.3. Furthermore it provides some
simple calculation functionality concerning mission and vehicle data to support the team handling
process through a Functionality Interface. These structures can be extended easily in order to add new
data or features. Due to the use of an external Data Management the Team Handler core is completely
independent from the structure of mission plans or kind of vehicle which should be controlled because
the internal structures are still the same.
167

3.2 Team Initialization Process
The first active part of the Team Handler builds the Initialization Process. Within these routines a first
level of cooperative coordination is realized which is controlled from the Team Handler of the leading
vehicle. Like the other critical parts of the presented structure the single steps of the initialization are
predefined and implemented as state machine.
Fig.4: Main process diagram of the Team Handler with focus on Team Initialization Process
The Initialization Process can be divided in two parts, see Fig.4. On the left side, there are the routines
that initialize the vehicle internal structures like the Team Navigation Module with specified data
from the Data Management or from the vehicle itself. On the right side, functionalities which setup
the team data are implemented. The process of the second part depends if the current vehicle is the
leading one or just a team member. While the Team Handler on the leading vehicle is responsible to
collect the group data to prepare the start of the mission, the member vehicles have to send required
data. After all parts are initialized in the correct way the main process loop, including Mission
Monitoring and Mission Replanning, will start.
3.3. Mission Monitoring
The main control part of the Team Handler structure builds the Mission Monitoring. Based on the
rational behavior model in conjunction with a global state machine this part generates commands for
replanning or information for other modules. Thereby we distinguish between two kinds of Team
Handlers in general. The Team Handler on the leading vehicle and the team handling structures on a
member vehicle. Both are realized identical while the leading vehicle has to fulfill some additional
tasks like the coordination of the group initialization process and the path re-/planning of complex
maneuvers. The role as leading vehicle can be transferred to another vehicle during the mission and
depends on the parameters which were set during the offline planning process.
Fig.5 gives an overview of the main workflow within the Team Handler structure from a more
practical point of view. The focused area points the major tasks of the Mission Monitoring including
the different layers specified by the Rational Behavior Model (RBM). The RBM is a standard
approach for hierarchical control structures in research on mobile robotics, Kwak et al. (1993). Every
layer is realized by at least one function which creates proposals to manipulate the behavior of the
current vehicle in order to activate and keep a team manner within the group of vehicles taking part on
a mission. Thereby the influence of the different layers gets smaller from the Strategic Level down to
the Executive Level.
168

Fig.5: Main process diagram of the Team Handler with focus on Mission Monitoring
The Strategic Level has the highest priority and the ability to abort the complete mission if an error
occurs. Therefore it checks all telegrams which contain error reports of modules or vehicles as well as
denies of replannings. On the other hand this layer is responsible to control the mission activity. If a
new part of the mission (primitive) starts, it initializes the internal states and structures with the new
data. Furthermore the Strategic Layer verifies the current position of the vehicle within the current
primitive and the given global mission area. If any inconsistency is found, the mission will be aborted
for security reasons.
The second layer of the Mission Monitoring builds the Tactical Level. It includes local state machines
which depend on the different Multi Vehicle Primitives that are realized within the Team Handler.
This layer can be extended with algorithms for complex multi vehicle scenarios like GoToFormation
or CoordinatedTargetTracking. Algorithms with a high computing time or ambiguous results are
started in separate and controlled threads as a precaution. Due to this realization there is no critical
impact in the main team handling core. On the other hand the results of complex calculations can also
be used for the complete team e. g. in case of the GoToFormation implementation. If so, the Team
Handler of the leading vehicle calculates and shares the data while the member vehicles have to wait
for it. If the parameters are known, this is done in advance during the standard mission execution to
guarantee a smooth mission cycle.
The Executive Level has just a small priority compared to the other ones but it is executed most
frequently during standard parts (tracks and arcs) of a mission scenario. In general it is responsible to
adapt the speed of its own vehicle to keep the predefined formation based on very fast algorithms, like
suggested in Ghabcheloo et al. (2005).
With the exception of decisions made by the Strategic Level, the results of the different algorithms
(speed adaption, new path, etc.) were passed through the Mission Replanning.
3.4. Mission Replanning
Beside the tactical part of the Team Handler, the Mission Replanning represents the executive part.
After a Mission Monitoring cycle is finished, the main process routine of the Mission Replanning will
be called, replanning or adjustment proposals will be examined and achieved. Fig.6 shows the main
functionalities of this Team Handler component. The dotted line in Fig.6 represents the data transfer
of the replanning or adjustment commands which will be evaluated and sorted by an intelligent
sorting routine. In general this filter works with two main criteria. On the one hand there is the
priority of a command depending on the level of the Mission Monitoring where it comes from. On the
other hand old data can get needless if the mission primitive changed. Based on this replanning
sequence the control part of the Mission Replanning just gets the command with the highest priority.
169

Due to the fact that within GREX the presented solution is one of the first realizations for such kind of
team handling structure and also for vehicle security reasons, only one replanning command is
executed at the same time. Furthermore every order which is send gets a unique identifier that has to
be in the reply message. Depending on the priority of a replanning it is possible that an order will be
denied by the vehicle, e.g. a speed adaptation. A decline of course changes or high priority commands
will end up with a global mission abort realized through an internal message to the Mission
Monitoring component.
Fig.6: Main process diagram of the Team Handler with focus on Mission Replanning
4. Simulation Environment and first results
This external software package provides all data and functionalities which are necessary to simulate
an environment for test purposes from a team handling point of view. It includes e. g. the height above
sea ground, the surrounding sea current or the communication delay as well as data loss as result of
the acoustic underwater communication. Furthermore the Simulation Environment is able to emulate
sensors of a vehicle by calculating the distance to static or dynamic objects like gas concentrations.
Due to the usage of the mentioned data, the GREX simulation software is able to execute missions
with multiple vehicles close to reality.
Fig.7: Simulation Environment
Fig.7 shows the used Simulation Environment with the Environmental Module itself. Every simulated
vehicle needs an interface to the Environment Server to get control relevant data or acoustic messages
from other vehicles. For flexibility reasons it is possible to run the Environment Module and each
simulated vehicle on a separate computer linked by a standard network or the internet. Due to cost
efficiency it is also feasible to run the Environment Module as well as each simulated vehicle on just
one computer.
170

Fig.8: Simulation result with two vehicles
Fig.8 shows a result of a test mission with some explanations at the different states of the example.
The Team Handler structures proposed in this paper provides group control mechanisms in every part
of a mission in terms of speed adaption to guarantee a given formation as well as replannings to allow
complex maneuvers like the shown GoToFormation algorithm.
5. Conclusion
In this paper we described a basic and tested concept which enables the team behavior of single
autonomous unmanned marine vehicles. Due to the generic realization the shown concept is usable for
nearly all kinds of vehicles and also very easy to extend with new control algorithms. Furthermore it
considers the limitations of the current generation of unmanned marine vehicles as well as the marine
environment. The existing vehicle hardware and the internal vehicle control gets just “proposals”
from the team handling structures, there is no active modification. Based on this strategy in
conjunction with the state machines and mission validation within the team handler core a very safe
concept is proposed. Furthermore it provides a test platform for new control algorithms which can be
validated in simulation.
Acknowledgements
The authors gratefully acknowledge financial support of the European Community in the framework
of the research project GREX. The project GREX (FP6-IST-2006-035223) is funded by the Sixth
Framework Programme of the European Community.
171

References
AGUIAR, A. P.; PASCOAL, A. (2007). Coordinated Path-Following Control for Nonlinear Systems
with Logic-Based Communication. 46 th IEEE Conf. on Decision and Control (CDC’07), New Orleans
AGUIAR, A. P.; PASCOAL, A. (2009). Networked Control of Multiple Marine Vehicles under
Communication Constraints. 8 th International Conference on Computer Applications and Information
Technology in the Maritime Industries (COMPIT2009), Budapest
ENGEL, R.; Kalwa, J. (2007). Coordinated Navigation of Multiple Underwater Vehicles. 17th
International Offshore and Polar Engineering Conference (ISOPE-2007), Lisbon, pp. 1066-1072
GHABCHELOO, R.; PASCOAL, A.; SILVESTRE, C.; CARVALHO, D. (2005). Coordinated
Motion Control of Multiple Autonomous Underwater Vehicles. The International Workshop on
Underwater Robotics, Genoa
GLOTZBACH, T.; SCHNEIDER, M.; OTTO, P. (2008). Multi System Mission Control for Teams of
Unmanned Marine Vehicles – Software Structure for Online Replanning of Mission Plans. 7 th Conf.
on Computer Applications and Information Technology in the Maritime Industries (COMPIT2008),
Liege
GREX: Coordination and control of cooperating heterogeneous unmanned systems in uncertain
environments, Home Page, http://www.grex-project.eu, visited on 14/03/2008
HAEUSLER, A.; GHABCHELOO R.; PASCOAL, A. M.; AGUIAR, A. P.; KAMINER, I. (2009).
Temporally and Spatially Deconflicted Path Planning for Multiple Autonomous Marine Vehicles. 8 th
IFAC Int. Conf. on Manoeuvring and Control of Marine Craft
KWAK, S.H.; McGHEE, R.B.; BIHARI, T.E. (1992): Rational Behavior Model: A Tri-level Multiple
Paradigm Architecture for Robot Vehicle Control. Technical Report NPSCS-92-003, Naval
Postgraduate School, Monterey
172