Long-Endurance Green Energy AutonomousSurface Vehicle Control Architecture

Alberto Dallolio, Bendik Agdal, Artur Zolich, Jo Arve Alfredsen, Tor Arne JohansenCenter for Autonomous Marine Operations and Systems

Department of Engineering CyberneticsNorwegian University of Science and Technology

Trondheim, Norway

Abstract—This paper presents the system design and archi-tecture of a wave-powered Autonomous Surface Vehicle (ASV).The proposed solution complies with the self-powering natureof the vehicle, ensuring long-duration operations in the openocean. In our field-tested concept, the vehicle is equipped withthe instruments and capabilities to deal with the environmentaluncertainties, while serving as an in-situ data provider foroceanographers and biologists. Robustness to mission failure anda high degree of redundancy are achieved by allocating compu-tational efforts and responsibilities to independent subsystems. Athree-layered system subdivision facilitates the implementation ofseveral capabilities involving solar energy harvesting, storage anddistribution, radio communication, autonomous navigation, AIS-based collision avoidance and onboard autonomy to superviseboth the mission execution and the scientific payload employment.

Index Terms—Autonomous Surface Vehicle, System Architec-ture, System Design

I. INTRODUCTION

This article focuses on the system architecture of a green-energy wave-powered autonomous surface vehicle (ASV)which relies on solar energy for powering its scientific payloadand support both navigation, control and communication. Thissystem is specifically developed for the commercially availableAutoNaut [1] (Fig. 1), chosen for its simplicity of operationand innovative propulsion system. Unlike common roboticplatforms, this system is less constrained by energy limitationwith respect to both propulsion and payload, ensuring long-duration missions without physical human intervention.This work presents a control system architecture, entirelydeveloped in academic environment, that is designed to meetthe requirements of robustness, endurance and redundancyrequired to successfully accomplish long-duration operationsin the open ocean. The architectural choices described revolvearound the unique self-powering nature of the vehicle, that isboth capable of transforming the energy induced by surfaceocean waves into forward propulsion but also of harvestingthe energy captured by solar panels. The proposed solution ismodular and scalable and relies on off-the-shelf componentsto target science-driven mission profiles later described.

II. MOTIVATIONS

With the emphasis on the ocean as the primary sink forgreenhouse gases, ocean science and the study of the climatechanges has become critical to understanding the evolution

of our planet. Monitoring dynamic environmental changesis of extreme urgency and to do so by moving towardssustainable and persistent ocean observation. Advancements inautonomous robotic systems can positively impact capabilitiesof ocean observation systems [2].

The lack of autonomous mobile platforms recording datacontinuously over long periods of time and in different areasof the globe, suggests the necessity to analyze oceanographicphenomena at spatio-temporal scales that are not approachablewith current observation tools and methodologies, which oftenrely on traditional ship-based methods. These observationscause substantial release of CO2, disturb the boundary layersignificantly, are not continuous and therefore limited inscaling across space and time. Meso-scale variability canbe best analyzed with semi-autonomous mobile platformsequipped with a suite of scientific payloads that can samplechlorophyll and biomass concentration, temperature, salinity,vertical current structure, sea surface height, turbulence etc.

To date, oceanic exploration and monitoring of the upperwater column, driven by scientific hypothesis and by meansof long-endurance robotic platforms, has already been demon-strated, e.g. [3], [4].

Fig. 1. Vehicle during operations in Trondheimsfjord.

Several types of long-endurance, green-energy powered sur-face vehicles are available on the market, e.g. Liquid RoboticsWaveGlider [5], Offshore Sensing SailBuoy [3], AutoNaut [6],or L3 Technologies C-Enduro [7]. All they show differentarchitecture designs, and find their need in various types ofoperations. In case of an academic research and possiblevehicle allocation to wide range of tasks, an easy systemcustomization is of high importance. However, to the authors’best knowledge, current literature doesn’t provide details ondesign of a long-endurance surface vehicle, that could be easilymodified towards research in oceans studies, marine biology,and control engineering.

This paper presents a custom system architecture, suitablefor long-endurance green-energy powered surface vehicles.The presented architecture has been designed to cover variouscriteria of research operations. Moreover, it is implementedand tested onboard the AutoNaut.

The structure of this paper is as follows. Section III definesmost important system design criteria. Section IV describes theAutoNaut platform. Section V presents the system architec-ture, whereas Section VI shows energy budget. Sections VII,VIII, IX guides through design of the system control logic.Section X discusses adopted communication solutions. Thedesign validation is presented in Section XI. Section XIIcontains conclusion remarks and future works.

III. MAIN SYSTEM REQUIREMENTS

The proposed system main focus is research activities con-ducted both in the Arctic and Atlantic waters and in Norwegiancoastal waters. The environmental harshness of these regionsand research applications result in a set of requirements thatthe presented system architecture needs to fulfill.

Research operations in the Arctic waters are often facingvarious challenges. The use of classic research vessels usuallyimplies significant constrains, such as limited number of on-board researchers, tight schedule due to high cost of operation,or non-negligible travel schedule to the point of interest.Moreover, human factors can not be neglected. Crew fatigueand sea-sickness can have a significant impact on missionsresults. Moreover, vessels powered by combustion engine havea particularly negative impact in the Arctic environment.

Two types of mission profiles are defined for the consideredautonomous vehicle.

1) Long-duration polar region research: The vehicle isdeployed using a Research Vessel in the polar region, whereit should work continuously during polar-day time, and for atleast two weeks continuously during polar night. The vehicleneed to be able to collect scientific data with re-configurableinterval, implying that communication is reduced to the aglobal-coverage satellite network. Access to the vehicle islimited, therefore control system robustness is a key feature.Large volumes of sensor data can be accessed only using alocal short-range radio, or WiFi, e.g. from a research vesselor Unmanned Aerial Vehicle (UAV).

2) Short-duration fjord operations: The vehicle is deployedfrom the shore (using a slip or pier crane), and performs

multi-day missions in the fjord. This scope serves coastalresearch and supports vehicle development and testing. Thevehicle is typically within the coverage of a high-speed cellularnetwork. Access to the vehicle is possible, although mayrequire additional assets. Quick access to both vehicle andsensor data is a key characteristics of this type of operation.

Taking into consideration the mission profiles that werepresented, the design requirements of the vehicle are:

• Deployment and recovery: The vehicle should supportdeployment from a slip or using a crane. Deploymentshould not require significant effort or put users at risk.The sea-bottom depth during launch should be as lowas possible. The vehicle should also be tow-able using asupport boat.

• Robustness: The system needs to be robust enough toavoid maintenance for several months. Mechanically thatcan be achieved by a sturdy design and a limited numberof moving parts. Electronically, the system should bebased on industrial grade components, including cablesand connectors. Control-wise, the system should providea well defined fallback system with redundant communi-cation channels.

• Energy management: Energy management system shouldenable to plan and monitor energy consumption, as wellas to harvest energy. The low-level system should allowto schedule when selected components are turned on andoff.

• Communication: The communication tools need to coverthree categories of links. An near-real-time, low band-width, global coverage link to report health status of thevehicle, its location, and an emergency manual control.A real-time, low bandwidth, long-range control of thevehicle, and detailed vehicle status and telemetry. A real-time, high bandwidth, short-range data link to collectsensors data. The mission scenario should define whichlinks are active. Therefore, faster links with lower rangeshould be able to cover functions of the slower, long-range links.

• Autonomy and control: The vehicle needs to be able toexecute maneuvers, and its predicted trajectory needs tobe computed taking into account environmental condi-tions, as sea currents or winds. The system needs tobe able to handle current and future developments incontrol algorithms and autonomy. The control systemshould be compatible with a fleet of Unmanned Vehiclesused at NTNU [8], [9], supporting a fully autonomoustasks allocation and multi-type, multi-vehicle cooperationin the future. The vehicle should also support manualcontrol, especially for launch and recovery.

• Modularity and scalability: The control and sensors sys-tems should not limit each others development and up-grades. The system should be modular, and each segmentcan be upgraded independently if necessary. Finally,the platform should be able to accommodate additionalscientific sensors in the future.

IV. VEHICLE OVERVIEW

In order to accomplish missions with the profiles describedin the previous section, the AutoNaut and equipped with ascientific payload that targets the environmental features ofinterest. The vehicle is provided with a propulsion systemthat entirely relies on sea surface waves [1]. A pair of spring-loaded hydrofoils are connected at the bottom of two verticalstruts (at the bow and stern respectively). When a surfacewave lifts the bow of the vehicle, the struts lift the foils,that are then recalled by the spring generating a forwardpropulsion. This self-propelling mechanism constraints thespeed achieved by the vessel during operations, that results tobe limited (up to 3-4 knots) compared to usual surface vehiclespropelled by a thruster. However, the platform is equippedwith a small thruster that is actuated by the collision avoidancealgorithm to enable sharper maneuvers or whenever the heightof sea surface waves is not enough to produce an acceptablepropulsion. The heading of the vessel is controlled by meansof a rudder, commanded by the navigation control unit, thatcan turn up to ±45◦ about its centered position.The hull is divided into two main water-tight compartments,

where batteries, computers and some sensors are hosted.However, most of the sensors needed for navigation andenvironmental data collection are however placed outside thecompartments, (Fig. 2).The scientific payload is described in Table I. Except for theWeather Station (Airmar 120WX), connected to the vehiclemast, all the sensors are placed on the keel, therefore con-stantly underwater (Fig. 3).

V. ARCHITECTURE OVERVIEW

The proposed architecture, publicly documented in [10],equips the vehicle with autonomous communication and nav-igation control capabilities. This paper discusses the designchoices that have been made in order to provide the vessel reli-able navigation, control and communication tools. Robustnessand durability constitute the baseline of more ambitious mis-sions that will involve automated operations of the scientificpayload, to serve as an in-situ data provider for oceanographersand biologists. As a consequence, navigation, control and

Fig. 2. Vehicle 3D model with hardware placement.

TABLE ISCIENTIFIC PAYLOAD

Sensor Information

Nortek Signature500 ADCP Current profiles at up to8 Hz sampling frequency.

Seabird CTD SBE49 Conductivity, temperature,and pressure of seawater.

ThelmaBiotel TBR700 Continuos tracking of tagged fishes.

Aanderaa Oxygen Optode 4835 Oxygen saturationand % saturation.

WET Labs ECO Puck Triplet chlorophyll and FDOMfluorescence and red backscattering.

Airmar 120WX Weather Station Wind, temperatureand pressure.

communication units rely on an selection of sensors to supporttheir operations and in turn the whole science-driven mission.Tables II, III, IV and V list all the sensors and hardware unitsthat support navigation control, communication and powermanagement.

TABLE IINAVIGATION SENSORS

Sensor Information

Vector V104 GPS Smart Antenna Accurate Time, SOGand COG/heading.

Raymarine AIS650 Tracking information forcollision avoidance

Airmar 120WX Weather Stationa Wind, temperatureand pressure.

ADIS16485 IMU Triaxial gyroscope andaccelerometer data.

HMR3000 Digital Compass Heading, pitchand roll outputs.

Echomax Radar Reflector Active Radar ReflectorNavigation Light Mast Navigation Light

aboth used for navigation andenvironment analysis.

In our field-tested control system architecture, a layeredsubdivision of computation efforts and mission responsibilitiesprovides a high degree of robustness and redundancy (Fig. 4).Level 1 unit is the low-level and fallback component of thesystem. It monitors the health status of the vehicle and itshardware, autonomously commands fallback maneuvers andmanages power harvesting, storage and distribution. Level 2

Fig. 3. Scientific Payload: ADCP, CTD, Optode4835 and ECO Puck on thekeel; Weather Station on the mast with Navigation Light and Radar Reflector.

TABLE IIICOMMUNICATION LINKS

Unit Purpose

OWL VHF Radio Long-range, low bandwidthradio transceiver.

MikroTik 4G/LTE Modem 4G/LTE Modemonboard the vehicle.

RockBLOCK+ Iridium Satellite communication.

TABLE IVPOWER MANAGEMENT

Unit Purpose

Victron BlueSolar MPPT Controller Solar Panels -Battery charge controller

DRA1-MPDCD3-B Solid State Relay

861SSR115-DD Solid State Relay

TABLE VCOMPUTATIONAL UNITS

Unit Purpose

Campbell ScientificCR6 Datalogger

Level 1: system monitoring, powerdistribution, fallbackcommunication and autopilot.

BeagleBone Black Level 2: advanced navigation, collisionavoidance and system monitoring.

TS-7970 Level 3: scientific Payload Control Unit.SenTiBoard High-accuracy timing board.

provides the vessel advanced navigation capabilities, includ-ing a course-keeping autopilot and an AIS-based collisionavoidance algorithm. Level 3 controls the scientific payloaddepending on the mission profile.

The Level 3 runs as a slave CPU, controlled by Level 2.Because of the slow-moving nature of the vehicle, Level 3is mostly in stand-by mode during navigation towards themission area, limiting power consumption. The multi-layeredapproach decreases the coupling in the design and facilitatesthe implementation of new functionalities. Also, it involvesgraceful degradation in low energy situations. As the onlyenergy source for the onboard electronics is solar, situationswhere energy must be conserved might arise. In such cases

Level 3

Scientific System

Level 2

Navigation & CollisionAvoidance

Navigation Sensors

GPS, IMU,Magnetometer, WeatherStation, AIS, SenTiBoard

Communication

3G/4G, Iridium,AIS, WiFi

Level 1

System Monitoring &Fallback Autopilot

Scientific Payload

ADCP, CTD, Fish Tracker,Oxygen Optode, ECO Triplet

Pumps, Nav. Light,Radar Reflector

Rudder & Thruster

PV Panels & Batteries

Communication

Iridium, VHF radio

Navigation Sensors

GPS

TS-7970BeagleBone BlackCampbell Scientific CR6

Ethernet

Misc.

Misc.

Misc.

RS-232(NMEA0183)+12V

+12V

+12V

Fig. 4. System Architecture

Fig. 5. Level 1 Hardware Architecture

Level 3 (and Level 2 in worst-case scenario) can be turned offwithout losing safety-critical functions.In the next three sections, a detailed description of the com-putational subsystems and the sensors they are interfaced toare presented. Then we present a validation of the proposedarchitecture, analyzing data gathered during field test missions.Optimizing the balance between energy harvested, producedby solar panels, and energy consumed by the system duringdifferent stages of the mission is of main importance inorder to allow the vehicle to run autonomously for severalweeks. Finally, the performances of the navigation autopilotare discussed.

VI. ENERGY HARVESTING, STORAGE &DISTRIBUTION

The upper surface of the hull is covered with three SolbianSP 104 solar panels, whose maximum output power rating is104W each. The onboard battery bank is made of four 12V70Ah Lead Gel batteries, wired in parallel as most of thecomponents require around 12V. In order to control the powerproduced by the panels, two Maximum Power Point Tracking(MPPT) controllers are chosen. These have built-in invertersand can step the voltage up or down before supplying thebatteries. This is extremely beneficial as the solar panel outputvaries with the observed load impedance. Two step-downMPPT controllers is used in the power system. Panel 3, whichis far from the mast, is connected to one controller because itis unlikely that the internal bypass diodes are activated due toshading, meaning that the panel output always will be higherthan the required input voltage for the controller. The panelsnear the mast, likely subject to partial shading, are connectedin series to another step-down MPPT controller. So doing, thechargers input will always be higher than the minimum voltagerequirement, even if both arrays in one panel are bypassed. Theunits selected are Victron BlueSolar MPPT 75/15.Fig. 5 provides an overview of the structural design of the

power management system implemented into Level 1 unitcase. An external toggle switch allows to disconnect the loadpower line that provides current to all the components. Thismeans that when a mission is completed and the user turns offcomputers and sensors, the batteries can still be recharged by

Fig. 6. Expected power on two solar panels through a period between Augustand September in Trondheim, based on historic data.

the solar panels through the controllers. Fig. 5 also shows howthe power is distributed to the whole system. The CR6 Camp-bell Scientific Datalogger, compass GPS, Iridium and RudderServo are directly connected to the load port of BlueSolar 1,through the switch. However, they are controlled by the CR6.Level 2, Level 3, AIS transceiver, 4G/LTE Modem, SentiBoardtiming unit, Radar Reflector and Pumps are instead powered bysolid state relays that are digitally controlled by CR6 GPIOs.The OWL VHF radio is the only component being directlypowered by a 12V output port of the CR6. Historic data forsolar radiation during fall in Trondheim (Norway), reducedby the solar panel efficiency factor, gives an insight about theexpected amount of energy the panels should provide Fig. 6.An estimate of the power consumption of the vehicle wasdefined according to datasheets of onboard, considering theexpected time of use for each device mentioned in TablesI, II, III, IV and V. Level 1 and Level 2 are estimated toconsume approximately 20W, assuming 14V system (fullycharged lead-acid batteries). The maximum average currentconsumption is estimated to be around 1.4A. The consumptionof Level 3 is dependent on sampling frequency of the scientificpayload. Based on sampling routine suggested by biologistsand oceanographers, the average constant power requirementfor Level 3 is estimated to reach 21W.

VII. SYSTEM MONITORING & FALLBACKAUTOPILOT

Level 1 subsystem is responsible for monitoring the healthstatus of the whole system. This unit observes the operationroutines of all the sensors and subsystems and is able to iden-tify anomalies. These can be related to powering issues, e.g.sudden decrease of supplied current or increase of consumedenergy, or to communication issues. In case an anomaly isidentified, a dedicated routine will try to provide a solution forit (e.g. restarting) and will open a communication link with theoperators in order to notify the failure. During developmentof the system, it was sought to keep complexity as low as

TABLE VIL1 Requirements

System Requirement Description Subsystem Requirements12± 2V outputLoad power monitoring

Onboard Power PV panel power monitoringStored energy estimationDisabling device powerIn-port chargingDevice error monitoringLevel 2 failure monitoring

Error Handling Level 3 failure monitoringSensors failure monitoringLeak detectionBilge pumps controlRemote Control Interface protocol

Control of Operation Mode Manual Control ModeLevel 2 Control ModeFallback Autopilot ModeRemote Control Interface protocol

Manual Control Rudder Angle ControlThruster ControlDisabling of Power for DevicesIridium Communication LinkVHF Radio Communication Link

Remote Data & Communication 4G/LTE Communication LinkOutput System Energy ParametersOutput Position, COG and SOGOutput Leak and Error Status

possible while still meeting the system requirements listed inTable VI, as described in [11].

A. Behavioural Design

Level 1 works as a state machine, switching operationmode when a failure is detected or the operators need tomanually control the vehicle heading and speed (Fig. 7).The transition from normal or fallback to manual only takesplace if the operator sends an instruction to the system. Ifthe connection is lost between the remote operator and theUSV when in manual mode, the USV will enter fallbackmode. Also, fallback state will be entered automatically ifLevel 1 does not receive instructions from Level 2. Note thata warning will be sent to the operator, over Iridium, in theevent of this transition. The transition from fallback to normalis also automatic and occurs as soon as Level 1 receives avalid instruction from Level 2. During normal operations,Level 1 periodically receives rudder (and, if needed, thruster)commands from the heading controller running in Level 2.Communication happens according to NMEA0183 protocolat RS-232 voltage levels. The communication standard waschosen because of low power consumption, low requiredbandwidth and human-readable formats. If the CR6 computerdoes not receive a verified control signal from the Level2 computer for a user-defined amount of time, it willassume that Level 2 has failed and therefore switch tofallback state. When the system enters fallback mode, threedifferent operating modes can be selected depending on thecircumstance:

Fig. 7. Level 1 State Diagram.

• Fallback mode 0: Sets the rudder angle to zero andthruster to 0.

• Fallback mode 1: Sets the rudder angle to 45 and thethruster to 0.

• Fallback mode 2: Activates a course-keeping autopilotthat reads the course over ground (COG) measurementfrom the GPS and computes the rudder angle that makesthe vehicle keep a desired course.

However, Level 1 periodically checks for messages receivedby the operators over VHF radio or Iridium. If a message isreceived by the onboard transceiver, the state machine auto-matically switches to manual, as shown in Fig. 7, prioritizingoperators directives. Manual control is needed, for example,to directly maneuver the vehicle inside the harbor.As already anticipated, Level 1 also monitors the batteryvoltage, solar cell power and load power. It obtains navigationdata from GPS and checks for leaks. For leak detection, theonboard bilge pumps are used. Since the motors are inductiveloads, the current will change based on their resistance. Pumpsare periodically activated, and based on the increase in current,the system is able to detect if water is being pumped.

B. Software Implementation

The choice of Campbell Scientific CR6 computer to ful-fill the requirements proposed with Level 1 is due to itsproven reliability, successfully tested in long-term monitoringexperiments in harsh environments [12], [13]. The CampbellScientific CR6 has a Renesas RX63N processor with a clockrate of 100 MHz and has sixteen general I/O pins withdedicated hardware for support of numerous communicationprotocols [14]. The CR6 was chosen due to the need ofmultiple I/O ports and fast CPU. All the functionalities ofLevel 1 described so far are implemented by means of PC400Datalogger Support Software and CR Basic Editor. To sup-port communication over VHF Radio and provide a human-readable GUI for operators on shore, a Java application wasdeveloped. Fig. 10 shows how the operator is able of manuallycommand the rudder and thruster of the vessel. Sensors andother units can be manually turned on and off and the fallbackbehaviour can be chosen and communicated to the vehicle.

VIII. ADVANCED NAVIGATION & COLLISIONAVOIDANCE

The Level 2 subsystem implements advanced navigation andcollision avoidance capabilities. It is powered by a dedicatedsolid state relay in Level 1 case that provides 12V. Thisvoltage is then transformed to match the input requirementsfor some of the components of Level 2, working at 5V(Fig. 8). The computational unit chosen for this subsystemis a BeagleBone Black, provided with a 1GHz ARM-basedCPU and two 46 pin headers that enable communication witha wide range of sensors and other hardware components.During normal operations, Level 2 acquires navigation datafrom GPS, magnetometer, IMU and Weather Station. Thisinformation is used to determine both the current state ofthe vehicle (heading, course over ground (COG), speed overground (SOG), location) and the state of the sea (wavesamplitude, frequency and direction, wind speed and direction).A high-level autopilot is implemented in order to govern thecourse and the speed of the vehicle by observing the waves’direction and height. Plans can be defined by the operator onshore and dispatched over 4G/LTE or Iridium to the onboardunit (Fig. 9). A typical mission plan can be made of a simpledesired location or of a more complex sequence of targets,e.g. a survey of an area. When the vehicle operates in remoteareas, communication is sporadic and onshore operators maynot have the same situational awareness of the environmentas the vehicle. In this case, a mission plan dispatched fromshore may be a list of high-level goals including target areasand specific data to be collected and sent to shore. An on-board decision-making system supports the generation of thenavigation plan, based on in-situ measurements and sea-stateestimation. T-REX is an execution layer designed with goal-driven mission planning in mind [15], [16]. T-REX dictates theexecution of plans and supports fast re-planning of the mission,providing a high degree of responsiveness those environmentalchanges that may cause the failure of the mission. A sea-stateestimator receives environmental data from the weather station(wind intensity and direction, temperature, pressure) and heaveacceleration from the IMU and computes an estimation ofthe current state of the environment. Once the plan is refinedonboard the vehicle, the desired course is computed according

Fig. 8. Level 2 Hardware Architecture.

to the chosen navigation law. Line-of-sight is preferred, due toits simple implementation. A PID course controller reads thecurrent course provided by the GPS and computes the rudderangle that allows the vehicle to keep the desired course to thetarget waypoint.

A. Collision Avoidance Algorithm

The collision avoidance algorithm involves a continuousmonitoring of the area in which the vehicle is navigating. Amonitoring radius around the vessel is defined and navigationdata corresponding to close vehicles equipped with AIS, areprovided by the transceiver. For the ASV to obey the rules-of-traffic when encountering other vehicles and execute thecorrect and predictable actions in hazardous situations, thealgorithm needs to be COLREGS compliant. Based on theinformation provided by the onboard AIS transceiver, thealgorithm searches for COLREGS compliant and collision-freetrajectories through a series of predictive simulations with afinite set of offsets to the nominal course. The offset associatedwith the lowest cost, while producing a collision-free andCOLREGS compliant trajectory, is selected as the new modi-fied course reference, and is passed on to the autopilot. Whenthe original desired trajectory no longer contains any potentialcollision, the ASV would return to the desired nominal pathand proceed towards the target destination. If no obstacle ispresent in the vicinity of the vehicle, no deviation is applied todesired course and speed. The algorithm is described in detailin [17], [18] and [19].

B. Software Implementation

The software dedicated to this subsystem is an open-sourcetoolchain developed by the Underwater System and Technol-ogy Laboratory (LSTS). The toolchain supports networked ve-hicles systems constituted by human operators, heterogeneousautonomous vehicles and sensors [20]. The software toolchainis primarily composed of the onshore mission control software

Fig. 9. Level 2 Software Functionality.

Fig. 10. Onshore mission control center (Neptus).

Neptus, the onboard software Dune, and IMC, a communica-tion protocol. The toolchain also uses its own operative system(GLUED), a minimal Linux distribution targeted at embeddedsystems. Operators on shore have complete control over themission through Neptus and are able to customize the missionplan visually as shown in Fig. 10.

IX. THE SCIENTIFIC PAYLOAD

The Level 3 subsystem is responsible for controllingthe scientific payload according to the mission plan. Duringnavigation to the survey site, this unit is meant to be turned offin order to save energy. When the target area is reached, Level2 communicates to Level 1 the need to turn on the scientificunit. A plan that involves commanding the scientific payload iseither manually built by the operators and dispatched to Level2 over 4G/LTE or Iridium, or autonomously synthesizedonboard the vehicle. Plans involving the control of thescientific payload are synthesized in Level 2, where decision-making techniques deduce mission plans while reasoningon resources, time constraints, environment changes andoperational risk. This functionality will support the missionexecution when the vehicle is exploring remote areas andcommunication to shore results to be sporadic and expensive.The master-slave relation between Level 2 (master) and Level3 (slave) further motivated with the following routine example.

1) based on the chosen navigation law, the master autopilotcomputes rudder commands that allow the vessel toreach the area of interest described by the operator plan- the slave unit is turned off.

2) once the target area is reached, the slave is turned onand a plan is communicated by the master to the slave.

3) the slave executes the plan, locally stores data sampledby the sensors.

4) data are then compressed, packed and transferred to themaster.

5) the master communicates the outcome of the mission tothe operator, sends the data and turns off the scientificsubsystem.

X. COMMUNICATION LINKS

The vehicle is provided with four different communicationlinks. Depending on the mission, the operator can communi-cate with vehicle over 4G/LTE, Iridium or VHF radio (Fig. 11).Both Level 1 and Level 2 have access to separate Iridiumtransceivers.

A. 4G/LTE Communication

Communication over Internet allows the users on shore tohave a full live stream of the mission. Onboard the vehiclea 4G/LTE modem (MikroTik) connects to Internet through adedicated antenna on the mast. Every five minutes a programinternal to the modem reports the modem IP to a dynamicDNS remote service. The modem implements port forwardingand NAT, enabling communication between operators andthe BeagleBone Black in both directions, through the routeritself. The local network is therefore always accessible via thesame URL, no matter the IP provided by the internet serviceprovider. An ethernet switch allows the inclusion of Level 3in the local network, Fig. 8. The operators are able to closelyobserve and control Level 2 and Level 3 via SSH protocol.As discussed in VIII-B, the communication protocol (IMC)allows different nodes to share the same message formatting.In order to enable a full transmission of the messages payloadfrom one node to another (in our case, the operators and thevehicle), a dedicated proxy is used. IMCProxy bridges IMCnetworks over Internet. This is achieved through a centralizedproxy server that receives IMC messages and forwards themto other connected nodes, Fig. 12. For missions close to thecoast, where signal coverage is strong, this communicationlink is preferred due to its flexibility.

B. Iridium Communication

The vessel is equipped with two separate Iridium Rock-block+ units that host an Iridium 9602 transceiver, an antennaand a voltage regulator. As shown in Fig. 4, both Level1 and Level 2 can send a receive messages over satellite.This communication link supports the mission when 4G/LTEcoverage is absent and involves less mission flexibility andhigher costs.Level 1 periodically sends a message reporting the overallstate of the system: time and location, power settings, bat-tery voltage, consumed and produced power. The operator is

Fig. 11. Communication links.

Fig. 12. IMC networks communicating.

therefore able to communicate changes in the power settingsof the vehicle and restart sensors and components.The Rockblock+ unit connected to Level 2 is instead used tocommunicate new or modified plans to the onboard software(Dune). The vehicle acknowledges the reception of the planand later its outcome. This solution has a limited bandwidthand is therefore only suitable for simple control monitoringor tracking applications. The maximum package sizes are 340bytes for sending and 270 bytes for receiving. Although thelatency is typically a few seconds, it may increase up to aminute or more depending on the remoteness of the area andthe available satellites.

C. VHF Radio Communication

Onboard the vehicle, an OWL VHF radio transceiver allowsefficient point-to-point communication between the operatorsand Level 1. It supports a large variety of modulation types andencoding, that can be configured through a serial port. A JavaGUI (Fig. 10) enables manual control and direct monitoring ofthe vehicle, over VHF. During a mission, this link is turned offin order to save energy. It is however turned on when manualcontrol of the vehicle is needed. An automatic routine enablesthe radio whenever a fault is detected. The radio transmits thelocation and power settings, allowing the operators to find thevehicle and manually control it to shore.A passive duplexer allows the OWL VHF radio to share oneantenna with the AIS. Unlike an active splitter, the duplexerhas a notch filter in each port that attenuates the frequencyused by the other port. This means that both radios can alwaystransmit without hearing each other and everything is sent outon the antenna. The filters are tuned to specific frequencies,so the radios cannot change frequency. The selected cut-off frequency of the AIS port is 162MHz (center of AISfrequencies 161,975MHz and 162,025MHz) and 155,9MHzfor the VHF radio.

XI. ARCHITECTURE VALIDATION

The proposed architecture is validated with several fieldtrials in Trondheimsfjord (Trondheim, Norway). The missionsconducted so far aimed at testing the correct functioning ofLevel 1 and Level 2 subsystem. This involved monitoring ofthe onboard energy balance of the vehicle, manual control

Fig. 13. Power generated by two solar panels on September 7, 2019 inTrondheim.

and autonomous waypoint navigation. Implicitly, all threecommunication links were successfully tested.

A. Power System Validation

Based on the considerations anticipated in section VI, a24-hours long dataset is acquired on September 7, 2019 inTrondheim. Figure 13 shows that the power harvested by twosolar panels properly fits within the borders defined by historicdata Fig. 6. Figure 14 shows a 24-hours system run. It can beobserved that measured current of Level 1 and Level 2 is belowthe estimated value of 1.4A, based on maximum componentsconsumption and mentioned in section VI.

Graphs showing the expected remaining onboard energy forTrondheim and Svalbard areas, where the vehicle is expectedto operate mostly, are presented in Fig. 15 and Fig. 16.Graphs are based on expected power consumption of all threesubsystems, and the historic data of solar irradiance in theseregions. The graphs give information about the remainingenergy stored in the onboard battery bank of the vehicle duringa long-term operation. By evaluating both the power produced

Fig. 14. Current consumption by Level 1 and Level 2 on September 7, 2019

Fig. 15. Expected onboard stored energy based on data from 2016 inTrondheim.

Fig. 16. Expected on-board-stored energy based on data from 2016 onSvalbard

by solar panels and that consumed by the system, includingLevel 1 & 2, the graphs show a higher energy efficiency thanthe estimated values.

B. Navigation Control Validation

Once Level 1 proved to work properly, advanced navigationand collision avoidance were tested. Fig. 17 shows a simplegoto mission, where the vehicle navigates towards a destina-tion target from the harbor. The line-of-sight navigation lawcomputes the desired course for the course-keeping autopilot.Fig. 18 shows instead a survey of five points executed by thevehicle close to shore. The completion of this mission tookaround 76 minutes and the vehicle average speed was 0.8m/s.The navigation plans was defined on shore via Neptus GUI anddispatched over Internet to the vehicle. On shore, the missionwas observed in Neptus that periodically received real-timenavigation and power management data.

Fig. 17. Autonomous navigation towards a target location.

XII. CONCLUSIONS & FUTURE WORK

In this article we presented the system architecture de-sign of an autonomous surface vehicle that targets long-duration missions in the open ocean. The design choiceswere motivated keeping in mind the concepts of operationand the mission profiles standing beyond the choice of thevehicle. Through the validation of the proposed architecture,we aim at providing scientists a tool to further extend theconcept of marine observation and monitoring. Our intentionis to leverage current technological efforts towards building apersistent observational capability, in order to better observeand understand all those environmental oceanic phenomenathat evolve at spatio-temporal scales not approachable withcurrent instrumentation.Future works point in the direction of onboard, goal-drivenmission planning. To date, the literature already presentsextensive operational capability with networked heterogeneousassets for upper water-exploration driven by scientific hypothe-ses. Moreover, the vehicle will need to autonomously synthe-

Fig. 18. Autonomous survey of five waypoints.

size its own short-term mission goals onboard, without relyingon support from shore, reasoning on available resources andestimating the environmental conditions.

XIII. ACKNOWLEDGEMENTSThis work was supported by the Research Council of

Norway (RCN) through the MASSIVE project, grant number270959, and AMOS grant number 223254 to NTNU. Theauthors would like to thank Pedro De La Torre for thesupport with the operations and logistics, Petter Knutsen forthe hardware integration and Joao Fortuna for the softwaresuggestions and support.

REFERENCES

[1] AutoNautLtd., “Autonaut - wave propelled unmanned surface vehicle,”http://www.autonautusv.com/.

[2] P. McGillivary, J. Borges de Sousa, R. Martins, K. Rajan, and F. Leroy,“Integrating autonomous underwater vessels, surface vessels and aircraftas persistent surveillance components of ocean observing studies,” in2012 IEEE/OES Autonomous Underwater Vehicles (AUV), Sep. 2012,pp. 1–5.

[3] I. Fer and D. Peddie, “Near surface oceanographic measurements usingthe sailbuoy,” in 2013 MTS/IEEE OCEANS - Bergen, June 2013, pp.1–15.

[4] R. Hine, S. Willcox, G. Hine, and T. Richardson, “The wave glider:A wave-powered autonomous marine vehicle,” in OCEANS 2009, Oct2009, pp. 1–6.

[5] J. Manley and S. Willcox, “The wave glider: A new concept fordeploying ocean instrumentation,” IEEE Instrumentation MeasurementMagazine, vol. 13, no. 6, pp. 8–13, December 2010.

[6] P. Johnston and M. Poole, “Marine surveillance capabilities of theautonaut wave-propelled unmanned surface vessel (usv),” in OCEANS2017 - Aberdeen, June 2017, pp. 1–46.

[7] L. Technologies. (2019) C-enduro long endurance asv. [Online].Available: https://www.asvglobal.com/wp-content/uploads/2019/04/C-Enduro-MKII 2019.pdf

[8] M. Ludvigsen et al., “Network of heterogeneous autonomous vehiclesfor marine research and management,” in OCEANS 2016 MTS/IEEEMonterey. IEEE, 2016, pp. 1–7.

[9] A. Zolich, A. Sgrov, E. Vgsholm, V. Hovstein, and T. A. Johansen, “Co-ordinated maritime missions of unmanned vehicles network architectureand performance analysis,” in 2017 IEEE International Conference onCommunications (ICC), May 2017, pp. 1–7.

[10] NTNU, “NTNU autonaut documentation wiki,”http://autonaut.itk.ntnu.no.

[11] B. O. Agdal, “Design and implementation of control system for greenunmanned surface vehicle,” Master’s thesis, NTNU, 2018.

[12] “Greenland ecology [online],” http://CampbellSci.com/, 2018.[13] “Costa rica: Buoy system [online],” http://CampbellSci.com/, 2018.[14] CampbellScientific, “Cr6 measurement and control system operators

manual,” 2015.[15] C. McGann, F. Py, K. Rajan, H. Thomas, R. Henthorn, and R. McEwen,

“A Deliberative Architecture for AUV Control,” in IEEE InternationalConference on Robotics and Automation (ICRA), Pasadena, May 2008.

[16] K. Rajan and F. Py, “T-REX: Partitioned Inference for AUV MissionControl,” in Further Advances in Unmanned Marine Vehicles, August2012.

[17] T. A. Johansen, T. Perez, and A. Cristofaro, “Ship collision avoid-ance and colregs compliance using simulation-based control behaviorselection with predictive hazard assessment,” IEEE Transactions onIntelligent Transportation Systems, vol. 17, no. 12, pp. 3407–3422, Dec2016.

[18] I. B. Hagen, “Collision avoidance for ASVs using model predictivecontrol,” Master’s thesis, Trondheim, NTNU, 2017.

[19] S. D. Sæter, “COLREGS compliant Collision Avoidance System for aWave and Solar Powered USV,” Master’s thesis, Trondheim, NTNU,2018.

[20] J. Pinto, P. Calado, J. Braga, P. Dias, R. Martins, E. Marques, andJ. Sousa, “Implementation of a control architecture for networked vehiclesystems,” IFAC Proceedings Volumes, vol. 45, no. 5, pp. 100 – 105, 2012.