vol 3 issue 4

Unifying underwater vehicle control systems

5 June 2008
By Edin Omerdic
Share |

Subsea vehicle control is a tough job in a harsh environment requiring great skill. E&T explains the Mobile & Marine Robotics Research Centre's efforts to build a standardised control system.

Exploring and exploiting the deep oceans is a challenging, expensive and time-consuming activity. It is a complex environ-ment in which vehicle control systems must not only avoid obstacles but also compensate for unpredictable disturbances, such as sea currents and the drag effects of umbilicals, while compensating for uncertainties in position and orientation.

There are many types of underwater vehicle, each using its own bespoke control system, but we at the Mobile & Marine Robotics Research Centre (MMRRC) favour a single system that can both control and simulate vehicles.

Our Virtual Underwater Lab (VUL) is a mixed hardware/software tool that offers a unique, generic solution for underwater vehicle development. It is designed to make overall system integration easier and to provide a framework for researchers to develop, implement and test advanced control algorithms in a combined real-world/simulated environment.

The systems are now complete and we are ready to disconnect the simulator and connect to the real thing without any change in the code. However, the software has not been developed to be specific to ROVs (remotely operated vehicles); everything is programmable and the system can be used with any ROV because it is completely modular.

We have tried to cover all configurations of thrusters that currently exist within the industry and we are currently building our own ROV for demonstration purposes.

One of the problems that many vehicles suffer from is that of tracking errors, which leads to an unnecessary extension of survey mission time and an increase in mission costs. Continuous course correction can also lead to wasted battery power, particularly in the case of AUVs. 

Our control system copes with sea currents extremely well - we have a good model where you can inject currents on different layers as required to see how the controller will compensate.

It is even possible to change the pitch and roll during a mission if the ROV is not perfectly aligned, or for example, if a mission requires the ROV to have a 10° roll.

The dynamic behaviour of the vehicle depends upon the configuration of the onboard sensors and equipment. In order to achieve the best performance, low-level controllers need to be retuned before each mission to adapt to a particular vehicle payload configuration. Our auto-tuning feature ensures that a simple button push will optimise the low-level controllers for a particular mission vehicle configuration.

To develop, implement and test advanced control algorithms with auto-tuning and fault-tolerant capabilities under realistic conditions, it is necessary to build an environment where rapid control prototyping and hardware-in-the-loop techniques can be used.

Integrating equipment

Working with underwater vehicles on a typical seabed survey mission requires the integration of the existing ship equipment (GPS, USBL) with ROV onboard components.  Each component has its own mechanical and electrical interface, which includes mechanical installation and alignment, power requirements, communication protocols, and so on.

Most underwater sensors still communicate through ordinary serial protocols, which makes wiring these components more complex. In addition, each component has its own configuration software. In order to obtain the best quality navigation data, it is necessary to reconfigure some components for the best performance in real time, depending on the stage of the mission. This makes overall system integration difficult, requiring significant technical expertise. It is also very expensive to work with all this equipment in real conditions, since ship time is very expensive - upwards of €15,000 per day for research vessels.

This makes the development of a simulated environment very desirable, given that all the connections and functionality can be checked in the laboratory, and many integration problems can be detected and resolved in advance.

Research work requires that ROVs perform sampling, data acquisition and high-resolution acoustic and video survey in deep oceans using expensive equipment that is deployed close to the seabed, putting a huge amount of responsibility on the ROV pilot to control the vehicle and prevent any damage or loss of equipment.

The success of missions is closely related to individual skill and previous experience of the ROV pilot, hence the demand for a set of aiding tools (control algorithms) that can enable an ROV pilot with moderate skills to perform complex tasks.

The pilot's job will be to bring the vehicle to the initial position, to activate the corresponding aiding tool (algorithm) and to monitor the vehicle.

3D real-time visualisation

Underwater, a pilot's field of view is limited to onboard cameras, which have a limited range and sector of view, and are significantly affected by turbidity. The scanning sonar  also gives noisy returns that are frequently difficult to interpret.

The pilot will also often have a projected plan position indication showing UAV position relative to the surface vessel. A pilot's view and understanding of the ROV in its underwater environment would be greatly enhanced if the pilot was provided with, and could control, a scene view from the side of the ROV or from above, or from any other vantage point.

This is  possible if a virtual reality (VR) underwater scene is prepared in advance, with 3D models of the vehicle, ship and seabed, and if real-time signals from sensors (position and orientation of the ROV and ship) are forwarded to the VR scene in real-time.

Different viewpoints in the VR scene can be rendered in different displays, so that the same scene can be viewed from vantage points at the same time, allowing the visualisation of navigation data in real time, making control of the vehicle easier and safer.

The Virtual Underwater Lab has been designed to address these needs, and its main features offer:

  • Signal-level compatibility between simulated and real-world environment
  • 3D real-time visualisation of navigation data
  • Advanced, flexible, fault-tolerant control system with auto-tuning capabilities
  • Open architecture for rapid control prototyping and hardware-in-the-loop development
  • Aiding tools for ROV pilot.

Technical SPECs

To use the VUL in the simulated environment, real-world components from the ship (GPS1, GAPS) and the ROV (PHINS, external sensors, power lines and leak detectors) are replaced with hardware/software simulators and all the software (except the sonar simulator) has been implemented in NI LabVIEW using the State Diagram Toolkit, Simulation and FPGA Module.

Data (outputs of individual components) are bundled into clusters and transmitted using network-published shared variables, based on the NI Publish-Subscribe Protocol (NI-PSP).

The NI-PSP protocol uses less network bandwidth and is more efficient than TCP/IP for the given requirements of the NI-PSP protocol. Unlike the UDP protocol, however, the NI-PSP protocol guarantees delivery by implementing an additional layer of functionality on top of the raw UDP protocol.

All simulators are synchronised with real-time. Full six degrees of freedom (DOF) vessel dynamic models are implemented, including thruster DC-motor dynamics with nonlinearities, such as saturation, slew-rate limiter, friction, nonlinear propeller load, etc.

The different components of the ship and ROV simulators are simulated as parallel loops executed with different speeds, depending on the dynamics of components. For example, the propulsion system component for the ROV simulator has simulation time of 1ms synchronised with real time, so it is possible to monitor current consumption of thruster motors in real time. However, the rigid body dynamic loop is executed with simulation time 20ms, compatible with PHINS output rate.

The inputs to and outputs from virtual instrument (simulators) are compatible with the corresponding real-world instruments on the signal level.

This means, for example, that the output PHINS standard of the ROV simulator is sent through the serial ports in the same RS232 format as output of the real IxSea PHINS (Identical message formats including checksums; Port settings are: Baud rate 57600, Parity: Odd, Stop bits: 2). In this way, all communication delays and latencies are present during the control design stage, which provide a framework to design robust control system in a realistic representative environment.

Hybrid control

The control system utilises a hybrid control approach, which combines the advantages of a top-down traditional (hierarchical) AI approach and a bottom-up behaviour-based approach.

Currently, two high-level task executors have been implemented: Way-Point Tracking and Obstacle Avoidance.

Each of these task executors is competing to take control of actuators. The control buffer concept has been developed to provide transparency and easy fusion of different task executor control demands. Each task executor has its own control cluster and mask inside the control buffer. The control cluster consists of Hand Control Unit (HCU) components (to simulate a virtual joystick) and a series of settings for low-level controllers (set points and on/off switches to activate/deactivate individual controllers).

Each control cluster is masked with a corresponding mask, depending on the state of the mission and navigation data (interaction with the real world).

A mask is built from weights and logic gates, which are bundled into the same structure as the control cluster. Masking is performed by multiplying (ANDing) corresponding fields in the control cluster and mask.

The priority level of the task executor is determined by the mask content. In this way it is possible to control the degree of cooperation and competition between different task executors. After masking, control clusters are bundled into the Winner Control Cluster, which has exclusive actuator control.

Safety critical behaviours are implemented using competitive, winner-takes-all procedures.  For normal mission operation cooperative behaviour fusion is used to realise mission execution consistent with the mission plan in the implemented control hierarchy.

Currently, two planners have been implemented in the VUL: Mission Planner and Tracking Way-Points Planner. The main task of the Mission Planner is the decomposition of the mission into a set of tasks.  The Mission Planner has been realised as a state machine using the State Diagram Toolkit.

Each state in the machine represents a stage of a typical ROV/AUV mission. States are executed in a sequential order. The output of each state is a high-level task, which is transmitted to the Behaviour Co-ordinator/Arbitration component.

Actual way-point guidance is performed inside the Tracking Way-Points state. The main task of the Tracking Way-Points Planner is the decomposition of the way-point guidance algorithm into a set of tasks.  The Tracking Way-Points Planner is also realised as a state machine, whose parent is the Tracking Way-Points super-state.

Depending on the predetermined tracking mode (e.g. constant depth or constant altitude), the corresponding operation mode of the Auto-Heave low-level controller (Depth or Altitude) is permanently activated in the tracking control cluster during the way-point guidance.

The Navigation PC is running a real-time side-scan sonar simulator, developed within the research centre at the University of Limerick. The serial input to the sonar simulator is PHINS standard (absolute position and orientation of the ROV in the Earth-fixed frame obtained from the ROV simulator). Alternatively, the same data can be sent through Ethernet using the UDP protocol.

Control allocation

A hybrid control allocation approach is implemented inside the Control Allocation Express VI. In the fault-free case, optimal control allocation is guaranteed for all possible command inputs, since the hybrid approach for control allocation finds the exact solution on the entire attainable command set.

In faulty situations, the fault diagnosis part of the system immediately detects and isolates any fault in a thruster using fault detection units and delivers knowledge about faults in the form of a fault indicator vector. The fault accommodation part of the system uses this vector to accommodate fault and eventually switch off the faulty thruster. At the same time, control reallocation is performed by redistribution of control energy among remaining operable thrusters, so that the mission can be continued with a minimal loss of control performance.

All inputs to the Control Allocation Express VI are normalised to standard intervals. Depending on user-defined settings inside the dialogue box, the outputs (actuator settings) can be compensated for non-symmetrical propeller T-curves and adapted (scaled and/or rounded, if necessary) to meet the requirements of thruster input interfaces.

The use of each thruster is controlled by sliders HT (VT) Saturation Bounds. The position of these sliders is determined by the ROV pilot or the fault accommodation system, depending on the state of the thrusters (healthy, partial fault or total fault).

The current version of the Control Allocation Express VI covers the most common thruster configurations. The user can choose a combination that matches the particular thruster configurations of the vehicle.

Virtual reality interface

The Virtual Reality Interface has been built using COM object technology and the virtual underwater scene is built in four steps, using four wizards:

  • The Terrain Builder Wizard to build a realistic survey environment from existing imported seabed maps;
  • The ROV Configuration Wizard to select an ROV and configure survey equipment;
  • The Ship Configuration Wizard to select a ship and configure the interface with ship equipment;
  • The Underwater Structure Configuration Wizard to configure and place underwater structures, such as fish cages, pipes etc. in the virtual scene.

The finished VUL has an open architecture, which provides a framework for researchers to develop, implement and test advanced control algorithms in a safe simulated environment before actual tests are performed in a real-world environment. The signal-level compatibility between simulated and real-world environment provides the opportunity for rapid control prototyping and hardware-in-the-loop development techniques to be used in system design.

Real world

An ROV system has been designed at the University of Limerick and vehicle construction is nearing completion in the university workshops. Final base vehicle construction is practically complete and invitations to tender have been issued for supply of a winch and umbilical system.

The control system development is complete, has been fully tested in the VUL and is ready for testing as soon as the vehicle is complete. Initial tests will be carried out in test tanks in the lab prior to open water testing at a nearby dock before offshore testing.

Sea testing is planned for summer 2008 with ship time onboard the research vessel Celtic Explorer at the Marine Institute in Galway. The main focus before the sea trials will be to complete system interconnection. The vehicle is equipped with eight SM4 thrusters from Saab Seaeye which are used on the company's Tiger and other ROVs. They will be installed in a four horizontal and four vertical thrusters configuration, giving considerable redundancy.

Share |
Related forum discussions
forum comment To start a discussion topic about this article, please log in or register.    

Latest Issue

E&T cover image 1410

"Climate change in Antarctica is leading to interest in extracting the region's natural resources, but there's the small matter of a treaty."

E&T jobs

E&T Marketplace

The essential source of engineering products and suppliers.

E&T podcast

Tune into our latest podcast

iTunes logo

Subscribe

Choose the way you would like to access the latest news and developments in your field.

Subscribe to E&T