Effects of Model-Specific Parameters on the Development of Custom Module in PX4 Autopilot Software-in-the-Loop

This is an open access article under the terms of the Creative Commons Attribution License, which permits use, distribution and reproduction in any medium, provided the original work is properly cited.

1. Introduction

Prior to actual deployment, a new module is required to pass through rigorous tests and modifications in a simulated environment. Such a simulated environment–based testing and modification of modules avoids tiresome and risky physical experiments. Recursive testing and modification of a new module has multiple stages of the developmental process. In its early stage, a module is entirely developed and tested on a desktop computer. Such a process is termed as software-in-the-loop (SIL) [1, 2].

In SIL, the module is processed with a simulated time pace, which is not real-time [3]. The background operating system of a computer used for SIL is not a real-time operating system, unlike the operating system often utilized for actual hardware onboard unmanned aerial or ground vehicles. As a result, there can be delays or loss of information while the module is processed on actual hardware, and that deteriorates the performance of the module. To address such drawbacks, in the next development stage, the actual hardware is incorporated into the simulation process in which the module runs on the processor of the actual hardware. Such simulation process is termed as process-in-the-loop (PIL) [4]. To validate a desired workflow of the module with the rest of the systems, required hardware components are included in the simulation process, and this is called hardware-in-the-loop [5, 6].

Furthermore, module development in SIL is based on a linearized dynamic model of the actual platform (e.g., unmanned aerial vehicle (UAV) model), and acquired data from modeled sensors in SIL are smoother than the data from actual sensors. All these may incur a reduced performance of the module on actual hardware. As a remedy to this, once the module is confirmed to satisfy a required level of reliability, a vehicle on which the entire process is intended to operate can be integrated into the simulation loop [7, 8].

Nevertheless, SIL tools are being used in software development and testing for ground, air, and space missions. For validation of the custom control algorithm developed for the driverless railway vehicle, Michele et al. [9] implemented SIL. As a means of rapid prototyping environment and validation platform for automotive software, Sooyong, Yongsub, and Woo [10] and Giovanni et al. [11] utilized SIL. Xiang et al. [12] reported the effectiveness of SIL for the validation of control design performance in automotive systems. Antal et al. utilized SIL to test the object detection algorithm developed for UAV-based situational awareness [13]. Calvin, Michal, and Nathan studied and verified the validation of SIL platforms for preflight testing of flight dynamics models [14]. A comprehensive SIL simulation environment for quadcopter UAV was designed and implemented for the testing of various modules by Meyer et al. [15]. Aziz, Adnane, and Zouhair [16] utilized SIL to develop and test the speed control of a reaction wheel used in the attitude control of nanosatellites. For stability validation and performance testing of autonomous space systems, Kaveh and Won-Sook [17] implemented SIL simulation.

In the aeronautical sector, the role of SIL simulation tools for the development and testing of modules such as flight control systems is by far crucial, for the risk of any failure in these flight control systems has a detrimental effect on life and annihilates significant amounts of financial investments. Many UAV accidents recorded over the years reveal that they are a result of flight system errors [18]. Nowadays, UAVs are being deployed for missions such as package delivery, disaster monitoring, and law enforcement in urban areas. This dictates that in-depth SIL simulation–based testing and modification of modules prior to their implementation is indispensable to avoid potential dangers of operational failures.

In order for the modules to be properly developed and tested, the SIL simulation tool, in use, has to be reliably redesigned with unique features of a vehicle model for which the modules are being developed in the simulation process. Shoaib and Mana [19] designed a model-specific SIL simulation framework to develop and test a hybrid control algorithm dedicated to their hybrid aircraft. Nguyen, Ha, and Jang [20] designed an SIL configuration to validate the performance effectiveness of their new hybrid UAV model. They also demonstrated the required processes to customize PX4 Autopilot SIL for the development of a vision algorithm for a custom UAV model incorporated into the SIL simulation process. A new approach to configuring SIL for flight guidance algorithm development was proposed by Adriano et al. [21].

There are various SIL simulation tools, many of which are provided with flight control firmware. Of this firmware, which provides SIL tools, PX4 Autopilot, an open-source autopilot firmware, is popular for its versatility to run on various hardware and to provide a wide range of options for users to customize the firmware with new features. A comprehensive report on the robustness of this firmware was presented by Meier, Honegger, and Pollefeys [22]. The firmware also comes with multiple aerial, ground, and underground vehicle models that can be suitably used in the SIL simulation environment.

Moreover, the architecture of PX4 Autopilot firmware is modular in that users can implement custom modules without affecting the original firmware. It, also, enables the integration of various external hardware (e.g., sensors) and software (e.g., simulators) so as to make the firmware robust. PX4 Autopilot SIL supports various simulators, where Gazebo, FlightGear, and jMAVSim are the commonly used ones. The fidelity and versatility of these simulators are determined by factors such as stability in the simulation process, good visual rendering, and the type of physics engines they have to solve the kinematics and dynamics of a body [23, 24]. Pitonakova et al. [25] listed out some of these features to compare the performance of simulators. A detailed comparison of some popular simulators was also given by Marian et al. [26] based on features such as speed and stability during simulation as well as hardware utilization.

The remainder of this work is organized as follows. In Section 2, opportunities and challenges of SIL simulation tools and approaches to resolve the challenges are presented. The necessary technical approaches to incorporate custom modules and models into PX4 Autopilot SIL are described in Section 3. A case study on the effects of model-specific parameters on the development and testing of custom modules in PX4 Autopilot SIL is presented in Section 4. In Section 5, results and discussions on the simulation outcomes are presented, and conclusions on the relevance of this work are drawn in Section 6.

2. Problem Statement and Methodology

It is of interest to both complete novices and practitioners to test and modify modules in the SIL simulation environment prior to their actual implementation. A simulation framework presented by PX4 Autopilot SIL and the Gazebo simulation environment is among the top-rated tools used for custom module development in the realm of unmanned aerial systems in particular.

PX4 Autopilot SIL is already integrated into the Gazebo simulator, in which various models of aerial, ground, and underground vehicles are incorporated. Active developers of PX4 Autopilot are well aware that there can be cases when a custom model is required to be added to the pre-existing ones to develop and test model-specific modules. Therefore, the PX4 Autopilot firmware is developed with a feature that allows users to add custom models and modules. Effective use of PX4 Autopilot SIL and the Gazebo simulator requires proper configuration and customization of both software with the custom models and modules. Flaws in either of the two software affect the other. As a result, the simulation process may abort or output inaccurate values.

There are many researchers requesting technical procedures to resolve their problems [27–30]. Most of the technical issues are related to PX4 Autopilot SIL customization with new models and modules [31–37]. Likewise, the Gazebo simulator invokes issues if not properly customized. There are multiple questions raised in Gazebo discussion forums as well [38–41]. To address these issues, the complete guidelines for proper customization of both the PX4 Autopilot SIL and Gazebo simulator are given prior to investigating the effects of model-specific parameters on custom module development and testing. The preprint of this work is available online [42].

Following the technical presentations, a case study is conducted by extracting model-specific parameters and analyzing their effects on the development and testing of a custom module. In the process of investigating the effects of model-specific parameters on the development and testing of a custom module, parameters such as mass, moments of inertia, and aerodynamics are considered. The mechanism is designed in such a way that accurate and faulty values of the parameters are incorporated into the simulation process and the outputs are analyzed.

3. PX4 Autopilot

PX4 (PX stands for Pixhawk and 4 refers to the fourth round rewriting of the firmware) is an autopilot firmware for unmanned vehicles. It is open-source and available for off-the-shelf implementation by end-users or customization by researchers. The PX4 Autopilot firmware is a cross-platform that enables personal computers to run the firmware in a simulated environment. This flight control firmware is actively being developed in various sectors, all the way from universities to industries. The firmware can run on any operating system that provides Portable Operating System Interface (POSIX), a standard made suitable for users to port their software across platforms. Operating systems such as Nuttx, Linux, Windows, and MacOS provide POSIX; hence, PX4 Autopilot can run on any of these operating systems through the use of Linux, which is highly recommended. The PX4 Autopilot firmware customization presented in this work runs on the Linux operating system.

The PX4 Autopilot firmware is preferred by researchers and commercial sectors for it is under the Berkeley Software Distribution licensing that allows everyone to customize the firmware without publicizing the customized source (src) codes and to commercialize with or without modification. Three of the most important features of this autopilot firmware are as follows:

◆ Modularity: A user can replace, modify, or add new modules without affecting the integrity of the firmware. Researchers take advantage of this feature and customize the firmware easily.

◆ Large number of peripherals: Many external hardware such as distance sensors, inertial measurement unit (IMU) sensors, light detection and ranging (LiDAR), global positioning system (GPS), and optical flow are supported. It is also possible to add a custom driver module to the firmware so as to support new hardware.

◆ Availability of many airframe types: The firmware is rich in the number of airframe types it supports. However, it is still open for a user to add any custom airframe type.

3.1. Architecture

PX4 Autopilot firmware contains two layers: the applications layer, commonly known as the flight stack, and the communication service layer, known as middleware. The flight stack layer deals with estimation (e.g., position and attitude), control, navigation, and guidance, whereas the middleware provides interapplications and interhardware communication services. It is through the middleware that the PX4 Autopilot firmware provides its SIL version for researchers to develop their algorithms in the simulated environment.

The middleware layer also enables communication between the firmware and the operating system it is running on. Communications among applications are handled by the so-called micro object request broker (uORB) of the middleware. This uORB allows modules to publish their outputs and/or subscribe to outputs of other modules asynchronously. The outputs are messaged through topics (message buses). These topics are listed in the directory: ~/PX4/Autopilot/msg, where PX4/Autopilot is the root directory of PX4 Autopilot firmware to which a user navigates to build and upload the firmware. Note that the guidelines given in this paper are based on the PX4 Autopilot firmware Version 1.9.2 stable release. There can be some modifications and re-locations of directories in the other versions of the firmware.

3.2. PX4 Autopilot SIL

PX4 Autopilot firmware provides an SIL feature that is made suitable for computer-based simulation of algorithms under development. PX4 Autopilot SIL uses two modules, simulator and mavlink, to communicate with the external environments. The two modules are located in the /PX4-Autopilot/src/modules directory. The simulator module communicates with virtual environments such as the Gazebo simulator, whereas the mavlink module communicates with ground control stations (e.g., QGroundcontrol) and offboard/APIs or companion computers. Both the mavlink and simulator modules receive information from external environments and send it to uORB so that other PX4 Autopilot modules can use this information. Likewise, information published by PX4 Autopilot modules to uORB topics is delivered to external environments through mavlink and simulator modules.

It is possible that PX4 Autopilot SIL and the external environments run either on the same computer or on different computers. In either case, PX4 Autopilot mavlink defines ports as local and remote, where local ports are ports to which PX4 Autopilot SIL listens and remote ports are ports to which information is broadcasted. The local and remote ports are specified by the startup file rcS located in PX4-Autopilot/ROMFS/px4fmu_common/init.d-posix.

Communication between the Gazebo simulator and PX4 Autopilot SIL begins as the simulator sends sensors’ data through the Gazebo plugin to a defined UDP (User Datagram Protocol) port. PX4 Autopilot SIL listens to the port and acquires sensor data through its simulator model. When QGroundcontrol is opened while the SIL simulation process is active, it communicates not only with PX4 Autopilot SIL but also with the Gazebo simulator. QGroundcontrol gets connected to the Gazebo simulator as QGroundcontrol initiates communication with the simulator by sending a message whose destination (dst) is a defined UDP port and expecting information on a defined src port. Soon the simulator confirms acceptance of the message on the src port, it starts sending messages on the dst UDP port. The overall communication among the three software, PX4 Autopilot SIL, QGroundcontrol, and Gazebo simulator, is shown in Figure 1. The black arrows show intercommunication among the software, and the white arrows show communications among modules of each software.

[figure(s) omitted; refer to PDF]

3.3. Custom Module in PX4 Autopilot SIL

Custom modules can be directly included in PX4 Autopilot firmware. The custom module inclusion to PX4 Autopilot firmware should fulfill the firmware’s module content and configuration requirements. The firmware has two layers; hence, the type of the custom module written by a user can be categorized into either of these two layers. If the custom module belongs to the flight stack, it is saved in PX4-Autopilot/src/modules, and if it belongs to middleware, it is saved either in

• the driver directory: as device module, PX4-Autopilot/src/drivers,

• the system cmd directory: as system module PX4-Autopilot/src/systemcmds, or

• the lib directory: as shared library module PX4-Autopilot/src/lib.

To create a custom module that belongs to the flight stack layer and implement it for the PX4 Autopilot SIL simulation process, the following steps are required:

• Create a folder in the module directory located in PX4-Autopilot/src/modules and name it. The created folder shall contain at least three files: the src code, the header file that enables access to PX4 Autopilot libraries, and the CMakeLists.txt file that introduces the module to the firmware during compilation.

• Create the header file for the src code and save it in the folder.

• Create a src code and save it in the folder. The content of the src code has to follow the publish/subscribe messaging protocol of PX4 Autopilot firmware. This can be referred to from pre-existing src codes.

• Copy and paste a CMakeList.txt file from any pre-existing flight stack module and modify its contents. CMakeLists.txt file, mainly, contains:

■ module category specifier: to which the module belongs,

■ name of the custom module,

■ name of the main function of the src code, and

■ name of the src code.

• Once the module creation is completed, the module has to be configured with PX4 Autopilot firmware. For this, there are two things to consider:

■ to test the custom module in SIL, list the name of the custom module in the default.cmake file located in PX4-Autopilot/boards/px4/sitl. The name of the custom module should be listed under the category that was specified in the CMakeLists.txt file of the custom module and

■ to upload the custom module to the flight control board, add it to the default.cmake file located in PX4-Autopilot/boards/px4/[version of flight control board. e.g. fmu-v5]. Make sure that the name of the custom module is added to the default.cmake in the right category.

■ The custom module is then built along with other modules when a build command is prompted.

3.3.1. Start/Stop Custom Module

During SIL simulation tests, the custom module can be started or stopped on the SIL shell (pxh). Furthermore, a custom module can be automatically started upon autopilot boot if the module is included in one of the startup shell scripts located in PX4-Autopilot/ROMFS/px4fmu_common/init.d. To be more specific, the custom module has to be included in the appropriate startup shell script. For instance, if the custom module is specific to:

• multicopter UAV, include the custom module in rc.mc_apps,

• vertical takeoff and landing (VTOL) UAV, include the custom module in rc.vtol_apps.

This starts the custom module only if the required airframe is used. A detailed explanation of the sequence of startup shell scripts can be found here.

3.3.2. Simulation Results

SIL simulation results are stored in .ulg file format. The location of these data depends on the option taken to launch PX4 Autopilot SIL.

• If the model is launched using $make \: px4_sitl_default$, the simulation data are stored in the log directory located in PX4-Autopilot/build/px4_sitl_default.

• If the model is launched using roslaunch (e.g., px4 mavros_posix_sitl.launch), the simulation data are stored in a log file located in ros/sitl_"model name”/log.

In order to get access to the numerical data of the .ulg file, the Python script named pyulog can be used. The installation instructions are given in pyulg. The command ulog2csv/path_to_directory/filename.ulg generates an Excel file from the .ulg file. The .ulg can, also, be directly plotted using PX4 flight review.

3.4. Gazebo 3D (Three-Dimensional) Simulation Environment

Gazebo is open-source software that provides a virtual 3D world for researchers to rigorously test algorithms and models before implementing them for real missions. The software has a modular architecture like that of the PX4 Autopilot firmware. It has a close-to-realistic physics engine that accurately and efficiently simulates the kinematics and dynamics of three models and is among the well-known, powerful simulation tools used by many sectors dealing with autonomous vehicles [42, 43].

Gazebo presents a 3D virtual world and model(s) being simulated in the world. As shown in Figure 2, a client interacts with the model(s) through Gazebo APIs.

[figure(s) omitted; refer to PDF]

The word “model” in Gazebo refers to a visual representation of an object that may constitute rigid bodies (links) and joints between the links. It is also possible that a model has one link with no joint. Moreover, a model may include sensor(s) attached to the link(s) or the joint(s). Gazebo implements an open dynamic engine: a physics engine that handles the kinematics and dynamics of the model(s) as well as data generation from sensors. Though not shown in the figure, Gazebo also supports the use of other physics engines: Bullet for gaming, Simbody for biomechanics, and dynamic animation and robotics toolkits for computer graphics and robot control. For visual rendering and display of sensors and other objects such as vehicles in a simulated world, Gazebo uses openGL and openGL utility toolkit. Gazebo also presents many features of the actual world, such as gravity, light, wind, and water.

3.4.1. Gazebo Plugins

A Gazebo plugin is a code that handles direct access to all functionalities of Gazebo. There are six different plugin types: model, sensor, world, visual, system, and graphical user interface (GUI). Gazebo software can be extended by adding custom plugins to it. Gazebo plugins play roles of information interchange between PX4 Autopilot SIL and the Gazebo simulation environment. PX4 Autopilot SIL_gazebo has plugins located in PX4-Autopilot/Tools/sitl_gazebo/src. However, when a custom model is introduced to Gazebo, the model may require a new plugin.

To create a custom Gazebo plugin, it is recommended to copy the already existing plugin of the same type. If the custom plugin is for a model, then copy the already existing model plugin and modify it as per requirements. If the custom plugin is for video streaming, the existing GUI plugin type is to be copied. Upon compiling the custom plugin, the corresponding shared library is generated and stored in PX4-Autopilot/build/px4_sitl_default/build_gazebo. This library can be called into the Gazebo vehicle model to control model properties such as the dynamics of the joints of the vehicle model. As the name indicates, a model plugin is used by Gazebo models; a sensor plugin is used by sensors, and so on. The technical steps required to create a custom Gazebo plugin are as follows:

■ write and save the header file of the src code in PX4-Autopilot/Tools/sitl_gazebo/include.

The header calls in required Gazebo functions and contains the class that inherits a plugin type.

■ write and save the custom plugin src code in the directory PX4-Autopilot/Tools/sitl_gazebo/src.

For src code developed from scratch, it is important to make sure that the following are included in the code:

■ Gazebo namespace, a function that loads physics engines and information about Gazebo vehicles, Gazebo topics through which messages are published, and a plugin type registration macro that informs Gazebo about the presence of the plugin and its type.

■ To compile the custom plugin src code, the name of the src code should be listed in the CMakeList.txt file located in PX4-Autopilot/Tools/sitl_gazebo.

Once the name of the custom plugin is included in the Gazebo plugins list, upon building the px4 SIL with Gazebo, a corresponding shared library file with the extension of .so file is generated and saved in PX4-Autopilot/build/px4_sitl_default/build_gazebo. The prefix “lib” is added to the custom plugin name to indicate that it is a library. This Gazebo plugin library can be called by the custom model or any other model if needed.

3.4.2. PX4 Autopilot SIL Gazebo Models

There are various simulation environments that work with PX4 Autopilot SIL, among which are Gazebo, jMAVSim, FlightGear, and AirSim. Gazebo is the most widely used simulation environment for PX4 Autopilot SIL [44–48]. It supports the lock-step feature of PX4 Autopilot SIL that enables the PX4 Autopilot SIL and Gazebo to wait on each other during information processing. This feature has many advantages in PX4 Autopilot SIL simulation, and detail on these advantages is given.

PX4 Autopilot SIL provides access to implement any model of aerial, ground, or underground vehicle in the simulation environment. However, the intended model has to have a certain file format to be used in the simulation environment. It is essential to know how Gazebo reads and understands a model that is going to be simulated in its virtual world. For a model to be simulated in the Gazebo world, it has to have the following components:

■ link with mass, inertia, collision, and visual attributes,

■ joints between links of the model to which forces or velocity are applied to put the model into dynamics. A joint has an axis of translation or rotation along or about which force or torque is applied,

■ sensors that can be attached to the model through its links or joints, and

■ Gazebo plugin that provides access to Gazebo functionalities such as physics engines.

In PX4 Autopilot SIL Gazebo vehicle models, it is required that a model directory has to have at least two files: a configuration file saved in .config format and an eXtensible Markup Language (XML) file saved in Simulation Description Format (SDF). A Gazebo model plugin uses vehicle model attributes in the SDF file as inputs for the Gazebo physics engine to determine the dynamics of the vehicle model in the Gazebo world. There can be two subdirectories, meshes and materials, in a model directory. The meshes subdirectory contains links (e.g., vehicle model), and the materials subdirectory contains the texture paints of the links and scripts about the links. The steps required to add and configure a custom UAV model in PX4 Autopilot SIL are as follows:

• create a custom model directory in PX4-Autopilot/Tools/sitl_gazebo/models,

• create two files in the custom model directory: configuration and SDF files,

• copy and paste the contents of the configuration and SDF files from the pre-existing model to the custom model’s configuration and SDF files,

• modify both the configuration and the SDF files as per needs,

■ in the configuration file, replace the name of the SDF attribute with the custom model’s SDF file name,

■ modification of contents in an SDF file requires extensive work, such as

◆ replacing the existing model name with the name of the custom model,

◆ adding and scaling the UAV model into the base_link of the SDF file,

◆ adding texture paint to the vehicle model which is optional,

◆ creating joints between the base_link (UAV model) with other links (e.g., sensor platform model),

◆ attach sensors to link(s) or joints(s).

• add a model plugin required for the custom model,

• the name of the custom model should be included in the sitl_target.cmake file located in PX4-Autopilot/platforms/posix/cmake so that it can be compiled,

• create airframe file in the airframes directory of PX4 Autopilot located in PX4-Autopilot/ROMFS/px4fmu$_common/init.d-posix/airframes. The name of the airframe should be unique with its numeric and/or alphabetic parts.

• add the name of the airframe to the CMakeLists.txt file located in the airframes directory.

In the case of the actual scenario (not a simulation), a new airframe is created and saved in PX4-Autopilot/ROMFS/px4fmu_common/init.d/airframes so that the new airframe shows up in the ground control station during vehicle setup.

3.4.3. Custom Mixer

Often, custom models incorporated into PX4 Autopilot SIL require custom mixers that output servo motor control signals. A mixer in PX4 Autopilot SIL is a script that takes in actuator_control values and mixes them according to the needs depending on the airframe type and its motors’ arrangement. If the airframe type is custom-built, the mixer has to be defined for this airframe and saved in the directory: PX4-Autopilot/ROMFS/px4fmu_common/mixers-sitl. The procedure of passing actuator control commands through mixer logic to actuator output in pulse width modulated (PWM) signal form is as follows:

• The actuator commanding module (e.g., mc_att_control) publishes normalized attitude angles to the actuator_control topic located in PX4-Autopilot/msg.

• A mixer takes in these normalized angular values and mixes them accordingly.

• The pwm_output_sim located in PX4-Autopilot/src/drivers scales the mixed angular values to the required level of PWM signal, often, ranging from 900 to 2000, and publishes them to actuator_output topic located in PX4-Autopilot/msg.

• These outputs are, then, ported to designated autopilot board ports to actuate motors/servos connected to the ports.

During PX4 Autopilot SIL simulation with Gazebo, these actuator output values should be sent to a Gazebo vehicle model through a simulator module located in PX4-Autopilot/src/modules. If the actuator output values are required by a companion computer connected to the Pixhawk autopilot board, the values pass through the mavlink module located in the above directory. The flowchart shown in Figure 3 demonstrates the publication and subscription of messages to the actuator_outpouts topic. The arrows are read as “publishes to” or “subscribes to.” For instance, PWM_outputs_sim publishes to the actuator_outpouts topic and the mavlink module subscribes to the actuator_outpouts topic.

[figure(s) omitted; refer to PDF]

There are two extension options for the mixer file: .main.mix and .aux.mix. The mixer file saved with the extension of .main.mix assigns the mixer values to the main output ports on the flight control board, and the file saved with .aux.mix assigns values to the auxiliary output ports of the board. Figure 4 shows the mixer setup for the new airframe type (18001_bwb_vtol) that requires both main and auxiliary mixers.

[figure(s) omitted; refer to PDF]

The configuration file of this airframe is created and added to the list of configuration files located in PX4-Autopilot/ROMFS/px4fmu_common/init.d-posix/airframes. The configuration file, in its content, specifies various parameters specific to the airframe. It, also, contains the mixers defined for the airframe. Both the main and aux mixers of the airframe are specified in the airframe as follows:

• set mixer quad_x, where quad_x is the main mixer whose content is shown in the second row of the left column of Figure 4,

• set MIXER_AUX vtol_delta, where vtol_delta is for the auxiliary mixer whose content is shown in the right column of Figure 4.

Add the name of the airframe configuration file in the CMakeLists.txt file of the above directory. Note that the auxiliary mixer for the sensor gimbal is added to the auxiliary mixer of the vtol_delta. The order of mixer blocks defines the PWM output numbering.

3.5. Interfacing Gazebo Vehicle Models With PX4 Autopilot SIL

A vehicle model in the Gazebo world gets access to Gazebo’s functionalities through model plugins that are called into the vehicle model. These model plugins communicate with Gazebo_mavlink_interface_plugin to convey messages between the Gazebo vehicle model and PX4 SIL. Therefore, PX4 Autopilot SIL interacts with a Gazebo vehicle model indirectly through gazebo_mavlink_interface_plugin which is located in PX4-Autopilot/Tools/sitl_gazebo/src.

The overall flow of information between the Gazebo vehicle model and the PX4 Autopilot SIL is shown in Figure 5.

[figure(s) omitted; refer to PDF]

The generated library of gazebo_mavlink_interface_plugin is called in the SDF file of the Gazebo vehicle model. The plugin contains a control_channels tag in which indexed channel elements are listed with their respective attributes, such as

• joint name of the vehicle model,

• joint control type, and

• Gazebo topics through which messages, such as intended positions of joints, are published.

4. Case Study

The case study presented here is to investigate the effects of model-specific parameters on the development and testing of a custom module by taking fixed-wing VTOL UAV and steerable sensor platform models as instances. These models are designed and incorporated into the PX4 Autopilot SIL Gazebo simulation process along with their respective parameters. Parameters such as mass, inertial elements, and aerodynamics are common types of parameters that affect the flight dynamics of aerial vehicles. Therefore, this case study investigates their effects on the development of a custom model.

The objective of this investigation is to analyze how a custom module under development is affected by faulty values of model parameters. The custom module is intended to control the dynamics of the steerable sensor platform mounted on the nose of a UAV model. It seems that the custom module is dependent only on the sensor platform for which it is being developed, but in this case study, the effects of UAV model parameters are also considered.

For the sake of completeness, the design process of the models and extraction of model-specific parameters are presented in detail. The operational modes of the steerable sensor platform, whose dynamics are controlled by the custom module, are explained. Different flight mission profiles are given to the UAV, and the performance of the custom module is tested for missions under accurate and faulty values of parameters of the models.

4.1. UAV Model Design and Analysis

The UAV model is designed in OpenVSP (Vehicle Sketch Pad), released by NASA as open-source software for public use [49]. This software tool is parametric and has the capability of calculating the mass, center of gravity, and moments of inertia of the UAV model. Moreover, OpenVSP is integrated with another open-source module named VSPAERO (vehicle sketch pad with aerodynamics) that computes the aerodynamic performance of the UAV and stores multiple aerodynamic parameters.

A blended wing body (BWB) UAV model, shown in Figure 6(a), is designed in OpenVSP, and its aerodynamic performance was computed by VSPAERO. The design of the UAV is in such a way that a steerable sensor platform/gimbal can be mounted on its nose. Inertial property parameters, shown in Figure 6(a), of the UAV can be extracted from OpenVSP and imported to the inertial attributes of the SDF file of the UAV model in the PX4 Autopilot SIL Gazebo vehicle model.

[figure(s) omitted; refer to PDF]

The aerodynamic performance of the UAV is computed by VSPAERO. Figure 6(b) shows the span-wise distribution of pressure difference over the wing area and the location of the center of gravity of the UAV. Other essential aerodynamic parameters are stored in multiple file formats in a desired directory from which required parameters can be obtained. Parameters required in the PX4 Autopilot SIL Gazebo vehicle model are identified, as shown in Table 1, and extracted from the simulation results of VSPAERO. The required parameters are listed as attributes in the SDF file of the PX4 Autopilot SIL Gazebo vehicle model. The Gazebo plugin that imports these attributes into the Gazebo physics engine is called liftdrag_plugin, located in PX4-Autopilot/Tools/sitl_gazebo/src.

Table 1

Aerodynamic parameters of the UAV model.

Parameter	Description
$${\alpha }_{\text{o}}$$	Initial angle of attack
$$cla$$	Ratio of the change in lift coefficient to alpha before stall
$$cda$$	Ratio of the change in drag coefficient to alpha before stall
$$cma$$	Ratio of the change in moment coefficient to alpha before stall
$${\alpha }_s$$	Angle of attack at stall
$$cl{a}_s$$	Ratio of the change in lift coefficient to alpha after stall
$$cd{a}_s$$	Ratio of the change in drag coefficient to alpha after stall
$$cm{a}_s$$	Ratio of the change in moment coefficient to alpha after stall
$$cp$$	Center of pressure at which lift, torque, and drag are calculated
$$A$$	Area of the control surface under consideration
$$\rho$$	Density of air the UAV is operating in
$$c_j$$	Change in coefficient of lift per radial change in control surface joint

VSPAERO generates the history file that contains the aerodynamic parameters for different flight scenarios. Plots of the aerodynamic performance of the UAV model are shown in Figure 7. The required aerodynamic parameters can be obtained directly from the plots or their derivatives (slopes). For the variable “controlJointRadToCL” in Table 1, VSPAERO runs multiple times to acquire the relationship between the coefficient of lift and radial deflection of the control surface. The area of the control surface is directly obtained from OpenVSP.

[figure(s) omitted; refer to PDF]

4.2. Platform Model Design and Application

A model of a steerable sensor platform, shown in Figure 8, was created using Blender. The platform is designed to fit into the nose of the BWB VTOL UAV model. To determine its mass and elements of inertial moments, the platform is imported to FreeCAD, an open-source software tool. As a result, a mass of 0.75 kg and moments of inertia ($I_x=I_y=I_z=0.00417$ kg m² and $I_{xy}=I_{xz}=I_{yz}=0$ are obtained.

[figure(s) omitted; refer to PDF]

Gimbal 1, shown in Figure 8, is the component of the platform that is designed to be connected to the nose of the vehicle model with a revolute joint in such a way that it rolls about the forward axis through the nose of the UAV. Gimbal 2, shown in Figure 8(b), is the component of the platform that is connected to Gimbal 1 with a revolute joint in pitch/yaw. The two gimbals are assembled, as shown in Figure 8(c), and the assembly is termed as a sensor platform where sensors are mounted on Gimbal 2. Gimbal 2 of the platform can be designed to carry different sensors according to the requirements. The front view of the sensor platform is shown in Figure 8(d). It is shown in this figure that Gimbal 2 is designed to carry a monocular camera in the lower section and a LiDAR sensor in the upper section. The roll of Gimbal 1 about the nose of the UAV and the pitch/yaw of Gimbal 2 about Gimbal 1 enables the platform to engage the sensors on all sides of the UAV except the rear side.

The assembled platform is nose-mounted on the BWB VTOL UAV, as shown in Figure 9. The roll joint is defined in the SDF file of the vehicle model with attributes such as parent (vehicle), child (Gimbal 1), and axis of rotation. For the pitch/yaw joint, the parent is Gimbal 1 and the child is Gimbal 2. The platform controller custom Gazebo plugin was written and included in the list of Gazebo plugins. The shared library generated from this plugin src code is called in the roll and pitch/yaw joints so that the attributes can be loaded to the Gazebo physics engine to perform and control the rotational dynamics of the gimbals.

[figure(s) omitted; refer to PDF]

5. Results and Discussion

The custom UAV airframe and sensor platform models shown in Figures 6 and 8, respectively, are assembled, and all the aforementioned technical procedures are followed in configuring and customizing both the PX4 Autopilot SIL and the Gazebo simulator. A custom module that directs sensors on the steerable platform along the flight path of the UAV is written and added to the PX4 Autopilot flight stack. The objective of steering the platform is to detect any obstacle along the flight path. The module subscribes to the velocity vector and attitude of the UAV and publishes actuator control commands that rotate the gimbals of the sensor platform. A custom mixer is designed to take these control commands and mix accordingly from which the PWM signal is processed and sent to the Gazebo simulation environment. The custom Gazebo plugin receives the PWMs and applies them to the two gimbals of the platform.

The corresponding values of model-specific parameters of UAV and platform models such as mass, moment of inertia, and aerodynamics are included in the SDF files of the two models. To investigate the responses of the sensor platform to accurate and faulty values of the parameters, tests are conducted under different mission profiles: takeoffs, slide sideways, navigate through waypoints, and returns to launch are given to the UAV. To test whether the platform is steered in response to changes in flight modes of the UAV, the UAV is commanded to take off to a certain altitude, slide sideways, and then land. Under such a mission profile, both gimbals of the platform are engaged to roll and pitch/yaw the platform in such a way that the sensors onboard the platform are directed towards the velocity vector of the UAV.

With all parameters correctly valued, the UAV was commanded to take off, as shown in Figure 10(a). During takeoff, Gimbal 2 automatically steered up to engage sensors for scanning the environment above the UAV. The UAV attains an altitude of 8 m, descends down to 4 m, and slides sideways for a meter. Figure 10(b) shows the roll and yaw responses of the sensor platform as the UAV slides sideways. Then, the UAV descends to land, as shown in Figure 10(c), where Gimbal 2 is pitched downward while the UAV is landing and disengaged as soon as landing is detected, as shown in Figure 10(d). This test validates that the responses of the sensor platform are according to the requirements.

[figure(s) omitted; refer to PDF]

Following the verification of the proper responses of the sensor platform, the values of mass and elements of moments of inertia of the platform are altered. As shown in Table 2, $M_0$ and $I_0$ are the accurate values of mass and inertial elements of the sensor platform, whereas the values of masses ($M_1$, $M_2$, and $M_3$) and elements of moments of inertia ($\text{Inertia}=I_x,I_y,I_z$) are faulty values introduced to investigate their effects on the steering responses of the sensor platform. These values are used in mass and inertial attributes of the platform model incorporated into the SDF file of the custom UAV model.

Table 2

Platform mass and moments of inertia.

Parameter	Value	Unit
$$M_0$$	0.75	kg
$$M_1$$	1.0	kg
$$M_2$$	1.5	kg
$$M_3$$	2.0	kg
$$I_0$$	$$I{o}_x=I{o}_y=I{o}_z=0.00417$$	kgm2
Inertia	$$I_x=I_y=I_z=0.417$$	kgm2

Simulations were conducted using these parameters for UAV mission command of takeoff to a certain altitude and return to launch. The actuator output PWM signals received by Gimbal 2 of the platform are plotted, as shown in Figure 11(a). The PWM values of the actuator outputs sent to Gimbal 2 are substantially affected by the faulty values of the parameters. A drastic increase in the platform pitch error for increased error in its parameters is observed in Figure 11(b). Since the UAV is commanded to take off and land, there is no effect on Gimbal 1 (roll response) of the platform.

[figure(s) omitted; refer to PDF]

These wrong values of mass and moment of inertia affect not only the pitch responses of the platform but also the attitude of the UAV. Figure 11(c) shows the UAV’s pitch responses to different platform masses and inertial values. Since the sensor platform control module subscribes to UAV attitude values, such unstable inputs are introduced to actuator output signal calculation and affect the outcomes, which in turn affect the development and testing of the custom module that steers the sensor platform. The effects of mass and inertial parameters of the UAV on the responses of the platform are also considered. The correct values of these parameters are given in Figure 11(d). The faulty masses ($\text{V}{\text{M}}_1=\text{V}{\text{M}}_0+2$ kg and $\text{V}{\text{M}}_2=\text{V}{\text{M}}_0+4$ kg), where $\text{V}{\text{M}}_0=9.144$ kg and VM stands for UAV mass, are used in the SDF file of the UAV model. It is observed that changes in the mass of the UAV affect actuator signal output as shown in Figure 11(d). The changes in inertial parameters of the UAV show no significant effect on the pitch response of the platform unless the magnitudes of these faulty values are significantly large.

In another mission profile, the UAV is commanded to navigate through the waypoints shown in Figure 12 and return to launch. For reference, the UAV was commanded to navigate through the waypoints while all the parameters were given the correct values in the SDF file. The UAV navigates through the waypoints with gimbals of the platform undergoing roll and pitch/yaw, as shown in Figure 13(a), to scan the environment along the flight course, accordingly. The four peaks in magnitudes of roll and yaw of the gimbals correspond to the amount of changes in the velocity vector of the UAV at the four-waypoint nodes. The change in the velocity vector or flight course of the UAV at Waypoint 1 (WP1) is lesser than the changes at other waypoints. In other words, the UAV is required to make relatively sharp turns at Waypoints WP2, WP3, and WP4 as compared to a turn at WP1. As a result, the amount of rotations of gimbals, as shown in Figure 13(a) (as PWM peaks) at the waypoints, corresponds to the amount of change in the velocity vector of the UA. The first PWM peak in Figure 13(a) corresponds to WP1.

[figure(s) omitted; refer to PDF]

The same mission, shown in Figure 12, is given to the UAV, with all model-specific parameters of the two models set correctly except for the lift coefficient (aerodynamic parameter) of the UAV. This faulty value of the lift coefficient (10% of its accurate value) is introduced to the SDF file of the UAV model. During takeoff, Gimbal 2 pitches upward, as shown in Figure 13(b) ($\text{PWM}=2000$ μs), while Gimbal 1 remains fixed. This enables the platform to orient the sensors towards the velocity vector of the UAV. There is no effect on the UAV in this flight mode (multicopter mode up to 0.6 normalized simulation times). However, the moment the flight mode is switched to fixed-wing mode (for cruise), the UAV stumbles and falls out of the sky, to which unstable roll and pitch responses of the platform are shown in Figure 13(b).

It is an extreme condition that the UAV fails out of the sky. With little error in values of aerodynamic parameters, the UAV may manage to execute the mission. Mitigating the cause of error would be challenging if multiple aerodynamic variables are given random values, and any module development and testing under such circumstances outputs inaccurate results and jeopardizes the fidelity of the module for practical use cases. From aerodynamic parameters, the effect of inconsistent lift coefficient value is considered. The study can be extended to the remaining aerodynamic parameters. However, the above tests suffice the importance of incorporating model-specific parameters into the SIL simulation process.

6. Conclusion

SIL software are essential tools for the safe and rapid development of new algorithms. However, their effective use is to the extent that they are properly customized, and correct model-specific parameters are used in the simulation processes, custom module development, and testing. In this work, the impacts of model-specific parameters on custom module development and testing are investigated. To address proper customization of the PX4 Autopilot SIL and Gazebo simulation environment, technical steps are presented. These technical steps are of interest to complete novices and practitioners who seek to test and modify their own algorithms in effective SIL simulation tools. The technical steps presented for PX4 Autopilot SIL customization can, also, be used to customize the PX4 Autopilot firmware for actual scenarios.

As a case study, a custom module that steers the sensor platform for obstacle avoidance is tested in the PX4 Autopilot SIL simulation with custom UAV and sensor platform models. Faulty values of the parameters of the models are given, and their effects are analyzed. It is shown in the simulations that a single faulty value of a parameter of either model affects not only the control of the steerable sensor platform but also the dynamics of the UAV. The above simulation results highlight the importance of proper customization of the PX4 Autopilot SIL software tool for developing and testing custom modules.

Disclosure

The preprint of this manuscript was made available online to increase the visibility of the work. This manuscript has not been submitted to another journal for publication.

Author Contributions

In this manuscript, the design, development, and configuration of custom modules and models in the PX4 Autopilot SIL and Gazebo simulation environment are done by A.T. and S.L. The overall conceptual design techniques followed in this manuscript were designed by S.K. The authors mentioned in this manuscript have been strongly involved in this study from the start to the end. The manuscript was thoroughly reviewed by the authors before its submission to the journal.

Funding

This study was supported by the BK21 FOUR program through the National Research Foundation of Korea (NRF) funded by the Korean government (Grant Number 5199990714521).

Acknowledgments

We are very grateful to the BK21 FOUR program for the support we received throughout the research works done in this manuscript.

References

[1] D. Stephanie, G. Praveen, K. Latha, "A generic solution to software-in-the-loop," MILCOM 2007 - IEEE Military Communications Conference,DOI: 10.1109/MILCOM.2007.4455268, .

[2] F. Zhennan, A. Mikael, T. Andreas, "Correlation of software-in-the-loop simulation with physical testing for autonomous driving," 2024. https://arxiv.org/abs/2406.03040

[3] H. H. Soo, C. Seong-Gyu, S. Kwon, "Real-time software-in-the-loop simulation for control education," Computer Science, vol. 33 no. 31, pp. 265-270, 2011.

[4] M. Jesus, F. Zabdi, L. Erik, P. F. Alejandro, C. Hugo, "Processor-in-the-loop and hardware-in-the-loop simulation of electric systems based in FPGA," 2016 13th International Conference on Power Electronics (CIEP), pp. 172-177, DOI: 10.1109/CIEP.2016.7530751, .

[5] C. Guowei, M. Ben, T. H. Lee, M. Dong, "Design and implementation of a hardware-in-the-loop simulation system for small-scale UAV helicopters," Mechatronics, vol. 19 no. 7, pp. 1057-1066, DOI: 10.1016/j.mechatronics.2009.06.001, 2009.

[6] H. Muhsin, B. Rahman, B. Ismail, "Designing 3-DOF hardware-in-the-loop test platform controlling multirotor vehicles," IFAC-PapersOnline, vol. 51 no. 4, pp. 119-124, DOI: 10.1016/j.ifacol.2018.06.058, 2018.

[7] B. Mohammad, T. Morteza, Z. Man, "A real-test and simulation combined platform for developing intelligent tracking control of multirotors," International Journal of Intelligent Unmanned Systems, vol. 11 no. 4, pp. 453-467, DOI: 10.1108/IJIUS-06-2022-0085, 2023.

[8] T. Tamas, S. Matyas, V. Sandor, T. Viktor, "Vehicle-in-the-loop test environment for autonomous driving with microscopic traffic simulation," 2018 IEEE International Conference on Vehicular Electronics and Safety (ICVES),DOI: 10.1109/ICVES.2018.8519486, .

[9] V. Michele, D. Nicola, L. B. Maria, T. Davide, "A software-in-the-loop simulation of vehicle control unit algorithms for a driverless railway vehicle," Applied Sciences, vol. 11 no. 15,DOI: 10.3390/app11156730, 2021.

[10] J. Sooyong, K. Yongsub, J. L. Woo, "Software-in-the-loop simulation for early-stage testing of AUTOSAR software component," 2016 Eighth International Conference on Ubiquitous and Future Networks (ICUFN),DOI: 10.1109/ICUFN.2016.7536980, .

[11] M. C. Giovanni, A. T. Milad, A. Alessandro, A. Mariano, M. Fabrizio, "Software-in-the-loop simulation of a test system for automotive electric drives," IECON 2016 - 42nd Annual Conference of the IEEE Industrial Electronics Society, pp. 1882-1887, DOI: 10.1109/IECON.2016.7794145, .

[12] C. Xiang, S. Meranda, D. Tuhin, C. Xiaoqun, "Real time software-in-the-loop simulation for control performance validation," Simulation, vol. 84 no. 8-9, pp. 457-471, DOI: 10.1177/0037549708097420, 2008.

[13] H. Antal, B. Peter, N. Mihaly, S. Erno, K. Adam, I. K. Gergely, D. Istvan, "Software-in-the-loop simulation of the forerunner UAV system," IFAC-PapersOnLine, vol. 55 no. 14, pp. 139-144, DOI: 10.1016/j.ifacol.2022.07.596, 2022.

[14] C. Calvin, P. Michal, V. H. Nathan, "Software-and hardware-in-the-loop verification of flight dynamics model and flight control simulation of a fixed-wing unmanned aerial vehicle," 2015 Workshop on Research, Education and Development of Unmanned Aerial Systems (RED-UAS), pp. 23-25, DOI: 10.1109/RED-UAS.2015.7440998, .

[15] J. Meyer, A. Sendobry, S. Kohlbrecher, U. Klingauf, O. von Stryk, "Comprehensive simulation of quadrotor UAVs using ROS and Gazebo," Simulation, Modeling, and Programming for Autonomous Robots. SIMPAR 2012, vol. 7628,DOI: 10.1007/978-3-642-34327-8_36, 2012.

[16] F. Aziz, El, A. Adnane, G. Zouhair, "Real-time software in the loop simulation for PID control of the nanosatellite reaction wheel," 2022 2nd International Conference on Innovative Research in Applied Science, Engineering and Technology (IRASET),DOI: 10.1109/IRASET52964.2022.9737929, .

[17] H. Kaveh, L. Won-Sook, "A software-in-the-loop simulation of an intelligent microsatellite within a virtual environment," 2013 IEEE International Conference on Computational Intelligence and Virtual Environments for Measurement Systems and Applications (CIVEMSA), pp. 31-36, DOI: 10.1109/CIVEMSA.2013.6617391, .

[18] W. Graham, M. John, B. Glenn, "Exploring civil drone accidents and incidents to help prevent potential air disasters," Aerospace, vol. 3 no. 3,DOI: 10.3390/aerospace3030022, 2016.

[19] M. Shoaib, S. Mana, "Software-in-the-loop simulation of a quadcopter portion for hybrid aircraft control," IOP Conference Series Materials Science and Engineering, vol. 297,DOI: 10.1088/1757-899X/297/1/012044, 2018.

[20] K. D. Nguyen, C. Ha, J. T. Jang, "Development of a new hybrid drone and software-in-the-loop simulation using PX4 code," Intelligent Computing Theories and Application. ICIC 2018, vol. 10954,DOI: 10.1007/978-3-319-95930-6_9, 2018.

[21] B. Adriano, V. F. Helosman, A. G. Poliana, C. M. Alessandro, "Guidance software-in-the-loop simulation using X-plane and simulink for UAVs," 2014 International Conference on Unmanned Aircraft Systems (ICUAS), pp. 993-1002, DOI: 10.1109/ICUAS.2014.6842350, .

[22] L. Meier, D. Honegger, M. Pollefeys, "A node-based multithreaded open source robotics framework for deeply embedded platforms," 2015 IEEE International Conference on Robotics and Automation (ICRA), pp. 6235-6240, DOI: 10.1109/ICRA.2015.7140074, .

[23] F. D'Urso, C. Santoro, F. F. Santoro, "An integrated framework for the realistic simulation of multi-UAV applications," Computers & Electrical Engineering, vol. 74, pp. 196-209, DOI: 10.1016/j.compeleceng.2019.01.016, 2019.

[24] D. B. Massimiliano, D. U. Fabio, M. Fabrizio, P. Giuseppe, S. Corrado, "3D simulation of unmanned aerial vehicles," Proceedings of the 18th Workshop “From Objects to Agents”, .

[25] L. Pitonakova, M. Giuliani, A. Pipe, A. Winfield, "Feature and performance comparison of the V-REP, Gazebo and ARGoS robot simulators," Towards Autonomous Robotic Systems: 19th Annual Conference, TAROS 2018, Bristol, UK July 25-27, 2018, Proceedings 19, pp. 357-368, 2018.

[26] K. Marian, L. Johann, R. Stephan, S. Simon, G. Roland, "Comparing popular simulation environments in the scope of robotics and reinforcement learning," 2021. https://arxiv.org/abs/2103.04616

[27] Dronecode, "Simulation of custom models in Gazebo," . Accessed January 28, 2024 https://discuss.px4.io/t/simulation-of-custom-models-in-gazebo/19037

[28] Dronecode, "Specify vehicle parameters (startup file) in SIL," . Accessed January 28, 2024 https://discuss.px4.io/t/specify-vehicle-parameters-startup-file-in-sitl/13267

[29] Dronecode, "Gazebo simulation issue," . Accessed January 28, 2024 https://discuss.px4.io/t/gazebo-simulation-issue/17898

[30] Dronecode, "Gazebo simulation," . Accessed January 28, 2024 https://discuss.px4.io/t/gazebo-simulation/18321

[31] Github, "PX4-SIL_Gazebo: iris (quadrotor) Gazebo (PX4) model modification," . Accessed January 28, 2024 https://discuss.px4.io/t/how-does-sitl-with-gazebo-work/16247

[32] Dronecode, "Create custom model for SIL," . Accessed January 28, 2024 https://discuss.px4.io/t/create-custom-model-for-sitl/6700

[33] Dronecode, "Custom UAV model to SIL," . Accessed January 28, 2024 https://discuss.px4.io/t/custom-uav-model-to-sitl/26861

[34] Dronecode, "PX4 SIL with Gazebo - custom vehicle model," . Accessed January 28, 2024 https://discuss.px4.io/t/px4-sitl-with-gazebo-custom-vehicle-model/12066

[35] Dronecode, "New custom drone SIL Gazebo," . Accessed January 28, 2024 https://discuss.px4.io/t/new-custom-drone-sitl-gazebo/27768

[36] Dronecode, "Questions about SIL from a beginner," . Accessed January 28, 2024 https://discuss.px4.io/t/questions-about-sitl-from-a-beginner/2505

[37] Dronecode, "How does PX4 SIL simulation works?," . Accessed January 28, 2024 https://discuss.px4.io/t/how-does-px4-sitl-simulation-works/19239

[38] Gazebo Answers, "Unable to add textures while following tutorial," . Accessed January 28, 2024 https://answers.gazebosim.org/question/27534/unable-to-add-textures-while-following-tutorial/

[39] Gazebo Answers, "Gazebo crash when loading a model," . Accessed January 28, 2024. https://answers.gazebosim.org/question/27515/gazebo-crash-when-loading-a-model/

[40] Gazebo Answers, "Exporting model and textures from blender," . Accessed January 28, 2024 https://answers.gazebosim.org/question/23398/exporting-model-and-textures-from-blender/

[41] Gazebo Answers, "Gazebo plugin for ZED2 camera," . Accessed January 28, 2024, https://answers.gazebosim.org/question/4619/

[42] T. Abera, J. Sunghun, L. Sangchul, K. Sangho, "Effects of model specific parameters on the development of custom module in PX4 Autopilot software-in-the-loop," . Accessed on December 26, 2024

[43] F. S. A. Mohamed, T. Girma, K. Jaerock, "Software-in-the-loop modeling and simulation framework for autonomous vehicles," 2018 IEEE International Conference on Electro/Information Technology (EIT), pp. 305-310, DOI: 10.1109/EIT.2018.8500101, .

[44] K. Nathan, H. Andrew, "Design and use paradigms for Gazebo, an open-source multi-robot simulator," 2004 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) (IEEE Cat. No.04CH37566), pp. 2149-2154, DOI: 10.1109/IROS.2004.1389727, .

[45] X. Kun, T. Shaochang, W. Guohui, A. Xueyan, W. Xiang, W. Xiangke, "XTDrone: a customizable multi-rotor UAVs simulation platform," 2020 4th International Conference on Robotics and Automation Sciences (ICRAS),DOI: 10.1109/ICRAS49812.2020.9134922, .

[46] N. D. Khoa, T. N. Trong, "Vision-based software-in-the-loop-simulation for unmanned aerial vehicles using gazebo and PX4 open source," 2019 International Conference on System Science and Engineering (ICSSE), pp. 429-432, DOI: 10.1109/ICSSE.2019.8823322, .

[47] G. Jesus, M. M. Jose, "Simulation in real conditions of navigation and obstacle avoidance with PX4/Gazebo platform," IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops), pp. 979-984, .

[48] T. Kim, D. Kim, S. Kim, Y. Kim, S. Han, "Improved optical sensor fusion in UAV navigation using feature point threshold filter," International Journal of Aeronautical and Space Sciences, vol. 23 no. 1, pp. 157-168, DOI: 10.1007/s42405-021-00423-6, 2022.

[49] H. Duoxiu, D. Wenhan, X. Wujie, H. Lei, "Proximal policy optimization for multi-rotor UAV autonomous guidance, tracking and obstacle avoidance," International Journal of Aeronautical and Space Sciences, vol. 23 no. 2, pp. 339-353, DOI: 10.1007/s42405-021-00427-2, 2022.

[50] "NASA open source parametric geometry," , . Accessed 2024-01-28. http://openvsp.org/