# UV System Architecture: Challenges and Evolution
## 4 UV System Architecture Version 3: Base Station Specifications  
So far, the evolution of the architecture has been focused on the UV, but it is important and necessary to include the details of the base station. The base station is the part of the system that will provide instructions to the UV, process all the data, and send information to the user. Before showing the final version of the architecture of the UV, two options are presented. The first option involves the modification of the communication subsystem that allows the processing of the movement data. The second option is the evolution of the heterogeneous proposal, now with the option to divide the RT and no RT tasks using logical or hardware solutions. This approach is also used in the first option. Figure 4: Proof of concept of Architecture V2. The first option is based on the fact that commercial FCs offer flight stability. However, in all cases, manual operation is maintained, which is known as \"Man in the loop\". Therefore, the option of using a commercial FC but intervening in the interaction between the control and communication submodules can be considered, consisting of changing the \"manual\" operation mode to a (more) autonomous flight mode, as initially programmed. With this, the aim is to obtain an intermediate system in which the \"Man in the loop\" is no longer mandatory for the continuous operation of the drone. In this way, an operator can be dedicated to the tasks of a higher level of abstraction without having to deal with minor details such as flight correction/stability. The detailed implementation is found in [32]. The proof of concept starts with taking a 6-channel 2.4 GHz commercial receiver (the FS-IA6B [33]) and a 6-channel RC controller (Flysky FS-I6 [34]) as a reference. A study of the signals that the receiver sends to the FC according to the commands or operations of the manual control was performed. This study allowed us to replace the receiver with a NodeMCU [35] and a Quad 2-Input AND Gates CD4081 [36]. The AND gates are needed to implement \"glue logic\" to guarantee that all the signals are synchronized on the rising edge independently of the delay generated by the NodeMCU to handle them individually. Replacing the receiver with the developed one allowed us to take advantage of the stability and control solutions provided by commercial FCs to a certain extent, and by using the tools that these already have, such as configuration and calibration software, it allowed us to obtain a test environment before the flight, reducing the risk of failure. On the other hand, commercial receivers are devices designed and optimized for this specific function, in addition to having the interaction with the operator as input. The latter was quite a challenge since it involved making adaptations at the level of command execution times to obtain response times closer to those of an operator, an example of which is the inclusion of delays when  
for example, in the case of a search and rescue mission, the user is informed of the detection of the found person. The second option (Figure 6) is the continuation of the heterogenous approach. For this option, a proof of concept was developed using the Ryze Tello drone [37] as the UV. This UV is equipped with a 5 MP camera, with a flight time of 13 min, a maximum height of 30 m, and control through its own SDK, which allows:  
* Programmed control, which is essential for the UAV's path/mobility, with stability provided by its own flight control system. * Programming of/for scalar or multimedia data. * Basic automatic functions such as takeoff, landing, and maintaining the flight position or hovering (referred to as \"hover\" in the literature). The details of the proof of concept of this architecture can be found in [38], which was based on the implementation of a search and rescue application using the proposed architecture. In the field of search and rescue applications using UAVs, there are many related works.