Development of a novel autonomous vehicle significantly reducing costs related to subsea sensors deployment and recovery

Final Report Summary - AUTODROP (Development of a novel autonomous vehicle significantly reducing costs related to subsea sensors deployment and recovery)

Executive Summary:
Executive summary

Operational challenges related to environmental data harvesting from sensors on the seafloor is addressed in this research project funded by the European Commission - Research & Innovation. To date these types of operations, comprising offshore support vessel, complex handling and auxiliary equipment, will in most cases surpass the cost of the sensor itself, cause the survey-cost to proliferate or alternatively place constraints to the survey-extent or duration. This cost will heavily impact on single point installations, but operational cost is also proportionally significant for multi-sensor installations and for retrievable sensor-grids, especially when sensors are to be deployed in deep water. Also the challenge in reducing mobilization time and survey turn-around is addressed.

Isolating the main hurdles to overcome resulted in a strong focus on the through water-column transportation, lateral displacement bundled with tight installation accuracy, i.e. eliminate or significantly reduce the resources required to bring a sensor from the surface of the water to a predefined location on the seafloor a small distance away from the vertical, and similarly return to the surface deployment point after completion of the data harvesting.

Based on a substantial vertical component a self-propelled or gravity based concept were considered, adding features such as onboard or self-contained navigation combined with active control surfaces, all comprised in a torpedo-shaped hull with integrated landing-gear that may reveal a hosted sensor-cargo. Additionally a variable buoyancy-/ballast system was to be developed.

During the course of theoretical study, initial analysis and testing, a delta-shaped rudder assembly were designed and fully engineered, and subsequently integrated with a tailored portfolio of sensors, shortlisted and analyzed through specially developed navigation algorithms and simulation. A generic shape was initially used for this virtual modeling, in parallel to developing a fully physical prototype hydro dynamically tested and mathematically defined through testing both in a tow tank and circulation tank, completing the autonomous sensor platform - AutoDrop.

Targeting the prosperous seismic node market, i.e. capable of hosting a subsea sensor-assembly comprising geophones and a hydrophone, the vehicle cargo capacity was defined and all sub-systems finalized, e.g. hull-size, landing-gear capacity and excess buoyancy needed to compensate for negative battery weight etc. Also means of external geo-referencing and wireless-communication were subsequently defined, and components sourced and integrated.

Finally a 3D-modell of the optimal assembly was presented, and corresponding data from simulation presented. The overall complexity partly defend the exhausted use of resources, but research findings and positive results more than balance not fully meeting the project objectives, and the consortium strategy is to finalize a fully operational prototype vehicle, and demonstrate the operational efficiency and accuracy capacity.

Project Context and Objectives:
Project Context and Objectives

This project was conceived during, or directly after, having successfully contributed to the design and launch of a new autonomous node operation - CASE Abyss. To date this semi-automatic sensor package, which is deployed to the seafloor and subsequently recovered onboard by the use of tether operated underwater vehicles (WROVs) and onboard winch etc., still represents the latest generation available for seabed seismic. Some 1200 units of this four component (4C) seismic sensor is produced and currently been operated in large seismic grids on the seafloor in deep waters offshore.

From initially being a generic tool for deploying a variety of sensors to the seafloor the AutoDrop-project have grown to become a highly valued answer to the market surge for a more efficient seabed seismic operation. It is however a few interesting development programs targeting the same market, but this only support our vision of a stronger market demand. In fact the market, initially only covering operational field simulation and exploration seismic, have grown significantly to apply also for geo-hazard survey. The later to fully expose geo-mechanical imperfections, potentially leading to severe environmental incidents and potentially avoid disasters like the Deepwater Horizon oil spill at the Macondo-field. Gigantic wind-farms offshore also add to this market while requesting fully surveyed seafloor foundations for the numerous supersized windmills.

Knowledge and experience from these offshore mobilizations, tailoring of special offshore vessels to this type of seabed node operation, incl. highly specialized onboard and in-water handling equipment, simply defined a huge market opportunity and potential CAPEX savings. Let alone the investment in the numerous sensors itself and the related operational cost, mechanically deploying and recovering them to and from the seafloor respectively. The latter cover some 2/3 of the operational expenditure; hence a significant OPEX saving is targeted in this development of ‘free-fall’ robotics.
The AutoDrop represents a generic sensor platform, i.e. no unique sensor-payload is defined, but the system to be prototyped and demonstrated is initially targeting a commercial entry level by offering deployment of 4C-sensors. An increasing demand and subsequent growing market size for this type of data acquisition, in particular were the seismic sensors is to be physically planted into the seafloor soil, have been pursued. Hence some 2nd order priorities have been defined, e.g. size of accumulated energy stored onboard, volume and form-factor for the payload itself and facilitating a vertical “open-cargo” landing.

Another market resonance is the robotization trend subsea, combined with the car and cellphone-producers ongoing struggle to miniaturize sensors and driver electronics for maximum energy utilization nonetheless a minimal size. Oil companies have already shown a great interest in and funded both mature developments as well as more speculative initiatives, but more importantly ramped up the commercial use of existing deployment technology, e.g. WROV-installed nodes and cable or wire based systems. Another general trend in the oil&gas segment is for license owners to explore steadily deeper and eventually ultra-deep prospects.

The AutoDrop is potentially one solution to this, utilizing the significant vertical component to drop fast, based on negative weight and gravity, from an initial surface position to a pre-defined location on the seafloor, purely assisted by onboard inertia measurement sensors and dynamically activating the tail-mounted control-surfaces. A proportional cross line displacement is facilitated by planning a glide-trajectory and the accuracy to profit on the fast deployment through potential sea-current and sensor drift. By merely a coincidence an environmental drop of ballast is developed, in a response to client skepticism in dropping conventional concrete-slabs accidentally on manmade structures on the seafloor.

Three main operational phases were identified, the deployment and recovery transit from surface to the seabed and return, and the payload-logging of sensor data while landed on the seafloor. Variable gravity based propulsion were initially considered, and a self-contained navigation package adopted.

The basic idea is that the accuracy of a lateral gliding object could be actively controlled by a set of rudders in a closed-looped process controlled by the onboard control system, with a highly specialized navigation algorithm running on a CPU being continuously feed by a small drift inertia measurement unit. A last minute GPS-input at the surface combined with a rapid decent, were considered to be sufficiently accurate, and energy efficient, to place the sensor at a predefined location on the seafloor. The bulk weight component being the onboard stored energy for the payload sensor, facilitating a gravity force descending, but negatively affecting the ascending, having to be compensated by buoyancy material. Consequently an on-the-seafloor weight transfer operation was identified.

The overall objective were to develop a working prototype, defined as an autonomous cargo vessel for deployment of a subsea instrument on a predefined location on the seafloor, efficiently and accurately, based merely on gravity propulsion and a self-contained navigation package onboard. Subsequently the vehicle was to drop negative ballast and use the net positive buoyancy to return, upon receiving a wireless surface command.

One commercial scenario was to drop 5 or 9 units from a given surface location, and allow all but one glide to each side of the vessel, to individually predefined locations on the seafloor. The first unit would ideally just drop vertically from the vessel, possibly prior to dropping the remaining units, in order to establish a first on-site environmental measurement and communicate this back to surface. The units would then autonomously be organized in a sensor grid on the seafloor without the need for in-water mechanical or human intervention. A theoretical cost reduction for the deployment phase is in the order of 1:10, not including the same concept returning to the surface.

The AutoDrop-system is based on the following subsystems:

1) Hull shape – a hydro dynamically optimized vehicle exterior, incl. control surfaces
2) Landing-gear – enable a vertical adjustable support while on the seafloor
3) Variable buoyancy control and ballast – a cost efficient and environmental friendly ballast
4) Navigation system – navigation algorithms for vehicle navigation and sensor simulation
5) Sensor array – maximize the positioning accuracy while limiting energy consumption and cost
6) Control system – backbone the complete vehicle electronics, incl. CPU and driver electronics
7) Subsea actuator – dynamically activating the control surfaces, and operate other functions
8) Payload – provided to the project from the LE

Defining the hull size were initially a project obstacle, and it was agreed to consider a last generation node-volume as a starting point – 50 liter and an oval cylindrical shape or form-factor, i.e. 1,5-1,8 m long and Ø300-500mm in diameter. This was then used as design input, and all interfacing sub-assemblies constrained to fit within this envelope. Although this was used to start developing the navigation algorithm, the size and form-factor was continuously revised based on theoretical studies, computer analysis and test-results. Practicalities such as handling storage and operational constraints were to be compensated for, and features added.

To achieve the general objectives, the AutoDrop project has pursued the following three innovative specific scientific and technological objectives:

1. Design, test and improve a hydrodynamically optimized hull shape and size, capable of hosting a defined sensor payload, combined with features enabling a swift deployment from a surface vessel, damped landing with vertical inclination corrections and reliable recovery after guest sensor data acquisition is completed.
2. Develop a tailored navigation algorithm targeting a best possible final accurate upon landing, and use the same software to simulate a variety of sensors, and sensor combinations, in order to source and shortlist a cost efficient hardware assembly
3. Engineer a tailored control and power management system, which integrate the above mentioned sensors and navigation software, including specially developed actuator design and in water and in air communication links.

From the project description these detailed work-packages, and related deliveries, were defined:

WP-1 / Enhanced understanding of system properties
Objectives => to develop detailed specifications for the construction of AutoDrop*

WP-2 / Embedded control system
Objectives => Construct the onboard control system consisting of:
- Development of control system hardware interfaced with all sensors and actuators
- Development of firmware for the control system hardware gathering sensors data and controlling actuators
- Development of power management system including batteries

WP-3 / Embedded navigation software
Objectives =>
- Code the algorithms developed in Task 1.4 in the C-language
- Develop path estimator software
- These software modules are integrated with the control system and subsequently run in a laboratory test bench for functionality

WP-4 / Mechanical Design and construction
Objective => To develop a mechanical design and construction of the AutoDrop with optimal hydrodynamic and functional properties

WP-5 / System integration and validation
Objectives => Integrate the control system with the hull, and test positioning and navigation algorithms in a hydro lab. Perform environmental tests.

WP-6 / Validation
Objectives => Test the integrated system from WP5 in shallow and deep water

WP-7 / Demonstration
Objectives => Demonstrate the AutoDrop to receive feed-back from end users.

WP-8 / Innovation Related Activities and dissemination
Objectives => Formulate/compile project results into a protectable form, including patents and develop an Exploitation Strategy; a Consortium Agreement signed between the partners and protection of the Intellectual Property Rights arising from the development in the project.
Transfer specific knowledge from the RTD performers to the SME participants to enable them to rapidly apply the technology into specific products. Broadcast the benefits of the developed technology and knowledge beyond the consortium to potential end user communities.

WP-9 / Consortium Management
Objective => Conduct overall consortium management and coordination

Another challenge that appeared during the course of development were the need for a dedicated landing-system, and a variable buoyancy or ballast system. For the latter case a simple or traditional release of a concrete slab were initially outlined, but later redesigned with a ballast-tank system. This would allow a fixed hull-exterior, since the tanks were to fully integrated and only level of filling to be changed. Flexibility in the overall assembly is considered to be important.

Project Results:
Main S&T results/foregrounds

General outline

Initially a project definition phase was performed with contribution from all partners and relevant disciplines, identifying and prioritizing the boundary conditions wrt environment, sensor payload and operational constraints. The number one priorities were agreed in the consortium – ‘descending’, ‘landing’ and ‘buoyancy control’, whereas another eight 2nd and 3rd order priorities were defined, e.g. ‘planting of payload-sensor’ and ‘ascending’.

A relatively small vehicle was defined, cylindrical shaped with a small sensor-portfolio onboard.

Subsequently a hull definition and analysis was done, incl. design of control-surfaces, heavily influenced by the size and weight of payload-sensor, control strategy, capacity to glide lateral in a controlled matter and land safely. A dual paired rudder configuration with counteracting fixed wings were designed, but later replaced by a symmetrical control surfaces organized in a delta-configuration, facilitating a roll-control capability. These were actuator controlled individually, with a balanced attach angle 90-degrees to the center axis, i.e. in a braking fail-safe modus, (prior to landing and before surfacing). The control surfaces were also recessed slightly into hull and the edges chamfered to reduce potential tangling with floating debris, ropes or fishing nets.

The transferable ballast-weight was addressed early, combined with a cargo opening in the front and a fold-out landing-gear. Features for optimized payload sensor protection, seafloor contact point and rubber-type deformation zone was added to avoid accidental high impact and damage to the surroundings.

Considerable time was spent testing the hydrodynamics of the vehicle, incl. control surfaces, first in a semi-fixed configuration towed in a large tow-tank and later actively controlled by the actuator powered control-surfaces and processed inertial motion sensor data, and finally with closed-loop auto functions, in a flume tank. In the latter case a 1:1 prototype plug was deployed, with both the rudder-assembly assembled and a complete three-fold landing-gear, physically verifying max speed and brake speed, and the impact of folding out the landing-gear incrementally. The delta-shaped rudder-assembly worked well, so did the tailored IMU and the lab setup. The specially developed stepper-motor actuators started leaking immediately, and cased a major delay in the test period, but corrective action was made by the test-team allowing continuous testing and to verify a stable behavior whilst folding out the landing-gear. The legs could also be individually operated in order to correct verticality if landed on a sloped seafloor, referenced to the sensor verticality. A 3-part “cake”-split of the nose-cone were considered made of rubber, adding a deformation zone and possibly a better interface towards the seafloor. Simultaneously the feet open the “cargo-volume”, protecting the payload-sensor in flight and allowing it to be deployed vertically down in the soil when landed. A complementary vibration damping is foreseen between rubber-feet’s and the AutoDrop-unit, isolating it from the shear-wave measurement.

During this testing a ballast system based on tanks with entrapped salt-slurry were proposed, combined with a more detailed operational functionality definition, e.g. preferably design a fixed hull shape simplifying the control algorithm, tail floating out of the water upon returning to the surface to communicate with GPS and RF-radio and recessed landing-gear. A 70% 3D-printed prototype tank-setup was successfully tested. The tanks were later described to be an integrated part of the hull, allowing fail-safe release of the tank itself, should the salt-slurry dysfunction. The tank-concept also allowed for an appreciated flexibility in the design and manipulation of the placement relationship between the CoG and CoB, important for the glide-angle and on-seafloor stability. This cost efficient and environmentally friendly solution could preferably be used for other subsea applications.
In parallel to these hydrodynamic analysis, tank testing and feasibility studies on mechanical parts, a navigation algorithm was developed. The MATLAB-simulator emulated real sensor data, adding white noise to the data simulating and optimized algorithm and corresponding sensor-portfolio. A variety of sensor configurations is tested and evaluated, prior to finalizing the algorithm, building a c-code equivalent and prepare for running on the dedicated mother board and CPU.

During this later phase the landing-gear have been optimized and improved by detail engineering, and documentation prepared for serial production. A complete landing-gear is produced and tested, and future production facilities sourced.
In the final phases of the project a complete AutoDrop were to be designed, engineered and build. However these tasks have not been completed and only parts fully engineered. The importance of submerged weight figure and placement of CoG vs CoB is not realized by the RTD-partner, nor the importance of sealing of the electronics. An assisting consortium partner has offered to provide an existing pressure-vessel, but interface details is not yes defined, nor the pressure vessel interior design complete.

The leaking actuators have been redesigned, assisted by the other consortium partners, but none of the 7 actuators completely engineered, built or tested. The only component fully built by the responsible partner is the rudder-assembly, incl. driver and sensor boards, and possibly the associated driver-software. Hardware detail design is not finished, and fabrication practically not started.

Equally are subsea connectors and terminations, fabrication methods and materials proposed and sourced by assisting partners in order to assist partner lacking qualified resources.

The embedded control system is currently in a design phase, and no hardware presented to the consortium, e.g. Mother board, sensor integration and power management. Hence complete integration and test of the navigation algorithms not possible. The embedded control software is fractionally developed and not completed, demonstrated or delivered.

Final integration could not be done because of incomplete delivery of AutoDrop prototype, embedded electronics and control software. Subsequently the management planned demonstration in water offshore not completed.

Detailed description of HW and SW

1. Hull design, computational analysis, model testing

During the second reporting period of the AutoDrop project, the activities performed at the hydrodynamic test laboratory can mainly be summarized in the following list:

- Design and manufacturing of 1:1 scale model in nylon
- Lab testing: Identification of hydrodynamic coefficients using PMM (Planar Motion Mechanism) ,analysis of hydrodynamic forces during gliding, maneuvering and braking,
- Mathematical modeling of AutoDrop dynamic , optimization of Center Of Gravity (COG), Center Of Lift positioning for maneuvering stability.
- CAD modeling of the main body’s shape, for integration with rudders actuators designed by TI and legs designed by Labor.
- Mechanical Integration in the model of :
- Rudders actuation and control system designed by TI,
- Legs , with related actuation and control system designed by TI and Labor
- Inertia Motion Unit (IMU)
- Shallow water testing in the circulating channel in order to evaluate the stability of the AutoDrop and a first functionality test of the complete control system loop

1.1) Design and manufacturing of 1:1 scale model

- To perform experimental tests a 1:1 model has been built instead of the ¼ scaled one
- Using the 1:1 model a better accuracy in the mathematical model has been achieved, and it was also possible to test the mechanical devices and control system.

This model is nylon made: This leads to have a light weight object that can be easily modified (i.e. cut, drilled or screwed) also reducing production time. The mock up was designed in two main parts that can be assembled just screwing in each other.

1.2) Identification of hydrodynamic coefficients using PMM

The control system of the AutoDrop requires an accurate mathematical model based on the hydrodynamic coefficients. These quantities have been identified through two experimental maneuverability test sessions using the PMM in the towing tank.

The PMM is an automated system able to impose a repeatable motion law to the model under testing in order to measure, through a force transducer the hydrodynamic forces. The particular scale of the AutoDrop model, much smaller if compared to the typical dimensions of a submarine model usually tested didn’t allowed to use the standard force transducer and a custom setup has been developed . In particular a small 6 axis balance was designed, manufactured and calibrated.

List of activities:
- Design of the mechanical connections between the AUTODROP mock-up and the towing carriage’s PMM
- Design of the 6 DOF transducer;
- 6 DOF transducer manufacturing and assembly;
- Transducer’s calibration matrix characterization
- AUTODROP assembly and PMM mechanical connection setup
- Full system preliminary functional and operative tests
- PMM towing tests to evaluate the experimental setup efficiency and model’s drag. The model has been towed varying speed from 1m/s up to 3 m/s, and at angles of attack between -10° and 10°
- Data have been analyzed in order to obtain the drag hydrodynamic coefficients.
- PMM towing tests focused on AUTODROP’s behavior under different flow conditions: the model has been towed varying speed from 1m/s up to 4 m/s, and at angles of attack between -90° and 90° as summarized in the following table:
- The large amount of measurement data has been analyzed and a full set of model’s hydrodynamic coefficients was defined. The coefficients have been used to refine the mathematical model obtaining a first comparison with the theoretical one, where, the coefficients had been derived from literature. By means of the mathematical model a numerical AutoDrop simulator has been implemented and some simulations of operative AUTODROP’s trajectories have been carried out.

1.3) Mathematical Modeling of AutoDrop dynamics / Hydrodynamic forces

The results of experimental measurement (forces and moments versus speed and angles) carried out in two test sessions, have been processed and a dynamic mathematical model of the AutoDrop, including the hydrodynamic forces and the actuators (rudders) control forces has been defined.

The equations have been tested through different motion simulations in order to validate the model. These equations have been used also to model the stability of the AutoDrop versus the position of CoG (center of gravity). On outcome of this activity was the calculation of the admissible region for the location of COG that guarantees the motion stability in ascending, descending and braking phase, that is, the capability of the AutoDrop to rotate and stabilize its attitude starting from any possible initial condition (speed and angle).

2. Mechanical design

The initial mechanical system design specification was established in the Functional Requirements, and based these Top Level Mechanical Design was established.

The purpose of the Top Level Mechanical Design document was:
- Review the requirements from deliverable Functional Requirements and related documents
- Define the main problem statement and prioritized objectives for the mechanical system
- Define and prioritize the main tasks and subtasks of the mechanical system
- Define criteria for the mechanical elements

The work described herein is based on the principal and conceptual design solutions presented. The starting point of initial mechanical design specification was to create a function- and element tree based on the main goals for the mechanical system. The main functions were identified, and these were further divided into sub-functions, to help identify the mechanical elements that will perform the different functions. Alternative solutions are included, as well.

With respect to the function tree the mechanical design has created the following:
- Descend: Ballast system and rudders
- Approach/Reduced speed: Turning rudders 90-degrees
- Approach/Trajectory: Rudders
- Land/Vertically: Landing gear/legs
- Land/Horizontally: Abandoned as solution
- Deploy sensor: Sensor deployment system putting sensor in seabed. Pick up of sensor
- Take off: Ballast system buoyancy calculations
- Ascend: Same as descend

The results from the first reporting period are the principal total lay-out of the AutoDrop and the specifications of the system were formulated in the Functional Requirements document and in the Mechanical top level design. The conceptual physical lay-out idea of the AutoDrop is dependent on the choice of the principal solutions for the sub-functions and elements.

The placement of the elements corresponds to the main idea of a nose, mid and tail section with landing gear in the nose, ballast and electronics in the mid-section and rudders in the tail. Internal elements such as batteries, electronics and cabling may vary in position but is important for the balance of the AutoDrop.

The following criteria were agreed upon:
- The batteries have a significant weight/volume ratio, and can function as ballast. The weight of the batteries can be used to affect the center of gravity, and will most likely be positioned towards the front.
- The pressure vessel container (EPV) for the electronics can be placed inside the central cylinder of the AutoDrop.
- The landing gear should be integrated into the outer surface of the AutoDrop. It is expected that the landing gear elements will take some of the volume available for ballast and buoyancy material in the front and middle sections. This should not be significant, but the landing gear elements should be designed as slender as possible.

The next level of development divided the key features in separate packages:
- Rudder mechanism
- Landing system (Develop by Labor, but TI took the responsibility of integration)
- Buoyancy system
- Deployment system and payload
- Electronic pressure vessel (EPV)
- Others, e.g. cable harness, connectors and general optimization

2.1) The tail section development

The rudder mechanism

Purpose:
- Steer, break and balance the AutoDrop movements

The concept for the rudder mechanism was discussed in detail ended up with the following criteria:

Rigid criteria’s:
- For the requirements of the control surfaces
- The requirements for the mechanical actuation of the rudders:
Working sector is 20 degrees, +/-10 degrees about a zero degrees position on axial direction.
Braking position is 90 degrees from the 0 degrees position.
The rate of change of the angle of attack is minimum 0.5 deg/sec.
This is the requirement for the rotational speed of the actuation system output shaft.

Desired criteria’s:
- There should be a fail-to-safe system, so that the control surfaces are positioned in the brake position in the event of a power loss.
- The rudders should have an anti-snag design, to prevent snagging of fishing lines etc., for instance between the rudder and the AutoDrop body.

The principal solutions for the rudder mechanism are:
- Three rudders, oriented in a Delta-formation
- Symmetrical about the rudder shaft
- Individual stepper motors controlling each
- Software controlled movement

The rudder mechanism development

A considerable effort was made in developing the conceptual design into a working prototype. This process includes many new innovations and several steps and prototyping to reach a final successful solution.

Main developments:
- The main Y-shaped motor housing
- he motor housings lids and sealings
- The rudders shafts
- The fixation of the rudders to the shafts

The main features of the final rudder mechanism are:
- One single, simple Y shaped module contain all functions, including electronics
- Although the single prototype housing was expensive to machine housings for production purposes may be made much cheaper i.e. not machine but casted
- Oil filled housing to compensate for high pressure
- Well documented strength (FEM-analysis) of shafts, bearings and housing to withstand mechanical forces expected under normal use

Initial test results – lab testing

The rudder mechanism has been tested as a complete unit and fulfills the specifications. It moves with desired accuracy and the control system works as expected. The positioning in straight position works also as planned. The desired 90 degree positioning in case of power failure described in the previous deliverables has not been implemented. It seems rather unlikely that it is possible to foresee a power failure and turn the rudders 90 degree in case of such a problem. A mechanical solution to the problem is not possible with the gear solution selected. It is not possible to move the rudders without motor power. Turning the rudders mechanically e.g. with a spring is not possible as such a movement is prevented by the gears, and will if made by force damage them.

Strength Analysis of the AutoDrop Rudder Actuator, incl. Actuator Main Housing Analysis

The purpose to verify the following:
- Strength of main components including shafts
- Radial displacement of the harmonic drive interface of the shaft
- Bolted connections

The FEM analysis done on the rudder mechanism is presented in Appendix 1 to this deliverable.
The conclusion is that the final solution of the rudder mechanism complies with the specifications. The materials selected for the housing, the shafts and the rudder has the desired strength. The harmonic drive has the sufficient strength to withstand the pressure on it caused by radial displacement forces on the shafts. The shafts in themself are sufficiently dimensioned to take the foreseen forces. Bolts and fixations have the strength needed.

2.2) The front section development

Landing system

Purpose:
- Make the AutoDrop stand in an upright position on the seabed
- Open, subsequently close, the sensor cargo volume
- Stabilize and dampen the impact while landing
- Help reduce landing-speed
- Optimize contact with the seafloor wrt grip and distributed support

Originally the landing system was not part of the AutoDrop design but was taken in after extensive discussions at kick off. It has complicated the whole AutoDrop unit, and also added considerably extra work to the project. It was argued that this could have an impact on the total resources available for other work. But it was a strong wish from the coordinator, to get this future working on the AutoDrop unit, right from the beginning. It was agreed to look into the possibilities, to see if it was feasible to get the job done with available resources. During the project the RTD developed three versions of landing gear on a very high level. This has led to a long development process using a lot of resources.

It was decided to use stepper motors. They are rugged and get their momentum at low speed, so normally they can be use them without a gear system. For use to drive the leg screws direct drive is a preferred alternative.

Requirements; leg actuator:
- The motor should be strong enough to drive the legs i.e. turning the screw (0,7 Nm)
- The actuator should have a water tight housing
- The motors should be run by the electronic control system
- The screws moving the legs should run dry i.e. without any oil or grease
- The legs should be extremely light weighted

Main developments:
- Motor with specified torque implemented
- Torques tested in specific test bench
- Housing designed
- Flexible solution/connection based on the Oldham principle between screw and motor
- A 100% leak proof solution

Results

The solution works and is tested in a test bench. However modifications to the design should be considered post project i.e. a support crib for the slider of the screws.

Problems encountered
- The material in the screws and the slider stick to each other and the motor are not capable of driving the screw
- The screw that is almost 50cm long flexes when there are put pressure on the legs. The flexing hinders the movement of the slider.
- The end fixation point of the screw is not on the motor side causing the screw to move in/out some millimeters in the housing. As room was limited it has been hard to compensate for this movement that caused problems for the sealing of the screw.
- The flexing of the screw makes it difficult to keep the sealing 100% water tight as it will not rotate in a fully circular movement
- Leaks during tests

A modified design and final Results

After the conclusions from the test, a new version of the complete actuator assembly were designed. The motors were found to be satisfactory as is, and was consequently not changed. The main layout of the actuator, and its mounting to the rest of the AutoDrop assembly was also kept.

This was changed:
- housing,
- bearing,
- sealing,
- screw,
- base
- coupling
- connector

The motor housing design was modified from a two pieces design (designed this way to save cost but with increased risk of leaks), to one piece made in aluminum. The housing was fixed to the actuator boss with tree screws from the side. Sealing is by two O-rings for extra security. The sealing and stepper motor is redesigned to allow for new sealing equal to the one used in the rudder gear box put in the front of the engine. A new flexible connection was implemented based on the Oldham principle. This principle allows for a lot of flex. It prevents the screw from flexing in the sealing. The new construction allows for a safely wide contact surface against the seal preventing leaks if the screw moves in and out of the actuator. Axial or angular movement on the screw will not interfere with the contact surface and the seal. The Oldham coupling acts as an end cap on the treaded rod. It is secured by a couple of set screws, so it can be dissembled. And the axel with the Oldham part can slide out of the bearing, with part attached. A new adapter for the oil filled hose and cabling has been implemented. These modifications solved most of the problems encountered in earlier test and the final result is now that the work performed has solved the problems and delivered a good solution. However the flexing screws are still an issue.

2.3) The deployment system and payload

Purpose: Place and retract the seismic sensor from the seabed (or other payloads to be used with the AutoDrop)

Requirements:
- Plant the payload i.e. the seismic sensor in the seabed
- Plant the sensor in an upright position (requires the AutoDrop legs to adjust)
- Plant with enough force (which is a function of the AutoDrop weight)
- Detach the sensor from the AutoDrop (except from flexible cable) so measurements can be done with a free sensor
- Grab the sensor with some tolerance as the AutoDrop and sensor may not be 100% aligned
- Lift the sensor with enough force

The actuator should have enough force to press the payload spikes in to the seabed. The force is limited to the weight of the AutoDrop, i.e. too much force will lift the AutoDrop from the ground. Most seedbeds to be investigated by AutoDrop are soft and a force of 16 kg should be sufficient. This is the weight of the AutoDrop in water. The payload is connected to the AutoDrop when in use, by a highly flexible cable, but otherwise it must be mechanically disconnected. The reason for this is that mechanical vibrations that may be generated from the standing and parked AutoDrop unit shall not be transferred to the sensor as this may interfere with the seismic measurements done by the sensor unit. The actuator must be able to recover the payload, when the AutoDrop unit is to be returned to the surface. This requires a certain force, depending on seabed conditions. We have calculated to get a total of 600N lifting force from the actuator. This we expect to be more than sufficient, but it needs to be verified by real tests. The actuator is used to pick up the payload/sensor. The gripper must be tolerant to misalignment related to the payload as the sensor or the AutoDrop may move during operations. It is therefore constructed with conical mechanism that makes it possible to grab the sensor even if a misalignment has occurred. The actuator with gripper should not be using energy in home position. As the AutoDrop unit may be on the seabed for some time. Therefore the gripper is made so it uses only energy when the gripper is unlocked. That is a few seconds at the time.

Main developments are a complete unit anchored to the front ring nose of the AutoDrop including:
- Actuator motor driving a gear box with three outlets
- Outlets rotating three treaded rods in parallel
- A gripper moved by the rods
- A conical gripper that can grab the sensor even if sensor and AutoDrop is not aligned
- A gripper solution that can hold and release the gripper
- A gripper holding mechanism that only needs power when opened and not for holding
- Actuator assembly for deployment of the sensor

The actuator is anchored to the front ring in the nose of the AutoDrop unit, and connected to the EPV by one cable with a connector in the end. When the rubber feet's for the legs is moved away, the payload and actuator unit can easily be removed, or replaced by another unit.

The stepper motor used is the same type as used for driving the legs and it will be covered by oil filled housing like the one used for the legs. The rotating rods are fully exposed. But they have smooth surface, and the nuts is made of plastic, so the assembly will not be sensitive to contamination of sand or other seabed materials. Further protection is possible by attaching seals on both sides of the nuts. This should not be needed for the prototype.

The gear mechanism will move the sensor slowly as a slow movement is desired both for planting the sensor carefully and for being able to use a small motor. Simple and rough plastic gears are used in an open construction that can easily be cleaned and flushed with water after use, and before storage, to avoid malfunction and dour. This gear unit is made as light and cost effective as possible.
The rods are calculated to push/pull at a force of 200N each, a total of 600N, with the actual stepper motor and gears. The solution has a linear movement of 230mm for the gripper. The rods are fixed to regular ball bearing using e-clamps. Then the ball bearing is pressed in to a recess in the front plastic ring, for so to be locked in to place by an aluminum plate. The gripper works a bit like an air hose coupling, with magnetic release. The locking piston is moved by a magnet, and is only powered when open, and is meant to be using minimal force/energy.

Late in the process it came clear the buoyancy was a critical issue. All possible solution were therefor tried to reduce weight and save space (i.e. give more room for buoyancy material). The final version of the deployment/payload system that should be as light/small as possible is based on a design made in cooperation between partners. The sensor provider made a considerable effort to make a lighter and space saving design to fulfill the buoyancy requirements. The linear movement of the gripper was shortened to save space. More space meant more buoyancy materials.
A minor update is needed on the payload to make the stem on the gripper ball a bit longer. An outer skin for protection may also be added to smooth surfaces. An outer skin may also help guiding the payload on the way out or in.

An advanced and complicated oil filled piping system is design between the payload and the EPV and internally in the payload. The internal pipe is an angled pipe with an outlet. This pipe is the connection between the two cable coils, and also has an outlet to the gripper to provide power to the magnet. The pipe is to be made of none corrosive steel parts, that is soldered together in a jig.
The current TI/Fugro design is a compromise between weight/space and function. The changes that had to be made to the payload may influence its function in a negative way as the linear movement had to be reduced.

2.4) The mid-section development / the ballast system

To adjust the weight of the AutoDrop to obtain the required buoyancy for the descent and ascent, typically achieved by either carrying a drop weight, or by having internal ballast tanks.

Initial requirement were to obtain a descent velocity of 5 m/s, a negative buoyancy of 250 N is required. To obtain an ascent velocity of 3 m/s, a positive buoyancy force of 100 N is required. The total shift in buoyancy between descent and ascent is then 350 N, which is equivalent to 35 kg ballast. There is a critical window with regards to time during the emptying of ballast. Once the first 250 N of ballast are released, the AD should be neutral, and start ascending when further ballast is released. Until minimum stable flight speed of 1 m/s is reached, the AD will ascend without control. A speed of 1 m/s requires around 30 N of additional buoyancy, which is a release of 3 kg of ballast once the AD is neutral. The release of these 3 kg’s should be performed before the AD has ascended 50 meters.

Optionally the release of the ballast should move the center of gravity from a position where the AD is oriented nose down to a position where the AD is oriented with the nose up.

Two principal solutions have been identified and are presented below:

1) High concentration saltwater ballast in tank
Ballast tanks are filled with a high concentration salt water solution, which can have a density as high as 1.8 to 1.9 kg per liter. To release ballast, ports or hatches in the ballast tanks are opened, allowing the ballast fluid to mix with the surrounding seawater. This is a very eco-friendly ballast solution, but the risk of leakage over time while at sea bottom, which can cause the vessel to surface too early, must be further explored and assessed.

2) High density solid ballast
An eco-friendly concrete drop weight can be integrated into the nose section. This ballast is to be released and left behind, and should degrade in a relatively short time, but not so fast that it affects the buoyancy while the AD is parked on the seabed.

It was recommended to investigate the salt solution ballast concept, as this concept had several advantages if it could be implemented. The main advantages of this concept were eco-friendliness, inexpensive ballast material and simple ballast integration.

Specifications for the ballast tanks
- Salt mix with specific density of 1.8
- Ballast weight in water of 25kg = 31.25 liter salt mix
- Ballast divided in three compartments
- The ballast tanks is closely related to the buoyancy balance points

Investigation into ballast options

The ballast solution was one of the critical elements in the development of the AutoDrop prototype. The original idea was to have deployable ballast in form of concrete, but the solution of the salt slush came up during the first months of the project as an alternative not mentioned in the original DoW.

The believed advantages of salt were:
- Salt would not need any mechanical action to be expelled/discarded from the AutoDrop because it would itself be dissolved in a while simply opening windows in the hull and letting the water come in when the system has to be retrieved; this would allow an entire section of the hull to be completely filled with salt, allowing during design phase an easy tuning of the buoyancy change by optimizing the length of the section;
- Salt is the most friendly material for the sea environment, being part of seawater composition;
- As common salt could be used, the dead weight would result pretty cheap and easy to obtain.

Main developments and achievements:
- Three ballast tanks designed as part of the Autodrop body
- Size and shape to conform both to body shape, body structure and room for the needed amount of salt
- Motors screws and thrusters to open gates and drive out the salt slush

Further experiments showed that a passive drop of the salt was too slow and not reliable. The screw/thruster solution to drive out the salt was therefore developed. Solutions with salt tanks that could snap off if problems with getting the salt out was also investigated but not designed above concept level as it would complicate the construction and its costs.

The salt tank solution is a much more advanced solution than the original weight drop solution. The effort to reach a workable solution has therefore been high both because of the tests needed and the refinements of the solution. It has also been much more complicated than originally expected because it was decided that motors, screws and thrusters had to be added. Further complications was made as the motors are placed outside the salt tanks and therefore needed to be integrated in the AutoDrop body. The salt thanks size, placement and shape have been designed as optimal as possible. However as the buoyancy and center of gravity has been critical to the whole AutoDrop the ballast tanks has been difficult to 100% finish. What further has complicated this process is that enough buoyancy has been hard to achieve with the given shape and size of the AutoDrop. Increasing buoyancy by increasing the salt tank volume is a trade off with weakening the structure of the whole AutoDrop construction. In the final AutoDrop version it is the floating elements that also are the carrying structure of the whole system. There is no back bone or central tube as in the first concepts.

The first principal test was performed at TI, with a simple container containing a 1.8 kg/liter salt slush. Basically the test was performed to observe the behavior of the salt slush.
A full scale test more accurate and closer to application was performed with three salt tanks designed and printed in rapid prototyping. The test was performed at TI in a small water tank. The purpose was to evaluate the principal and evaluate the time taken to empty the slush from the tanks. The tests were performed with and without an internal screw to investigate the effect of such a solution
The results show as expected that the salt poured out of the tanks and that the tanks with the buoyancy material attached between them rose to the surface slowly as salt was emptied from the tanks. The time to empty the tanks and the movement of the tanks seem to be in line with desired behavior of the AutoDrop. A screw improved the disposal of the salt.

The stepper motor controls the emptying process. The valves are open approximately 70% of the time when the shaft is rotating. Thrusters are mounted on the shaft to decrease the time of emptying the ballast salt mix. The purpose of changing the design was moving the stepper motor out of the tank. This would simplify the design and add more volume to the tank.
The final ballast system has few changes from the second version developed. The main changes are the integration/connection to the AutoDrop body with screw holes along the side. The addition of strengthening pillars inside combined with a small wall thickness reduction. Finally the housing around the stepper motor was improved in and is now the same as for the leg stepper engines solution.

The actuator has single stack stepper motors of the same type as is in use elsewhere in the AutoDrop. The same stepper driver is used attaching it to the rear of the motor. The motor is protected in the same way as the leg actuators, with the same axel seal used as in the rudder actuator. Also this actuator has a gear reduction, before the output shaft, with a "claw" coupling. The coupling is the connection between the actuator, and the rotating valves, in the ends of the salt slush tanks. The couplings is robust made with high angular tolerance, so it is uncomplicated to remove the tanks, and put them back again if needed e.g for cleaning or inside work of the AutoDrop unit.

For prototype production it is planned to use rapid prototyping for the body parts of the salt tanks. It is a simple solution for prototyping and eliminates high cost. The valve has two parts with advance properties; The tribological properties are especially good concerning low friction for a smooth rotation (POM against aluminum). The POM part has two functions; one to keep the valve closed and secondly it uses a "scoop out blade" to move the salt. The overall ballast system has minimized amount of part without compromising function and assembling.

2.5) Electronic pressure vessel (EPV)

Purpose: Housing for the electronics and batteries and the only part of the construction that can withstand high pressure in itself

Requirements:
- Enough space to hold batteries and electronics
- Withstand pressure down to 500 meters depth
- As light and small as possible
- Water tight standard connections for large depths

Originally the EPV was a standard component to be delivered by a SMEo. The EPV should then be used as is without any modifications. Due to the problems with buoyancy and space needed for buoyancy material some modifications to a standard solution had to be made. This included also placements of connectors. Main developments: A modified EPV made by partner.

The EPV (electronics pressure vessel) is made from an aluminum pipe, with the front end plugged and welded. The back end has a standard lid solution with two O-rings. The EPV have connectors at both ends.

3. Embedded control system

Objective => Construct the onboard control system consisting of:
- Development of control system hardware interfaced with all sensors and actuators
- Development of firmware for the control system hardware gathering sensors data and controlling actuators
- Development of power management system including batteries.
Based on the specifications made earlier - “Specification of onboard control system and instruments”, a complete control and power management has been developed.

The control system has been sectionalized in three control boards (PCBs). One control board located in the 1-atm pressure vessel (main control board) and the other two boards located in the oil filled and pressurized tail section (rudder control and rudder sensor board).The power management control is a part on the main control board.

3.1) MAIN CONTROL BOARD

General description and purpose

The AutoDrop main-board is a re-design of a development-kit from EMBEST (SBC-6300X). This kit is built of the commercially available processor module: Mini6300, and a versatile base board with a wide brand of IO capabilities. In this project we have made a custom variant of the base board.

The AutoDrop main-board is equipped with 8 serial ports (RS485, RS232 and RS232/TTL, used for communication towards the external units:

- One high speed Ethernet interface for debugging purposes
- The interfaces to the salt actuators (release of ballast), sensor deployment actuator and the actuators for controlling the landing gears, are all controlled via the same RS485-bus
- The interface to the rudder control and sensor unit consists of 2 RS485 lines without flow control
- One is used for controlling the rudders
- One for monitoring the rudder position
- The main interface to the IMU is a RS232 with TTL levels without handshake. The PPS and Trig signals from the IMU are connected and can be used for synchronization purposes. The IMU has a RS232 debug interface and a BSL-signal (Boot strap loader), connected to an external connection plug. The pressure sensor is connected to the IMU via RS485. The IMU processes the pressure data and includes samples as an extension to the protocol.
- The Acoustic modem is connected through RS232 without handshake. An additional signal to this modem, S_LP, is used for “super low power mode”.
- Communication towards the RF-modem is UART, 3.3V with HW handshake.
- The interface to the payload electronics is a RS232 line without handshake.

Furthermore the AutoDrop main board contains:
- Connector for SD-card (flash memory) for logging and other storage.
- Relays for power control of other devices
- Line drivers for serial lines
- Connectors for other power control
- Low power processor for monitoring activity when main processor is turned off:
- AT-Tiny
- Real-Time clock
- Watch-dog
- Power control

3.2) Processor module (Mini6300)

The processing unit (μC) is the central component in the AutoDrop unit.

The Mini6300 board consists of:
- Atmel AT91SAM9263 (ARM926EJ-S core with MMU)
- 64 Mbytes SDRAM
- 128 Mbytes Nand Flash
- Kbit EEPROM

The navigation algorithm, the actuator control, sensor data acquisition as well as the topside/ external communication SW will all be processed by this μC. The navigation algorithm obtains its input data from the IMU instruments and the pressure sensor. The output from the algorithm is a desired angle to the rudders. Dedicated position controllers for each rudder ensure that the rudder moves to the desired angle set by the navigation algorithm. When the AutoDrop approaches the sea bed the landing gears will be activated. The landing gears will also be controlled by position controllers in the same way as the rudders. On the sea-bed, the deployment of the sensor will also be handled by a position controlled actuator commended by the μC. The AutoDrop unit may now also communicate status information, via the acoustic communication line, to the topside unit (service vessel). When the AutoDrop receives command form the top-side unit, or after a pre-defined time to ascend, the ballast will be released by the ballast actuator and the AutoDrop will then return to the surface. At the surface, the AutoDrop will broadcast its GPS position via the RF modem.

Early in the project there were discussions in the consortium, concluding that the selected Atmel processor is sufficient for processing of the navigation algorithms.

3.3) IMU interface

An SME partner has provided the project with an advanced IMU.

The IMU supports the navigation and estimation algorithms in with several instruments:

- Magnetometer (compass)
- Accelerometer
- Gyroscope
- GPS – available when antenna is above sea surface
- Precise pressure measurement from external pressure sensor (Keller)

The IMU itself is a complex computer collecting and communicating the necessary data to the AutoDrop Mainboard. The main IMU interface is a RS232 TTL level port running at high speed, and collecting a data message every sample (e.g. every 10 milliseconds)

The IMU is connected to the Mainboard with an additional interface: PPS and trigger lines. These signals are not used in the current prototype.

3.4) Actuator interface

The AutoDrop has in total 10 actuators; 3 rudders, 3 landing gears, 3 salt actuators and one for sensor deployment. All the actuators, except the rudders, have been equipped with identical driver boards (Trinamic TWCW series).

The electrical interface to the motor driver boards is:
- supply voltage (24Vdc) and
- a 2-wire RS485 bus.

Each motor driver board, connected to the RS-485 bus, can be pre-programmed with a unique address. This means that several actuators can be controlled through the same bus. The salt actuators and the sensor deployment actuator are connected together first RS485-bus and the salt actuators are connected to the second RS-485 bus. It would have been electrical possible to connect all the actuators to one RS-485 (256 unique addresses are possible), but because of practical reasons, wire splicing and termination, it was decided to implement two independent buses.

3.5) Rudder interfaces

The rudder interface on the main-board is a RS485 bus driven by isolated line drivers.

3.6) Front bus interface

The “Front bus” is a common RS-485 addressable bus for all the devices in the front of AutoDrop. The selection of the different devices is done in software.

This interface controls:
- Landing gear motors
- Buoyancy actuators
- Payload actuator(s)

3.7) Landing gear

The landing gear consists of three legs with one stepper motor with integrated controller each.

3.8) Buoyancy Actuators

The buoyant/salt tanks system is designed with three tanks with one stepper motor and an integrated controller each.

3.9) Modem interface

In order to communicate with the top-side unit, on-board the service vessel, the AutoDrop will be equipped with an acoustic modem. The acoustic communication line will be used for transferring status information. It will also be deployed to enable remote controlled surfacing of the AutoDrop unit by commanding it to release the ballast.

The operating distance of the acoustic modem has to be more than 700 meters, since the maximum depth is set to 500m and the horizontal positions between the service vessel and the target point can also differ by a few hundred meters. The baud rate is not critical, only small amounts of data/commands will be transferred, preferably more than 1kbps.

3.10) Radio Modem
While the AutoDrop unit is surfacing it is capable of broadcasting its own position, determined by a GPS receiver, in order to facilitate the pick up by the service vessel. The GPS receiver is built into the IMU and a dedicated antenna cable is connected through the pressure chamber to the GPS antenna at the tail of the AutoDrop.

A Radio modem is connected in the same manner, with radio antenna in the tail of AutoDrop. The main computer will start transmitting discovery messages as soon as the AutoDrop is back in surface position. The frequency used for this communication is in the “free” band for data traffic according to EU regulations. The AMB 8355 Radio module uses the 868 MHz band for data communication.

3.11) Pressure sensor interface

The pressure sensor will be responsible for measuring the current sea depth. The accuracy of the depth measurement has to be within a few meters and a resolution in the decimeter range in order to provide the navigation algorithm with sufficient data. The sensor that has been selected is the PA-33X from Kelle

Basic sensor data:
- Accuracy (10...40 °C) 0,05 % FS (RS485)
- Accuracy (-10...80 °C) 0,1 % FS (RS485)
- Resolution 0,01 %FS

Permitted external case pressure up to 400 bar. The pressure signal compensation uses a mathematical model based on polynomial approximation, which provides almost perfect compensation over the operating temperature range. The output signal is updated every 10 milliseconds. The pressure sensor is connected to the IMU and a special version of the IMU has been made by IMAR to incorporate the depth measurement.

For the cabling between salt actuators and cabling between Landing gear actuators and Deployment Actuator, the wires will be guided in pressure balanced oil filled hoses. The hoses will be terminated by nipples on each actuator housing. The required clearance of the pressure vessel end-cap (for wiring), is estimated to 2-3 cm.

3.12) Power management

The supply distribution to the AutoDrop units has been implemented in accordance with Figure 3. In “normal mode”, AutoDrop is powered from the on-board battery source (Batt. 24V). In “debug/test
mode”, to avoid emptying the battery during testing/debugging it is powered from an external power
source via the external interface plug. In the event of a “valid” voltage level is present on the external
power supply line, the “source selector” automatically disconnects the battery and switches over to the external power source. The AutoDrop main-board is permanently supplied via the source selector. The main-board has the overall control of supply distribution to the other units. In order to save power, in particular during the sensing period at sea-bed, units that are not used will be completely switched off by the main-board.

3.13) Power Estimation

In order to estimate the required size of the battery pack and also the power consumption needed during different operating modes, a detailed estimation on the AutoDrop’ s energy consumption have been carried out. Table 2 lists the power consumption for each consumer in the AutoDrop unit. This list is used to calculate the detailed energy demand calculated.

3.14) Batteries

For the prototype, a special made alkaline battery has been selected. It is built of industrial quality high power alkaline cells, to make up a 24V high capacity battery suitable for test drop. The final product will have a rechargeable battery, and circuitry to ensure battery health while connected to vessel power system.

3.15) Rudder sensor board

The purpose of implementing a rudder sensor board was to monitor the actual angle position of the rudder shafts. The rudders are controlled by stepper motors, this means that there is actually not a need for a govern loop, involving angular positioning sensor element, to set/control the angle of the rudder shaft. A stepper motor converts pulses into shaft rotations and the rotations are directly related to the number of pulses as long as the maximum holding torque not is overridden. If the torque is overridden the motor will slip and the angular position of the shaft will be lost.
In AutoDrop, the torque acting on the rudder shafts is strongly dependent on the velocity of the AutoDrop and the rudder attack angle. The maximum holding torque of the stepper motors can accidentally be overridden especially during testing and optimization of the AutoDrop’s navigation and control system. By continuously monitor the angle of each rudder shaft by an independent sensing system, an accidentally override in torque can be discovered and counter actions can be taken.

Measuring Principle

The rudder shaft angles are measured through a highly sophisticated and accurate magnetically based sensor system. On each rudder shaft a magnetic ring has been attached. The magnetic ring consists of magnetic pole pairs, with a length of 2 mm, evenly distributed around the ring. Each pole pair corresponds to a shaft angle of 5.625 degree. By using the sensor chip, NSE-5310 from Austria Micro Systems, with integrated hall elements for measuring rotary motion on multi-pole magnetic rings, an incremental resolution of 1.92 μm or 0.052° has been possible to achieve.

NSE-5310

The NSE-5310 is an incremental position sensor with on-chip encoding for direct digital output. A Hall
element array on the chip is used to derive the incremental position of an external magnetic ring/strip placed above the IC at a distance of typically 0.3 mm. This sensor array detects the ends of the magnetic ring/strip to provide a zero reference point. The integration of Hall-effect position sensors, analog front end and digital signal processing on a single IC chip provides an ingeniously small position sensor, without the need for external pulse counters. Direct digital output is accessible over the serial interface using I²C protocol*.

Implementation

The microcontroller, ATMEGA-168, has been implemented on the rudder sensor board to collect data over the I²C- bus from all the three rudder shaft sensors (NSE-5310). The sensors are accessed by predefined addresses. The A0-pin on the NSE-5310 chip is used for address configuration. Through this pin two different addresses can be selected. Since three NSE-5310 sensors are used on the same bus, a SW controlled switch (DG2743) is used to switch in and out the sensors with the same address configuration. The microcontroller reads and processes the sensor data sequentially. The angle (position) of each rudder shaft is calculated by combining the count of magnets segments passing and the measured inter-magnet position, by analyzing the magnetic field outputted by the sensor as illustrated in Figure 8 NSE-5310 output data. The calculated rudder shaft angles are then buffered and transferred over serial interface to the main board. The rudder shaft angles are outputted every 3 milliseconds.

On the sensor board there is two RS-485serial bus drivers implemented. One is used to convert the RS-485 control signal levels to TTL-logic levels between the main board and the stepper motor driver board, TCM-341. The other bus driver is used by the sensor board for converting the TTL-logic levels on the serial output interface connected to the RS-485 interface on main board.

The sensor board also contains a capacitor-bank, used for the 24Vdc power supply to the steeper motor board TCM-341. Tantalum capacitors have been chosen in order to handle the pressurization.

3.16) Rudder control board

The rudder control board is a triple axis stepper motor controller module, TMCM-343. It is controlled via a serial RS-485 interface connected to the main controller board located in the 1-atm pressure vessel.

4. Embedded navigation software

During this task an aided inertial navigation system (INS) is designed for AutoDrop. Various sensors such as IMU, pressure sensor and magnetometer are integrated in the aided INS. However because of the drifts in gyro and accelerometer at a low rate, the low frequency content of the IMU output is poor and the position errors grow slowly with time. In order to compensate this low frequency error, some external source of data, such as GPS position, Doppler velocity and acoustic signal would be considered to aid the typical INS and bound the position error.

These navigation aids provide good data in low frequency while degraded by high frequency noise. The combination of the typical INS and the external data sources often provides an efficient navigation. However because the sensors such as acoustic range sensor and Doppler velocity log (DVL) are not available for AutoDrop, a virtual velocity meter (VVM) based on the dynamics of AutoDrop is implemented in software to output AutoDrop velocity.

To glide to the predefined target position on the seabed, a cascade PI controller is designed to control the AutoDrop to follow a reference path to the target position. Later the aided inertial navigation system and the controller are introduced with a brief description of the AutoDrop model which is also used in VVM.

The navigation method, simulation model and findings is described in a separate paper to be released shortly – Hold!

5. Embedded control system software

The AutoDrop project main objective is to construct a prototype of an autonomous vehicle capable of bringing equipment from the sea surface to the pre-set position on the seabed without propulsion. The AutoDrop will navigate using on-board instruments and move vertically due to its initial negative buoyancy. When properly placed on the seabed it will place the payload instrument on the bottom. After finished bottom time, or by external signal it shall be able to shift its buoyancy to positive by means of dropping weight, and consequently return to the sea surface where it will transmit radio messages suitable for tracking its position.

The embedded control system is in charge of controlling all activities and states, and controlling all actuators and sensors. Furthermore it will support the communication with external units both in surface and submersed position. The path-planner, estimator and navigation algorithms are all contained in a separate delivery from Aalborg University, even though they run on the embedded control system. Support for these algorithms is covered by this deliverable.

The embedded system designed for control of the AutoDrop unit consists of an Atmel ARM processor (AT91SAM9263) running Linux operating system. By using a module board with this processor, early software development was supported by a development kit from EMBEST. The final main processor board is an optimized subset of the development kit with some additional electronics. The processor module is identical, and is piggybacked on the processor board, as on the development kit.

The final system will embed one low-power processor capable of processing the minimum features required to detect the return condition and control the power of the main-processor board. Power distribution to some external electronic modules will be distributed by the main processor system, e.g. rudder control electronics, detectors and landing leg control. The main processor is installed in the atmospheric pressure enclosure of the unit.

A separate Rudder sensor board has been made for rudder sensor interface and calculation. This board is placed in the oil filled rudder house, and is exposed to the pressure surrounding the AutoDrop.

Communications throughout the system is based on RS-485, TTL level RS-232 or V.24 level serial communications.

5.1) Objectives

The Deliverable Functional Requirements specifies the priorities of the AutoDrop project. This lists what to prioritize in case the frames of the project does not allow for full implementation of the wanted AutoDrop product. The Functional Requirements document states that: “some of [the requirements] are relatively ambiguous within the timeframe of this project” – and this justifies the priority measures. However the “Functional requirements” states: “The life stages - descending, landing and buoyancy control - are regarded as the most challenging and important stages and will be prioritized in this project. The ability for AutoDrop to land on the seabed without destroying a possible subsea structure, or itself, is regarded by the consortium as the first priority of this project.”

First priority SW related requirements:
- Two-way RF-communication. Up to 5 km
- Two-way acoustic communication. Up to 2 km
- Possible to log sensor, actuator, control signals etc. into non-volatile memory (flash/EEprom)
- Contain an IMU, compass etc
- Measure barometric pressure
- Release system for drop-weight, trigged by time or by communication with vessel

Second priority items included:
- Battery duration: 60 days (15 days)
- High speed communication line (Ethernet in order to read out logging data)

Specifically there is one requirement listed as priority (1) for the product but (3) for the prototype:
- Electrical connection between AutoDrop and (seismic)sensor

This has been designed into the electronics, but there is no software or protocol developed for this. For the RF communication there is implemented a simple protocol and a service to broadcast the GPS position in surface position. The RF link is furthermore used in the prototype to initialize the navigation system with the unit position and orientation. For the final system, we foresee that this message will contain all possible vectors measured externally by launching equipment, but as long as this has not been specified, the message will be as simple as a “ping”, signaling that the unit is forced into a vertical position with “zero” velocity and rotated to “zero” rotation.

By receiving this signal the Navigation system will set its reference values and measure the position from the GPS instrument. The seabed position will be communicated separately as a relative position from this known point.

For the Acoustic modem there is a simple mechanism for action upon messages from surface vessel to start the ascending, but no protocol for this is discussed or implemented. The acoustic system consists of one onboard modem and a separate surface unit with extended functionality. The surface unit is not addressed in the project.

5.2) Hardware platform

Calculation on computational needs was performed in the project leading to the selection of the AT91SAM9263. This processor is available in a suitable development kit with a high number of IO ports, suitable for the needs of the AutoDrop Embedded Controller system

5.3) SW design specification

The main goal of the Embedded Control system software prototype is to show its capability to perform the necessary calculations, sensor measurement and actuator control together with the path planning and navigation to bring the AutoDrop from its drop point to the predefined target on the seabed in a safe way. Furthermore, the Embedded Control System software prototype shall prove a capability to initiate the return of the AutoDrop after predefined conditions.

In details, the software shall be able to communicate with:
- Radio modem (external units)
- Inertial Measurement Unit
- Acoustic modem
- Payload

Furthermore the software shall be able to control:
- three rudders
- three legs
- buoyancy control
- payload positioning
The payload software shall also be in charge of effective power control of the other units, to be able to control energy consumption to support long battery life and consequently a sufficient mission period for the device.

5.4) AutoDrop State machine

The AutoDrop SW is driven by a State-machine to change between the different modes of operation during its initialization and mission.

When started from power-up, the AutoDrop will investigate a persistent file to see if it is initialized with mission data. This file will contain information about the mission progress, and shows if it expects to be at seafloor position. As described in the chapter “AT Tiny processor” on page 12, the power on at seafloor level may be caused by either a signal from acoustic modem, or a predefined timeout. If the AutoDrop system does not detect a condition to start the payload retraction and ascend to the surface, it will go to sleep again by asking the AT Tiny to shut of its power for a new period. Possible conditions to return to the surface include acoustic message, predefined max bottom time or detection of low battery power level.

5.5) AutoDrop main processor SW

AutoDrop Main SW is built by giving a single “make”command in the mainboard catalog of the code tree. The code will then be generated in two separate catalogs and shall be placed in corresponding catalogs in the target file system: ./mainboard/binarm –> /home/autodrop

The /home/autodrop/ folder contain the executables necessary to run the complete system together with all relevant configuration info and mission data. The /home/Autodrop/lib folder contains libraries for iniparser and other libraries mainly for the navigation SW. The cgiarm-files are support executables for the debug and management provided by the Autodrop internal web server.
The webserver also needs some static files to be placed in /opt/apache/www, being static means that they are not generated by the makefile: ./mainboard/www -> /opt/apache/www

5.6) Navigation, Estimation and Path planner

The navigation build process will compile the C code. The API providing the necessary interface to the AutoDrop system and sensor data is linked in to this system. The makefile for this part is in the nav catalog of the code tree.

5.7) Main processor board - Evaluation kit, EMBEST SBC6300X

NOTE: There is an error regarding port numbering in the SBC6300 Hardware Manual: COM1 is supporting the RS485 connectors at J26, not COM2. COM1 has no drivers for RS232 mounted, and the edge DB9 connector is not working.

Key characteristics:
- Processor: AT91SAM9263
- 64 MB SDRAM
- 128 MB NandFlash
- RTC: DS3231SN
- Uarts: Debug: RS232/TTL 3 line / COM0: RS232/TTL 5 line / COM1: TTL 5 line - semiduplex RS485(isolated) 3 line (@ J26) / COM2: RS232/TTL / COM3-6:RS232/TTL 5 line – extended
- Net: NET0 MAC in MCU / sExt_NET: DM9000
- USB: Two channel USB 2.0 Host / One channel USB 2.0 device
- Audio in/out
- AD converter in
- GPIO out

5.8) Prototype MP

The prototype main processor board is utilizing the processor module from the Evaluation Kit, and offers a selection of IO ports suitable for the communication needs of the AutoDrop:

- RS232 DEBUG port
- RS232 TTL line for Radio modem
- RS232 TTL line for the IMU data
- RS232 line for the Acoustic modem
- RS485 line for Rudder sensor data
- RS485 line for Rudder motor control
- RS485 interface for Leg motors, bouncy tank actuators and payload actuator(s)

The the Main Processor prototype board version A with modifications can be seen here with connections for radio, debug and rudder sensor and rudder actuators.

5.9) AT Tiny processor

The AT tiny low power processor is able to control the power on the Main processor. A simple protocol provides the functionality to make the main processor ask for power to be switched off when at seabed position. While in low power mode, the AT Tiny processor monitors the Acoustic modem for traffic and if it detects activity it will wake up the Main processor board. The main processor board will then listen for an acoustic message containing an “ascend command”. If no message arrives the Main processor board will signal the AT Tiny to turn off the power again. The AT tiny will also periodically turn on the power and start the Main processor, which in turn may evaluate if it shall return to the surface due to a predefined timeout condition or battery power condition.

5.10) Linux operation system

The software base for the main processor board is a Linux operating system 2.6.24 with customized board support for the module. The system is built as a standard embedded Linux environment.

- AT91 Bootstrap
- U-Boot
- Kernel
- File system

All these parts may be loaded separately to the module.

9.1 Main processor SW / overview

Key features of the main processor SW:
- Linux
- C language
- Multi process
- Shared Memory IPC
- Serial IO to multiple devices
- Dedicated IO
- Flash memory log

To facilitate the simultaneous service on several serial IO devices, it turned out that the most stable solution is to start one Linux process for each of the serial ports, as input signaling did not work for one process handling more than one serial input, not even if port were handled in different threads.
Shared memory was selected for inter process communication (IPC) for many reasons. It is very easy to extend, it is stable and easy to debug. Many of the data paths in the system do not need queuing of messages, as the message containing the most recent measurement or sample always is the most interesting. So if the data source (say the IMU) overwrites the former sample before the Navigator reads it, it has low impact on the result. In the same way, the rudder controller does not care for the next to latest value to set, only the most recent. Shared memory is ideal for this, as the data structures may be shared by all relevant processes. This also facilitated the debugging services implemented, as it is easy to replace the source for any data by another process, being a special debug process or a CGI script running under the Apache web server for external web debugging.

The AutoDrop Main program is in charge of starting these separate processes when needed, according to the state machine parameters:
- IMU data process
- Rudder Position process
- Rudder Motor Control process
- Leg, Payload and buoyancy process
- Radio Modem process
- Acoustic Modem process

5.11) Low-power mainboard SW (AT Tiny)

The software in the low power processor is running constantly at low power including when the system is “shut down” to reduce energy consumption at seafloor acquisition position. The AT tiny will receive an IO signal from the main processor requesting to be shut down. The AT tiny will then power off the main processor and wait for a predefined low-power period only listening for incoming traffic from the acoustic modem. At the expiration of this period or at the event of acoustic signals – the main processor will be started.

The main processor in turn, will then decide how to act depending on three factors:
- Ascend command detected from the acoustic modem
- Predefined Ascend time reached
- Battery power condition. The AutoDrop will ascend to the surface if battery power reaches a certain “low watermark”

5.12) Prototype results

The prototype for the Embedded Control System Software has shown its capability to control and communicate with all planned devices for the AutoDrop system. The API is missing some details not yet decided upon regarding the navigation system. The initial integration with the Navigation and estimation software gave us some ideas, but as the navigation SW haven’t been at a stage ready to integrate there are some details left to decide and code. The software has shown stable and responsive and has been running with IMU parser and rudder control for several days on target hardware without showing communication errors or other errors.

5.13) Prototype and future product(s)

For the prototype SW the emphasis has been on the descent phase – and supporting the navigational system with multithreaded data driven environment. Simple start-up and state-machine methods has been tested, but there is need for extensions here to comply with the total state-chart of a whole mission. The Navigation and Estimation software has not been integrated, although some simple tests have been run in cooperation between TI and Aalborg University. There are tests and verifications needed on this matter to ensure that the timing requirements are fulfilled when running all tasks together.

Mission data communication is extremely simple in the prototype, and will have to be refined and extended in a future product. The external systems to support a mission, planning the target, giving the environmental parameters needed or navigation and calibration is not defined. Protocols will have to be developed and implemented for support of those systems.

Mechanisms for seabed to surface communication will also be needed in the future product. This prototype version does not include any such modules. The final product will also probably need a more thoroughly tuned Linux system.

5.14) Conclusion
As far as practically possible, the Embedded Control System Software is ready for integration with the AutoDrop devices and for integration with the Navigation and Estimation software. The software is made for running inside the AutoDrop and control and communicates with all its devices. It will be able to show the AutoDrop status and log if a computer is connected to external connector with RS232 and Ethernet.

In the collaborative work with the interface (API) supporting the Navigation suite, it was decided to change from the proposed polling services to a more data-driven architecture. Whenever new data is available from the IMU or other services – the Navigation SW sample handler will be started immediately or at least within a short sample-time.

Potential Impact:
Base on the excellent work, devoted personnel and excess resources from most of the RTDs and supporting SMEs, the AutoDrop idea and concept is significantly developed, but the prototype not built, tested and demonstrated as planned. The results gained so far have been very well received by a small group of clients, e.g. NOC and Seismic-company, being presented to a preview.

A first production series is discussed based on an on-schedule delivery, but recently a strong focus is to establish an overview of not completed work and outstanding tasks.
Simulations of the navigation and path-control algorithms have shown very promising accuracy, and tank-testing of a prototype-plug with integrated control-rudders, landing-gear and Inertia measurement unit have confirmed a stable behavior in water.

The unique salt-ballast system is fully demonstrated in a 70% setup, and will definitely change the way we plan to deploy sensor, and initially weighting down a temporary installed sensor. Environmental aspects of this concept is huge, and the flexibility and cost-efficiency significant.

We see a market trend towards robotization of operating sensor nodes, not only for traditional seismic exploration for oil&gas but also for geological determination of soil mechanics prior to installing offshore infrastructure such as offshore wind-mills etc.
A 10-20x operational efficiency gain is foreseen in deploying numerous sensors in a predefined grid in deep-water. The cost per unit is expected to be a fraction of the existing sensor hardware, and the operational response and mobilization flexibility on a vessel of opportunity dramatically improved. Due to the extremely efficient deployment and recovery, saving in the order of 60-70% of the current survey-time, battery capacity can be reduced or logging duration extended accordingly.

Significantly reducing a sensor spread CAPEX is foreseen, flexibility in deployment platform and improved operational efficiency and rapid survey response expected.

List of Websites:
www.autodrop.no

Project contact: Abyssus Marine Services A/S I Mr.Kyrre J.Tjøm I +4799525162 I kjt@abyssus.no

Final Report Summary - AUTODROP (Development of a novel autonomous vehicle significantly reducing costs related to subsea sensors deployment and recovery)

Udostępnij tę stronę

Pobierz