*3.3. Software Architecture*

The software routines which control OpenSWAP are divided into two main groups, those for navigation and those for data acquisition. A block-model of the software architecture is displayed in Figure 5, and described in detail below.

**Figure 5.** Block diagram showing OpenSWAP hardware/software architecture.

#### 3.3.1. DUNVAG, the Autonomous Navigation Firmware

DUNVAG represents the "heart" of the system. It is a multiplatform firmware that runs on several different commercially available micro-controllers (i.e., ArduinoDue®, Teensy, STM32, etc.), and implements several functions, including: full control over propulsion system by using ESC (electronic speed control) boards; inertial navigation (INS), by means ofMEMS (micro electro-mechanical systems) gyroscopes, accelerometers, magnetometers and single or double GPS antenna (with or without RTK correction); several algorithms for autonomous navigation and path following; wireless

communication for telemetry and remote control, both for long range point-to-point connections, and by means of wide area links using 3G/4G/5G terminals. DUNVAG is configured through the editing of three text files stored inside a μSD card at the root level: CFG\_NAV.TXT for configuring navigation, CFG\_IMU.TXT, for the inertial system, and CFG\_IO.TXT for I/O ports. A detailed description of all parameters is reported in Supplementary Tables S1–S3.

The module controlling propulsion and direction changes of the vehicle is implemented through PWM (pulse width modulation) or DSHOT1200/2400 protocols, driving two (or more) underwater electrical motors connected to STM32 based ESCs. The system is able to process feedbacks from the ESCs (when DSHOT protocol is used) to inspect the status of active motors, such as: -current absorption; -applied voltage; spinning velocity (RPM); and ESC temperature. The module is also responsible for controlling direction changes during navigation by modulating the power distributed between port and starboard. Typically, the OpenSWAP vehicles mount two motors per side, a redundancy which results critical in case of failure, but also useful for enhancing propulsion under di fficult environmental conditions (strong currents, waves, wind, etc.). Since the propulsion module supports up to eight motors, and because four propellers are generally used, the spare slots are available for customizations, including implementation of di fferent types of propulsion. An example, that was specifically tested for wetlands and swamps, is implementing an airboat by installing air propellers on top of the vehicle to avoid aquatic plants and reduce the environmental impact. One specific feature implemented in this module, is the real-time acquisition of the propulsion devices telemetry, allowing for intervention in the event of partial or total failure. Through the analysis of the ESCs status, the propulsion module can monitor at a rate of 10<sup>2</sup> samples per second propellers and controllers, and use such data to manage emergencies. A typical example is case of a propeller failure overcome by distributing more power to the other motors in the attempt of continue the navigation under the predefined constraints. This allows the vehicle to attempt accomplishing the mission in case of minor failures and/or re-entering the base in case o major. The configuration file including all parameters controlling the propulsion module is CFG\_NAV.TXT (Supplementary Table S1).

The *I*/*O system* allows internal and external devices to be connected to the vehicle. It is based on several input ports, including eight RS232 serial lines and eight 0–5 V analogue inputs. In the default configuration, serial lines are configured to be connected to basic devices used for normal operations. They include:

(1) Serial-1, connected to the 433 MHz high-power, long-range, wireless module used for telemetry and remote controls;

(2) Serial-2, connected to the SBE module, is used to pass to the echosounder computer (a*Raspberry* ™ PI) all the NMEA (National Marine Electronics Association) encoded sentences coming from the installed GPS, plus additional information in NMEA custom formatted strings, such as all vehicle status parameters, water temperature if temperature sensor is installed and any other readings coming from additional analog sensor eventually installed; asynchronously, *Raspberry* ™ returns to the DUNVAG software the water depth computed in real time by analyzing the received echograms, all the NMEA sentences of any serial sensor connected at its ports and eventually the control-packets coming from the WAN (wide area network) detailed later on;

(3) Serial-3, connected in shared mode with every ESCs for telemetry;

(4) Serial-4, connected to the internal double RTK GPS receiver for high precision headings;

The remaining two serial lines are available for additional devices and can be accessed by the users through the internal FORTH scripting language.

Eight lines are also available for external analogue devices, accepting any input in the 0–5 V range, one already assigned to a temperature sensor embedded in the echosounder. Configuration parameters can be set to apply bias and/or scaling corrections if needed. Analogue lines could be also accessed by means of FORTH language commands, as well as through custom \$IIXDR sentences sent to Serial-2. The sequence of such sentences is stored in a log file by the *Raspberry* ™ echosounder module and/or eventually sent over the INTERNET when a connection is available.

The Inertial Navigation System is composed by three MEMS devices and one or two GPS receivers (see scheme in Figure 5). It is a key part of the system as it implements the HW/SW layer responsible for updating in real-time the vehicle position and its heading, also providing attitude information (pitch, roll and heave). It makes use of a MARG sensor fusion and Kalman 1D filtering algorithm [5–9] receiving data from gyroscopes, accelerometers and magnetometers, and integrating them with GPS heading and position. The inertial navigation system is configured through a text file, the CFG\_IMU.TXT (Supplementary Materials), containing parameters for accelerometer and gyroscope bias, linear correction on temperature changes, and for hard and soft iron perturbation induced on magnetometer by external sources such as ferromagnetic material. Additionally, for more accurate calibrations over temperature, an IMU0.CAL file can be added, containing a list of corrections to be applied to gyroscope and accelerometer for a given temperature range (−50/100 ◦C). While a standard calibration is provided, in the event of calibration loss or unsatisfactory behaviors, an additional JAVA® application named MUVIMANT is available, to perform calibration of magnetometer and accelerometer/gyroscope couple.

Once calibrated, the system is able to integrate and correct the heading with using data from the GPS receiver, injecting the heading available through the IMU (Inertial Measurement System), prioritizing on most precise NMEA sentences (i.e., HDG before VTG). This provides a quick updating of the heading, since MEMS are characterized by a very fast and relatively accurate heading/positioning, and the GPSs, although slower, would provide best the accuracy in the presence of a good satellites signal.

Autonomous navigation system. Once accurate positioning and direction, as well as waypoints of the predetermined path are available to the system, they are sent to the autonomous navigation module (AIVAG), responsible for computing actual direction and power to be distributed to the propulsion module, which translate such indications into a direct control of the propellers by distributing the electrical power to the motors.

FORTH scripting language: Although it is well known that open standards and open applications are far better than the closed ones, there is still very few cases of real open applications giving to the users the possibility of "reprogramming the program", which would extend to unpredictable fields the application itself. This is mostly the case for marine oriented application, where the high software development costs do not leave additional economic resources to add extensions needed to open the application to the end-users. In most cases, not opening the software packages is among the politics of the software companies, operating in a small, very competitive market. However, in the field of Earth Sciences and more specifically in Marine Science there is a long-standing tradition for developing open software packages with high performances. Interesting examples of such packages presently diffused worldwide and used by a large audience of scientists are the Generic Mapping Tool [10] for maps and spatial data processing, MB-System [11], for processing MBES data, Seismic Unix [12] for seismic data processing, and many others. The OpenSWAP project would fall on the track of such scientific tools, and was developed assuming that all scientific applications developed by academic institutions should be, if not Open Source, at least open, giving the opportunity to adapt their functionalities to the scientific issue to be addressed. In this respect, DUNVAG implements a FORTH scripting language that gives the full control on almost every aspects of the application. It is based on a FORTH-83 implementation made available on the public domain by John Walker (https://www.fourmilab.ch/atlast/) and has been ported to DUNVAG to have access to most of the variables and parameters of the DUNVAG application. For manual of the language please refer to the above given URL. The built-in FORTH language is interfaced with DUNVAG through the execution of predefined FORTH commands, a block diagram of the DUNVAG program is shown in Figure 6, along with the FORTH entry points. Several variables of DUNVAG and some useful functions are available for full controlling the vehicle. Supplementary Tables S4 and S5 include a list of FORTH functions and variables.

**Figure 6.** Block model of *DUNVAG*, the hearth of the system which implement autonomous navigation algorithms.

Since execution of the FORTH routines is placed inside the main loop, it is very important that each call to those routines will not block the normal flow for too long. For this reason, they will be interrupted after 2 ms. of CPU time. Examples of FORTH programming are given into a download area, which also includes additional contents. The reader could find into those examples, amongs<sup>t</sup> others, a definition that implements a virtual GPS through reading a file with lat, lon, pitch, roll, heading and speed values, allowing for a mission replay and/or simulation.

While the DUNVAG firmware is not ye<sup>t</sup> open source (it will be in the near future), the FORTH scripting capabilities opens up the SWAP autonomous class of vehicles to user extensions, hence the name OpenSWAP.

#### 3.3.2. The Embedded SBE/SBP Instruments

The block-diagram of Figure 5, shows how the SBE is implemented. It can be both integrated into the navigation board or available as a separate module, while the chirped SBP is available only as separate board. Both instruments are installed inside the water-proof central box, together with other electronics/sensors eventually added to the payload.

SBE and SBP follows the same design, based on a *Raspberry*™ PI driving an ArduinoDue® microcontroller. The ArduinoDue® is loaded with two small pieces of software, μEcho and μChirp, which use the microcontroller ADC (analog to digital) and DAC (digital to analog) ports, as well as some transmitting/receiving circuits/sensors, to emit and receive acoustic signals into the water in a given time-window. The Raspberry™ PI, on the others side, runs CIAPCIAP, the software responsible for geo-referencing the data coming from the ArduinoDue® and for its storing into the μSD installed card or into an external support (hard-disk). The SBE/SBP pair can work in parallel, leading for synchronous acquisition of stratigraphic and bathymetric data. It would be possible for example, to allow the two systems modify some acquisition parameters, such as pulse length, pulse frequency, acquisition time window, etc, based on analysis of incoming data, in an AI (artificial intelligence) scheme, relating their values to actual bottom depth or other different variable environment parameters.

μEcho/μChirp Both SBE and SBP systems, we name μEcho and μChirp, respectively, are based on an ArduinoDue® microcontroller, which emits analog signals through a DAC port sampled at a very high rate (<1 μs). This performance, together with the possibility of programming the microcontroller, allow for a complete control on the emitted signal, an important characteristic to optimize signal generation in relation to specific survey, and to optimize the deconvolution of the signal. All acquisition parameters are controlled by a set of commands sent to an USB port of the micro-controller, while a second port is used for data acquisition. The software module CIAPCIAP, running on a Raspberry™ PI, is responsible for managing consistently these two ports, to implement a synchronized data acquisition. Supplementary Table S6 and S7 include the entire set of commands along with a brief description.

The μChirp SBP uses as emitter transducers lightweight electromagnetic resonators directly applied to the catamaran hulls, that show interesting performances in shallow water environments, and are easily installed on the vehicle. The system is composed by: (1) a digital generator of frequency-modulated signals based on an ArduinoDue ® board; (2) a 600 W RMS power amplifier; (3) an array of waterproof magnetic resonators composed of four 4 Ω *MONACOR* transducers; (4) an acquisition system based on a hydrophone array, a signal amplifier, and an *ArduinoDue* ® board used as analog-to-digital-converter (ADC). A Raspberry ™ PI is employed to store the digital data in SEG-Y format [13] on a SD memory card.

The CIAPCIAP software module. CIAPCIAP runs on a Raspberry ™ PI and is interfaced with DUNVAG (Figure 5) through a serial port to gather current position and orientation from the navigation board. On the other side, it passes to DUNVAG additional parameters such, as NMEA sentences from a GPS eventually connected to the geophysical sensors. CIAPCIAP makes also possible to connect to itself through a Wi-Fi hotspot client, or to implement an internal hotspot eventually used by external clients. It is also able to open a channel between the Mission Control Software (see next section) and DUNVAG by means of an INTERNET connection, eventually opened through available mobile networks. In such a case, a ssh tunnel with an external sshd server can be opened, allowing for connecting to the INTERNET from virtually everywhere. The operating system chosen for CIAPCIAP is Linux ®, running from the installed μSD card in R/O (read only) mode for reliability reasons, and it is configurable by editing the files contained in the/boot/partitions (see Supplementary Table S8). The acquisition parameters are set by commands/parameters specified by the params, commands.echo and commands.chirp files, whose syntax is reported in the Supplementary Materials (Tables S6 and S7).

*CIAPCIAP* starts by reading the params file and subsequently opens the commands.echo or the commands.chirp files (the specified within params). It then sends all lines of the opened file to a proper USB port connected to the ArduinoDue ® which set the emission and the acquisition parameters of the transmit/receive cycles. Such parameters are those controlling the cycle, such as the acquisition time window, the emitted waveform shape and length, the emission rate etc. Supplementary Tables S6 and S7, and could be modified by the user. This is obtained by editing a "commands file" containing initialization parameters for both, emitter and receiver. Special commands such as "WAVEOUT:" or "CHIRP:" (they are equivalent) are sent to the emitting or receiving processes. A configuration command sequence should begin with the receiver (sampler) configuration, followed by the emitter configuration. Once a WAVEOUT:MKSIGNAL command is sent, the emitting process adds a waveform with current parameters to a waveform bu ffer, along with current sampling parameters, allowing for the creation of waveforms of di fferent length, duration and sweep. All waveforms are stored into an internal bu ffer and subsequently used to de-convolve the received signal. When the command WAVEOUT: GO is entered, the emission process starts, by generating the first available waveform since an emission timeout is reached. At this point, a second waveform (if present) could be generated, until the last waveform is reproduced. Then, the emission process starts again using the first available waveform. Synchronized with emission, the receiving procedure starts, digitally sampling the analog signal detected by the transducer/amplifier chain, according to parameters set for each configured waveform.

To start the whole emitting and receiving processes, the commands "WAVEOUT: GO" and "GO" should be entered in this order. After that, CIAPCIAP starts signal emission and the acquisition, and stops only if a "STOP" command and a "WAVEOUT: STOP" is sent.

An example of a commands file is given in Supplementary Tables S6 and S7, where a multi-chirp acquisition is activated with a start frequency of 24 Hz, and a 6 Hz frequency increasing every 4 generated waveforms. Each sweep generation is followed by data acquisition according to predefined acquisition parameters.

The acquisition process is not working separately by the other software modules. In fact, it is parallelized with several ancillary tasks dealing with: position and orientation updates (received from an external GPS and/or from the internal NAVBOARD); managing connection to a remote monitoring window; receiving commands from remote controlling applications; checking periodically whether an INTERNET connection is available. In this case, CIAPCIAP connects to a proprietary server (openswap.it) opening a bidirectional channel that allows for a remote telemetry from DUNVAG and a basic control of the vehicle. Further details on such functionality are given in the next session.

#### *3.4. OpenSWAPNav, the Mission Control Software*

The Mission Control Software, OpenSWAPNav (OSN), written in Java ®, was developed to allow for interactive route planning and vehicle remote control. It runs a small C++ [14] app, (SwapCONTROLLER) that communicates through a wireless long-range (433MHz) device with the vehicle, receives the telemetry at a rate of six times per seconds, and send to the vehicle a set user-command. It can receive inputs from the user by means of a joystick or through the user interface, easily allowing manual control of the vehicle. The choice to have a small app doing the basic jobs of communicating to and controlling the remote vehicle is due to the need of a quick start/restart control system in case of problems. The SwapCONTROLLER application allows to fully control the remote vehicle in manual or auto modes.

OSN is connected with SwapCONTROLLER through a socket, for vehicle telemetry and other information. This allows the user to easily edit the routes and send the waypoints to the vehicle. As seen previously, the vehicle needs that some configuration files are present into its μSD (CFG\_IMU.TXT, CFG\_IO.TXT, CFG\_IMU.TXT etc.), and OSN provides download and upload such files to the vehicle to update all parameters. OSN can communicate with the vehicle also through the *INTERNET* (if the vehicle is configured for the purpose), can receive telemetry also through such a connection from the vehicle and send to commands, such as the next point to reach or where to stop navigation, or even maintain the actual position. This is particularly useful when the vehicle exits the coverage of internal 433 MHz telemetry module.

A Screenshot of OSN and SwapCONTROLLER during a survey is shown in Figure 7.

**Figure 7.** Screenshots of OSN and SwapController (**inset**) during a survey. Planned lines are marked in white, while navigation performed is indicated by green lines.

#### **4. Performances of the Vehicles and Data Acquisition Examples**

Performances and functionalities of the OpenSWAP prototypes were tested in several environments, under di fferent weather and sea conditions, and di fferent instrument payloads. Below, we report some examples of data acquisitions carried out in areas not, or very di fficultly accessed by conventional surveys.

## *4.1. Navigation Accuracy*

The accuracy in following pre-determined paths was first tested in "controlled" environments, such as small lakes, ponds and easily accessible coastal areas. Figure 8 shows an example of navigation test carried out in shallow waters along the Emilia Romagna coast, were two runs over the same planned lines were carried out. It includes a statistical evaluation of the navigation performances, i.e., of the errors that occurred in the following predetermined routes, which indicates that almost 90% of the route waypoints are within 0.30 m of polar distance from those planned. In worst cases, repeatability of the planned paths is within a mean error of about 0.40–0.50 m, reaching up to ~0.10 m in the best-case scenarios (calm weather and sea conditions). The test reported in Figure 8 consisted of navigating along a 1 km straight line towards the o ffshore during two di fferent days. In this case, we used a double-antenna, double-frequency Trimble SPS461 GPS receiver, with an RTK cm accuracy. The mean error between the two path is 0.19 m, with a maximum over 99% of the points within 0.70 m.

**Figure 8.** Navigation performance test along a 1 km straight line. **Left**: screenshot of OSN with first (white) and second (red) navigation lines. **Right**: distribution of the error modules between the two paths.
