Vous êtes sur la page 1sur 20

4.

The ROV Control System




This section describes the selection of the control strategy. It then presents the control
system design, the sensor package and real-time monitoring system. The section concludes
with an overview of the anticipated system architecture in terms of the computer hardware,
operating system and system software.

4.1 Selection of control strategy

In selecting the control strategy for this ROV system a decision was made to limit the choice
to those strategies which have been demonstrated on practical systems and which have been
reported in the literature. A review of strategies which fit these criteria was presented in
section three.

Although relatively cheap and simple to implement, Open-loop controllers provide no
automatic compensation for environmental disturbances. Such controllers are therefore not
suitable for vehicles used for marine survey or diver support operations, or for vehicles
intended for AUV system development.

Closed-loop Two- and Three-Term Controllers include a feedback component enabling
the controller to automatically compensate for environmental disturbances. It has been
suggested, however, that three-term controllers may not be sufficiently robust to deal with
the variations in system parameters which may be expected in a modular submersible
vehicle in the marine environment. Several controllers will also be required for each degree-
of-freedom if stable, high-performance, control is to be achieved across the whole operating
range of the vehicle [Yoerger, et al., 1986]. Most authors seem to agree that more advanced
controllers are better suited to the problem of controlling a submersible vehicle. PID
controllers do, however, seem suitable candidates for control of ROV thrusters if problems
of thruster non-linearity can be resolved. These problems might be eliminated, or at least
significantly reduced, by the application of a simple 2- or 3-term controller to compensate
for thruster non-linearity.

Linear-Quadratic (LQ) Control has been combined with the 'Smith-Predictor' Adaptive
Controller to produce a robust controller for underwater vehicles which incorporate time
delays. The strategy has been successfully demonstrated on the ARGO towed-vehicle at the
Woods Hole Oceanographic Institute. However, there appear to be no examples of LQ
control of ROV systems in which the effect of thruster dynamics produces more complex
vehicle behaviour [Yoerger, et al., 1990]. As with other linear controllers, several would be
required for each degree-of-freedom to be controlled. For this reason, the LQ control
strategy has been rejected.

The marine environment is, by definition, 'unstructured'. In addition, the vehicle
configuration will be changed as the sensor package is tailored for the mission requirements.
An ideal controller for a submersible vehicle will be able to adapt to changes in vehicle
configuration or operating environment. Of the so-called Adaptive Controllers, the
'Variable-Structure' or 'Sliding-Mode' Controller has been successfully used on several
ROV/AUV systems. These systems have been widely reported in the literature [for
examples see: Yoerger et al., 1986; Christi et al., 1990; Healey & Lienard, 1993; and da
Cunha et al., 1995].

Sliding-mode control has the additional attraction that a single controller can control the
vehicle across it's entire operating range. This strategy appears to be the best suited of
current control strategies for a vehicle AUV mission controller.

Whether the mission controller is a human pilot or an intelligent AUV controller, it is
desirable to minimise the effect of external disturbances on the vehicle. This can be
achieved by implementing cascaded control, with a lower-level controller to provide some
compensation for external disturbances. Furthermore, when AUV controllers are employed,
and especially when AUV controllers are being developed and tested, there will be
occasions where control must be switched between manual and automatic. In these
circumstances a bumpless transfer between manual and automatic control is highly
desirable.

Differences between the actual motion of the vehicle and that required by the controller at
the moment control is switched have the same effect as step inputs applied to the controller.
The effect may be severe leading to sudden, violent, movements of the vehicle. In extreme
cases, effects may exceed the vehicles design characteristics. A rapid change after a large
step change may upset or bump vehicle operating conditions. Transient responses resulting
from the bump may take a relatively long time to settle to the set-point. In circumstances
where the vehicle is deployed in restricted spaces or close to divers in the water, bumpless
transfer is thus essential. A lower-level controller, independent of the mission controller
helps provide bumpless transfer on the vehicle.

Additional complexity in controllers normally results in higher costs. Thus it is normal
practice to use the simplest controller which fulfils the requirements. This has been the
approach used in selecting controller designs for this project. A 3-term PID controller has
thus been chosen for thruster control to compensate for external disturbances. Implementing
this controller by DDC offers a number of advantages. In particular, vehicle motion can be
constantly monitored and regulated in three-dimensions, and controller parameters can be
rapidly changed in software to optimise controller performance. This last is important given
the iterative nature of ROV design.

As explained in chapter 2, thruster dynamics have a significant effect on overall vehicle
dynamics. The inherent non-linearity degrades thruster performance especially at low
speeds. Thruster performance can therefore be improved, and vehicle dynamics potentially
simplified, by incorporating a third level of control to compensate for thruster non-linearity.


4.2 Design of the control system

As stated from the outset, the vehicle controller developed in this project is for a ROV
system. The control system design thus incorporates the lower two levels of the control
strategy. Both elements of the control system have been designed for implementation by
DDC on an on-board computer. As stated above, one advantage of this is that controller
parameters can be quickly and easily modified in software. Once a prototype vehicle
becomes available for testing the estimated values for controller parameters used below will
be replaced by those obtained from testing the vehicle. The Zeigler-Nichols methods
[Appendix 5] offer a practical approach for establishing these values.

The lowest level of the control system, compensation for thruster non-linearity, is
considered first.


4.2.1 Thruster Non-linearity Compensation

Thruster non-linearity results from a number of sources. The main factors causing non-
linearity in thruster response are static friction (stiction) in the motor cog, gearing, o-ring
water seal etc., and the problem of thrusters stalling at low currents. A closed-loop controller
on each thruster to provide velocity compensation for the propeller will eliminate the non-
linearity. This will improve thruster performance and reliability. It will also improve the
reliability of controllers operating at a higher level in the control hierarchy. A simple and
economical PI controller would appear to be suitable for this application.

Electrically the thruster is an armature-current controlled motor, in which the armature
voltage is varied to change the speed. This provides a speed-controlled thruster similar to the
motor described in PMT604 [Block 3, section 3.2]. This is a fairly common design for ROV
thrusters. The thruster characteristics, provided by the manufacturer, are tabulated below:





















Table 4.1 Thruster Characteristics

Rotor velocity and direction can be measured using an optical encoder. A number of
suitable low-cost devices are available offering similar performance. The sensor selected
is the HEDS-5640 optical encoder combined with the HCTL-2016 16-bit quadrature
decoder/counter, both from Agilent Technologies [Appendix E]. The maximum motor
speed is 25000 rpm (approximately 417 revolutions per second) which corresponds to an
input voltage of 25V. The 16-bit counter on the quadrature decoder offers a
quantization interval of less than 1 rpm. The effects of quantization errors are thus
avoided.

A PI controller to provide thruster compensation is shown below:

Thruster Characteristics

Rated voltage 25V
Rated current 20A
Stall current 1.8A
Max power (85% efficiency) 425W
Armature resistance 0.24
Armature inductance 1mH
back EMF constant 0.092V (rad/sec)
Torque constant 0.087 Nm/A
Motor speed control 1000 rpm/V
Propeller speed constant 125 rpm/V
Rotor inertia 0.00458 kgm
-2


Gearing ratio 8:1

Electrical time-constant 4.2 ms
Mechanical time-constant 600ms

Figure 4.1: PI Thruster compensation


The general form of the PI controller is:

X
E
Kp
Ti
= +

1
1
s


where Kp = controller gain
Ti = integral time

An alternative form, suitable for implementation in software is:

u n Kp e n Io
T
Ti
e k
k
k n
( ) ( ) ( ) = + +

`
)

=
=

1


where u(n) = required output
e(n) = error signal (controller input)
Kp = proportional gain
Io = initial condition of integrator
T = sampling period
Ti = integral time

The closed-loop transfer function will be a second-order differential equation. To obtain
an initial estimate for controller parameters the thruster transfer function has been
assumed to be of the form:

G(s)
s
=
+
K
1


is the thruster time-constant, and the gain K is given by K
Kb
=
1
where Kb is the back-
emf constant. Thus, using values from table 1 above, =600ms and K=10.87.

Assuming the sensor to act as a proportional device with unity gain, and neglecting the
effect of the limiter, the closed-loop transfer function becomes:

G(s)
s
s s
=
+
|
\

|
+
+
|
\

| +
|
\

|
KpK
Ti
KKp KKp
Ti


1
1
2


The system must employ positive damping for a stable time-response. An underdamped
system will provide a relatively fast-acting response. The system is intended to improve
thruster non-linearity, so minimising overshoot and avoiding a resonance peak at =
n

in the closed-loop frequency response are desirable. A damping factor =0.7 should
provide an acceptable speed of response without excessive overshoot. Selecting the
closed-loop undamped natural frequency
n
=1.4 rads
-1
gives poles located at s = -1 j.
From this the values for Kp and Ti can be calculated thus:

Kp
K
=
2 1
so Kp = 0.018

Ti =
2 1
2

so, Ti = 0.167 s c.f. [PMT604, Block 3, Section 3.2]



substituting these values back into the closed-loop transfer function gives:

G(s)
s
s s
=
+
+ +
2
3
2 2
2


The sampling rate needs to be at least five to ten times the closed-loop bandwidth. This
would require a sampling interval of between 450 and 900ms. In fact, a sampling interval
of 200ms has been selected since this is well within the capabilities of the on-board
processor intended for the ROV. At maximum speed, this sampling interval corresponds
to slightly more than 10 revolutions of the propeller.

It is recognised that the above model is a gross over-simplification. Firstly, the thruster
cannot be represented as a linear first order system. The controller is being developed
expressly to compensate for the thruster non-linearity. Secondly, the sensor gain is not
unity, and the effect of the limiter has been neglected. Lastly, a digital to analogue
converter (DAC) will need to be added to the loop, further modifying the closed-loop
transfer function. Nevertheless, the model suffices to provide initial estimates for
controller parameters.

An outline for the required software has been developed and is shown below:
4.2.2 Thruster Control

A human pilot controls a ROV by means of joysticks on a control panel. The pilots
inputs correspond to required movement along the vehicles x, y or z axes. It seems
reasonable to assume that an AUV controller will also provide x, y and z components for
required vehicle movements. The ROV has been designed to have six thrusters mounted
DEFINE VARIABLES
;controller settings
REAL gain = 0.018 ;proportional gain
REAL TI = 0.167 ;integral time (seconds)
REAL IO = 0 ;integrator initial condition
REAL T = 0.2 ;sampling period (seconds)
REAL MAXV = 25000 ;maximum rotor speed
REAL MINV = -25000
REAL T1 = T/TI

;initial conditions
REAL Vact = 0 ;actual rotor speed
REAL Vreq = 0 ;required rotor speed
REAL error = 0 ;current error value
REAL Esum = 0 ;sum of samples
REAL UN = 0 ;initial output

REPEAT every 200ms
BEGIN
READ volt ;applied voltage
Vreq = volt * 1000
READ Vact ;current speed

error = Vreq - Vact
Esum = Esum + error ;update sum of samples

UN = gain * (error + Io + (T1 * Esum))

IF UN > MAXV ;limit speed
THEN UN = MAXV
ENDIF
IF UN < MINV
THEN UN = MINV
ENDIF

WRITE UN ;write output
END
in pairs orthogonally aligned with the vehicle axes. A controller is therefore provided for
each pair of thrusters.

Motion can be measured using solid-state accelerometers acting as rate-gyros. Three
such gyros, mounted orthogonally at the centre of mass and aligned with the vehicle axes,
will therefore monitor the x, y and z components of the vehicles motion. The gyros can
also function as the sensors for a basic inertial positioning system. The maximum ROV
speed is specified as 2 knots (1.03 ms
-1
). For a positional error of 0.1m, the minimum
sample interval is 51ms.

Several suitable accelerometers are available. Tri-axial units are also available but these
cost significantly more than three equivalent single-axis models. The device chosen for
the sensor is the Analog Devices ADXL105 high-accuracy 1g to 5g single-axis
accelerometer, combined with the AD976 16-bit 10
5
sample/second A/D converter
[Appendix E]. The ADXL105 incorporates an uncommitted amplifier suitable for
configuration as a low-pass filter to eliminate high frequency vibration.

The form of the controller is shown below:


Figure 4.2 PID Controller



The thruster assembly includes the non-linearity compensator described in section 4.2.1
above. The general form of the transfer function of a PID controller can be expressed as:


X
E
K
Ti
Td = + +

1
1
s
s

where K = controller gain
Ti = integral time
Td = derivative time


An alternative form suitable for implementation in software is:

[ ] u n K e n Io
T
Ti
e k
Td
T
e n e n
k
k n
( ) ( ) ( ) ( ) ( = + + +



`
) =
=

1
1


where u(n) = required output
e(n) = error signal (controller input)
K = proportional gain
Io = initial condition of integrator
T = sampling period
Ti = integral time
Td = derivative time
[PMT604, Block 2,
p23]


Setting Ti = 4Td simplifies the tuning of the controller and is normal practice for PID
controllers. Setting Io = 0 at time t=0 is also reasonable at this stage.

No data is available for the thruster response when attached to the ROV. The mechanical
time-constant of the thruster is known to be 600ms, but this is now part of the control-
loop described in section 4.2.1 above. The time-response of the loop to a unit-step is
given by:

( ) c t
e
t
n
t
d
( ) sin =

1
1
2

where
d n
= 1
2

and

tan
1
2
1


The control-loop has been designed with a natural frequency
n
= 1.4rads
-1
, and a
damping factor of =0.7, which gives a minimal overshoot of about 4.5% of the final
value. If this overshoot is neglected, an approximate time-constant for the closed-loop
can be estimated, giving a value of 1.23 seconds.

For stable systems, an value for the integral time which is too large is almost always
preferred than one which is too small. In this instance, a value for Ti of 5 seconds has
been selected. This will be modified by the Zeigler-Nichols method [Appendix F] when
the prototype is available. The gain will also be determined by this method. For the
present, the controller gain has been assigned a value of 2. A low value of gain is
preferred for the Zeigler-Nichols closed-loop tuning method.

The complete controller is shown in figure 4.3 below:

2 1
1
5
125 + +

s
s .
0 018 1
1
0167
.
.
+

s
Figure 4.3: Complete Control System

The sampling interval of 50ms has been chosen to enable the sensor to function as a
simple inertial guidance module for a future AUV mission controller if this is required.
The sampling frequency is thus far higher than the minimum actually required for the
controller.

The outline for the required software shown below is for the x-axis PID controller.
Controllers for the y and z axes will be essentially similar in form.




4.3 Signal Conditioning

The ROV system incorporates electrical, mechanical and hydraulic systems. The vehicle
is therefore an electrically and mechanically noisy environment. Electrical noise will
degrade signals and mechanical vibrations will effect sensors. The vehicle is a compact
unit so signal paths are short. Shielded cables, which are also necessary for protection
DEFINE VARIABLES
;controller settings
REAL gain = 2 ;proportional gain
REAL TI = 5 ;integral time (seconds)
REAL TD = TI/4 ;derivative time (seconds)
REAL IO = 0 ;integrator initial condition
REAL T = 0.05 ;sampling period (seconds)

REAL T1 = T/TI
REAL T2 = TD/T

;initial conditions
REAL Xact = 0 ;actual motion in X
REAL Xreq = 0 ;required motion in X
REAL error = 0 ;current error value
REAL Elast = 0 ;last error value
REAL Esum = 0 ;sum of samples
REAL Ediff = 0
REAL UN = 0 ;initial output

REPEAT every 50ms
BEGIN
READ Xreq
READ Xact

error = Xreq - Xact
Esum = Esum + error
Ediff = error + Elast
Elast = error

UN = gain * (error + (T1 * Esum) + (T2 *Ediff))

WRITE UN ;write output
END
against the marine environment, will minimise the effect of electrical noise and reduce
the signal conditioning requirements.

The optical encoder employed as the sensor for thruster non-linearity compensation
provides a direct digital output corresponding to motor shaft speed. Pull-up resistors on
the output pins enable each of the three channels to drive a single TTL load. These
resistors can be mounted directly on the sensor. An analogue to digital converter and low-
pass filter will be required on the motor drive voltage at the controller input. The low-
pass filter will eliminate high-frequency noise. No further signal conditioning is required
on this controller.

The sensors for the thruster controllers are accelerometers which provide an analogue
voltage proportional to the acceleration along each of the vehicles axes. Vibration will
also be measured by these sensors providing an unwanted output. A low-pass filter on
the output will eliminate responses due to this vibration leaving only the required signal
at the analogue to digital converter input, and also act as an anti-aliasing filter. A design
for a suitable filter, which also provides 0g offset, using the uncommitted amplifier is
provided in the ADXL105 data sheet [Appendix E]. The filter is a second-order Sallen-
Key low-pass filter which has been re-drawn below as figure 4.4:

C2
C1
R1 R2
R4
R3
VR1
VDD
IN
OUT

Figure 4.4: Active low-pass filter with gain and offset

The cut-off frequency,
c
, and gain, K, are given by:

c
c
f
R C R C

= = 2
1
1 1 2 2
and K
R
R
= + 1
4
3


the component values given in the data sheet are R
1
= R
2
= R
3
= 47k
R
4
= 100k
C
1
= C
2
= 0.1F
VR
1
= 10k

giving a cut-off frequency f
c
= 33Hz and gain K 3. These appear to be reasonable
values for a first estimate until measurements from a prototype unit are available. The
controller input, from the pilot, is already in digital form, and should require no further
signal conditioning apart from amplification.

4.4 Real-Time Monitoring Systems

The sensor package which is carried by an ROV is determined by its mission. Some sensors
which may be carried are tabulated below. The list is not intended to be exhaustive.


Attitude; Metal Detector;
Echo sounder; Obstacle Avoidance;
Global Positioning System (GPS); Sub-bottom Profile;
Compass / Heading; Video;
Depth; [Lights];
Gyro/Inertial Navigation;
Source:- (ROV Survey '96)


The controller design will also impose a minimum requirement in order to provide feedback
on the current status of controlled parameters (position, orientation etc.).

The default sensor configuration for this ROV will measure: depth (pressure sensor),
direction (electronic flux-gate compass), yaw (accelerometer), pitch (accelerometer), roll
(accelerometer), and water speed (log). These sensors provide inputs to the control
system. In addition, two CCD camera units and sensors for temperature, salinity and pH
will be provided on the standard ROV.

The default sensor package will be supplemented by additional sensors appropriate to a
particular mission. In particular, it is intended that an acoustic echo-sounder/sonar, sub-
bottom profile unit, and magnetometer/discriminating metal-detector will be developed.
since these would be particularly appropriate for the target market.

To extend their functionality, many ROVs are designed to carry manipulators which
facilitate remote intervention. Manipulators are classified according to the number of joint
movements. Thus, a manipulator which bends at the wrist (1), elbow (2) and shoulder (3),
rotates at the elbow (4), wrist (5) and jaw (6); & having a jaw which opens & closes (7)
would be classified as a "7-function manipulator". A 5-function manipulator has been
designed for attachment to this ROV. The general arrangement, together with mechanical
and hydraulic system designs for the manipulator are attached as appendix D to this report.
{additional camera units will be mounted on each manipulator arm}.

The data system must therefore be able to handle analogue data, digital data, and video
signals. Suitable umbilicals are readily available as standard items from several suppliers.
However, in order to ensure compatibility with other systems, it is desirable to use a
standard bus design. The IEEE standard STE-bus, which is also the design used in the
autonomous vehicle described in T395 Mechatronics: Designing Intelligent Machines has
been selected for this vehicle.


4.5 System Architecture


This section considers the practical hardware and software issues effecting the
implementation of the ROV and controllers. The present project has been to design
controllers to be implemented on-board the vehicle, with control inputs originating from a
human pilot at the surface. The system will thus consist of two connected computer systems.
The elements of these systems are covered below:

4.5.1. Computer Hardware

The surface control console is being built around a standard Intel Pentium 233 MHz PC
motherboard fitted. This offers a standard architecture with both serial and parallel interface
ports. Standard plug-in expansion cards for the STE-bus are available from a number of
suppliers for the real-time monitoring system. There are precedents for the use of PC
hardware as controllers for ROV systems. The sliding-mode controller for the Jason ROV
was implemented on an IBM PC-AT using an 80286 processor with an 80287 math co-
processor [Yoerger, et al., 1986]. The proposed hardware thus has ample processing
capacity for this application.

A human operator provides inputs at the console via joysticks and switches. The interface
design is similar that used in radio-control model-helicopter consoles produced by Futaba
and other manufacturers. A proposed console layout is illustrated in figure 4.5 below:-



Modular manipulator control panels can be fitted (shown on the left and right of figure 4.5)
with additional monitors to display pictures from cameras mounted on the manipulators.
The default configuration will only include the 'ROV Control' and 'Sensor Panel 1' modules
together with 'Camera 1', 'Camera 2', and 'Vehicle Status' monitors. All other positions will
be blanked-off. The console will be environmentally sealed to the IP67 standard to allow its
use on a small boat.

The on-board slave module will be constructed using PC104 hardware. The PC104
standard [Appendix E] has become the de-facto standard for on-board controllers on ROVs
and AUVs. The PC104 bus is designed to be an ultra-compact version of the standard PC
bus, intended to provide hardware solutions where reduced space and power requirements
are important. It is thus ideal for ROV and AUV systems. The present design calls for a
single Intel 486 processor with appropriate data-acquisition and I/O boards. Suitable
hardware is available from a range of suppliers.


Figure 4.5 - Proposed ROV Control Console Layout
4.5.2. Operating System

The operating system chosen for the surface unit is Red Hat Linux version 7.1. Linux is an
open source product which offers a number of advantages. It is a genuinely open system,
with distributions available from a wide range of suppliers. It is stable, robust, well
supported and inexpensive. It also uses the UNIX process model wherein each process
operates in its own protected virtual address space. It offers multi-threading and multi-
tasking which are essential for real-time control and monitoring systems. Linux also
supports a much wider range of hardware devices than many proprietary real-time operating
systems and an increasing number and variety of applications have been written for, or
ported to, Linux.

The on-board slave controller will also employ Linux as the operating system. In this case
one of the real-time embedded distributions is appropriate. A real-time, multi-tasking
operating system is required for the single central-processor to switch between the various
controller tasks as required. Several Linux distributions are being considered. These include
On-Core Linux, LynxOS, and BlueCat. The use of Linux for the on-board system will avoid
potential interface or compatibility problems with the surface unit. All the distributions
being considered are highly configurable with the final installation tailored for the
application from a range of Linux components.


4.5.3. System Software

Considerable analysis has been carried out in the literature regarding the relative merits of
Hierarchical and Layered architectures for AUV system software. Although this project has
considered the design of a controller for a ROV, and not an AUV, a requirement is for the
vehicle to be suitable for developing AUV systems. The 'Master controller' should thus be
designed in such a way as to facilitate it's incorporation as a module of an AUV controller.

Software Architectures for Autonomous Underwater Vehicles are divided into two main
categories - 'hierarchical' and 'layered' (some authors prefer the terms 'heterarchical' or
'subsumption' to 'layered'). An experimental comparison of the architectures showed that
both accomplished the mission in a "behaviourally equivalent fashion" [Byrnes et al., 1992].
The authors of the report were unable to agree on which architecture was 'best' for practical
implementations.

An analysis of the software architectures of twelve practical AUV systems has been carried
out by William Hall and Milton Adams. On the basis of this analysis, the authors have
proposed a number of ways in which AUV software architectures should develop [Hall &
Adams, 1992]. The authors conclude with a design for an on-board, AUV planning-system
architecture which is hierarchical in nature [Ibid.].

Since neither of the two dominant approaches toward AUV software architectures offers any
obvious advantages, it is reasonable to assume that both will remain in use for the
foreseeable future. The ROV controller software must therefore be designed to be
compatible with either AUV architecture. The controller modules developed in outline in
sections 4.2.1 and 4.2.2 above are suitable for implementation as stand-alone processes
running concurrently on a multi-tasking operating system, and therefore meet this
requirement.

Vous aimerez peut-être aussi