GitHub - 19h/EPathfinder

EPathfinder: Gerbera onboard autonomy stack

Inside the recovered Gerbera aircraft, an NVIDIA Jetson Orin NX sits at the junction of the camera, flight controller, navigation services, and communication links. EPathfinder is the application that turns this companion computer into the aircraft's perception and mission layer. It decodes video, consumes flight telemetry, fuses navigation inputs, processes road and target observations, manages mission state, and issues high-level requests to a separate autopilot.

Gerbera is an expendable fixed-wing unmanned aircraft family documented in false-target, reconnaissance, and one-way-attack/"kamikaze" roles. The two aircraft examined here use the same core computing and imaging architecture: the Jetson performs the outer perception, navigation, and mission functions, while a separate flight controller remains responsible for stabilization and physical actuator output. A shared deleted test log identifies that historical controller target as ArduPilot/ArduPlane 4.5.7 on MATEKH743; it does not prove which compatible Matek PCB or revision was installed in either aircraft. Additional serial, USB, UDP, and TCP paths connect the Jetson to the camera, ELink, VNav, service clients, and optional sensors.

This repository reconstructs that Jetson application as compiling source and documents the surrounding hardware as a system. It is not the complete aircraft firmware, an airframe design, or a claim that every supported peripheral was installed. Platform attribution comes from the forensic case context—the application does not self-identify as Gerbera—so the documentation consistently separates observed hardware, configured interfaces, optional capabilities, and unknown components.

Confirmed onboard computer and imaging stack

Both recovered aircraft use the same core architecture:

NVIDIA documents P3767-0000 as the production Jetson Orin NX 16 GB module and P3768-0000 as an Orin Nano reference-carrier configuration. The latter is the software/board-support identity seen on disk; the supplied photographs resolve the actual carrier manufacturer to LEETOP. Its connector layout and revision match the LEETOP A603 V2.1 manual, but the photographed PN 900-14887-0000 differs from the current A603 catalog number 900-44887-0000. The commercial A603 designation is therefore high-confidence, while the photographed manufacturer, PN, and revision are confirmed. The KingSpec NE series is an M.2-2242, PCIe Gen3 ×2 NVMe family, and Intel documents the AC 8265 as a 2×2 Wi-Fi 5 adapter with integrated Bluetooth 4.2. See the forensic hardware inventory for unit-specific evidence and exclusions.

Physically populated carrier assembly

The photographs and operating-system evidence establish the following populated assembly:

• the P3767 module is seated in the carrier's 260-contact Jetson connector and cooled by the photographed fan/heat-spreader assembly;
• an Intel 8265NGW occupies the M.2 Key E 2230 position; its Wi-Fi function is PCIe and its Bluetooth function is USB;
• a 128 GB NVMe device occupies the M.2 Key M 2242 position; the unit-12702 storage identifies as KingSpec NE-128 2242;
• the carrier exposes Realtek Gigabit Ethernet, USB host/device connections, a CSI connector, CAN, a 40-position expansion header, and a two-pole DC input; these are board facilities, not proof that every connector was used;
• the running systems enumerated the UVC camera, a four-port USB 2.0 hub, and a USB CDC ACM device in addition to the onboard PCIe devices;
• the exact carrier connectors and wire colors used for /dev/ttyAP, /dev/ttyFC, and the camera cannot be derived from the photographs or storage images. Five discrete-line numbers survive in configuration, but the recovered unit-12702 executable does not drive them.

How the aircraft electronics fit together

flowchart LR
    GCS[Ground or service client] -->|TCP JSON / network telemetry| J
    CAM[HJ-ZOOM10-4K USB UVC camera] -->|1080p30 MJPEG| J
    FC[Historical MATEKH743 target; exact PCB unknown] <-->|UART / MAVLink| J
    EL[Responding, unidentified ELink peripheral] <-->|USB CDC ACM / ELink| J
    VN[VNav service] <-->|UDP navigation and plan checks| J
    OPT[Optional radar or Livox sensor] -->|TCP or Ethernet point data| J

    subgraph J[LEETOP carrier with Jetson Orin NX 16 GB]
        DEC[Hardware video decode]
        TG[ThunderGaze vision]
        VIS[EVision calibration and target projection]
        SC[EScout state fusion]
        PF[EPathfinder mode and guidance layer]
        VC[VehicleController]
        CC[ClientController]
        DEC --> TG --> VIS --> PF
        SC --> PF --> VC --> CC
    end

    J -.->|five retained settings; no writes in recovered build| IO[Unproven GPIO / external circuits]

The normal information path is:

1. The flight controller supplies attitude, GNSS, airspeed, RC, system status, mission state, range, and related telemetry over MAVLink.
2. EScout time-aligns and fuses flight-controller, ELink, VNav, road, odometry, and optional exact-heading observations.
3. The UVC camera feeds the Jetson media pipeline. ThunderGaze produces target and road observations; EVision converts image coordinates to angular measurements using the selected USB backend's 21-point field-of-view/zoom calibration. The separate 1,920 × 1,080 JSON grid is retained as the no-camera fallback.
4. EPathfinder combines mission state, fused navigation, and vision results into high-level modes and control requests.
5. MAVLink control handlers send mission, parameter, gimbal, and controller traffic back to the separate flight controller. The low-level actuator loops remain inside that separate controller.
6. ELink and network paths exchange vehicle state, plan data, remote-control state, targets, and launcher/configurator status. Unit 12674 also recorded six received ELink arm-test state cycles, proving a live peer on this path without identifying its board or downstream load.
7. ClientController exposes the local service API; VehicleController translates requests into vehicle state and subsystem operations.

The settings name line 11 for a green indicator, 12 for red, 33 for an arm-related pull-up, and 29 and 31 for execute-related pull-down/pull-up functions. In the original recovered unit-12702 executable, however, the GPIOController constructor ignores its final three integer arguments, VehicleLed::init and VehicleLed::setLedEnabled return immediately, while GPIOController::armTestOn, armTestOff, armOn, and selfDestruction only emit debug output and return. No GPIO library dependency or sysfs/gpiod access is present. Comparative disassembly of the recovered historical 3613 executable shows the same implementation, so the behavior persisted across at least 3613 and unit 12702's 3793M build. These integers therefore do not establish a driven connector, voltage, external load, fuze, or terminal payload. Unit 12674's later executable is absent, so the binary-level conclusion cannot be transferred to build 3815M without qualification.

Configured and optional peripherals

The checked-in configuration selects /dev/video0, /dev/ttyAP, and /dev/ttyFC; enables VNav; and leaves the backup UART, radar, remote-controller, tablet, and odometry endpoints unset or disabled. The software also contains:

• a SIYI ZR10 Ethernet/UART gimbal-camera backend; this is supported code, not the camera observed in either recovered aircraft;
• Livox SDK 2.3.0 and a point-clustering adapter; no installed Livox model is established by the two storage images;
• radar/interceptor and remote-controller TCP clients whose configured addresses are empty;
• serial, UDP, and TCP transport abstractions;
• a proprietary ELink stack and UDP telemetry transport;
• VNav plan validation, AHRS correction, target, road-point, and odometry datagrams;
• GPIO/LED abstractions and launch/execute control surfaces; their handlers are inert in the recovered unit-12702 build, and any external circuitry remains unproven.

What remains unidentified

The deployments are now constrained to the application's SH10_5 profile: a tandem-layout, attack-role, battery-electric (BEV) catalog entry with numeric weight and payload fields 17.0 and 5.0. This identifies the selected software architecture, not a public commercial model, construction material, or installed payload. The mapping is direct for unit 12702. Unit 12674 logged the same enum under the same reported 3793M build and again after updating to 3815M, but its executable is absent, so transferring the name and metadata is a strong inference rather than a byte-for-byte confirmation. GERBERA is a separate, unselected application enum; Gerbera attribution here comes from the forensic case context.

A deleted EPathfinder session shared byte-for-byte by both cloned APP images contains an actual AUTOPILOT_VERSION response. It reports flight version 0x040507ff (4.5.7, stable-version class), custom tag 45INAV06, board version 0x03f50000 (APJ board ID 1013, MATEKH743), generic ArduPilot USB VID:PID 1209:5740, and ChibiOS hash 6a85082c. This resolves the historical firmware target to the Matek H743 family, but not the exact H743-WING, WLITE, SLIM, or MINI PCB/revision, and the cloned residue cannot establish that target as the per-aircraft installed board. The same session contains live primary IMU, magnetometer, absolute-pressure and differential-pressure data. It also shows the flight controller's own GPS input at no fix while ELink reports a separate 25–27-satellite position solution. Sixty-two ELink fixes span 6.105 seconds at approximately 10 Hz but move only 0.111 m north-to-south and 0.025 m east-to-west; the flight controller is disarmed, throttle and distance-sensor altitude remain zero, and relative altitude remains close to zero. This is a stationary integration/test trace, not a flight.

The fixes center on 55.692162906, 49.250045682, approximately 565 m inside the current OpenStreetMap boundary for the Kazan Higher Tank Command School training range near Usady and on an isolated structure in the supplied satellite view. Continuous counters and changing PVT data favor a live stationary GNSS feed, but replay cannot be excluded. Because the complete fragment is cloned at the same physical offset in both APP images, the location is provenance for a common historical test/master filesystem—not evidence that either acquired aircraft visited, launched from, or was manufactured at the site. See the full geolocation analysis.

Exact GNSS, IMU, compass, barometer, and airspeed-sensor chip models remain absent. The session additionally enumerates the UVC camera's 0–736 zoom, 0–289 focus, continuous-autofocus, auto-exposure, and auto-white-balance controls, but supplies no sensor or lens identity. The recovered Mordor / Flight adapter strings still describe a historical ELink-side USB device, not the main autopilot.

The BEV class and RC-style throttle settings do not identify the motor, propeller, ESC, battery, BMS, or power-distribution hardware. The live ELink arm-test channel does not identify or prove a fuze, initiator, warhead, or other terminal payload. Antenna hardware, airframe structure/materials, and the camera sensor/lens also remain unknown. The configured Sony IMX219 node failed its I²C probe and was not the operational camera. No Quectel cellular modem was detected. The TI INA3221 resolves the Jetson module's own three-channel power monitor, not the wider aircraft power system. The separate mec vision payload remains LUKS2-encrypted: no passphrase or plaintext unlock transaction survives in either storage image, and deliberate shred/trim cleanup closes ordinary local undelete paths.

Reconstruction status

This tree is a compiling source reconstruction with all identified application component boundaries represented. Protocol, record-layout, mathematical, camera, link, MAVLink, ELink, VNav, and state-management paths have executable tests. It is not a statement-equivalent production replacement.

The current executable directly instantiates the TCP client service, VehicleController, EScout, and EPathfinder. Peripheral classes are built and tested, but the present VehicleController::Init() does not yet construct the production MAVLink, ELink, vision, VNav, Livox, radar, or GPIO object graph. ThunderGaze version-specific payload decoding, large road-matching routines, autonomous flight laws, tablet serial transport, and deployment-specific host actions remain bounded implementations. See implementation status and assumptions.

Build and test

The Livox SDK 2.3.0 and MAVLink C headers are Git submodules. Clone the repository with its dependencies:

git clone --recurse-submodules <repository-url>

For an existing checkout, initialize the pinned dependency revisions with:

git submodule update --init --recursive

Then configure, build, and test:

cmake -S . -B build -G Ninja
cmake --build build -j4
ctest --test-dir build --output-on-failure

Run the reconstructed service with:

./build/epathfinder_reconstructed

By default it reads versions.json and settings.json and exposes the local TCP service on port 8052.

Documentation

• Forensic hardware inventory
• Hardware and interface wiring
• Software component architecture
• Source-component coverage map
• Implementation status, assumptions, and quality gates
• Qt signal/slot interface inventory

Primary external references

• NVIDIA Jetson module and carrier table
• NVIDIA Orin Nano/NX module part-number table
• LEETOP A603 product specification
• LEETOP A603 Carrier Board V2.1 manual
• KingSpec NE 2242 NVMe specification
• Intel Wireless-AC 8265 specification
• ArduPilot MAVLink interface
• ArduPilot APJ board-ID registry
• ArduPilot MATEKH743 hardware definition
• Matek H743 target and sensor matrix
• OpenStreetMap KVVKU training-range boundary
• SIYI ZR10 specification
• Livox SDK product support
• Gerbera platform record