# FlockAI: A Testing Suite for ML-Driven Drone Applications
## 4 Modeling and Implementation
### Drone Configuration
\begin{table}
\begin{tabular}{p{42.7 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt}} \hline
**Scenario No.** & **Drone Controller** & **Autopilot** & **Monitoring** & **ML Algorithm** & **ML Execution** \\ \hline \multirow{2}{*}{1-A} & \multirow{2}{*}{DJIMavic2} & Bounding Box ZigZag Pilot & Flight, Compute, Comp and Energy Probes & \multirow{2}{*}{-} & \multirow{2}{*}{-} \\  & & Bounding Box ZigZag Pilot & Flight, Compute, Comp and Energy Probes & & \\ \multirow{2}{*}{1-B} & \multirow{2}{*}{DJIMavic2} & Bounding Box ZigZag Pilot & Flight, Compute, Comp and Energy Probes & & \\  & & & Flight, Compute, Comp and Energy & & \\  & & & Flight, Compute, Comp and Energy & & \\  & & Zig Zag Pilot & Propes & & \\ \multirow{2}{*}{2} & \multirow{2}{*}{DJIMavic2} & Bounding Box Zig Zig Pilot & Flight, Compute, Comp and Energy Probes & & \\  & & & Flight, Compute, Comp and Energy & & \\ \multirow{2}{*}{3-A} & \multirow{2}{*}{DJIMavic2} & Bounding Box Zig Zig Pilot & Flight, Compute, Comp and Energy Probes & & \\  & & & Flight, Compute, Comp and Energy & & \\ \multirow{2}{*}{3-B} & \multirow{2}{*}{DJIMavic2} & Bounding Box Zig Zig Pilot & Flight, Compute, Comp and Energy Probes & & \\  & & & Flight, Compute, Comp and Energy & & \\  & & Zig Zag Pilot & Propes & & \\ \hline \end{tabular}
\end{table} 
Table 2: Use-case scenarios key configurations for reproducibility However, despite the significance of \(E_{motors}\) when the ML task is enabled, \(E_{proc}\) contributes to approximately 21% of the total energy and this is far from being considered as negligible. The additional energy consumption is, of course, attributed to the ML algorithm. In order to further understand the impact of the ML algorithm on the energy consumed for processing (ML), we use FlockAI monitoring data to further decompose the \(E_{proc}\) component into its sub-components. These, are depicted in Figure 7, where we observe that the majority of the energy for processing, is consumed by the CPU when in active state (\(\sim\)79%) and this, of course, is attributed to the overhead imposed by the ML inference algorithm. Moreover, one can also observe that a fraction of the overhead is also attributed to the use of the flight controller (\(\sim\)9%) and another to the CPU when in idle state (\(\sim\)10%), while the I/O overhead is minimal (\(\sim\)1%) since images are not stored. In regards to the total flight time, when deploying the ML task and performing on-board inference the flight time is reduced from 30 min and 6 s to 24 min and 48 s. Finally, we reiterate that an ML practitioner undergoing this experiment, now, has answers for both Q1 and Q2 of the questions presented in Section 2. Figure 5: Energy decomposed into components (No ML). Figure 6: Energy decomposed into components (On-board ML with CNN). ### Scenario 2: Remote Inference

This experiment scenario resembles Scenario 1, but with a key differentiating factor: the ML algorithm is run remotely, and specifically, on the ground station. Hence, during the flight the drone is programmed to continuously collect both the camera feed and positioning data, with these streamed to the ground station through an open Wi-Fi link established between the drone and the ground station. Figure 8 depicts the energy consumption decomposed for when inference is performed remotely. Comparing the results of this experiment with the previous, we immediately observe that the energy consumption for communication is higher, and specifically, 16% higher compared to the No-ML scenario and 12% when performing on-board inference. Obviously, the key difference is that \(E_{comm}\) is now attributed as the second energy consuming component, which is due to the fact that the wireless link is open throughout the flight and a data payload is exchanged with the ground station. In turn, we observe something that may not be immediately evident. Despite the fact that inference is performed remotely, \(E_{proc}\) has not dropped to the value it had when a non-ML flight was executed.