## 4 Experiments
### DPIV on Raspberry Pi  
DPIV is computationally expensive on the raspberry pi hardware even when cross correlation is implemented with FFT (see Equation (2)). In implementing our algorithm, we used the OpenPIV library ([[http://www.openpiv.net](http://www.openpiv.net)]([http://www.openpiv.net](http://www.openpiv.net))), a community driven initiative to develop free and open-source particle image velocimetry software. Since in our BeePi monitors all data capture and computation is done on raspberry pi computers, it is imperative that DPIV run on the raspberry pi hardware. We tested our algorithm on a single raspberry pi 3 model B v1.2 computer on several 30-s videos from our dataset. The video frame size was \(640\times 480\), the interrogation window size was 90, and the interrogation window overlap was 60%. On average, it took \(\approx\)2.5 h for the algorithm to process a single 30-s video. This result is unacceptable to us, because each BeePi monitor records a 30-s video every 15 min from 8:00 to 21:00 every day. An obvious solution is cloud computing where the captured videos are processed in the cloud by a collection of GPUs. We rejected this solution, because from the beginning of the BeePi project in 2014 we made it a priority to avoid external dependencies such as continuous Internet and cloud computing. In remote areas, BeePi monitors should function as self-configurable and self-contained networks that rely exclusively on local area networking mechanisms (e.g., as an ad hoc network). Since the raspberry pi 3 model B v1.2 computer has four CPUs, we decided to introduce multi-threading into our algorithm to reduce video processing time. A BeePi monitor records videos at \(\approx\)25 frames per second. Thus, a 30-s video generates 743-745 frames. Each thread ran on a separate CPU to process a subset of frames. Specifically, Thread 1 processed Frames 1 processed 185, Thread 2 processed Frames 185-370, Thread 3 processed Frames 370-555, and Thread 4 processed Frames 555-743/745. It should be noted that, to handle boundary frames, there is a one frame overlap between the ranges because DPIV works on pairs of consecutive frames. Multi-threading reduced the average video processing time from 2.5 h to 1 h 12 min. After multi-threading, we introduced parallelism to our system by distributing the algorithm's computation over six raspberry pi computers. We chose to experiment with six raspberry pi computers, because they easily fit into a single deep Langstroth super (i.e., a wooden box) placed on top of a beehive [26; 27]. The current BeePi hardware also fits into a single deep super. In this six-node network, one node acts as a dispatcher in that it captures video via a raspberry pi camera and dispatches video frames to the other five nodes that process them and return the results back to the dispatcher. In this architecture, the dispatcher sends Frames 1-148 to Node 1, Frames 148-296 to Node 2, Frames 296-444 to Node 3, Frames 444-592 to Node 4, and Frames 592-743/745 to Node 5. Each processing node uses multi-threading, described above, to compute directional vectors, classifies them as incoming, outgoing, and lateral, and returns these vector counts to the dispatcher. We timed each task in the system on ten 30-s videos. Table 6 details our measurements. The sum total of the third column is equal to 1169.462 s \(\approx\) 19.49 min, which is the total time our six-node network takes to process a 30-s video. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Task** & **Executive** & **Time (in sec)** \\ \hline Frame Generation & Dispatcher Node & 70.826 \\ \hline Frame Dispatch & Dispatcher Node & 211.116 \\ \hline Frame Processing & 5 Processing Nodes & 887.52 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Average video processing performance of six-node ad hoc network. Through multi-threading and parallelism, we managed to reduce the processing time of a single video from 2.5 h to below 20 min, which makes it feasible to process all videos captured in one 24-h period.