High-Level Modular Autopilot Solution for Fast Prototyping of Unmanned Aerial Systems

Received November 24, 2020, accepted December 1, 2020, date of publication December 11, 2020, date of current version December 28, 2020. Digital Object Identifier 10.1109/ACCESS.2020.3044098 High-Level Modular Autopilot Solution for Fast Prototyping of Unmanned Aerial Systems CARLOS RODRÍGUEZ DE COS , (Member, IEEE), MANUEL J. FERNANDEZ, PEDRO J. SANCHEZ-CUEVAS , (Member, IEEE), JOSÉ ÁNGEL ACOSTA , AND ANIBAL OLLERO , (Fellow, IEEE) GRVC Robotics Laboratory, Universidad de Sevilla, 41092 Sevilla, Spain Corresponding author: Carlos Rodríguez de Cos ([email protected]) This work was supported in part by the HYFLIERS and AERIAL-CORE projects of the EU Horizon 2020 programme under Grant 779411 and Grant 871479, and in part by the ARM-EXTEND project of the Spanish Ministerio de Economía, Industria y Competitividad, under Grant DPI2017-89790-R. The work of Carlos Rodríguez de Cos and Pedro J. Sanchez-Cuevas was supported by the V Plan Propio de Investigación (VPPI) of Universidad de Sevilla and the Spanish Ministerio de Educación, Cultura y Deporte Formación de Profesorado Universitario (FPU) programme. ABSTRACT A redundant fast prototyping autopilot solution for unmanned aerial systems has been developed and successfully tested outdoors. While its low-level backbone is executed in a Raspberry PiR 3+ NAVIO2R with a backup autopilot, the computational power of an IntelR NUC mini-computer is employed to implement complex functionalities directly in SimulinkR , thus including in-flight debugging, tuning and monitoring. Altogether, the presented tool provides a flexible and user-friendly high-level environment with enhanced computational capabilities, which drastically reduces the prototyping timespans of complex algorithms –between 50% and 75%, according to our long and proven experience in aerial robotics–, while preventing incidents thanks to its redundant design with a human-in-the-loop pilot on the reliable PX4. Three typical outdoor cases are carried out for validation in real-life scenarios, all mounted in a DJI c F550 platform. Full integration results and telemetry for more than 50 hours of outdoor flight tests are provided. INDEX TERMS Unmanned autonomous systems (UASs), aerospace systems and applications, applications (robotics), middleware, redundancy, PX4, fast prototyping. I. INTRODUCTION The increasing complexity of new applications for small Unmanned Aerial Systems (UAS) is demanding autopilots with higher computational power and, more importantly, faster prototyping timespans. The novel branch of Aerial Robotics is pushing forward in this direction, mainly due to its broad range of applications, such as contact inspection, maintenance, and assembling at inaccessible and/or dangerous places. For a detailed literature review on this emerging area, we refer interested readers to cutting-edge projects [1]–[3] and its ongoing follow-up in [4] (see survey papers [5], [6]), the overview of aerial manipulation in [7], the applications with multi-joint manipulators in [8], [9], [10] and [11], the self-coordinated approach in [12] and [13], and to the ad-hoc autopilot in [14]. In particular, in [2] we challenged ourselves to complete complex missions outdoors, being the inter-consortium integration and code The associate editor coordinating the review of this manuscript and approving it for publication was Cong Pu . customisation difficulties found while implementing new complex algorithms the main motivation of this work. To cope with these obstacles, most of the aerial platforms depend whether on autopilots based on open-source software compiled in target computer boards (e.g. PX4 in [15], [16]), or on ad-hoc solutions made by research groups to fulfil their needs, e.g. in [17]. Thus, advances in these complex functionalities are implemented either modifying the open-source code to specifically implement new challenging guidance and/or control strategies, as in [18] for Model Predictive Control (MPC) or in [19] for backstepping sliding mode control (SMC), or for general purpose applications, as in [20], [21] and [22]; or linking it with previously built software, as in the multi-layer approach in [23], the model-based design and validation in [24] or the architecture for a nonlinear controller in [25]. Although these open autopilot options provide a wide range of well-polished features that are sufficient in most outdoor1cases, their thorough internal integration 1Applications including wired appliances to support computations offboard –as e.g. [26], [27]– are omitted due to the outdoor and autonomous nature of our design, i.e. with a completely onboard implementation system. VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ 223827 C. R. de Cos et al.: High-Level Modular Autopilot Solution for Fast Prototyping of UASs distorts the project schedules by expanding the time devoted to the customisation of source code. To illustrate this point, a comparison between widely used autopilots for UAVs2and the proposed Modular Autopilot Solution MASPX4is shown in Table 1. It is worth noting that this study is based on the deep knowledge acquired by our research group after more than 50 aerial projects along the last 10 years, allowing us to identify common drawbacks in the early stages of prototyping of these autopilot solutions: •The implementation of customised functionalities generally demands offline ad-hoc modifications of the native source code, resulting in longer debugging times during the integration stages. •The implementation of complex algorithms is not possible in the existing computer boards, mainly due to the lack of computational power and/or to their closed nature, which, in turn, might compromise their feasibility. Even though the prolongation of the timespans by the former could be tolerated on paper, the solution commonly given to adhere to the project deadlines when it occurs is to limit the extension of the advances in complex functionalities. In contrast, we found the latter a hard constraint while executing dexterous manipulation tasks in the onboard computer in [2], mainly due to the coverage of localisation, vision, flight control and manipulation subtasks. Altogether it ends up forcing a trade-off that downgrades the implementation, and hence, the overall performance. To overcome these limitations, the main contributions of the MASPX4 autopilot solution are: C1. Drastic reduction of programming and debugging times. The full use of the user-friendly and highly modular SimulinkR [35] environment expedites the software development and implementation of complex algorithms. C2. High-level in-flight code debugging, tuning and monitoring, while preserving the autopilot redundancy for unexpected incidents and/or learning capabilities. C3. Enough computational power to implement and execute heavy and complex algorithms onboard, with no need for downgrading the implementation. C4. Nonetheless, selected functionalities of PX4 can be kept running, thus providing a step-by-step way to implement fast-prototyping functionalities as desired. For instance, here we keep the EKF estimator and the motor mixer and modify the planning and control core algorithms. Remark 1: We underscore that the fast prototyping potential relies on two novel specifications. First, the mainframe Simulink R environment whose modularity and fast integration capabilities are widely known, facilitating the external validation and/or cooperation between research groups. Secondly, to the best of the authors’ knowledge, MASPX4 is the 2Only solutions validated in flight are considered, thus excluding general purpose and/or educational approaches, such as [28]–[34]. In any case, the only redundant alternative is MASPX4. TABLE 1. Comparison between MASPX4 and alternative autopilots. first autopilot with in-flight human-in-the-loop redundancy and debug capabilities, drastically reducing the implementation and tuning times. Remark 2: It is also worth highlighting the flexibility of the MASPX4 framework in terms of computational capabilities. In here, we have proposed a particular hardware solution with an Intel R NUC computer board, but it could be replaced by others. For example, sooner than later the All Up Weight (AUW) is expected to be reduced, as it evinces the arrival of lighter computers, such as [37] or the recent release [38] with an NPU of 5 TOPS.3 The paper is structured as follows: Section II describes the hardware and software architectures as well as a thorough description of the autopilot low-level implementation, and Section III is devoted to the experimental validation in three separate cases of study. Finally, the paper is wrapped up with a conclusion section. II. AUTOPILOT ARCHITECTURE As aforementioned, the main goal of the proposed architecture is to obtain a safe autopilot that facilitates the fastprototyping implementation of complex algorithms onboard, thus overcoming the previously presented limitations and allowing their full experimental demonstration. This is achieved by making a reliable environment that integrates: i) the customised algorithms in SimulinkR –more complex and optimised over a wider range of conditions–; and ii) the flight stack PX4 (see [15], [16]) –simpler, more reliable, and well-known for having been used for more than 10 years in the majority of our prototypes of different projects–. A detailed discussion of similar types of software 3TOPS stands for Tera Operations Per Second. 223828 VOLUME 8, 2020 C. R. de Cos et al.: High-Level Modular Autopilot Solution for Fast Prototyping of UASs FIGURE 1. Validation platform in flight with the hardware solution used as an exploded detail view highlighting the setup. FIGURE 2. Redundant MASPX4 solution as a schematic diagram (similar to a transit map) with the modifications in aquamarine bypassing the backup PX4 autopilot in purple via the operator switch in orange. architectures in commercial flight control systems is provided in [39], of course despite the apparent differences. The actual hardware implementation of this solution is shown in Fig. 1and a sketch of its global software functionality –highlighting the backup and bypass lines– is depicted in Fig. 2. In particular, the proposed solution is implemented with custom daemon modules, located after the state estimator and before the motor mixer4: i) the PX4 ecl/EKF state estimation is sent to the customisation environment, making use of the current reliable estimator, which is not the focus of this work; and ii) both redundant controllers, i.e. the cascade-like of PX4 and the customised one, join at the command switch (RC Switch in Figs. 2and 3). In this second point, the roles of the two agents involved in the experimentation phase come into action. On the one hand, the ground operator, an expert engineer involved in the development of the algorithm being validated, confirms the correct behaviour of the new functionalities. On the other hand, the backup pilot (or pilot in command) is in charge of guaranteeing the safety conditions of aircraft during the flight. If during their task, this pilot detects any risk in the experiment, they would trigger the backup switch, bypassing the prototyped algorithm to the backup PX4 controller. It is worth noting that the latter has been previously tested and tuned to be used as a safe reliable controller. 4This PX4 version is available at https://github.com/grvcTeam/MASp. FIGURE 3. Architecture for MASPX4, with both human agents included in the ground systems and highlighting the RC switch. A. HARDWARE ARCHITECTURE The hardware implementation –schematically depicted in Fig. 3– consists of a Raspberry PiR 3 [40] equipped with a NAVIO2R as carrier [41], used for both the backup controller and the state estimation; and an IntelR NUC [42] as the main computer. In this approach, the Raspberry PiR 3 is adopted as the interface board and delegated the backup autopilot, and the IntelR NUC is dedicated to implementing customised algorithms directly on SimulinkR modules (e.g. control, planning or navigation), maximising the computational capacity. All of these make the autopilot modular, customisable and safe, due to the redundancy master backup switch. Remark 3: It is important to highlight that those modules do not need to be compatible with the Simulink R external mode, thus guaranteeing broader compatibility in normal mode and full functionality. Additionally, accelerator mode can be used if needed, with its implicit limitations (see Appendix A). For the sake of completeness, a comparison with other environments is in order. On the one hand, the proposed autopilot has in common with the Dronecode ecosystem [43] –which includes PX4– the possibility of using the hardware Raspberry PiR 3+NAVIO2R  . However, none of the projects fostered by Dronecode employs an external computer board for the implementation of complex algorithms. Additionally, the ROS capabilities could be enabled through MAVLink/MAVROS (see [36]) –as in Dronecode– or via the ROS toolbox in SimulinkR , and hence, both providing full connectivity. On the other hand, the proposed autopilot significantly improves the technical specifications of another VOLUME 8, 2020 223829 C. R. de Cos et al.: High-Level Modular Autopilot Solution for Fast Prototyping of UASs TABLE 2. UDP connection results from both sides (25 MB packages). common solution, Pixhawk [44], which is known for being only valid in simple and slow tasks —due to its PID implementation and sample frequency—, and for not supporting Ethernet communications, unlike the proposed approach. Additionally, it is also worth mentioning ROSflight [45], a recently appeared board with which the MASPX4 environment concurs on some characteristics. Both share, for instance, the implementation of new algorithms on a companion computer board, and their sensor and actuator interfaces are similar to our Raspberry PiR 3+ NAVIO2R approach. Nonetheless, although ROSflight also focuses on easing the development stages –in particular the low-level coding–, it is based on ROS; while in MASPX4, this feature is optional and the prototyping interface is the user-friendly graphical interface SimulinkR . Additionally, MASPX4 includes redundancy with the mature PX4 backup, thus offering the possibility of progressively implementing custom functionalities safely. Moving back to MASPX4, it is worth noting that a trade-off between the computational power and the endurance has to be a priori decided, as usual in electrically-powered UAS applications. As commented in Remark 2, for lower computational missions, the external board IntelR NUC can be replaced by any other that reduces the AUW of the benchmark platform (3.2 Kg), and improves its endurance (about 8 min). B. SOFTWARE INTEGRATION The core of this reliable implementation is the integration of PX4 with the prototyping environment. A thorough analysis is therefore dedicated to the internal UDP communications,5 which over a robust Ethernet communication form the sinequa-non condition for the reliability of the whole solution. On the one hand, the quality of the Ethernet UDP connection is studied in terms of bandwidth, jitter and lost datagrams in a 20 seconds experiment with overestimated6packages (25 MB) using iPerf [46]. This tool calculates jitter as the difference between the receiving and sending times –via a timestamp added to the package sent by the client–, correcting any discrepancy due to the lack of clock synchronisation. The results are then collected in Table 2, confirming that no datagrams were lost during the test and that a bandwidth of 1 Mb/s is more than enough for the application. In what 5For the sake of completeness, the pseudocode for the UDP modules is shown as an appendix. 6This assures the possibility of future scalability. FIGURE 4. Time ratio for 20 tests of 8 seconds, on normal and accelerator modes, in an Intel R NUC 5i7RYH, where the solid lines correspond to mean values and the error bars to most distant value of these tests. respects to the jitter, it should be highlighted that, although the package congestion in UDP protocols is lower than in TCP, this fluctuation could also have an impact on UDP applications. Nonetheless, the provided results evince that the jitter in the proposed solution is negligible. On the other hand, a preliminary study on the Round Trip Time (RTT) –that includes the communication and the customised code execution– is also conducted. For that purpose, the time between a simple RC command is given and its impact on the controller output is measured.7As a result, we obtain a mean RTT estimation of 1235 µ s using the controller in Subsection III-A. In comparison, the PX4 output runs at 250Hz (4000 µ s), being the RTT of this application below this sample time. Nonetheless, the influence of the complexity of the customised algorithm on the execution times should also be studied to complete this analysis. This is done in part in Subsection II-C but more specifically in the load test for a computational-demanding implementation in Fig. 8, showing that the computational capabilities of the solution are well above the current demands. Accordingly, we can conclude that an increase in the complexity of the algorithms implemented can be compensated by the computational power margins of the proposed environment. Considering this, the RTT is not being significantly affected. C. SIMULATION VERSUS REAL-TIME OVERSAMPLING The proposed solution is designed to use the full potential of the SimulinkR environment (i.e. avoiding incompatibilities), and to reduce the simulation-to-experimentation times at the expense of real-time. This results in two phenomena: timevariant random disturbances and high-frequency spurious signals. To study both of them, let us define the time ratio TR as the rate between the clock time according to the simulation records and its real value according to the PX4 board clock.8 A thorough batch of experimental tests was carried out and, 7Without passing by the EKF estimator, being considered the contributions of this step to the RTT negligible for this analysis. 8Notice that the implementation of explicit time-variant terms, such as integrals, will need the corresponding correction with this time ratio. 223830 VOLUME 8, 2020 C. R. de Cos et al.: High-Level Modular Autopilot Solution for Fast Prototyping of UASs FIGURE 5. MASPX4 customisation environment including the standard Simulink R communication modules (upper) with a detailed view of the main module, highlighting the position (A) and attitude (B) controllers, together with the navigation module and the flight modes (lower). as shown in Fig. 4, the TR is only altered during short initial transients of about 2 seconds, thus being assimilable to the time convergence of the ecl/EKF estimator in PX4. Consequently, this time ratio can be considered constant in the design of custom algorithms (but being recommended to recalculate its value after significant changes in the complexity of the algorithms to re-adjust time-varying terms). Moreover, the potential problems that may arise for highfrequency residual signals were also analysed in depth. The experimental tests evince that in all cases those spurious signals were completely filtered by the propulsion system dynamics and other common UAS filters, as well as for the 200-250Hz sampling rate limitation of the PX4 motor mixer uORB. In summary, no incidents were detected in more than 50 hours of flight, and therefore the influence of signal oversampling is considered negligible in UAS applications. III. EXPERIMENTAL VALIDATION (EV) The validation of the autopilot is demonstrated through three typical implementation cases, thus providing a general overview of its possibilities in real-life scenarios, and showing the friendly fast-prototyping implementation of simple and complex algorithms. These experiments, in which a standard DJI c F550 frame [47] (see Fig. 1) is selected as the platform to mount the autopilot, are: EV1. The progressive development of a cascade PID controller mimetic to the controller in PX4, to illustrate the redundancy and reliability of MASPX4 and to serve as an example of the implementation of a complete strategy. EV2. A complex nonlinear control algorithm without any simplification, to reveal the computational capabilities of the autopilot as well as to demonstrate its feasibility for more complex implementations. Additionally, since the algorithm runs in faster-than-real-time, its implementation stability is analysed. EV3. A navigation module, to illustrate the wide range of possibilities MASPX4 offers for fast prototyping apart from control (not be confounded with a final evaluation). Accordingly, the controller chosen to run underneath this module is the cascade PID in EV1, thus assuring that those researchers not mainly interested in control can implement their modules without getting discouraged by the complexity and lack of intuitiveness of the controller. The procedure followed to implement these cases –thought to avoid incidents while changing the core algorithms– is also worth mentioning. Firstly, the basic functionalities of an initial solution in SimulinkR progressively replace their homologous in PX4, testing these changes in a confined scenario with the platform suspending from a structure. When all these basic changes are checked, the limitations of the scenario are relaxed by removing the suspension of the platform, thus allowing a realistic evaluation of the novel functionalities. Finally, the obtained control strategy is demonstrated in a non-confined scenario equivalent to a fully autonomous flight outdoors, testing the higher-level capabilities. As a result, a reliable complete solution directly evolving from a simulation-based development is obtained. To ease understanding of the implementation of the algorithms for EV1-EV3, in Fig. 5we show the general modular structure of the SimulinkR environment. This includes the inputs and outputs and the position (A) and attitude (B) subsystems, whose contents will be detailed in each experiment. A. EV1: SIMPLE PID CONTROLLER MODULE A standard PID cascade controller is implemented by progressively replacing parts of its PX4 counterpart and tuning them from the inner to the outer loop, as follows: i) Attitude rates; ii) Attitude; iii) Altitude; iv) Cartesian speed; and, finally, v) Cartesian position, resulting in a semi-autonomous controller. As previously mentioned, this cascade controller VOLUME 8, 2020 223831 C. R. de Cos et al.: High-Level Modular Autopilot Solution for Fast Prototyping of UASs is intended to be mimetic to the native controller in PX4, but implemented in SimulinkR using the IntelR NUC. This is used both to validate the customisation environment and to illustrate the redundancy capabilities of the solution. In Fig. 6we depict the SimulinkR implementation for subsystems (top), together with the results for both attitude and position controllers (bottom), respectively. Moreover, all references, including position, attitude and their associated rates, are tracked with minimal steady-state error, similarly to the error in PX4. Altogether, this demonstrates that both controllers can be considered mimetic and corroborates the whole reliability of the autopilot. B. EV2: COMPLEX NONLINEAR CONTROLLER MODULE To exemplify the computational capabilities, we implement a cascade nonlinear controller based on feedback linearisation and command-filtered backstepping. This type of controllers –together with the cascade PIDs– are the most commonly used in this kind of multi-rotor platform. Although standard in aerial robotics, the one implemented here is an adapted version of [48] –and references therein–, being briefly summarised next. Thus, let U=col(U1,U2,U3)∈R3be the virtual command in the Cartesian position outer loop of the cascade, hence becoming the feedback-linearisation controller U= ¨pref +KD˙pe+KPpe+KIpI,0 e+Zt t0 pedτ, with pref ∈R3the cartesian position reference and pe∈R3 its associated error; KP,KI,KD∈R3×3the matrix control gains; and pI,0 e=col(0,0,zI,0 e) a feedforward integral action counteracting the initial vertical forces, zI,0 e. This outer loop provides the attitude reference commands for the inner and nonlinear control loop reading T=mkU−gk, tan θref =U1cos ψ+U2sin ψ U3− kgk, sin φref = −U1cos ψ−U2sin ψ (T/m), where m∈Ris the UAV mass, g∈R3the gravity acceleration vector, T∈Rthe total thrust and ψ∈Rthe yaw angle. On the other hand, the attitude controller of the inner loop is formulated using the command-filtered backstepping technique (see references therein [48]), yielding τa=×I+02Z2+I(W>¯ Z1+˙ ref ), ˙ ref = − ¯ 0(ref −d), ˙= −01−W(ref −d), with τa∈R3the control torque produced by the differential thrust between the rotors (see [49] and references therein); 2=col(φ, θ, ψ)∈R3and ∈R3the attitude and attitude rate, with W(2)∈R3×3their associated matrix; I∈R3×3the inertia matrix of the UAV in the body frame; FIGURE 6. Cascade PID controller implemented in MASPX4 with results from the position and attitude control loops at constant altitude. ¯ Z1=2ref −2−the filtered attitude error; ∈R3 a filter to counteract the mismatch of the tracking error; Z2=ref −the attitude rate error, and 01, 02and ¯ 0∈R3×3are control and filter matrix gains. Notice that the gyroscopic terms have been neglected because of their irrelevance for this platform, and that the highorder implementation of this solution includes 9 nonlinear integrators. 223832 VOLUME 8, 2020 C. R. de Cos et al.: High-Level Modular Autopilot Solution for Fast Prototyping of UASs FIGURE 7. Command-filtered backstepping controller implemented in MASPX4 with results for position and attitude at constant altitude. In Fig. 7we depict again the SimulinkR implementation of this much more involved nonlinear controller for the subsystems (top), together with the results at the bottom when commanded to track a variable reference. It is worth noting in this case that the attitude controller steady-state error does not affect the position controller. Additionally, a CPU load test for this algorithm –in which aggressive RC commands and ad-hoc parameter tuning were induced in its first half to estimate their maximum impact– is shown in Fig. 8, becoming clear that the IntelR NUC is capable of running significantly more demanding algorithms even without turning to the accelerator mode of SimulinkR , FIGURE 8. Stacked CPU load executing command-filtered backstepping controller in MASPX4, being the RAM use consistently steady at 25%. FIGURE 9. Navigation module implemented in MASPX4. as expected. It is also worth noting that the variations due to the aforementioned additional elements in the first half of the experiment are perceptible. Nonetheless, considering the time ratio analysis in Fig. 4, in which significant computational power margins were detected, we can conclude that their impact on the reliability of the solution is negligible. C. EV3: AUTONOMOUS NAVIGATION MODULE Finally, a separate autonomous flight has been carried out in an outdoor scenario with wind disturbances and GPS inaccuracies including an additional navigation module depicted (see Fig. 9). The flight path, as depicted on the left side of Fig. 10, consists of an XY square followed by a vertical rectangle sharing one of its sides, being this manoeuvre chosen to show the response of the controller to changes in all directions. To highlight the changing speed during the flight, a set of time-equispaced points have been added to the position plot. It can be concluded that the solution is perfectly capable of tracking the proposed trajectory with a good overall performance. As shown by both path tracking and position subplots, the most important error peaks correspond to the regions around the waypoints, as expected, being the displayed overshoots at their typical range in aerial robotics. VOLUME 8, 2020 223833 C. R. de Cos et al.: High-Level Modular Autopilot Solution for Fast Prototyping of UASs FIGURE 10. Monitoring of the UAV using a PID cascade controller: path tracking (on the left, with position markers separated by 0.25 s and navigation waypoint order –where the initial and final positions are highlighted in green and red, respectively–), global position (top right) and attitude (bottom right), where black lines represent the references (with speeds of up to 1 m/s) and the coloured lines/markers the UAV state. IV. CONCLUSION In the present work, a high-level modular autopilot solution for fast prototyping of custom algorithms in UAVs is presented and demonstrated in an experimental setting. The approach is proven to be safe and reliable in terms of communication, integration and execution of new algorithms due to its inherent redundancy. Moreover, the proposed solution provides a user-friendly modular environment in the well-known SimulinkR software, making the theory-to- implementation step easier and faster, and facilitating the interchange and external validation of custom algorithms. Finally, its feasibility for computation-intensive methods is demonstrated by the implementation of a high-order nonlinear controller, thus overcoming the prototyping issues generally arisen when applying complex algorithms on aerial robotics. Future work is underway to include additional modules like estimator and mixer for other multi-rotor setups. All these implementations and modules will be available in a shared open repository,9thus facilitating the aforementioned interchange and validation of custom functionalities. APPENDIX A Simulink R RUNNING MODES Since the need for compilation in SimulinkR is not evident, in here we include a disambiguation of the difference between compilation and interpretation in this graphical programming environment. According to the available technical documentation, the model is interpreted in Normal mode during each simulation run (see 10-11 in [50] and [51]), thus being this mode preferable when frequent changes of the model are needed. Moreover, including only Interpreted Function blocks –without using Math-Function ones– forces the execution engine to be called at each simulation time step, mimicking interpreters. Therefore, 9https://github.com/grvcTeam/MASp some kind of compilation –in the sense of SimulinkR , i.e. the translation of the block diagram to an internal representation that interacts with the SimulinkR engine (see 11-26 in [50])– is made in most applications, but it can never be comparable to a full standalone solution with an external compiler. In what respects to the Accelerator mode [52], SimulinkR  uses by default the Just-In-Time (JIT) compilation. This generates an execution engine in memory for the top-level model only, and not for referenced models. As a result, a C compiler is not required during simulations. This is related to another helpful prototyping tool for the interpreter/compiler, the Model Reference. Wherever this Model-Reference block is used, the simulation mode of a sub-system can be controlled –i.e. by setting it to Accelerator mode, it is simulated through code generation; and by setting it to Normal mode this is done in interpreted mode–. Additionally, Accelerator mode does not support most runtime diagnostics of Normal mode, which is also very important during prototyping. Finally, in Rapid Accelerator mode, SimulinkR creates a standalone executable including both the solver and the models interacting with SimulinkR via the external mode, with the subsequent lack of debugging options (see [53]). In summary, the interpretation made in Normal mode (and in Accelerator mode via JIT) is not comparable to a full compilation obtaining a standalone executable or a binary file, as in Rapid Accelerator mode. The graphical programming, the tools for diagnostics and the possibility of a modular compilation (if desired with Model Reference) make this approach superior in prototyping stages. To provide a quantitative measure, we made a comparison in terms of time consumption. On average, our solution takes about 1-2 s to interpret a modified model (Normal mode), while the complete compilation of minimal changes in PX4 –our previous implementation approach– last about 20-25 s, 10 times slower in the least favourable case. 223834 VOLUME 8, 2020 C. R. de Cos et al.: High-Level Modular Autopilot Solution for Fast Prototyping of UASs Algorithm 1 UDP Module – SEND Data 1: Fcode simplified for brevity 2: [· · · ]Finit daemon module in px4 3: thread_task(){ 4: create_udp_socket() 5: subscribe_topic(topic_name)Fdata source 6: while thread_is_running do 7: if topic_update() then 8: struct_data ←topic_data Fread topic content 9: destination ←udp_send(struct_data) 10: end if 11: end while 12: close_udp_socket()} Algorithm 2 UDP Module – RECEIVE Data 1: Fcode simplified for brevity 2: [· · · ]Finit daemon module in px4 3: thread_task(){ 4: create_udp_socket() 5: advert_topic(topic_name) 6: while thread_is_running do 7: if recv_data() then 8: struct_data ←data_received 9: topic_name ←uorb_publish(struct_data) 10: end if 11: end while 12: close_udp_socket()} APPENDIX B PX4-Simulink R UDP COMMUNICATIONS As mentioned in the Software Integration subsection, the proposed solution is based on the UDP communications between PX4 and a SimulinkR environment. This is implemented via two sockets, one after the ecl/EKF estimation and another one just before the input to the motor mixer. The core of their respective pseudocodes is shown in Algorithms 1and 2. Additionally, for those interested in the integration between the basic PX4 functionalities and the customisable MASPX4 environment, we refer readers to our GitHub repository at https://github.com/grvcTeam/MASp, which is currently under construction. Apart from the code support, a wiki of the SimulinkR environment and the space to share custom modules with the MASPX4standard I/O connections will be included. REFERENCES [1] Aerial Robotics Cooperative Assembly System, ARCAS Project, Eur. Commission Under the Seventh Framework Programme. [Online]. Available: http://www.arcas-project.eu/ [2] A. Ollero, J. Cortes, A. Santamaria-Navarro, M. A. T. Soto, R. Balachandran, J. Andrade-Cetto, A. Rodriguez, G. Heredia, A. Franchi, G. Antonelli, K. Kondak, A. Sanfeliu, A. Viguria, J. R. Martinez-de-Dios, and F. Pierri, ‘‘The AEROARMS project: Aerial robots with advanced manipulation capabilities for inspection and maintenance,’’ IEEE Robot. Autom. Mag., vol. 25, no. 4, pp. 12–23, Dec. 2018. [3] Collaborative Aerial Robotic Workers, AEROWORKS Project, Eur. Commission Under the H2020 Framework Programme. [Online]. Available: http://www.aeroworks2020.eu/ [4] AERIAL Cognitive Integrated Multi-Task Robotic System With Extended Operation Range and Safety, AERIAL-CORE Project, Eur. Commission Under the H2020 Framework Programme. [Online]. Available: https://aerial-core.eu/ [5] F. Ruggiero, V. Lippiello, and A. Ollero, ‘‘Aerial manipulation: A literature review,’’ IEEE Robot. Autom. Lett., vol. 3, no. 3, pp. 1957–1964, Jul. 2018. [6] X. Meng, Y. He, and J. Han, ‘‘Survey on aerial manipulator: System, modeling, and control,’’ Robotica, vol. 38, no. 7, pp. 1288–1317, Jul. 2020. [7] A. Ollero and B. Siciliano, Aerial Robotic Manipulation (Springer Tracts in Advanced Robotics). Cham, Switzerland: Springer, Jul. 2019. [8] N. Michael, J. Fink, and V. Kumar, ‘‘Cooperative manipulation and transportation with aerial robots,’’ Auton. Robots. Special Issue, Robot., Sci. Syst., vol. 30, no. 1, pp. 73–86, 2011. [9] C. Korpela, M. Orsag, T. Danko, B. Kobe, C. McNeil, R. Pisch, and P. Oh, ‘‘Flight stability in aerial redundant manipulators,’’ in Proc. IEEE Int. Conf. Robot. Automat., May 2012, pp. 3529–3530. [10] A. E. Jimenez-Cano, J. Martin, G. Heredia, A. Ollero, and R. Cano, ‘‘Control of an aerial robot with multi-link arm for assembly tasks,’’ in Proc. IEEE Int. Conf. Robot. Automat. (ICRA), May 2013, pp. 4916–4921. [11] A. Suarez, F. Real, V. M. Vega, G. Heredia, A. Rodriguez-Castano, and A. Ollero, ‘‘Compliant bimanual aerial manipulation: Standard and long reach configurations,’’ IEEE Access, vol. 8, pp. 88844–88865, 2020. [12] J. Á. Acosta, C. R. de Cos, and A. Ollero, ‘‘Accurate control of aerial manipulators outdoors. A reliable and self-coordinated nonlinear approach,’’ Aerosp. Sci. Technol., vol. 99, Apr. 2020, Art. no. 105731. [13] J. A. Acosta, C. R. de Cos, and A. Ollero, ‘‘A robust decentralised strategy for multi-task control of unmanned aerial systems. Application on underactuated aerial manipulator,’’ in Proc. Int. Conf. Unmanned Aircr. Syst. (ICUAS), Jun. 2016, pp. 1075–1084. [14] Y. E. Tlatelpa-Osorio, J. J. Corona-Sanchez, and H. Rodriguez-Cortes, ‘‘Quadrotor control based on an estimator of external forces and moments,’’ in Proc. Int. Conf. Unmanned Aircr. Syst. (ICUAS), Jun. 2016, pp. 957–963. [15] L. Meier, D. Honegger, and M. Pollefeys, ‘‘PX4: A node-based multithreaded open source robotics framework for deeply embedded platforms,’’ in Proc. IEEE Int. Conf. Robot. Automat. (ICRA), May 2015, pp. 6235–6240. [16] (May 2019). Dronecode Project PX4 Open Source Flight Control Software. [Online]. Available: http://px4.io [17] J. R. Guadarrama-Olvera, J. J. Corona-Sánchez, and H. Rodríguez-Cortés, ‘‘Hard real-time implementation of a nonlinear controller for the quadrotor helicopter,’’ J. Intell. Robotic Syst., vol. 73, nos. 1–4, pp. 81–97, Jan. 2014. [18] M. Bangura and R. Mahony, ‘‘Real-time model predictive control for quadrotors,’’ IFAC Proc. Volumes, vol. 47, no. 3, pp. 11773–11780, 2014. [19] L. Xu, H. Ma, D. Guo, A. Xie, and D. Song, ‘‘Backstepping slidingmode and cascade active disturbance rejection control for a quadrotor UAV,’’ IEEE/ASME Trans. Mechatronics, early access, Apr. 27, 2020, doi: 10.1109/TMECH.2020.2990582. [20] B. Fuller, J. Kok, N. A. Kelson, and L. F. Gonzalez, ‘‘Hardware design and implementation of a MAVLink interface for an FPGA-based autonomous UAV flight control system,’’ in Proc. Australas. Conf. Robot. Automat. (ACRA), Melbourne, VIC, Australia, Dec. 2014, pp. 1–6. [21] Q. Lin, Z. Cai, and Y. Wang, ‘‘Design, model and attitude control of a model-scaled gyroplane,’’ in Proc. IEEE Chin. Guid., Navigat. Control Conf., Aug. 2014, pp. 1282–1287. [22] J. R. Kutia, K. A. Stol, and W. Xu, ‘‘Aerial manipulator interactions with trees for canopy sampling,’’ IEEE/ASME Trans. Mechatronics, vol. 23, no. 4, pp. 1740–1749, Aug. 2018. [23] F. Ruggiero, M. A. Trujillo, R. Cano, H. Ascorbe, A. Viguria, C. Perez, V. Lippiello, A. Ollero, and B. Siciliano, ‘‘A multilayer control for multirotor UAVs equipped with a servo robot arm,’’ in Proc. IEEE Int. Conf. Robot. Automat. (ICRA), May 2015, pp. 4014–4020. [24] D. Santamaría, F. Alarcón, A. Jiménez, A. Viguria, M. Béjar, and A. Ollero, ‘‘Model-based design, development and validation for UAS critical software,’’ J. Intell. Robotic Syst., vol. 65, nos. 1–4, pp. 103–114, Jan. 2012. [25] S. Omari, M.-D. Hua, G. Ducard, and T. Hamel, ‘‘Hardware and software architecture for nonlinear control of multirotor helicopters,’’ IEEE/ASME Trans. Mechatronics, vol. 18, no. 6, pp. 1724–1736, Dec. 2013. [26] M. Tognon and A. Franchi, ‘‘Dynamics, control, and estimation for aerial robots tethered by cables or bars,’’ IEEE Trans. Robot., vol. 33, no. 4, pp. 834–845, Aug. 2017. VOLUME 8, 2020 223835