2. Problem statement

In justifying the scientific effort in designing a new integrated architecture for realistic simulation, one must consider the specific characteristics of a relevant application scenario that highlights the challenges of designing ASVs and navigation algorithms for adverse environmental conditions. As previously stated, the solutions proposed in this article are validated in a practical context related to autonomous navigation on the Madeira River in Rondônia-Brazil at the Santo Antônio hydroelectric plant facilities. Figure 1a shows a satellite image of the regions of interest, and Figure 1b shows a panoramic view.

Figure 1.

Views of Santo Antônio hydroelectric power plant facilities (https://goo.gl/maps/Q7n5RZpm7e2futZD7).

Such images, in a macro-level observation, show two initial challenges, highlighted below:

• • Navigation zone with large dimensions: In this case, it is not feasible to use conventional navigation strategies that do not foresee the optimization of energy resources and effective coverage area. Additionally, computational models, especially those related to graphical rendering, must be optimized.

• • Water turbidity: The natural condition of the navigation surface makes it difficult or even impossible to use conventional cameras, LiDAR, and even human operations for monitoring and moving traction vessels.

To further highlight this last issue, the point cloud produced by a Livox MID-70 LiDAR was acquired in two different environments, as illustrated in Figures 2a and 2b. It is possible to notice that the waters of the Madeira River reflect LiDAR rays as if they were a solid plane in an invisible region below the surface.

In this scenario, it is necessary to have a multisensory system composed of LiDAR and Sonar for the complete mapping of solid structures above and below the water level, directly implicating the onboard computational and energy requirements.

From the point of view of realistic simulation systems, this problem still needs to be solved when considering the large volume of data, synchronization demands, and sophistication of modern algorithms for processing point clouds, making adopting centralized structures unfeasible.

At a localized level, the Log Boom safety mechanism retains impurities in the river, protecting the dam and ensuring proper disposal to maintain the ecosystem balance [Reference Katsuno, de Castro and Dantas31]. Figure 2c shows a Log Boom full of impurities, and Figure 2d illustrates their removal by human intervention.

Figure 2.

Issues associated with data acquisition and the accumulation of impurities.

As can be seen, they are heterogeneous sediment made up of materials of different sizes that, when associated with local biodiversity, make direct human interventions unfeasible, requiring heavy machinery. This reality implies more operational costs, problems with logistical optimization for allocating personnel and equipment, and risks of disruption of the Log Boom, among other potential problems.

In case of Log Boom failure, a large volume of high-density waste may pass to the area in front of the dam, severely compromising the plant operation and producing consequences in the most varied regulatory instances of the plant operation. Figure 3a shows a multibeam sonar image illustrating the accumulation of woody and sedimentary material in the adduction zone, close to the dam grids, making it possible to attest to the application’s severity and, as expected, nothing can be seen from the surface (Figure 3b).

Figure 3.

Submerged impurities accumulated in the dam grids.

As can be seen, the amount of material accumulated in front of the grids considerably compromises the flow of water to the internal structures of the dam, which affects the production of a given generating unit, in addition to the risk of rupture of the protection grids that would lead to the damage on even larger scales.

Additionally, random wind gusts impacting specific objects, high-magnitude localized water currents, vortices, fog, and others can cause serious accidents. These issues can lead to operational instability and severe consequences for the surrounding community without costly financial measures.

The objects accumulated in the grid were transported by the current of the river, which has an irregular riverbed with considerably shallow sections, which further increases the challenges associated with navigation tasks. This reality justifies the adoption of air-propelled ASVs, capable of moving on the surface and carrying sensors to implement mapping and obstacle avoidance algorithms.

These particularities prevent the adoption of monolithic solutions composed only of a flight control unit or a computational structure. The above features highlight the need for high onboard computing power to implement sophisticated navigation algorithms not found in currently available autopilot systems. On the other hand, one needs more than a single processing node because when solving the software implementation problem, the hardware specifications will be a bottleneck, potentially harming the real-time requirements. Added to this is the unavailability of realistic simulation systems that combine the two previous scenarios.

Designing an embedded solution that satisfies all the requirements presented without the minimum security and performance guarantees is unfeasible. In this sense, a novel solution is proposed for simulating monitoring missions capable of supporting decisions by field teams in the more diverse aspects. Additionally, the new integrated architecture supports advanced simulation strategies. It validates the main requirements for semi-automatic inspection systems, optimizes human and machine resources, and enables new projects for monitoring systems, including automatic intervention in areas of interest.

3. Proposed architecture

A careful selection of consolidated tools is mandatory to provide the required conceptual, functional, and temporal verification requirements in the context of the target application. These tools should be capable of forming a cohesive entity at a high level, enabling effective evaluations of the efficiency and effectiveness of the solutions across all presented domains. In the following sections, we propose a generalist solution composed of at least five main elements, as illustrated in Figure 4. Following is a general overview of these elements:

Figure 4.

Generic view of the proposed architecture.

• • Driver: Functioning as a multilevel converter, it receives data at the transaction level and converts it to the signal level for subsequent elements. Such signals can be physical or logical stimuli and are provided by specific processing node $D$ .

• • System simulator: A 3D simulator equipped with an efficient physics engine and naturally distributed implementation, capable of meeting the interprocess communication requirements required for integration with other processing nodes, whether physically distributed or not. It is composed of processing nodes $PS1$ , $PS2$ , …, $PSn$ , members of a supernode $S$ .

• • A set of low-level tools: Consolidated solutions for instrumentation through strategies of low computational complexity, enabling complete operational security of associated robotic systems and equipped with computational facilities for integration. It is composed of processing nodes $LS$ , $LC$ , $LA$ , members of a supernode $L$ .

• • A set of high-level tools: Consolidated solutions for robotics instrumentation through strategies of high computational complexity, capable of extending the solution’s range of applications and endowed with computational facilities for integration. It is composed of processing nodes $HS$ , $HC$ , $HA$ , members of a supernode $H$ .

• • Monitor: As opposed to the driver, it converts data at the level of signals originating from the physical or logical elements of the architecture to data at the transaction level that produces high-level outputs for real or virtual users. It is composed of processing output node $M$ .

The proposed integrated architecture can be better formalized through a undirected graph, as illustrated in Figure 5.

Figure 5.

Graph generic representation of proposed architecture. For simplicity of representation, the intermediate edges are not labeled.

Formally, let $ \mathcal{G} = (\mathcal{N}, \mathcal{E}, W)$ be a graph where:

• • $ \mathcal{N}$ is the set of nodes and supernodes:

  (1) \begin{align} \mathcal{N} = \{D, S, L, H, M\}. \end{align}

• • $ \mathcal{E}$ is the set of edges. Each edge, denoted as $ e_{xy}$ , is defined for every ordered pair $ (x, y)$ where $ x$ and $ y$ are elements of $ \mathcal{N}$ , representing a connection from $ x$ to $ y$ :

  (2) \begin{align} \mathcal{E} = \{e_{xy} \mid (x, y) \in \mathcal{N} \times \mathcal{N}\}. \end{align}

• • The adjacency matrix $ A$ is defined as a $ \left |\mathcal{N}\right | \times \left |\mathcal{N}\right |$ matrix where each element $ a_{ij}$ is given by:

  (3) \begin{align} a_{ij} = \begin{cases} 1 & \text{if } e_{ij} \in \mathcal{E};\\ 0 & \text{otherwise}. \end{cases} \end{align}

• • $ W$ is the weight vector representing the weights of the vertices, where each vertex $ x \in \mathcal{N}$ has an associated weight $ w_x$ , representing the weight of vertex $ x$ , determined by the available physical resource:

  (4) \begin{align} W = \{w_D, w_S, w_L, w_H, w_M\}. \end{align}

Generally, we have the following representation:

(5) \begin{align} A = \begin{bmatrix} e_{DD_{1 \times 1}} & e_{DS_{1 \times n}} & e_{DL_{1 \times 3}} & e_{DH_{1 \times 3}} & e_{DM_{1 \times 1}} \\[3pt] e_{SD_{n \times 1}} & e_{SS_{n \times n}} & e_{SL_{n \times 3}} & e_{SH_{n \times 3}} & e_{SM_{n \times 1}} \\[3pt] e_{LD_{3 \times 1}} & e_{LS_{3 \times n}} & e_{LL_{3 \times 3}} & e_{LH_{3 \times 3}} & e_{LM_{3 \times 1}} \\[3pt] e_{HD_{3 \times 1}} & e_{HS_{3 \times 1}} & e_{HL_{3 \times 3}} & e_{HH_{3 \times 3}} & e_{HM_{3 \times 1}} \\[3pt] e_{MD_{1 \times 1}} & e_{MS_{1 \times n}} & e_{ML_{1 \times 3}} & e_{MH_{1 \times 3}} & e_{MM_{1 \times 1}} \\[3pt] \end{bmatrix}, \end{align}

with:

(6) \begin{align} e_{DD} = e_{DM} = e_{MD} = e_{MM};\end{align}

(7) \begin{align} e_{SS} & = \begin{bmatrix} e_{PS1PS1} & \ldots & e_{PS1PSn} \\[5pt] \vdots & \ddots & \vdots \\[5pt] e_{PSnPS1} & \ldots & e_{PSnPSn} \end{bmatrix}; \end{align}

(8) \begin{align} e_{LL} &= \begin{bmatrix} e_{LSLS} & e_{LSLC} & e_{LSLA} \\[5pt] e_{LCLS} & e_{LCLC} & e_{LCLA} \\[5pt] e_{LALS} & e_{LALC} & e_{LALA} \\[5pt] \end{bmatrix}; \end{align}

(9) \begin{align} e_{SD} &= \begin{bmatrix} e_{PS1D} & e_{PS2D} & \dots & e_{PSnD} \end{bmatrix}^{T}; \end{align}

(10) \begin{align} e_{DL} &= \begin{bmatrix} e_{DLS} & e_{DLC} & e_{DLA} \end{bmatrix};\end{align}

(11) \begin{align} e_{DH} &= \begin{bmatrix} e_{DHS} & e_{DHC} & e_{DHA} \end{bmatrix}; \end{align}

(12) \begin{align} e_{HH} &= \begin{bmatrix} e_{HSHS} & e_{HSHC} & e_{HSHA} \\[5pt] e_{HCHS} & e_{HCHC} & e_{HCHA} \\[5pt] e_{HAHS} & e_{HAHC} & e_{HAHA} \\[5pt] \end{bmatrix}; \end{align}

(13) \begin{align} e_{SL} &= \begin{bmatrix} e_{PS1LS} & e_{PS1LC} & e_{PS1LA} \\[5pt] e_{PS2LS} & e_{PS2LC} & e_{PS2LA} \\[5pt] \vdots & \vdots & \vdots \\[5pt] e_{PSnLS} & e_{PSnLC} & e_{PSnLA} \\[5pt] \end{bmatrix}; \end{align}

(14) \begin{align} e_{SH} &= \begin{bmatrix} e_{PS1HS} & e_{PS1HC} & e_{PS1HA} \\[5pt] e_{PS2HS} & e_{PS2HC} & e_{PS2HA} \\[5pt] \vdots & \vdots & \vdots \\[5pt] e_{PSnHS} & e_{PSnHC} & e_{PSnHA} \\[5pt] \end{bmatrix}; \end{align}

(15) \begin{align} e_{SM} &= \begin{bmatrix} e_{PS1M} & e_{PS2M} & \dots & e_{PSnM} \end{bmatrix}^{T}; \end{align}

(16) \begin{align} e_{LS} &= \begin{bmatrix} e_{LSPS1} & e_{LCPS1} & e_{LAPS1} \\[5pt] e_{LSPS2} & e_{LCPS2} & e_{LAPS2} \\[5pt] \vdots & \vdots & \vdots \\[5pt] e_{LSPSn} & e_{LCPSn} & e_{LAPSn} \\[5pt] \end{bmatrix}^{T}; \end{align}

(17) \begin{align} e_{LH} &= \begin{bmatrix} e_{LSHS} & e_{LSHC} & e_{LSHA} \\[5pt] e_{LCHS} & e_{LCHC} & e_{LCHA} \\[5pt] e_{LAHS} & e_{LAHC} & e_{LAHA} \\[5pt] \end{bmatrix}; \end{align}

(18) \begin{align} e_{LM} &= \begin{bmatrix} e_{LSM} & e_{LCM} & e_{LAM} \end{bmatrix}^{T}; \end{align}

(19) \begin{align} e_{HS} &= \begin{bmatrix} e_{HSPS1} & e_{HCPS1} & e_{HAPS1} \\[5pt] e_{HSPS2} & e_{HCPS2} & e_{HAPS2} \\[5pt] \vdots & \vdots & \vdots \\[5pt] e_{HSPSn} & e_{HCPSn} & e_{HAPSn} \\[5pt] \end{bmatrix}; \end{align}

(20) \begin{align} e_{HL} &= \begin{bmatrix} e_{HSLS} & e_{HSLC} & e_{HSLA} \\[5pt] e_{HCLS} & e_{HCLC} & e_{HCLA} \\[5pt] e_{HALS} & e_{HALC} & e_{HALA} \\[5pt] \end{bmatrix}; \end{align}

(21) \begin{align} e_{HM} &= \begin{bmatrix} e_{HSM} & e_{HCM} & e_{HAM}\end{bmatrix}^{T}. \end{align}

Note that, as this is an undirected graph, $a_{ij} = a_{ji}$ for all $ i \neq j$ . In a practical sense, many edges will be inexistent depending on the computational tools chosen and specific interconnections. To evaluate the degree of realism of the simulations about a given experimental setup, we present the following metrics:

• • Weighted Average Degree: Adaptation of the average degree concept to consider the physical characteristics of the processing node that implements a given resource. It is given as follows:

  (22) \begin{align} \overline{d}_w = \frac{\sum _{i=1}^n w_i (d_i - 1)}{n} \end{align}
  where:

  1. – $n = |\mathcal{N}|$ is the number of vertices of $\mathcal{G}$ .

  2. – $w_i \in \mathbb{R}^+$ is the weight of vertex $v_i \in \mathcal{N}$ .

  3. – $d_i = \sum _{j=1}^n a_{ij}$ is the degree of vertex $v_i$ .

• • Weighted Degree Realism Index (WDRI): Index for measuring the degree of realism of simulations. It is stated as follows:

  (23) \begin{align} \text{WDRI} = 1 - \left | \frac{\overline{d}_{w,\text{sim}} - \overline{d}_{w,\text{ref}}}{\overline{d}_{w,\text{ref}}} \right | \end{align}
  where $\overline{d}_{w,\text{sim}}$ is the weighted average degree of the actual simulation graph and $\overline{d}_{w,\text{ref}}$ is the weighted average degree of a reference application graph.

The value of WDRI ranges from 0 to 1, where:

• • $\text{WDRI} = 1$ indicates a perfect match between the simulated and reference graphs.

• • $\text{WDRI} = 0$ indicates the maximum discrepancy between the simulated and reference graphs.

For a case of complete interconnectivity and without weighting at the vertices, we have $\overline{d}_w,\text{real} = 8.0$ , which is the average degree of a complete graph with n vertices.

With this representation, we establish a formal mathematical object with consolidated tools to guide the main aspects of hardware and software, including in an applied high-performance computing context, essential for effective, realistic simulations and safe, practical implementations.

This proposal is application-agnostic and adaptable to various scenarios through modifications in hardware and software. This article consolidates solutions for designing autonomous robotic systems, aiming for complete integration. Our goal is to develop an architecture that meets specifications with minimal effort and technical training for operators. The specified modules are shown in Figure 6.

Figure 6.

Overiview of the proposed simulation system.

The justifications for specifying each of the individual modules are given as follows:

• • Gazebo [Reference Koenig and Howard32]: A solution for the 3D simulation of robotic systems already quite consolidated. Several plugins for sensors, actuators, hierarchical controllers, and heterogeneous environments (terrestrial, aquatic, and aerial) are available in open source for the academic and developer communities. Its fully distributed nature and implementation in C++ enables efficient integration with the many other elements, which are naturally supported.

• • ArduPilot [33]: Consolidated FCU software has a framework of reliable solutions for developing autopilots for diversified vehicles. It also has an implementation in C++, making it very attractive for developing low-level and embedded solutions, including support for elementary instrumentation and many typical devices, facilitating the portability work for real applications.

• • ROS [Reference Quigley, Conley, Gerkey, Faust, Foote, Leibs, Wheeler and Ng34]: A multilingual framework considered a de facto standard for developing robotic systems. It also has a distributed implementation and a wide range of high-level navigation solutions, including SLAM techniques, trajectory planning and control, and compatibility with libraries such as OpenCV and PCL, among other benefits that make it the ideal solution for this essential element of this proposal.

The distributed nature of these tools makes the integration process more straightforward. Figure. 7 shows the specific graph representation for this set of tools.

Figure 7.

Graph-specific representation of proposed architecture.

For this representation and considering a general usage of specified tools, we have the following adjacency matrix:

(24) \begin{align} A = \begin{bmatrix} 0 & 1 & 1 & 1 & 1 & 1 & 1 & 0 & 0 \\[5pt] 1 & 0 & 1 & 1 & 1 & 1 & 0 & 1 & 1 \\[5pt] 1 & 1 & 0 & 1 & 0 & 0 & 1 & 0 & 1 \\[5pt] 1 & 1 & 1 & 0 & 1 & 1 & 0 & 0 & 1 \\[5pt] 1 & 1 & 0 & 1 & 0 & 0 & 0 & 0 & 1 \\[5pt] 1 & 1 & 0 & 1 & 0 & 0 & 1 & 0 & 1 \\[5pt] 1 & 0 & 1 & 0 & 0 & 1 & 0 & 1 & 1 \\[5pt] 0 & 1 & 0 & 0 & 0 & 0 & 1 & 0 & 1 \\[5pt] 0 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 0 \\[5pt] \end{bmatrix}. \end{align}

In this case, the weight vector is given by:

(25) \begin{align} W = \{ 1, 0.5, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0 \}. \end{align}

In this case, we have $\overline{d}_w,\text{sim}=4$ , resulting in a WDRI of 0.5. We use this WDRI value as a weighting factor for the vertices, aiming to reflect this quantity in the evaluations. Specifically, the weight $ w_x$ is set to 1 for real and 0.5 for virtual resources.

As a simple example, let us consider a simple SITL approach:

• • Only one simulator exists, implying there are no other simulators $ PS_{i}$ in set $ S$ for any $ i \neq 1$ : $ \exists PS_1 \in S \quad \text{and} \quad \forall i \neq 1, \, \nexists PS_i \in S$ .

• • No high-level resources, implying there are neither $ HC$ nor $ HC$ nor $ HA$ in set $ H$ : $\nexists HS \in H \text{and}\ \nexists HC \in H\ \text{and}\ \nexists HA \in H$ .

• • Neither Driver nor Monitor: $ \nexists D \in \mathcal{N} \quad \text{and} \quad \nexists M \in \mathcal{N}$ ;

• • $\overline{d}_w,\text{ref} = 4$

• • W = $\{ 0, 0.5, 0.5, 0.5, 0.5, 0, 0, 0, 0 \}$

In this case, we have the following adjacency matrix:

(26) \begin{align} A = \begin{bmatrix} 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\[5pt] 0 & 0 & 1 & 1 & 1 & 0 & 0 & 0 & 0 \\[5pt] 0 & 1 & 0 & 1 & 1 & 0 & 0 & 0 & 0 \\[5pt] 0 & 1 & 1 & 0 & 1 & 0 & 0 & 0 & 0 \\[5pt] 0 & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 0 \\[5pt] 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\[5pt] 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\[5pt] 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\[5pt] 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\[5pt] \end{bmatrix}, \end{align}

which gives $\overline{d}_w,\text{sim} = 1.0$ and WDRI = 0.25. This quantity provides a good indication of the realism of the simulation and is helpful to support field teams’ decisions.

Regarding specified tools, we illustrate the proposed architecture in Figure 8, emphasizing its specific support for multiple technologies in a realistic simulation. Subsequently, we highlight the main elements that enable the application of various simulation methodologies, thereby clarifying the primary contribution of this proposal:

• • Ardupilot_plugin: Adaptations in the source code of the ArduPilotPlugin source codeFootnote ¹ for intercommunication between Gazebo and ArduPilot. Initially developed for standardized SITL simulations in ArduPilot itself, this plugin was modified to include passing messages from the Gazebo sensors to the interface with ArduPilot and enabling the implementation of HITL strategies.

• • gazebo_ros_plugins: Codes for intercommunication between ROS and Gazebo. Essential communication elements are provided natively. Other specific elements, for example, for implementing low-level controllers, can be found in free repositories maintained by the software maintainer itself.Footnote ²

• • Mavlink: Low computational cost communication protocol developed for micro-aerial vehicles. MAVLink follows a hybrid publish/subscribe and point-to-point communication pattern. It is responsible for communicating with the ground control station (GCS) and receiving ArduPilot commands sent by ROS. We created custom messages to transmit data from the sensors in Gazebo to ArduPilot.

• • MAVROS: ROS package that provides a communication driver for several FCU software supported by MAVLink. Additionally, it provides a User Datagram Protocol (UDP) bridge between MAVLink and GCSs. We created custom ROS messages to transmit data from the sensors in Gazebo to ArduPilot.

• • QGroundControl (QGC): GCS responsible for implementing a supervisory system that allows the user to interface safely and reliably with the vehicle.

• • Human: A human operator is responsible for monitoring and defining, in the first instance, the objectives of the navigation and exploration missions in the environment of interest. This human operator is crucial in implementing HuITL techniques in dataset generation, deep network training, and real-time application.

• • secure_mission: Codes responsible for implementing the computational intelligence elements of the architecture. It will comprise processing nodes for identifying and avoiding obstacles in the navigation route, regardless of the current missions.

• • joy: Device for receiving radio control signals issued by the operator.

Figure 8.

Simulation system architecture.

To support XITL simulations, specifically to enable the application of Model, Software, Hardware, Human, and other schemes, we propose the integrative and modular paths highlighted by dashed lines in Figure 8. In this case, it highlighted only the essential elements for implementing a specific version of the simulation system, making it possible to use a superior layer for generating stimuli and high-level outputs required in an application scenario, not necessarily equal to the one presented in the present case study.

In the case of the HITL simulation, any autopilot board supported by ArduPilot and any embedded hardware with computational capability to run ROS could be used. The next section presents the hardware resources used to validate this proposal. Before, it is necessary to define the specific elements of the current case study, which involves navigation of ASVs in dynamic and unstructured environments, which includes a customized vessel and the structure of the environment in the proposed system, according to the following subsections.

Once the elements for each simulation modality are defined, it is possible to obtain new adjacency matrices and proceed with relevant studies of computational complexity and intercommunicaion technologies to, among other tasks, allocate the necessary hardware resources.

The choice of software elements is a design decision, with the only requirement being that they are distributed solutions with facilities for interprocess communication.

3.1. ASV and embedded sensors simulation

To meet the hydrodynamic requirements on water surfaces subject to submerged and floating obstacles, in addition to having the capacity to incorporate computational devices at different scales, a conceptual model of ASV with air propulsion was developed, as illustrated in Figure 9a. A scale version (1/3) was built and will be used to validate in practice the proposed novel architecture. Figure 9b shows this version.

Figure 9.

ASV conceptual model and its built scale version.

This development builds on legacy solutions for air-powered surface vehicles as detailed in and [Reference da Silva, de Mello Honório, dos Santos, dos Santos Neto, Cruz, Matos and Westin35] and [Reference Regina, Honório, Pancoti, Silva, Santos, Lopes, Neto and Westin36]. As can be seen, this is a customized vehicle to meet the specific demands of the navigation environment, such as the profile of the hulls and propellers and a waterproof compartment for the onboard electronics. In addition to the constructive specifications, this vessel was sized to contain the processing nodes dedicated to implementing low- and high-level navigation strategies and various sensors such as GPS, Sonars, LiDARs, and Cameras.

With the STL model of the conceptual vessel, after conversion to the DAE extension, directly supported by the computational tools specified above and the meeting of the initial construction parameters (geometry and inertia), a Gazebo model was built in SDF and URDF formats, enabling the individual use of the elements specified in Figure 10a illustrates the real size version of the simulated ASV and Figure 10b the scaled version.

Several plugins are specified to provide the realistic character in the simulations with this vessel, available in open source for the Gazebo simulator. Table I illustrates the main plugins used to implement the requested functionalities.

Table I.

Main plugins used in the simulated vessel¹.

$^1$ Available at: https://github.com/PX4/PX4-SITL_gazebo-classic.

To promote the required degree of realism, the collision models of these vessels were kept identical to the original 3D meshes in both cases, scaled or not. This choice does not compromise the computational performance of the simulations, given the large environmental dimensions and the high-definition graphic elements that make up the buildings to be detailed below.

Figure 10.

ASV conceptual model and its built scale version.

3.2. Enviroment modeling

The simulated environment needs to efficiently reproduce natural aspects of the application in the most varied contexts. For this, the use of 3D modeling tools and high-precision plugins, which take environmental imperfections into account, is mandatory. Figure 11 illustrates a representative flowchart of the main tools for building a realistic simulation environment.

Figure 11.

Main tools used for modeling the environment.

Google Maps generate an approximate 3D model for the margins and buildings, and after dimensional compliance through floor plans in Autocad, Blender generates the meshes of buildings and Log Boom. Figure 12 illustrates perspective views of the natural and simulated environment in the Gazebo software before including water models. Critical structural elements were contemplated, such as, for example, the dam grids and thresholds for the water intake, a critical visual monitoring point.

Figure 12.

Views of the real and simulated dam.

As highlighted for the choice of the main elements of the integrated architecture, the choice of software for building the environment is the free choice of the designer.

It is worth mentioning that, due to the actual dimensions of the installations in this part of the plant, to maintain the computational cost for the execution of the system, the collision models were simplified by simple geometric shapes. Another structure that must be modeled very accurately is the Log Boom so that there are the capabilities to interact with impurities typical of the monitoring zone in the actual application. Figure 13a illustrates a Section of Real Log Boom line and 13b detail of the developed Log Boom line model. Visual aspects are realistic and can promote the necessary feedback for the monitoring missions to be specified.

Figure 13.

Views of the real and simulated Log Boom.

For hydrodynamic, we specify libgazebo_usv_dynamics_plugin plugin,Footnote ³ which is capable of including several hydrodynamic parameters, as illustrated in Table II, which also provides the values adopted in the initial version of the simulation system. The visual aspects and interaction with surface undulations were implemented through adaptations in the ocean_waves modelFootnote ⁴ to include the particularities of the application, after gathering various information obtained in the field.

Table II.

Libgazebo_usv_dynamics_plugin plugin parametrization.

Other fundamental element contemplated in the simulation environment are the dynamic obstacles, which have particular aspects of buoyancy, flow in the river toward the dam. Table III brings together the main obstacles modeled in the initial versions of the system. The geometric, dynamic, and visual aspects of these obstacles can be modified at compile time directly in the SDF files so that it is possible to consider the generalities present in the natural navigation environment.

Table III.

Main objects modeled in the simulation system.

The developed solution allows the dynamic launch of obstacles in simulation time through ROS packages. In this way, the integrative capacity of this software is taken advantage of to validate the architecture in the most rigorous evaluation scenarios. After including all the elements listed in this subsection, the environment is shown in Figure 14.

Some other plugins were adapted from the above sources to contemplate natural phenomena typical of the present application, such as the simulation of water currents through forces and torque directly on the vehicle, additional buoyancy effects, and the simulation of random wind gusts. Thus, the developed environment allows the inclusion of seasonal climatic aspects in the simulation system, which is especially important in the proposal evaluation scenario.

Figure 14.

View of the simulation environment in the Gazebo software.