Goat Bridge: Rust and X-Plane Integration

Orbit climb in a real X-Plane instance, driven by a synthetic bridge scenario. The cockpit view is cropped to exclude private diagnostic logs; original timing is retained.

Role: Joe owns the simulator integration and engineering direction. AI-assisted implementation spans the Rust service, native X-Plane plugin, operator console, repeatable scenarios, and evidence capture. The published recordings document a working engineering bench integration.
System boundary: A Rust service receives flight-state datagrams, validates them, and forwards state to an X-Plane plugin. A thin C++ shim reaches the simulator SDK, while Rust handles the plugin logic. Simulator readback and terrain results return through the service; a separate desktop console observes the service and requests control.
Primary constraint: Keep the external flight model authoritative while applying state through X-Plane's native plugin boundary.
Strongest evidence: Separate orbit and takeoff recordings pair real X-Plane motion with a running bridge console and four remote simulator views. The input trajectories are software-generated.

The situation

An external flight model needs a visual world, and the visual simulator needs a trustworthy stream of aircraft state. The integration also needs to return terrain and environment information, show what each link actually observes, and make control ownership explicit.

A moving aircraft is only part of the result. Engineers need to distinguish received state from applied state, a live link from an attempted connection, and a synthetic scenario from a physical real-time target.

Constraints

Keep the external flight model authoritative while applying state through X-Plane's native plugin boundary.
Keep simulator SDK calls on the simulator thread; isolate transport, validation, and operator control from that boundary.
Distinguish software-generated scenario inputs from physical Speedgoat hardware. The supplied demonstrations use synthetic inputs with a real X-Plane instance.
Keep orbit and takeoff as separate scenarios. A validated continuous transition between them is not demonstrated.

My responsibility

Joe owns the simulator integration and engineering direction. AI-assisted implementation spans the Rust service, native X-Plane plugin, operator console, repeatable scenarios, and evidence capture. The published recordings document a working engineering bench integration.

The system

A Rust service receives flight-state datagrams, validates them, and forwards state to an X-Plane plugin. A thin C++ shim reaches the simulator SDK, while Rust handles the plugin logic. Simulator readback and terrain results return through the service; a separate desktop console observes the service and requests control.

Architecture descriptionFlight-state source to Rust service to native X-Plane plugin to simulator. Readback, terrain, and environment data travel back through the service. A separate operator console observes status and submits commands. Synthetic validator modes replace the hardware source for the recorded bench scenarios.

Critical decisions

Keep the simulator boundary small

Choice: Use a thin native shim for SDK access, with Rust owning the service and plugin behavior and thread-affinity guards constraining SDK calls.
Alternatives considered: Let the plugin own the inbound socket while a separate application monitors it.
Tradeoff: Separate components require explicit protocols and lifecycle handling, but keep blocking work away from the simulator's main thread.

Measure what the simulator applied

Choice: Return plugin readback and observed link state to the console, alongside counters and source provenance.
Alternatives considered: Treat a successful send or a connected socket as proof that the aircraft state was applied.
Tradeoff: More telemetry needs careful interpretation: a sent return packet is not proof of hardware receipt, and an inactive check is not a passing check.

Make bench scenarios repeatable

Choice: Provide distinct orbit, takeoff, and approach generators so the real service and simulator path can be exercised before hardware integration.
Alternatives considered: Require the physical real-time target for every iteration.
Tradeoff: Software-generated inputs shorten the feedback cycle, but cannot qualify the physical target, deployment, or release behavior.

Proof

Recorded simulator bench integrationSeparate orbit and takeoff recordings pair real X-Plane motion with a running bridge console and four remote simulator views. The input trajectories are software-generated.

Evidence boundary: September 2026 source and capture package. Real service-to-plugin operation and visible X-Plane response under synthetic scenario input. Public clips retain source timing, remove audio, and crop or mask private diagnostic details. The recordings are evidence of those bench sessions, not a new hardware run.
Known limits: No physical Speedgoat validation, certified flight model, production-ready release, or end-to-end latency guarantee is claimed. Capture starts were loosely aligned, not frame-synchronized. The mosaic encodes repeated cached snapshots. The package also records link re-establishment and a takeoff autonomy release; continuous fault-free operation and a seamless takeoff-to-orbit transition are not established.

Engineering signal

Making integration behavior inspectable

This work connects systems programming, simulator APIs, operator experience, and evidence-driven debugging across a real application boundary.

Systems integration

Rust services, native SDK access, structured messages, and a desktop console cooperate around one explicit state boundary.

Operator visibility

The console exposes link state, traffic, readback, and control ownership so an engineer can investigate what happened.

Verification judgment

The case study separates visible simulator behavior from hardware integration and release claims the evidence does not establish.

Captured evidence

Evidence gallery

Open the evidence video

Orbit console detail from the same capture window as the hero video. This crop focuses on the service, plugin, and simulator links; the input is synthetic. Players run independently.

Open the evidence video

Four views of the orbit. The source provides roughly one fresh snapshot every six seconds; held frames and black bars are preserved. Machine labels and diagnostic overlays are masked.

Open the evidence video

Takeoff roll is a separate recorded scenario, not the beginning of the orbit video. Cropping removes the diagnostic log window without changing playback speed.

Open the evidence video

Takeoff console detail. Traffic and readback describe this recorded session; they do not establish physical target integration or fault-free release behavior.

Open the evidence video

Four takeoff views with the original low snapshot refresh preserved. The five-fps encode repeats images between updates; it is not a measure of simulator frame rate.

Full Goat Bridge console with control ownership, link status, telemetry charts, and diagnostic flags while the bridge is idle. — The full operator interface before a run. This original screenshot is IDLE, not a live-traffic claim; the adjacent recordings show the bridge running. Open the full-size image to inspect the console.

Reflection

Bench recordings show the bridge driving real X-Plane motion and reporting simulator readback. Physical Speedgoat integration and release qualification remain open.

A status indicator needs a defined observation behind it. Connection attempts, transmitted packets, received packets, and applied state answer different questions.
Test generators are valuable only when their synthetic origin stays visible and their results are not presented as hardware validation.
Recording cadence is not information rate: the four-view mosaic holds cached images between updates, even though its video container plays at five frames per second.