Unmanned Systems Technology 017 | AAC HAMR UAV | Autopilots | Airborne surveillance | Primoco 500 two-stroke | Faro ScanBot UGV | Transponders | Intergeo, CUAV Expo and CUAV Show reports

43 Autopilots | Focus has standards for three levels of printed circuit board: IPC 1, 2 and 3.  IPC 3 is for safety-critical devices, and is the appropriate standard for circuit boards designed for UAV autopilots. It applies to the circuit board design and the manufacturing process, but adds significantly to the cost of the board – a board designed and manufactured to IPC 3 but without any electronic components installed can cost more than some complete low-cost autopilots. Accelerated life testing is an important tool in the design phase of a product. The testing applies extreme stresses to a board to reveal any latent design faults that are difficult to find with normal testing. It is essentially destruction testing, stressing the boards until they break and then identifying any failure mechanisms and designing them out. This helps to improve the reliability of the design. Software reliability Reliability is a challenge for the software as well. Hardware is a bit easier than software, with infant mortality as the main issue to identify boards that are vulnerable to failure. Also, as the autopilot becomes more complex there are more connections on the circuit board that can fail. The software for a simple modern autopilot can fit in the memory on the same chip as the microcontroller, but as the autopilot becomes more sophisticated, off-chip RAM and flash memory has to be added. That then means having about 50 signal lines going from the microcontroller to the memory, and if any one of them fails then the whole autopilot fails. This is a key issue with adding autonomous operation to autopilot software. However, adding autonomy through additional modules also increases the risk of failures. Software testing Software test tools such as a unit test tool, static code analysis, issue tracking and regression testing are useful, but none of them on their own will solve all the problems with software reliability. There is also a significant trade-off between software reliability and the need to make modifications to suit a customer’s needs. Lots of different modifications to the code base require a lot of additional testing and certification. One way around that is to use open source code developed specifically for autopilot applications. These are well- established and tested, with a wide community able to review the code. That allows developers to add their own code alongside. It can be added to existing autopilot hardware that, for example, includes a 5.8 GHz data link capable of streaming full HD video and telemetry up to 2 km back to a user. The autopilot runs the open-source firmware on a controller with two processor cores, alongside two temperature-controlled IMUs, a wide-range Hall sensor-based power module and an external GNSS module to provide the sensor data the autopilot needs. Yet another way is to use a modular architecture that can support different sizes of craft in the air as well as on land and sea. This is where each component of the system has its own microcontroller providing data processing and comms with other components within the CAN network. The architecture avoids loading the central processor with routine tasks by distributing management tasks to all system components. At the same time, there are effectively no restrictions on the number of modules of the same type that can be used, which makes it possible to implement multiple redundancy on all levels. That means almost any payload, third-party modules or even entire systems can be connected to the system via electrical interfaces. This often requires custom cabling though, and can reduce the overall reliability of the system, as additional cabling can be a source of failures. This approach opens up further options for redundancy, as multiple independent boards can be installed in the autopilot. Current algorithms allow two boards to provide redundancy with a failover manager that can move control to the redundant board if the main board fails. The main boards of the system are universal and can be used for the smallest UAVs as well as heavy ones with a take-off weight of more than 1200 kg. Increasing the size and complexity of a UAV’s systems changes the number of modules, the casing and the topology of the onboard electrical circuits, potentially reducing the overall reliability of the system as more modules are added. Such an approach reduces the workload on the development support teams, simplifies project engineering and development of the overall system. Naturally, the cost for small UAVs grows significantly but it provides high reliability for professional equipment. A flexible architecture also allows quick connection of various modules and systems to extend the functions of the unmanned platform and synchronise work. For example, it is possible for one operator to control several unmanned systems simultaneously from one place, whether they be on the ground Unmanned Systems Technology | December/January 2018 It takes time to design a UAV, and once there are a lot of them on the market, changing an autopilot involves a lot of work