## 2 Architecture of the Tethered Hexacopter System
### Navigational Equipment for Landing Pad Position Tracking
Additionally, an optional Wi-Fi connection was available to facilitate diagnostics and system performance testing. The UWB receiver was connected with the onboard computer via a USB. The ROS framework used to implement the positioning and navigational functionalities consisted of several components. A diagram of these components and their interactions is shown in Figure 6.  
The components can be briefly described as follows. The _maxlink bridge_ component forwarded the messages sent upstream from the LNS to the autopilot and extracted information about the base station's position and the desired UAV position from additional custom packets inserted into the stream. The bridge also forwarded downstream packets from the autopilot to the LNS and extracted the state information of the UAV. The state information, including the position estimate obtained through the _UWB_ component, was processed in the _state estimation_ component, where the precise position of the UAV with respect to the base station was calculated. The state estimate was further used by the _navigation and command_ component to compute the desired steering of the UAV. The additional _auxiliary communication_ component was also available to process diagnostic information and logging. Figure 5: Landing pad navigation station: 1—main computer; 2,3—GNSS modules with antennae; 4—electronic compass; 5—Wi-Fi router; 6—radio module. * Autopilot  
Although the autopilot directly controlled the flight of the UAV by managing its six motors, communication between the LNS and the UAV did not occur directly with the autopilot itself. Instead, the LNS computing unit communicated with the UAV's onboard computer. The onboard computer played a crucial role in integrating data from the positioning system and establishing communication with the autopilot. Essentially, the LNS station transmitted take-off and landing orders directly to the autopilot through the UAV's onboard computer. Meanwhile, the UAV's onboard computer was responsible for determining the tracking error between the UAV's actual position and the estimated position provided by the LNS. This information, including the estimated position and velocity from the LNS, was then relayed to the control loop of the autopilot. The autopilot that managed the drone's operation was the Pixhawk PX4 [30]. To regulate the altitude and heading of the UAV, the standard control algorithm implemented in the autopilot firmware was utilized. However, achieving control over the horizontal position (x, y) required making adjustments to the flight control code. In the standard PX4 multicopter control architecture, the setpoint velocity \(V_{sp}\) is determined based on the setpoint position \(X_{sp}=(x_{sp},y_{sp},z_{sp})\), as can be seen in Figure 7. This approach is suitable when the setpoint position does not change over time. In our scenario, the ferry's helipad was in constant horizontal motion, so the drone's setpoint position was also constantly changing over time. To remove the offset in the drone's position relative to the helipad, it was essential to also include in the control loop the velocity of the helipad. Therefore, the control loop for the horizontal motion of the drone took into account both the relative position error between the UAV and the LNS and the horizontal velocity of the landing pad. This was achieved by bypassing the _Position Control_ block for horizontal control, as shown in Figure 7.  
The altered control framework of the PX4 autopilot, with the relevant modifications highlighted in red and blue, is depicted in Figure 7. The key distinction from the original architecture was that the desired horizontal speed \(\bar{V}_{U_{D}}\) of the UAV was fed directly into the _Velocity Control_ block. Figure 6: Diagram of the onboard computer framework. Figure 7: Modified autopilot control architecture [31].