Omer Dic 2010
Omer Dic 2010
Omer Dic 2010
Abstract: This paper describes the control architecture of smart ROV LATIS. Smart ROVLATIS is a novel,
multi-mode of operation marine robotics vehicle, developed at Mobile & Marine Robotics Research
Centre (MMRRC), for operational flexibility in high-resolution near seabed survey from shallow inshore
waters out to the continental shelf edge. The vehicle can operate in surface-tow mode, surface-thrusted
mode and ROV operation mode. Special features of the system include: deployment interoperability for
small inshore boats and larger research vessel; built-in auto-tuning of low-level controllers; fault tolerant
thruster control in 6 DOF; onboard computer control enabling real-time disturbance reaction and topside
augmented reality system support. The vehicle can be used as a target platform in various scenarios
(research and scientific projects, inspections, seabed survey missions, vision experiments etc.).
Keywords: smart ROV, fault-tolerant control, control allocation, augmented reality.
processes ROV navigation data, transforms data into system HT/VT Interface
AC FO Cores
states using standard control frames (body-fixed and earth-
fixed), bundles data into clusters and shares it over the
CONTROL NETWORK. NI CompactRIO is used as a real-
Power Bottle
Multibeam
Cameras
DC Power Supply Units
3. CONTROL ARCHITECTURE Ethernet - FO Converters
RS-232/485 Converter
In contrast to most common control architectures used in
modern ROV industry (where ROV is equipped with basic DC DC
I/O modules, while control synthesis is performed topside),
ROVLATIS is equipped with a full real-time embedded control Control Bottle Survey Bottle
system, which performs all necessary data processing and Ethernet Serial Server Ethernet Serial Servers
synthesis online, aboard the vehicle in real-time. Ethernet Switch Ethernet Switch
Relay Module Relay Module
The block diagram of the ROVLATIS control system is shown PC EBX945
in Fig. 2, while physical layout of software modules CompactRIO
(software distribution) is presented in Fig. 3. The ROVLATIS Light Interface
control system utilises control allocation approach, where the Thruster Interface INS Sidescan
actuator selection task (mapping of the total control efforts Aiding Sensors:
onto individual actuator settings) is separated from the o DVL
regulation task (design of total control efforts) in the control o Depth
design. The Mission Builder module, Arbitration module and Lights o USBL
Synthesis module perform the regulation task, while the o GPS2
Control Allocation module performs the actuator selection
task. Fig. 1. ROVLATIS overall hardware architecture.
The main objective of the Mission Builder module is to Navigation Data
transform the mission objective, pilot inputs and measured (Support Vessel)
navigation data into the desired ROV trajectory, i.e. to
formulate the trajectory planning problem. A description of
the Arbitration module is given in the following. In order to
achieve the desired trajectory under real-time constraints, a ControlPC
set of task executors (Exclusive Behaviours (only one active
at a time) and Collaborative Behaviours (many active at a App1: GUI App2: Master
Instrument Display Shared Variable Manager
time)) have been developed. Each of these task executors is
ROV Pilot Input Interface Remote Power Control
competing to control actuators. The control buffer concept
Operation Mode Selector Interface with Support
has been developed to provide transparency and easy fusion Vessel
Autotuning Setup
of different task executor demands. Each task executor LLC Monitoring Mission Planning
produces its own control cluster inside the control buffer.
App: VR
Ethernet Switch Augmented Reality Display
Interface & Data Management (CONTROL NETWORK) Thruster Saturation Bound
Visualisation
App: PCEBX945
Arbitration Ethernet Switch Shared Variable Server
Collaborative Behaviours Autotuning
(CONTROL NETWORK)
Arbitration
Standard Control Cluster Coordinator
Exclusive Behaviours
Exclusive Standard NI CompactRIO
Mode Navigation Data
Switch Emergency Control Cluster App: IO_Host (RT Controller) (ROV)
Emergency Low-Level Controllers
Control Allocation
AUV
Operation
Mode App: IO_FPGA (FPGA)
ROV Mode Control Cluster
Switch ROV I/O Interface with Thrusters,
Leak Detectors and Lights
Fault Accommodation
ROV
Low-Level Controllers
IJd nd Propulsion Rigid-Body
IJ LLC + Control Allocation
System Dynamics
IJVJ + Synthesis Control Allocation
Faults
Fig. 2. Control architecture.
A control cluster (see Fig. 4) consists of Virtual Joystick performance in the case of the time-varying SP vector.
components (to mimic direct controls generated by a virtual Vector SP Offset is used to avoid integrator saturation
pilot) and a set of settings for Low-Level Controllers (set problems. For example, the PID depth control algorithm has
points, feed-forward inputs and on/off switches to pure performance during the transition stage, since the
enable/disable individual controllers). The Virtual Joystick ROVLATIS is slightly positively buoyant. However, much
components are normalised surge, sway and heave forces and better performance is obtained using the PD control
roll, pitch and yaw moments. The Coordinator performs the algorithm with SP Offset set to a positive value (0.1m for
fusion of these control clusters into the Standard Control example shown in Fig. 6) to compensate steady-state error
Cluster. due to positive buoyancy of the vehicle. In this case, depth
change is fast, smooth, without overshoot and without steady-
The Operation Mode Switch is used to switch between AUV state error, as shown in Fig. 6. However, this approach works
Mode and ROV Mode. In AUV Mode, control algorithms are well only in the case of smooth sensor signals, like in the
exclusively used to create control actions (write values and case of ROVLATIS, where the depth sensor measurements are
set switches inside control clusters), while in ROV Mode the fused with the INS estimations using the Kalman filter.
pilot has full freedom to generate these actions. However, the
SLORW VKRXOG EH DZDUH QRW WR ³ILJKW´ ZLWK HQDEOHG ORZ-level
controller. For example, if the low-level heading controller is
enabled to keep a set point (desired heading) of 60°, any yaw
moment created by the pilot using an input device, such as a
joystick or gamepad, is considered as a disturbance by the
heading controller. Therefore, the controller will create
corresponding actions to reject this disturbance and keep the
heading at 60°.
The Exclusive Mode Switch is used to switch between
Standard and Emergency Control Clusters in AUV Mode. In
the case of any leakage (water penetration inside any bottle),
two Leakage Answer Modes are available. In Auto-Answer Fig. 4. Control Cluster.
mode the main state machine will activate the Emergency
State setting the Exclusive Mode Switch to Emergency,
setting the Operation Mode Switch to AUV Mode and
initiating automatic ROV recovery to the surface. In Manual-
Answer Mode the Operation Mode Switch is set to ROV
Mode and the pilot is informed of the leakage, but no other
automatic action is undertaken.
Finally, the output control cluster is (optionally) blended with
the Obstacle Avoidance Control Cluster to create the Winner
&RQWURO &OXVWHUWKHXOWLPDWH ³ERVV´ ZLWKH[FOXVLYHULJKWVWR
control the actuators. Fig. 5. Internal structure of LLC loop.
Inside the Synthesis module the Winner Control Cluster is )LQDOO\ LQ VSHFLDO ³$XWRWXQLQJ´ RSHUDWLRQ PRGH WKH
unbundled into Virtual Joystick components (vector IJVJ ) controller output is generated using a relay (see Fig. 5).
Between successive ROV missions, it is likely that some of
and the Low-Level Controller (LLC) cluster, which is used as the onboard instruments/sensors/equipment will be
one of inputs to the LLC loop (Vectors SP and FF in Fig. 5). added/removed/replaced, leading to changes in dynamic
Other inputs include ROV navigation data (vectors PV and properties of the ROV (mass, moments of inertia, drag
dPV/dt) and other parameters (vectors SP Offset, FF , KFF, properties, etc). Controllers optimally tuned for a particular
KP, KI, KD and Relay Amplitude). vessel configuration will not give the optimal performance in
the case of a change in configuration. Autotuning of LLC is
There is a single controller for each degree of freedom an advanced feature of the control system, yielding optimal
(DOF). Surge and Sway controllers are velocity controllers, controller performance, regardless of configuration changes.
while Heave, Roll, Pitch and Yaw are position controllers. It is recommended that the autotuning is performed at the
Each controller generates a manipulated variable MV to be beginning of a mission.
applied to drive actuators, in order to keep process variable
PV as close as possible to set point SP. Individual outputs are Two types of autotuning algorithms have been developed.
bundled into a vector of normalised forces and moments Velocity controllers are tuned by recording and utilising the
force-speed static characteristics. Autotuning of position
IJ LLC . If a controller is disabled (not active), the controllers, described in the following, utilises self-
corresponding MV is set to zero. Otherwise, the controller oscillations. Autotuning algorithms described in (Miskovic et
output is calculated as a normalised output of a modified PID al., 2006) have been expanded for 4 DOF controllers: Heave,
controller. Feed-forward (FF) input improves the tracking Roll, Pitch and Yaw. The autotuning process involves the
following steps: (1) Generate self-oscillations; (2) Wait for iteration method is activated in the second step. In this way,
transient stage to finish; (3) Measure amplitude and period of the hybrid approach is able to allocate the exact solution,
steady-state oscillations; and (4) Find new values of optimal in the l2 sense, inside the entire attainable command
controller gains using tuning rules. A novel set of tuning set.
rules for underwater applications has been developed, which
provides the optimal performance of low-level controllers in
the case of configuration changes and the presence of
disturbances (waves & sea currents).