AprilTag · Raspberry Pi 4B · ROS 2 Jazzy · CV / IMM / GHOST-MH
Autonomous Object Tracking for Follower-Drone Applications
GHOST-X detects an AprilTag-marked object, estimates its camera-frame pose, maintains target state through temporary visibility loss, and exposes a state interface suitable for downstream follow behavior.
Actual scope: the vision and tracking backbone was exercised on Raspberry Pi hardware under guided tabletop conditions. Follower-drone navigation was evaluated in deterministic local-frame software simulation. No physical drone was flown. No physical closed-loop drone flight was performed.
Measured hardware
Synthetic software
Verification
Requirement not met
Follower interface
software output
software output
AprilTag target
tag36h11 · ID 0
tag36h11 · ID 0
VISIONmeasurement → estimate → state
01 · What this project is
A vision system that keeps track of a marked object
GHOST-X is a target-tracking and state-estimation system for a vision-guided follower drone. A USB camera detects an AprilTag attached to an object, estimates where that object is relative to the camera, and continues producing target-state estimates during brief visibility loss. This is the perception and estimation backbone that a downstream controller could use for follow behavior. The project did not fly or control a physical drone.
Measured hardwareGuided tabletop campaign
Hardware tracking backbone
A Raspberry Pi 4B and USB webcam observed a printed AprilTag. The pipeline produced pose measurements and simultaneous tracker outputs, including prediction-only and degraded states during target loss.
- TargetAprilTag tag36h11, ID 0
- ComputeRaspberry Pi 4 Model B Rev 1.5
- ValidationRelative response and short-dropout reacquisition
Synthetic softwareDeterministic local frame
Follower-drone mission logic
The software mission evaluator used camera line-of-sight gating, tracker prediction, obstacle-aware reposition commands, and reacquisition logic. The observer pose and map were known by the simulation.
Loading measured and synthetic mission evidence…
02 · Why this matters in aerospace and defense
The same estimation problem appears across autonomous vehicles
GHOST-X is not a deployed defense system and has no affiliation with an operational aerospace program. The relevance is technical: estimating a moving target through uncertainty, visibility loss, and conflicting motion hypotheses is a recurring autonomy and GNC problem.
Rendezvous and proximity operations
Spacecraft docking and inspection require relative-target estimation, uncertainty management, model switching, and safe behavior when measurements are temporarily unavailable.
UAV following and inspection
Follow-me, infrastructure inspection, and search-and-rescue concepts depend on stable target state, explicit visibility status, and controlled reacquisition after occlusion.
Multi-sensor target tracking
Ground vehicles, swarms, and guidance systems use related Kalman-filter, multiple-model, and multi-hypothesis methods to track uncertain motion without pretending one model always wins.
03 · System components
What the system is built from
Hardware, software, and estimators are listed together so a reviewer can see the complete stack before opening any chart.
| Component | What it is | Role in the system |
|---|---|---|
| AprilTag fiducial marker | tag36h11, ID 0, nominal 0.1 m | Provides a known, detectable target geometry. |
| USB camera | eMeet C960, UVC/V4L2 | Captures images of the marked target. |
| Raspberry Pi 4B | Edge compute platform | Runs the vision, estimation, tracking, logging, and ROS 2 pipeline. |
| Pose estimation | AprilTag detection + solvePnP | Converts detected tag corners into a camera-frame 3D position estimate. |
| CV Kalman filter | Baseline constant-velocity estimator | Provides a simple, low-cost tracking baseline. |
| Formal IMM | Interacting Multiple Model estimator | Combines multiple motion models and adapts their probabilities under the tested conditions. |
| GHOST-MH | Multi-hypothesis tracker | Maintains multiple possible target-state futures when motion or visibility is ambiguous. |
| ROS 2 Jazzy | Robotics middleware | Moves measurements, estimates, status, and evidence between components. |
| ICM-42688-P IMU | Inertial-sensor driver implemented; physical campaign evidence not retained | Intended future sensor-fusion input; not presented as validated hardware in this campaign. |
04 · How it works
From printed tag to downstream follow-state output
The complete flow is visible below without interaction. The expandable stage view then exposes inputs, outputs, failure modes, and supporting evidence.
- 01AprilTag target
A printed tag supplies known geometry and a stable visual identity for the object being followed.
- 02USB camera
The eMeet C960 captures timestamped images of the target through Linux UVC/V4L2.
- 03Pose estimation
AprilTag corners and camera calibration feed solvePnP to produce a camera-frame position measurement and covariance metadata.
- 04Tracking layer
CV, formal IMM, and GHOST-MH consume the same measurement contract and output estimated state, prediction status, and validity through visibility loss.
- 05Follow interface
The software exposes relative target state and status for downstream navigation logic; physical drone control was not validated.
Inspect the evidence behind each stageClickable technical detail
Loading evidence-backed stage details…
05 · Results at a glance
What was demonstrated—and what was not
This is the plain-language takeaway before the detailed dashboards. Measured hardware, synthetic software, and requirement failures remain visibly separated.
Under 24 controlled software trials, formal IMM produced the lowest overall and hidden-period tracking error, while GHOST-MH produced the highest error in that campaign but beat constant velocity in one specific measured dropout proxy. On Raspberry Pi hardware, the system reacquired the AprilTag after one 2.4510 s occlusion without a reset. All 12 declared software-injected fault cases met their predeclared detection, isolation, and accepted-recovery criteria. Two real-time requirements—RT-001 and RT-002—were not met on the retained hardware run and remain disclosed prominently.
Formal IMM had the lowest tracking error
Across 24 deterministic analytic-truth trials with identical inputs, formal IMM had the lowest overall and hidden-period RMSE. GHOST-MH had the highest RMSE in that campaign, although it beat constant velocity in one measured short-dropout proxy and did not beat the last-seen hold.
Source: GHOST_X_G10_CI_REPORT.jsonThe target was reacquired after a 2.4510 s hide
On the Raspberry Pi hardware setup, the single intended stationary-target occlusion ended with reacquisition and no tracker reset. This one event does not establish a repeated-trial success rate.
Source: GHOST_GUIDED_HARDWARE_VALIDATION_20260716.jsonAll 12 declared fault cases met their acceptance criteria
Each injected case was detected, isolated to the expected path, and returned to nominal or its predefined accepted recovery state. Shared-stream RMSE and recovery values are not independent physical degradation experiments.
Source: GHOST_X_G8_FAULT_REPORT.jsonRT-001 and RT-002 failed on the retained Pi run
Nominal latency exceeded the declared p95/p99 limits, and the observed publication rate was 3.4433 Hz versus a 29.7 Hz minimum. Hard-real-time, production-readiness, and flight-worthiness claims are withheld.
Source: GHOST_X_G9_RUNTIME_REPORT.json06 · Detailed evidence
Replay, estimator comparisons, hardware results, faults, and runtime
The following sections preserve the full evidence presentation: source classifications, sample sizes, equal chart scales, null results, failed requirements, and direct links to retained files.
Detailed evidence 01 · Recorded hardware replay
Scrub through the guided trial exactly as recorded
This is a data replay, not reconstructed camera footage. Every measurement point, event, and selected tracker point comes from retained JSONL records. No smoothing, interpolation, or synthetic filler is presented as captured data.
Measured hardware
Browser cue window with reviewed ±1.0 s analyzer padding
Loading hashes and sample counts…
XY stateRecorded measurement and estimator tracks
Lines connect recorded points for readability; cursor values use the latest actual sample at or before the selected time.Time historyCamera-frame X position and event markers
Missing measurements remain gaps; they are not filled.View replay data provenance and source hashes
Detailed evidence 02 · Fair estimator comparison
Same inputs, same scenarios, same chart scales
Overall and hidden-period errors come from 24 deterministic analytic-truth trials across eight scenario families. Runtime values use matched Raspberry Pi Python-reference rows with zero stress workers.
Synthetic software · N=24
Measured Pi runtime · Python reference · no stress
Symmetric reacquisition time and reset count were not retained; the page shows them as unavailable rather than zero.
Position errorOverall and hidden-period RMSE
Zero-based shared scaleExecution costp99 and maximum runtime
Matched Pi Python-reference rowsDetailed evidence 03 · Occlusion and dropout results
Two distinct evidence sets—no duplicate scenario labels
The measured short hide is one stationary-target event (N=1). The long-hide result contains two synthetic obstacle occlusions from one deterministic mission execution.
Loading scenario…
Detailed evidence 04 · Directional and range response
Movement-response tests kept separate from occlusion evidence
Lateral and closer/farther trials evaluate relative camera-frame response. They contain no retained occlusion or reacquisition metric and are not counted as dropout tests.
Loading response…
Detailed evidence 05 · Hardware validation
What the Raspberry Pi campaign actually recorded
Component identity, calibration, rate, memory, temperature, and throttling fields below are populated only when a retained source exists.
Camera calibration is not absolute system calibration
The retained reprojection RMS supports the camera model used for pose estimation. It does not validate metrology-grade target position accuracy.
ICM-42688-P implementation status
Driver/interface code exists. Physical sensor identity, WHO_AM_I, data rate, and campaign data validation were not retained.
Detailed evidence 06 · Fault and robustness testing
Twelve software-injected cases, retained individually
These are deterministic software injections—not claims that every corresponding physical hardware fault was reproduced. Detection, isolation, recovery, and per-tracker error remain visible for every case.
What “12 / 12 passed” means
Loading fault acceptance definition…
Shared-stream metric boundary
Loading fault metric interpretation…
RecoveryRecovery time for every retained fault case
Same axis for all cases| Fault | Detected | Isolated | Recovered | Recovery time | CV RMSE | IMM RMSE | GHOST-MH RMSE |
|---|
Detailed evidence 07 · Runtime and deployment readiness
The timing requirements did not all pass
RT-001 and RT-002 failures are retained prominently. This campaign does not support hard-real-time, production-readiness, or flight-worthiness wording.
Publication-rate root cause not established
Loading runtime interpretation…
One unresolved execution-time anomaly
Loading deadline-row interpretation…
Reporting check versus requirement result
Loading claim-governance interpretation…
Estimator deadlinep99 and maximum execution time vs 33.333 ms
Python reference and C++ production rows are labeled separatelyWhat passed
What did not pass
07 · Limitations & Claim Boundaries
What this project does not establish
This section is intentionally permanent and visible. No independent metrology-grade ground truth was available, and a reviewer should not need to infer where the evidence stops.
Original floor-grid capture
The camera/tag geometry was not moved between nominal grid positions. The resulting calculation is excluded from absolute position accuracy claims.
Last-seen hold beat GHOST-MH
In the single stationary short-dropout proxy, GHOST-MH beat constant velocity but not the stationary last-seen hold.
Hard-real-time wording withheld
RT-001 and RT-002 failed, and one C++ CV maximum exceeded the predeclared deadline.
08 · Evidence downloads
Download the reports, data, and reproducibility evidence
The interactive page is a navigation layer over retained JSON, CSV, reports, raw-source hashes, tests, and a checksum-published release.
Show claim-to-source evidence map
| Claim key | Supporting files |
|---|
34 / 34requirements traceable
47 / 47deterministic evidence checks passed
123files reproduced with identical tree hashes
ghost-x-v1.0.0checksum-published release
Static review copies
