# UV System Architecture: Challenges and Evolution
## 3 UV System Architecture Version 2: Heterogeneous Approach  
It is possible to change the device (Arduino) for one with higher capabilities and, at the same time, establish limits on consumption, size, and weight. These limits or characteristics will limit the use and selection of processing devices. There is also the alternative of a heterogeneous solution, which involves the use of two or more devices between which all the required tasks are executed. In that order, the architecture changes to a heterogeneous solution, as shown in Figure 3 [24].  
The proof of concept for the architecture is shown in Figure 4. The SYMA X5 HW [25] was modified by adding a Raspberry Pi Zero W (The Raspberry Pi Foundation, Cambridge, UK) with a camera for image capture (the no Real-Time Part), so the flight controller of the SYMA was left alone in the Real-Time task in the case of the drive subsystem.  
Tasks that require real-time processing, such as those identified as \"hard real-time\" (for example, a flight controller), will be performed by the Arduino board or another board that meets the real-time requirements. On the other hand, tasks that do not require real-time processing or that are of the \"soft real-time\" type will be carried out by a board with greater capacity, such as the Raspberry, as would be the case of image capture and/or tasks such as encryption or checksum review.  
Figure 3: Architecture V2.  
The choice to use Arduino as a flight controller can be found in [26], while the choice to use Raspberry as a device for video capture and streaming can be observed in [27]. The use of a heterogeneous architecture using Arduino and Raspberry boards can be seen in [28] for an irrigation system, while [29] presents a shell-fishing application. For UGVs, we reference the works of [30] and [31], which are the closest to our proposed system in terms of using the architecture for UVs in a general way.  
Our proposal implies additional energy consumption from the processing of the two plates, in addition to the extra weight that they impose on the UV, so the power and management subsystems must be adapted and implemented with these new configurations.  
Regardless of the use of a Raspberry device as hardware, the heterogeneous architecture will allow the correct execution of tasks, such as flight control and sensory processing. Additionally, it is important to ensure communication channels are not overlooked since, if only one channel is used to send both flight commands and sensor data, the channel can be occupied. The above is the result of making multiple extra shipments, for example, when having to resend an image. This could jeopardize the UV's stability. This is why having two devices can generate two or more different exclusive communication channels per device, allowing one to be used for everything related to control and the other for the rest of the tasks. These tasks would be, for example, telemetry or information from sensors that are not categorized as hard real time.  
This proof of concept shows that the architecture is viable, but, like version 1, presents a limitation. In this case, the limitation is in the base station. It is common for commercial drones of UVs to have closed systems. For Syma, the drive subsystem only works with the app that the fabricators provide, which means extra work is necessary to control all the subsystems from a single base station. The challenge here is focused not only on the use of a heterogeneous approach but also on the integration of the base station and obtaining an equilibrium between weight, power consumption, and processing capability.