# FlockAI: A Testing Suite for ML-Driven Drone Applications
## 4 Modeling and Implementation
### Drone Configuration
In this case, both \(E_{proc}\), denoting the energy consumed for compute and sensing tasks (including flight control and image/video capture), and \(E_{comm}\), the energy consumed for data exchange (including control messages), cannot be considered as negligible [26]. Unweaving Equation (2), the energy consumed by the electrical motors, \(E_{motors}\), to fly the drone can be modeled as:

\[E_{motors}=E_{takeoff}+E_{hover}+E_{move}+E_{landing} \tag{3}\]

In this equation, \(E_{takeoff}\) is the energy attributed to the drone lifted in the air till it enters a hovering state, and similar \(E_{landing}\) denotes the energy consumed for the drone to be safely grounded. In turn, \(E_{hover}\) is the energy attributed to keeping the drone in the air and is dependent to both drone and air characteristics, such as the drone mass and air density. What is more, \(E_{move}\) is the (kinetic) energy required to set a drone in motion from a hovering state. Interestingly, as denoted by [PERSON] et al. [27], \(E_{move}\) can simply be represented as a multiplying constant--modestly--affecting \(E_{hover}\) when acceleration is imposed to the moving drone (under \"normal\" weather conditions). So, assuming that movement occurs under constant velocity, meaning that the energy consumed for movement is only a fraction towards the energy contributing for stationary hovering, and that the takeoff/landing occur only once during the mission, then the following simplification can be considered:

\[E_{motors}\simeq E_{hover} \tag{4}\]

Now, to calculate the energy consumed for a drone to hover, we denote that energy consumption is equal to the power to hover multiplied by the time in the hovering state \(E_{t}=P\cdot t\). The following depicts the power to keep a drone in a hovering state, which is dependent to the mass (\(m\)) of the drone, area of the propeller (\(A\)), air density (\(\rho\)), gravity (\(g\)), and the drones' motor efficiency (\(\eta\)). \[P_{hover}=\frac{(\frac{2}{P\cdot A})^{1/2}\cdot(m\cdot g)^{3/2}}{\eta} \tag{5}\]

From Equation (2), the communication overhead of a drone can be model as:

\[E_{comm}=P_{x}\cdot t_{x}+P_{r}\cdot t_{r}+P_{idle}\cdot t_{idle} \tag{6}\]

In this equation, \(P_{x}\) is the power attributed to data transmission and \(t_{x}\) is the time in the transmission state. Similarly, \(P_{r}\) and \(t_{r}\) are the power and time consumed in a receiving state. When the communication unit is neither in a transmitting or receiving state, but still powered on (e.g., idle waiting for messages) then it consumes power, albeit significantly less, and is modeled with the values \(P_{idle}\) and \(t_{idle}\), respectively. In more complex settings, \(E_{comm}\) can be extended to also include components found in general mobile embedded systems, such as the energy consumed by the network unit if it can be placed in sleep mode along with the energy consumed for state transitioning. In a similar fashion, the compute overhead, \(E_{proc}\), of a drone's digital computing systems can be modeled as:

\[E_{proc}=P_{fc}\cdot t_{fc}+P_{soc}\cdot t_{soc}+P_{io}\cdot t_{io}+P_{ss} \cdot t_{ss} \tag{7}\]

In this equation, \(P_{fc}\) denotes the power level of the utilized flight controller (e.g., 8 W for DJI A3), while \(P_{soc}\) denotes the power utilized by system-on-chip units entrusted with domain-specific tasks, such as the ML-driven algorithms (e.g., object detection) deployed by users. The \(P_{soc}\) component can be further decomposed into the power level for when the compute unit is in active state and the minimal power consumed when idle. We particularly note that SoC power levels can drastically differ, where a Raspberry Pi microcontroller will feature in active state a power level of approximately 8 W, while a Nvidia Jetson Nano with an on-board GPU unit will consume 57 W, respectively. Finally, \(P_{io}\) denotes the power for I/O (e.g., writing to flash drive), while \(P_{ss}\) the power driving peripheral sensing devices. **The FlockAI approach**.