Académique Documents
Professionnel Documents
Culture Documents
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
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.