Hardware In The Loop Simulation Applied To

Semi-Autonomous Underwater Vehicles

Hilgad Montelo, Celso Massatoshi Furukawa
University of So Paulo
hmontelo@gmail.com, celso.furukawa@poli.usp.br
Abstract-Unmanned Underwater Vehicles (UUVs) have many
commercial, military, and scientific applications because of their
potential capabilities and significant cost-performance
improvements over traditional means of obtaining valuable
information about the underwater environment. The
development of a reliable sampling and testing platform for
these vehicles requires a thorough system design and many
costly at-sea trials during which systems specifications can be
validated. Modeling and simulation provide a cost-effective
measure to carry out preliminary component, system (hardware
and software), and mission testing and verification, thereby
reducing the number of potential failures in at-sea trials. An
accurate simulation environment can help engineers to find
hidden errors in the UUV embedded software and gain insights
into the UUV operation and dynamics. This work describes the
implementation of a UUV's control algorithm using
MATLAB/SIMULINK, its automatic conversion to an
executable code (in C++) and the verification of its performance
directly into the embedded computer using simulations. It is
detailed the necessary procedure to allow the conversion of the
models from MATLAB to C++ code, integration of the control
software with the real time operating system used on the
embedded computer (VxWorks) and the developed strategy of
Hardware In the Loop Simulation
(HILS). The Main
contribution of this work is to present a rational framework to
support the final implementation of the control software on the
embedded computer, starting from the model developed on an
environment friendly to the control engineers, like SIMULINK.

I.

INTRODUCTION

Traditional tests, many times refereed as static tests, are the

evaluation of functionalities of a particular component where,
to it, are provided measurable inputs and outputs. The
growing of the demand for new products faster and a
consequent reduction of the development cycles associated to
the projects, has caused a increase on necessity to execute
dynamic tests, where the behavior of each component is
evaluated at same moment of its interaction with the rest of
the system and environment. Dynamic tests, in [7], minimize
risks related to the security and costs, covering more tests
conditions when compared to static tests. The application of
the test approach involving components of hardware,
software and dynamic or behavioral conditions is called
HILS.
The HILS, described by [3], is a tool that comes to aid the
work of the controls engineer. Unnumbered systems could
be developed faster only using an initial conceptual model
developed adapting or adjusting the necessary controls
variables (for instance: maximum supported pressure,
maximum speed, minimal temperature, maximum depth, bus
clock, minimal systems memory, etc), where a set of them

could be encapsulated into a configurations profile, validated

in a simulated or basic prototype, and, finally, verified in a
final target. Into this environment, the controls engineer
could to dedicate more time analyzing and detailing features
to solve the control problems related to the project, avoiding
the necessity to take much time writing or debugging lines of
firmwares code or even the necessity to handle with
complexities like time restrictions, establishment of priorities
or techniques to tasks scheduling.
The HILS approach could be applied to all systems, for
research and development; in the most assorted areas, like
military, medicine, automotive, air space, like indicated by
[1], [5], [9], [13], [20]... or even in projects where interactions
between a product in development and its environment of
operation (part of the real world) are not so simple to
represent formally, like some models described by [10], [15],
[18], [21], [22].
The objective of this work is to present a rationale
approach to assist control engineers during the development
of a semi-autonomous underwater vehicle, vehicles that can
perform part of their operations with or without human
intervention, improving the integration between complex
subsystems like: navigation, power management, actuation,
sensing, etc all together working in an unpredictable and,
many times, hazardous environment.
II.

METODOLOGY

The approach to build an appropriate hardware in the loop

simulation architecture applied to a semi-autonomous
underwater unmanned vehicle consists of the construction
following environments, tools and modeling:
Development Environment: It consist, specifically, of the
assembly and utilization of a hardware with similar features
(preferentially) to those presented by the unmanned
underwater vehicle in development in the laboratory of
mechatronic engineer at Polytechnic School of So Paulo
(Escola Politcnica de So Paulo - EPUSP), allowing to make
a good utilization of the resources and solutions already in
research like described in [2], [8], [11], [12].
Real Time Operating Environment: VxWorks is a real
time operating system manufactured by Windriver Systems
and initial description could be found in [19]. Like others real
time operating systems, it includes a kernel that supports
multiple tasks and preemptive scheduling. Very popular in
embedded applications and widely used in a variety of

hardware architectures like: MIPS, PowerPC, SH-4, ARM,

StrongARM, xScale, and x86.
Real Time Framework: The Constellation consists of an
object oriented real time framework that provides capabilities
to interfacing and code generation from a model developed in
MATLAB/Simulink. The Constellation framework is
specified in [6]. The model could be converted in ANSI C++
programming language using all advantages of the objected
oriented programming and yet a high performance. The real
time capabilities are found in a middleware interface,
between the generated code and the real time environment.
The MATLABs real time workshop provides the necessary
elements to perform that relationship.
UUVs Dynamic: One of the first steps to realize an
appropriate simulation consists of the modeling of the
dynamic equations of the Hornet UUV, specified in [4] and
used in this work as a concept prove, due the fact that UUVs
model presents a simpler system of equations appropriate to
develop the necessary software interfaces to be used also by
others UUVs. The Fig. 1 presents the six degrees and the
respective derivatives used by a rigid body and its system of
is the
coordinates in the Hornet UUVs model. Where:
linear movement relationship to the longitudinal axis; is the
linear movement relationship to the transversal axis; is the
is the
linear movement relationship to the vertical axis;
angular or rotational movement over the
axis;
is the
angular or rotational movement over the axis and is the
angular or rotational movement over the axis.

The dynamic equations used to describe the vehicles

movement are developed in accordance with [14]. Taking the
sum of all forces in direction of the respective axis
(X, Y, Z), and solving its equations for acceleration,
presented, respectively, by (2), (3), and (4).

Where:
:
:
:
:
:
:
:

Acceleration over X axis.

Acceleration over Y axis.
Acceleration over Z axis.
Velocity over X axis.
Velocity over Y axis.
Angular velocity over Z axis.
Linear hydrodynamic drag force
over the X axis.
External disturbs over the X axis.
Linear hydrodynamic drag force
over the Y axis.
External disturbs over the Y axis.
Linear hydrodynamic drag force
over the Z axis.
External disturbs over the Z axis.
: Considering that there are not
disturbances.
Vehicles mass.
Vehicles weight in water
(Considering that the buoyancy
force is 0).

:
:
:
:
:

:
:

Fig. 1. Rigid body and its coordinate system.

The inputs of the system are defined by the following set of

forces: : force applied by lateral thruster, : force applied
by frontal thruster,
: force applied by vertical thruster,
: external disturbs or interferences like water
current for instance,
linear hydrodynamic drag
force as defined in (1), and studied by [16].

And taking the sum of the moments over the axis, it is

obtained the acceleration around that axis presented by (5):

Where:
:
:

:
Where:
: Drag coefficient.
:
Waters density.
: Projected area of drag.
: Velocity of the surface of drag.

Angular acceleration over Z axis.

Distance between the thrusters 1
(lateral thruster) and 2 (frontal
thruster)
Sum of the moments over Z axis
(Considering that there are not
disturbance over Z axis).
Moment of inertia over Z axis.

For the simulation purposes those movement equations

contains eight state variables, represented by the vector
and three inputs independently
controlled represented by
presented by (6):

The transformation matrix presented in (7) is responsible to

convert the output states of the rigid body found in the plant
model into the coordinate values associated to a geographic
reference in the horizontal plan.

To obtain the coordinates in the vertical plan, it is sufficient

to calculate the superposition matrix of
.
The Fig. 2 shows the block diagram used to represent the
depth controller. The vehicle receives a command with the
desired depth (
), it verifies the current depth
(
) and apply an output to the thruster 3 ( ).
Analyzing (4), it is possible to see that the relationship
between the depth and the actuator responsible to adjust it (in
this case, the thruster 3) is simple and linear; therefore a PID
(Proportional-Derivative-Integral) controller is sufficient
[23].

Fig. 2. Block Diagram of the PID depth controller..

Where:
:
:

:
:
:
:
:

Command of depth used by the mission

planner;
Current depth gathered by the navigation
system;
Depth error;
Vertical thruster output;
Proportional gain;
Integral gain;
Derivative gain.

A PID controller is also provided to establish the velocity

control; the velocity is obtained directly from the thruster (T1)
instead the desired velocity produced by the mission planner

This approach is used to minimize problems of accuracy

due utilization of estimated values. The velocity and direction
controller work together where, depending of the current
directions value, it is possible to increase or decrease the
vehicles velocity.
To control the vehicles direction, it was used a slide-mode
control, presented by Fig. 3 and also used by [24], that allows
errors in its sliding layer with about +/- 3 degrees and sliding
function defined by (8).

Fig. 3. Block Diagram of the slide-mode direction controller.

The direction controller uses the following parameters:

:
Direction angle used by the mission
planner;
:
Current UUVs direction angle;
:
Positive and negative limits used over the
thruster output;
:
Error gain;
:
Error rate gain;
and :
Horizontal thrusters output.
The direction controller uses the sliding function presented
by (8), to decrement the error and error rate down to zero.

Where:
:
Slide mode function;
:
It is a bi-dimensional array with the controllers
gains;
:
It is a bi-dimensional array that contains the
controllers error and error rate
Hardware In the Loop Simulation Environment: The
Fig. 4 shows a general overview of the HILS architecture
used to assist the development and construction of a semiautonomous underwater vehicle. It contains the main
components:
Embedded Hardware: It represents a clone of part of
the hardware used to produce the UUV. The inputs
consists of the forces generated by the environment
(like current, pressure, buoyancy, etc) and the forces
generated by the thrusters;
World Model: It consists the model used to represent
the physical world or, more precisely, a very close
representation of where the UUV will operate;
Control Parameters: They are the main and auxiliary
variables used to operate adequately the control

To prepare the target environment and to configure

its real time operating system to establish all
necessary connections;
To configure the real time framework to operate
either with the operating system in target machine or
with a simulation environment (environment with the
same interfaces but not considering time restrictions);
To establish connection between the target machine
and the Matlab/Simulink environment using the
middleware provided by Constellation tools;
Trough the Data Logger component and tools like the
Matlab's shell, WindView or Stethoscope, see [17]; is
possible to evaluate and even update values of
monitored variables or statuses in run time to achieve
the timers and specified control conditions;
All generated firmware's code is in ANSI C++ not
allowing the utilization of templates (generic
programming) or even dynamic memory allocation
(temporally to avoid problems with garbage
collection, for instance).

Fig. 4. Overview of the HILS used to assist the development of UUV.

algorithms used by the UUV (For example: initial

velocity, initial acceleration, Initial position, error
adjusts for directions, maximum pressure allowed,
etc);
Sensors and Actuators: They represent the components
that allow the inputs and outputs of the system,
respectively. They could be real components
(hardware like compass, inclinometers, temperature
sensors, pressure sensors) or virtual (represented by
input/output files, for instance).
Data Logger: This component is responsible to register
all operations that are using this infra-structure, either
through a partial or total simulation. Only using the log
files and registers produced by this component is
possible to evaluate if a control algorithm is adequate
for the UUV and its environment of operation.

The following steps are necessary to generate a useful code

compatible with the proposal of hardware in the loop
architecture, based in an initial UUV's conceptual model.
To prepare the UUV's control model in Simulink
environment: It consists in the utilization of the
Simulink tool box and its control blocks (like SFunctions, PID block, Plant block, etc). OBS: Before
the next step, it is important to eliminate any algebraic
loop in the model (algebraic loops occur when an input
port with direct feed through is driven by the output of
the same block, either directly, or by a feedback path
through other blocks which have direct feed through);
To convert the prepared UUV's control model in a
suitable software component compatible with the real
time framework adopted. There is a special tool
developed to achieve that objective where is possible
to specify event handlers, allows priority specification
and concurrent code;

III.

RESULTS

The dynamic model and its respective control algorithm,

published in [4], were successfully reproduced in
Matlab/Simulink environment, without any behavioral loss,
even after the elimination of undesired algebraic loops.
The hardware in the loop environment and the UUV's
controller was embedded in a hardware developed in PC104
standard, using x86 architecture, the same configuration
presented by the UUV in development. Virtual sensors and
virtual actuators (like compass, inclinometers, depth's
sensors, thrusters, etc) also had its embedded and real time
representation stored directly into the target's file system.
For all graphs generated, the following procedure was
executed:
All sensors have their values recorded in files.
The code generated for the controller reads the value
of those files (sensor values) and, after the necessary
calculus, generates the actuation signals for the UUV's
thrusters.
The actuation signals were also recorded in files, used
later as input for the dynamic simulator. They contain
information about velocity control, direction control,
and depth control.
To compare the results obtained with the implemented
HILS (identified by the label: "Reproduced") against
the adopted bibliographic material (identified by the
label: "Source").
The Fig. 5 shows a direction graph of the path traversed by
the UUV from the start point (point: X=0 and Y=0) in
direction to the point indicated by the beacon (point: X=35
and Y=35). The trajectory performed by the UUV in HILS
environment is similar and compatible with the results
presented by [4].