Software Modules
The onboard software is built upon a modular architecture where each SW Module serves as a specialized, independent functional unit. These modules are responsible for managing the core intelligence of the system: ranging from high-level decision making and mission logic to low-level hardware interfacing and health supervision.
By isolating specific tasks, such as control signal voting, data recording, and communication bridging, into distinct modules, the system achieves high reliability, easier troubleshooting, and the flexibility to scale across different hardware configurations. Each module operates within a unified communication stack, allowing for seamless data exchange and coordinated action across the entire system.
Recorder Module
The Recorder Module is the core logging engine responsible for capturing the real-time internal state of the system during operation. It monitors all internal messaging traffic and system events, streaming them into a high-density binary format to ensure minimal overhead on CPU performance and storage bandwidth. This raw binary log serves as the "black box" for the device, providing a complete, high-fidelity record that can later be extracted and processed for analysis.
Usage:
Usage: /oxc/recorder [OPTION]...
Options:
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
Monitor Module
The Monitor Module is a dedicated diagnostic utility responsible for tracking the real-time health and environmental status of the system. It continuously polls critical hardware and software metrics—including CPU load, memory consumption, and internal core temperatures—to ensure the system is operating within safe and expected parameters. By providing a live heartbeat of system performance, the module allows for early detection of resource bottlenecks or thermal issues, ensuring high reliability during intensive operations.
Usage:
Usage: /oxc/monitor [OPTION]...
Options:
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
Voter Module
The Voter Module serves as the system’s primary decision-making authority for hardware control. It acts as a multiplexer for actuator demands, receiving inputs from four distinct control sources: Failsafe, Manual, Augmented, and Automatic.
The module dynamically evaluates the integrity and availability of each source, "voting" on the most appropriate command based on a predefined priority matrix and the real-time health status of each input. This architectural layer ensures a seamless transition between control modes—such as a manual override or an automated failsafe trigger—maintaining stable and predictable vehicle behavior under varying operational conditions.
Usage:
Usage: /oxc/voter [OPTION]...
Options:
-c, --config <string> Configuration file to use.
Default value: /disk/param/failsafe.bin
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
RemoteID Module
The RemoteID Module is responsible for the continuous broadcast of digital identification beacons, ensuring the system remains compliant with airspace regulations and safety standards. It manages the transmission of real-time identity data—such as the unique serial number, location, altitude, and velocity via radio frequency (Bluetooth or Wi-Fi). This module enables external receivers and regulatory authorities to identify and track the device during operation, facilitating safe integration into shared airspace.
Usage:
Usage: /oxc/remoteid [OPTION]...
Options:
-c, --config <string> Configuration file to use.
Default value: /disk/param/remoteid.bin
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
Buzzer Module
The Buzzer Module provides acoustic feedback to the user by controlling the onboard piezo speaker. It translates system states and mission events into audible signals, ranging from simple status pings to complex multi-tone sequences. This module is essential for notifying operators of critical events: such as successful initialization, low battery warnings, or GPS lock. This is especially useful in situations where the user may not be looking at a ground station or display.
Usage:
Usage: /oxc/buzzer [OPTION]...
Options:
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
RTCM Module
The RTCM Module facilitates High-Precision GNSS positioning by processing Differential GPS correction data. It is responsible for parsing incoming RTCM v3 (Radio Technical Commission for Maritime Services) messages from an external source, such as the internal GNSS receiver.
Once these messages are validated, the module injects the correction data directly into the system's primary GNSS receiver. This process allows the receiver to transition from standard standalone positioning to a Real-Time Kinematic (RTK) Fixed state, achieving centimeter-level horizontal and vertical accuracy.
Usage:
Usage: /oxc/rtcm [OPTION]...
Options:
-s, --serial <string> Serial port to use.
Default value: /dev/ttyAMA0
-b, --baud <long> Baud rate to use.
Default value: 460800
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
Companion Module
The Companion Module manages the lifecycle and communication of the secondary onboard microcontroller. It ensures the companion processor is correctly provisioned and synchronized with the main system from the moment of power-on.
At system boot, the module performs an automated firmware check. If a version mismatch is detected or an update is required, it handles the direct upload and installation of the firmware to the companion hardware. During active operations, the module maintains a continuous communication link to exchange high-level messages and telemetry. It also serves as a supervisor, monitoring the companion’s health, task activity, and heartbeat to ensure both processors are working in lockstep.
Usage:
Usage: /oxc/companion [OPTION]...
Options:
-s, --serial <string> Serial port to use.
Default value: /dev/ttyAMA1
-b, --baud <long> Baud rate to use.
Default value: 1000000
-c, --config <string> Configuration file to use.
Default value: /disk/param/companion.bin
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
Serial-Bridge Module
The Serial-Bridge Module acts as a bidirectional gateway between the system’s internal communication stack and an external physical serial interface. It allows for the seamless exchange of data between onboard software components and external devices, such as long-range radios or ground-based units.
The module performs two primary functions. First, it parses incoming raw data from the serial port and injects the decoded messages into the internal communication stack. Second, it listens for specific internal messages via a subscription model and serializes them for transmission over the port. This functionality is typically used to bridge telemetry and command data to a Ground Control Station (GCS) or a Ground Lightforce Unit.
Usage:
Usage: /oxc/serial-bridge [OPTION]...
Options:
-s, --serial <string> Serial port to use.
Default value: /dev/ttyS0
-b, --baud <long> Baud rate to use.
Default value: 921600
-c, --compress Compress/decompress the data stream.
Default value: false
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
UDP-Bridge Module
The UDP-Bridge Module provides a high-speed network gateway between the system’s internal communication stack and an local UDP or external Ethernet or Wi-Fi interface. Similar in function to the Serial-Bridge Module, it enables the bidirectional exchange of data between onboard components and networked devices.
The module operates by listening for incoming UDP packets on a specified port, parsing the data, and injecting it into the internal communication stack. Simultaneously, it subscribes to internal messages and broadcasts them as UDP datagrams to a target IP address or network subnet. This is commonly used to interface with a Ground Control Station (GCS) over a high-bandwidth link or to communicate with other networked assets on a local area network (LAN).
Usage:
Usage: /oxc/udp-bridge [OPTION]...
Options:
-a, --addr <string> UDP address to use.
Default value: 10.0.0.1
-p, --port <long> UDP port to use.
Default value: 5555
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value:
NTRIP Module
The NTRIP Module provides the system with a network-based source for high-precision GNSS corrections. It acts as a specialized client that establishes a connection to a remote NTRIP Caster (Networked Transport of RTCM via Internet Protocol) over a cellular or Wi-Fi internet link.
The module manages the authentication and handshake process with the server to pull a continuous stream of differential data. Once the connection is established, it extracts the raw RTCM correction messages and routes them to the internal GNSS receiver. This network-sourced data enables the system to achieve an RTK Fix without requiring a physical, local base station on-site.
Usage:
Usage: /oxc/ntrip [OPTION]...
Options:
-s, --server <string> NTRIP caster server.
Default value: euref-ip.net
-m, --mountpoint <string> NTRIP mountpoint.
Default value:
-c, --credentials <string> Username and password separated by a colon.
Default value:
-a, --addr <string> UDP address to use.
Default value:
-p, --port <long> UDP port to use.
Default value: 5555
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
ELRS Module
The ELRS Module serves as the primary interface for high-performance radio control. It is responsible for communicating with an onboard ExpressLRS (ELRS) receiver using the low-latency CRSF (Crossfire) serial protocol.
The module decodes the high-speed pulse and telemetry packets from the receiver, converting them into standardized internal control demands. By leveraging the ELRS ecosystem, the module provides the system with long-range, high-update-rate RC links that are essential for precise manual or augmented control. It also handles the return path for telemetry, allowing internal system status messages to be sent back to the pilot's radio transmitter.
Usage:
Usage: /oxc/elrs [OPTION]...
Options:
-s, --serial <string> Serial port to use.
Default value: /dev/ttyAMA4
-b, --baud <long> Baud rate to use.
Default value: 460800
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
Joystick Module
The Joystick Module provides a direct interface for manual flight control by translating inputs from standard USB HID (Human Interface Device) peripherals into the internal RC command architecture. It handles the real-time scaling, dead-zone calibration, and axis-mapping required to convert raw HID inputs into the required control messages, allowing for intuitive manual piloting or payload operation.
Usage:
Usage: /oxc/joystick [OPTION]...
Options:
-j, --joystick <string> Joystick device to use.
Default value: /dev/input/js0
-c, --config <string> Configuration file to use.
Default value: /disk/param/joystick.bin
-a, --addr <string> UDP address to use.
Default value:
-p, --port <long> UDP port to use.
Default value: 5555
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
Manual Module
The Manual Module serves as the final arbitration layer for human-in-the-loop control, translating high-level RC commands into direct actuator demands. At its core is a fully configurable mixing matrix that allows operators to define exactly how joystick inputs (roll, pitch, yaw, and throttle) map to the 16 output channels. This modular approach supports a diverse range of platform configurations, from standard multirotors and fixed-wing aircraft to complex custom platforms, by applying user-defined gains and offsets to each channel before the final command is dispatched to the hardware.
Usage:
Usage: /oxc/manual [OPTION]...
Options:
-c, --config <string> Configuration file to use.
Default value: /disk/param/manual.bin
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
Navigation Module
The Navigation Module is the core sensor fusion and positioning engine of the LightForce autonomy platform. Unlike standard estimators, it utilizes a Unscented Kalman Filter (UKF) to handle the non-linear dynamics of various platforms more accurately than a traditional Extended Kalman Filter (EKF). The module is designed with a highly modular architecture, allowing developers to swap sensor sources or integration methods without rebuilding the core navigation logic.
Usage:
Usage: /oxc/navigation [OPTION]...
Options:
-c, --config <string> Configuration file to use.
Default value: /disk/param/nav.bin
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
MAVLink Module
The MAVLink Module acts as the primary communication bridge between the LightForce internal messaging bus and the industry-standard MAVLink protocol. This module abstracts the complex internal state data into standardized packets, ensuring seamless "plug-and-play" compatibility with popular Ground Control Stations (GCS) such as QGroundControl and Mission Planner. By translating high-fidelity telemetry, including the per-channel power analytics and UKF navigation states—into standard MAVLink messages, the module allows operators to utilize existing ecosystem tools for mission planning, real-time monitoring, and post-flight analysis without custom software overhead.
Usage:
Usage: /oxc/mavlink [OPTION]...
Options:
-a, --addr <string> UDP address to use.
Default value: 10.0.0.1
-p, --port <long> UDP port to use.
Default value: 9999
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 2
APM-Bridge Module
The APM-bridge Module acts as the primary communication bridge between the LightForce internal messaging bus and the ardupilot/arducopter firmware. This module simulates a VectorNav VN-100/VN-300 module in order to package the sensor data in a way that ardupilot natively supports. It is also reposnsible for bridging the MAVLink telemetry between the GCS software and ardupilot.
Usage:
Usage: apm-bridge [OPTION]...
Options:
-a, --addr <string> UDP address to use.
Default value: 0.0.0.0
-n, --nav <long> UDP port to connect to VectorNav interface.
Default value: 9001
-m, --mav <long> UDP port to connect to Mavlink interface.
Default value: 9002
-g, --gps Enable GPS output and simulate a VectorNav VN-300 instead of a VN-100.
Default value: false
-h, --help Print the help message.
Default value: false
-v, --verbose <long> Logging verbosity, from 0 (silent) to 4 (debug).
Default value: 3