⚠️ PROJECT STATUS: SUSPENDED / ARCHIVEDDevelopment of this custom Python architecture has been halted. The entire software stack for the FOKA autonomous boat has been migrated to the ROS 2 (Robot Operating System 2) framework to ensure better scalability, modularity, and industry-standard communication.
This repository remains available for historical reference and to demonstrate the custom multiprocessing architecture developed prior to the ROS 2 migration.
The main goal of this project was to design a robust system for acquisition, storage, and transmission of measurement data from the FOKA research USV (Unmanned Surface Vehicle). The boat is equipped with a specific array of sensors that must collect data simultaneously at a fixed frequency.
Key design principles included reliability and flexibility. Beyond raw data collection, the system handles:
- Data Timestamping & Pre-processing: Preparing raw signals for analysis.
- Local Storage: Saving data to the onboard SD card via dedicated processes.
- Telemetry: Transmitting vital statistics to the Ground Control Station via LoRa.
To utilize the onboard computer's resources efficiently and ensure that a failure in one module does not crash the entire system, the architecture relies heavily on Python's multiprocessing.
Each sensor (e.g., pH sensor, thermometer) is handled by a dedicated pair of processes:
- Driver Process: Connects to the hardware and acquires data.
- Saver Process: Writes data to the hard drive (SD card).
A single, shared Telemetry Process handles long-range communication for all sensors.
Fig. 1: Simplified data transfer diagram for a 2-sensor setup.
Since data acquisition and storage are tightly coupled, they are managed by a common parent script (sensor_main.py).
- Mechanism: The parent process creates a
multiprocessing.Queueand passes it to both children upon spawning. - Benefit: Low overhead and simple synchronization. The parent process terminates immediately after spawning children to save resources.
Fig. 2: Direct queue passing between sibling processes.
Telemetry is a global service, decoupled from individual sensors.
- Mechanism: A
Queue Manager(frommultiprocessing.managers.BaseManager) acts as a localhost server (procesManager.py). - Producer: Sensor drivers connect to the manager's port and
put()data. - Consumer: The telemetry module connects to the same port and
get()data. - Benefit: Decoupling. If the LoRa radio fails, the manager remains active. It also allows external debugging tools to connect to the queue over the network (Wi-Fi/Ethernet) to inspect real-time data flow manually.
Fig. 3: Server-based queue management for telemetry.
The system creates a "family tree" of processes. The "lightning bolt" in the diagram below indicates processes that spawn children and then terminate (fire-and-forget).
Fig. 4: Process genealogy.
- Python 3.x
- Required Python libraries (see
requirements.txtif available) - Configured hardware (or simulation mode)
First, launch the telemetry manager which acts as the data hub. From the architecture directory:
python3 -m Telemetry.telemetry
Wait ~10 seconds for all managers to initialize.
Open a new terminal. Use the launcher.sh script to spawn sensor processes. You must specify the configuration file for the target sensor:
# Example for pH sensor
./launcher.sh ph_config.yml
This executes sensor_main.py using the specified config.
To shut down the system, run the terminator script:
python3 terminator.py
Note: If the script fails to kill all detached processes, use:
pkill python3
The following tasks were in the backlog before the project was archived in favor of ROS 2:
- Refine sensor driver code for edge cases.
- Move hardcoded logging configurations to the main config file.
- Append system health logs to telemetry packets.
- Extend logging coverage to auxiliary modules (outside the main driver).
- Final integration tests with physical LoRa hardware and RPi power management.
- Verify analog data acquisition using a potentiometer as a mock sensor.