# Swarm of Drones in a Simulation Environment--Efficiency and Adaptation
## 3 Drones Swarm in Simulation Environment
### Prepared Software, Simulation Environment and Drone Modeling  
The assumptions of the simulation environment created for this article were described in our previous article [22]. The created simulation environment SITL enables the analysis of many different aspects affecting the operation of drones and drone swarms in collaboration with real drone swarm control software.  
Our SITL simulation was based on Microsoft AirSim [41]. We constructed the simulation environment using the most recent official source code and Unreal Engine. Basic 3D terrain was created, to ensure an obstacle-free space for the swarm. Physical prototypes were crafted utilizing the Holybro X500 frame, Pixhawk 6C flight controller, 2216 KV920 motors, 1045 propellers, a 4S 5000 mAh battery, and custom 3D-printed components such as the chassis, fastening elements, and covers. To bolster stability during autonomous landings, we relocated the battery to the top position and substituted the high landing gear with low-profile chassis legs directly mounted to the arms. The bottom case, safeguarding the compute module inside, serves as emergency landing gear in muddy terrain.  
Despite the variety of drone models available in the AirSim environment, none of them precisely match our physical model. For AirSim models, parameters are set in the source code, thus making it impossible to change the physical parameters of the kinematic model after compilation. To avoid this limitation, we migrated the kinematic model parameters to a settings file. Such an approach allowed effortless parameter modifications without model compilation. In contrast to the dimensions and mass of drones, which can be directly measured, determining the inertia matrix is a more intricate process. In the AirSim environment, inertia matrix computation relies on the mass and its position relative to the model's center point. For a more precise estimation of the inertia matrix, a CAD model with assigned materials of the elements can be employed. Motor parameters (encompassing thrust, torque, power, and current across RPM ranges from 30% to 100% throttle) were derived from producer documentation. Motor revolutions were capped at 9845 RPM, aligning with the maximum value measured from the documentation.  
The data transmission latency between the flight control unit and the position reporting information (PRI) interface was quantified at approximately 19 ms. Such an assumption resulted from the UART communication speed, which was set at a baud rate of 115,200 and a Mavlink message payload of 280 bytes. The data processing latency on a companion computer, specifically a Raspberry Pi 4B model, was determined to be a maximum of 10 ms. This time depended on the parameters of our custom-developed software. Moreover, the principal data processing loop within the Ardupilot framework, executed on a standard STM32H743 flight controller processor, operated at a frequency of 400 Hz (2.5 ms). The conducted simulation studies incorporated a foundational delay parameter of 40 ms. This allowed a realistic representation of the data processing time of the drone swarm.  
As part of the work, we also developed swarm control software (Figure 2) and Python-based software communication, drone behaviors, and localization based on GPS RTK data modules. The communication module supports data exchange protocols. Additionally, we created software support testing techniques: flight controller software, control systems, communication subsystems and ground stations.