*4.6. RTPS*

PX4-Fast RTPS Bridge (or more commonly RTPS, more info at: https://dev.px4.io/ v1.11\_noredirect/en/middleware/micrortps.html , last access: 30 March 2022) is a communication protocol that adds a real-time publish–subscribe (RTPS) interface to the PX4 Autopilot system, enabling the exchange messages between the various internal PX4 Autopilot components and ROS2 applications in real-time.

#### **5. Emulation Results**

#### *5.1. Software-in-the-Loop Simulation*

This section describes the results obtained with software-in-the-loop (SITL) tests performed with the help of the experimental architecture introduced in Section 4. To test the proposed methodology under realistic conditions, particularly as concerns the motion of the landing pad, we proceeded as follows. We first recorded to a log file of the telemetry (GNSS position and attitude) of the ULISSE catamaran executing a rendezvous with the quadrotor. The catamaran was directed toward a point and then instructed to hold its position. To do so, the catamaran positioned itself against the estimated direction of the current. However, note that the effects of waves and the fact that the catamaran is nonholonomic still induced a small lateral drift.

Then, we replicated the movement of the catamaran from the log file within the Gazebo environment and carried out several simulations of the quadrotor landing on it. Notice that, as the heave motion is not measurable in the real ULISSE ASV, we generated simulated motions using the Pierson–Moskowitz spectrum. Three different log files replicating the behavior of the catamaran were used. Over than 30 simulations have been performed; due to the similarity of the data among the logs, the catamaran's behavior was replicated from the same log file for the majority of the tests. In a few of them, it happened that the quadrotor lost visual contact with the tags on the platform; in these cases, the quadrotor restarted the algorithm by resetting the state machine and approaching the landing pad again. Despite these setbacks, the quadrotor was able to land successfully on the platform in each simulation. For the sake of brevity, only the results of one simulations are reported hereafter.

Let us begin by comparing the roll and pitch references and estimated values in Figure 7a and Figure 7b, respectively. From the figures, we can notice when the biggest adjustments in terms of position occurred from 82 to 98 s, when the procedure started with the searching state. Indeed, in this simulation, the UAV did not find the platform at the rendezvous point. Thus, the "searching" state was entered and the quadrotor started to move around in circles. From 98 to 118 s, the quadrotor placed itself in the front of the landing platform, to prepare for the landing. After then, before the quadrotor landed, the generated references varied slightly, because the effort needed to keep the alignment with the landing platform was minor. At around *t* = 135 s, the quadrotor successfully landed on the platform.

**Figure 7.** Time-wise behavior of the desired and estimated roll (**a**) and pitch (**b**) of the UAV during the landing procedure.

The yaw reference was kept constant during the entire simulation, as it does not have a significant influence on the landing performance. Thus, its graph is omitted here.

The data about the positions of the quadrotor and the catamaran with respect to the starting point are depicted in Figure 8a,b. The first figure shows a bird's eye view on the *x* and *y* dimensions only, and the second includes all the axes. The circular movements generated by Equations (12) and (13) during the searching state can be seen in the interval (*x* ∈ [24, 26] m, *y* ∈ [8, 10] m). The instant where the radius changed was point 1 (*x* = 25.9 m, *y* = 8.9 m). In this test, the quadrotor had to perform just one complete circle before seeing the platform at the start of the second one. The initialization phase came afterwards, where the quadrotor had to perform some adjustments to place itself on the bow side of the catamaran. It can be seen how the references slightly changed in the following period: this happened because the catamaran was sliding a bit while trying to keep its position against the sea current. More precisely, in this test the catamaran drifted laterally at an average velocity of ∼0.21 m/s. In order to find the maximum slide velocity the catamaran can have without compromising the landing of the quadrotor, several landing tests were performed in simulations with increasing drift velocity. The results of these simulations show that the quadrotor is able to successfully land at a drift velocity of up to 0.35 m/s, approximately. In Figure 8b, it can aksi be seen how the altitude of the catamaran had oscillating behavior in the final steps of the landing procedure. In fact, the catamaran's heave movement is more affected by waves when it is not moving forwards. Still, the quadrotor managed to follow the catamaran for the entire period and accomplish the land at point 2 (*x* = 33.6 m, *y* = 10.1 m, *z* = 2.0 m), showing the robustness of the proposed solution.

**Figure 8.** (**a**) Bird's eye view of the trajectories of the UAV and of the ULISSE ASV during the simulation. 1 indicates the position at which the search radius changed, and 2 indicates where the final landing was accomplished. (**b**) A 3D representation.

Figure 9 shows how the *x* and *y* axis velocities are generated starting from the pose references. In detail, during the searching phase from 82 to 98 s, the sum of the velocity components is approximately constant, corresponding to the parameter *vs* in Equations (12) and (13). This is not true when the quadrotor changes its circle's radius, at 84 and 96 s. After that, the quadrotor makes visual contact with the landing platform; thus, the generated velocities are the ones needed to place the quadrotor appropriately for the landing.

**Figure 9.** Time-wise behavior of the UAV's *x* and *y* velocities and their setpoints during the whole landing procedure.

Figure 10a shows the quadrotor's performances on the *z*-axis. As the inertial frame is a NED (north–east–down) frame, the sign of *z* is negative. Note the step-change reference at around *t* = 118 s, stating the transition between the initialization and tracking state (Section 3.4.3) of the landing state machine. This brings the quadrotor to a prefixed minimum altitude from the landing platform, to trigger as soon as possible the switch to the compensation state. When the quadrotor is centered with respect to the landing platform and the Kalman filter taking data from the ultrasonic sensor gives reliable outputs, the state is switched to the compensation one, where the quadrotor compensates for the platform's vertical motions (see Section 3.4.7).

**Figure 10.** Time-wise behavior of the absolute *z* position and setpoint: (**a**) overall simulation; (**b**) a zoom of the compensation state. Notice that at *t* = 134 s, a high setpoint was generated to force the UAV to freefall on top of the landing pad.

Figure 10b shows a zoom of Figure 10a. The generated references change step by step, allowing the quadrotor to be as reactive as possible with respect to the platform's oscillations. The peak at around *t* = 134 s in Figure 10b shows the transition from the compensation to the landing state. At that time, the *z* reference is set to a value (20 m) well below the platform height above the sea, to force the UAV to set its motors to the minimum, making it free-fall directly onto the platform. Once the Autopilot's firmware, PX4, has detected the landing, it automatically shuts off the motors in a few moments.

Figure 11 depicts the velocity on the *z* inertial axis. The generated references show the correlation among the *z* position setpoints. A full video of the simulation is available online and can be seen at: https://youtu.be/hILq4kUn9XY last access: 30 March 2022.

**Figure 11.** Time-wise behavior of the UAV *z* velocity and its setpoint during the whole landing procedure.

#### *5.2. Vision System Validaton*

To validate the pose estimation algorithm, an experimental trial where the quadrotor was manually controlled was conducted, and the output of the UAV's camera was recorded at a resolution of 480p. Then, the video was replayed offline. Each frame was sent to the pose estimation algorithm. This experiment was not conceived to test the system under different lightning conditions. We selected a day with clear sky, as we wanted to test the material of the landing platform, which was selected to ensure a high level of opacity, to prevent light reflections on the markers. Note that in poor light conditions, for instance, during the evening, at night or on a cloudy day, the landing platform should be backlit to ensure reliable detection of the tags.

In the following, different images taken at various altitudes are presented, showing the detection performances of the proposed algorithm. In particular, the outputs of the pose estimation node, i.e., the detected nodes, are shown in magenta together with the tag identifier, on top of the same input image, to highlight the detection results.

Figure 12a depicts a situation where the distance bewtween quadrotor and catamaran is around 6–7 m, a case similar to the initialization phase. At that distance, in the best case, the detected tags are eight in number; the bigger tags play a fundamental role, offering reliability and robustness in the positioning of the quadrotor. The smaller ones are instead not recognizable yet. In Figure 12b, the quadrotor is landing on the catamaran. In a medium-distance case like this one, the number of tags detected is higher. In fact, the smaller ones become visible, except for the smallest one at the center, and some of the bigger ones can be out of camera range. Tag 11, on the upper-left corner, is a little outside of the image plane, and tag 12, in the lower-left corner, is obscured by the roll-bar's shadow. Finally, Figure 12c shows the instants before the landing; there, the bigger tags are almost all not visible, whereas the smallest ones come into play to keep the quadrotor centered with respect to landing platform.

**Figure 12.** Detected tags at various altitudes: (**a**) initialization phase, high altitude; (**b**) tracking phase, medium altitude; (**c**) compensation phase, low altitude. Each detected tag is highlighted in magenta together with the tag identifier in blue.

These last three graphs depict additional data from the vision system. In Figure 13a, the number of detected tags is shown, varying between 1 and 10 tags (corresponding to Figure 12b). It can be seen that the number of detected tags was always equal to or greater than one, assuring the continuity of the platform detection during the whole landing procedure, confirming the performances achieved in the simulation environment. The estimated horizontal (Figure 13b) and vertical (Figure 13c) errors with respect to the catamaran instead are pretty consistent with the quadrotor's flight. A video of this emulation is available at https://youtu.be/iGNDCoQ2zaY last access: 30 March 2022. A further comparison of the vision system's performance in the real test and in simulations has been performed in terms of marker detectability: it has been noticed that the smaller markers (IDs 6, 7, 8, 9) became visible when the relative distance of quadrotor–landing platform was approximately under 1.5 m both in simulations and in the real tests. Instead, the bigger ones (IDs 10, 11, 12, 13) could be detected at distances up to 9.0 m in the simulations.

**Figure 13.** Evolution during manual landing experiment of: (**a**) number of tags detected; (**b**) horizontal error; (**c**) vertical error.

#### **6. Conclusions**

In this work, a procedure for the autonomous landing of a quadrotor on a catamaran has been presented. The objective was to propose a specific, reliable, and robust architecture composed of different modules, adaptable to both simulations and tests in a real environment. A vision system relying on AprilTags has been proposed to recognize the landing platform; several tags have been placed on the platform itself to always assure recognizability during the entire procedure.

A finite state machine handles the landing procedure. It is composed of different states, each one describing a specific behavior the quadrotor has to engage.

The validity of the proposed methodology has been shown in a simulation environment. To test the landing procedure with realistic motions of the landing pad, the motion of the ULISSE ASV was recorded at sea and then replayed within the Gazebo environment. The proposed vision system was further verified using a pre-recorded video of a landing performed under direct teleoperation of the quadrotor.

**Author Contributions:** Conceptualization, A.D., M.B. and E.S.; methodology, A.D., M.B. and E.S.; software, A.D.; data curation, A.D.; writing—original draft preparation, A.D.; writing—review and editing, A.D., M.B. and E.S.; visualization, A.D.; supervision, M.B. and E.S.; funding acquisition, E.S. All authors have read and agreed to the published version of the manuscript.

**Funding:** This publication was made possible by NPRP grant 10-0213-170458 from the Qatar National Research Fund (a member of Qatar Foundation).

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Not applicable.

**Conflicts of Interest:** The authors declare no conflict of interest.
