An operating system-enabled SBC provides the capabilities of thread prioritization, scheduling, synchronization, and multi-processing with Inter-Process Communications (IPC) through shared memory resources. These features greatly enhance the application code development flexibility and provide performance to accomplish more sophisticated tasks.

A hybrid architectural approach is adopted so that the original controller board can continue to perform its existing partial sensing tasks and actuator control while the SBC can handle more mathematically intensive tasks, e.g. Navigation computation, sensor fusion, and hi-level guidance and control behaviors.The ARM processor on the SBC is programmed in C code using an Eclipse-based Integrated Development Environment (IDE) in the Linux environment. For real-time application, C coding is adopted in preference to C++ which has shown to result in higher overheads and compromise the data latency for real-time sensing and control. A cross compiler for the ARM processor is used for porting the C code from a x86 code development machine to the SBC. Apart from low data latency, the SBC software is also programmed with task concurrency in mind. There are three processes running concurrently in the SBC. These processes are namely the main process, mission process and navigation process. The main process is designed and written to be concise with a small footprint to reduce the likelihood of software failure. It is designed to behave as a background program to monitor the other two processes, mission and navigation, which handle the high computational loads for the guidance, navigation and control algorithms. The mission and navigation processes are structured in a way that they have multiple threads to perform concurrency tasks. The threads in these processes are linked to each other through Inter-Process Communications (IPC). Depending on the nature of the tasks, certain tasks are to be run independently and need not be synchronized. For example, the communication and mission monitoring thread in the mission process can be run independently without needing to synchronize with other threads performing unrelated tasks. In contrast, some tasks are to be synchronized such that their threads have to meet somewhere before the process continues further.

Each sensor has different update rate and they are read independently in their own data acquisition thread but their data have to be synchronized some point in the code so that any algorithm can process the synchronized measurement data to produce proper computation. Thread synchronization is performed using mutex lock/unlock and barrier wait features, which strategically allow proper data synchronization. A mutex lock/unlock feature allows the respective thread, which is trying to access the critical code section to secure or lock the mutex so that other threads have to queue for their turns. Upon completion of the critical code section usage, the thread unlocks the mutex and thus allows next thread to access the critical code section. With regards to IPC, there are several modes that the processes use to communicate with one another in the SBC software. Signals between processes are reserved for drastic commands, such as to abort or kill an unsuccessful mission or to handle erroneous software initialization or operation. This action allows the respective processes to perform proper shutdown before the vehicle operating system can power off. The second mode of IPC is in using the message queue whereby non-data messages can be exchanged between the processes. An example is process running health status. The last and also main mode of data communications between the processes are through the shared memory (SM) which are synchronized through SYSTEM V semaphores. Each process includes an error handler, which will log errors to a log file for offline troubleshooting, and at the same time allows the code to perform safe shutdown procedures.

A Graphical user Interface (GUI) was developed for the AUDREY AUV for use during surface remote control operation. For safety reasons, if the WIFI communication breaks down, the vehicle software can sense it and automatically stop the thrusters after a 10 second timeout. The GUI also allows one to start and stop the mission when the vehicle is on the surface. Various sensor data fields also display the vehicle telemetry when it is on the surface so that the operator can check for proper functioning before starting a mission. After the end of a mission, the GUI also allows the log file to be played back in the GUI, a feature that greatly enhances debugging.