Vehicle & Aircraft Control

One of the domain options on the wizard’s first step. Pick this and the modules, solutions, and parameters that follow are filtered to the vehicle/aircraft side — you won’t see Home Datacenter or Edge AI things in the menus.

This page explains why the wizard is carved up this way. If you just want to click through, go to the browser wizard; if you’re tailoring your own solution and want to understand the trade-offs between parameters, this page gives you the mental scaffold.

The model is borrowed from the open-source quadcopter project Flix and extended to ground vehicles and hybrid setups. Flix itself is not a turnkey FPV car kit, but its firmware lays out the “vehicle control chain” cleanly enough to serve as a teaching skeleton.

One core principle

Keep the control chain and the video chain separate.

Video can drop a frame; control must not stutter with it. That’s why the wizard’s solution step exposes three logical chains with priorities rather than asking you to pick one “wireless protocol” — each chain solves a different problem and tolerates different failures.

The three logical chains

The wizard asks you to declare a position on each chain independently: quality / range / how much budget. The three answers together pick out the solution pool.

Don’t forget wired direct is a legitimate choice — for desk debugging or workshop scenarios, USB/UART straight into the vehicle’s main board is often the cleanest link.

The 6-layer stack

Borrowed from Flix’s imu.ino / rc.ino / estimate.ino / control.ino / motors.ino / mavlink.ino decomposition:

1. Vehicle main MCU — RC input → failsafe → control logic → motor / servo output. ESP32, ESP32-S3, or “upper SBC + lower MCU”.
2. Actuators — H-bridge (brushed), ESC (brushless), servo (steering / gimbal).
3. Sensors — IMU (6 / 9 / 10-axis), encoders, voltage/current sampling, ToF / camera. A ground vehicle doesn’t strictly need an IMU; the faster you want to go, or the more anti-rollover / autonomy you want, the more it matters.
4. Control uplink — see table above.
5. Video downlink — see table above.
6. Telemetry / tuning — see table above.

In the wizard, Module maps to layers 1–3 (hardware capability), Solution maps to layers 4–6 (how the links are wired up), and Parameters are the concrete chips / protocols / pins inside each layer.

Three typical topologies

The wizard’s solution pool is mostly organized around these three baselines.

Topology A: DIY / low-cost / single-board

[gamepad / phone]  --Wi-Fi / ESP-NOW-->  [ESP32 main + H-bridge]  -->  motors
                                              |
                                              +--HTTP/MJPEG--> [ESP32-S3-CAM]

• Closest to the Flix spirit. Cheap, transparent protocols, easy to pipe into a web UI.
• Fits: teaching, prototypes, indoor/short-range cars, anyone who wants to write their own protocol and UI.
• Doesn’t fit: high-speed real-time FPV, hostile RF environments, long-range stable operation.

Topology B: Standard FPV (two independent wireless links)

[ELRS TX]  --2.4 GHz CRSF-->  [ELRS RX]  --UART-->  [MCU controller]  -->  motors / servos

                                                    [FPV camera]  --VTX-->  [VRX / goggles]

• Control goes to an RC link (ELRS / Crossfire); video goes to a dedicated FPV VTX/VRX; the vehicle MCU only handles safety and chassis execution.
• Fits: anyone wanting a proper FPV experience and willing to spend on RC + VTX.
• Key win: every layer lives in the stack it’s best at — the control chain never fights the video chain for bandwidth.

Topology C: Research / hybrid (MCU + SBC, two boards)

[ELRS RX]  --CRSF-->  [ESP32-S3 controller]  --UART / CAN-->  [SBC (Pi, etc.)]
                              |                                       |
                              +--> motors / servos                    +--> camera / vision / WebRTC

• One board owns motors, servos, RC, and safety (hard real-time); another board owns video, light vision, and networking (soft real-time / compute).
• ESP32-S3-CAM + ESP32-S3 is a sensible two-board pairing — both are S3, the toolchain is one, and USB OTG makes debugging easy.
• Fits: vision / AI, remote WebRTC, research platforms.

The 7 MCU roles

Unfolding the “MCU blocks” that appear in the topologies above, the wizard slots your hardware into one of these 7 roles when picking modules and assigning pins:

What the wizard looks like in this domain

Concretely, once you’ve picked “Vehicle & Aircraft Control”:

• Module step — the visible hardware capabilities are constrained to: motor control (H-bridge / ESC), servo, IMU, safety relay, PMIC / current sampling, camera (only for All-in-One or Video Board roles). Things like “home gateway” or “Zigbee coordinator” don’t appear.
• Solution step — shows a three-chain priority summary (control uplink / video downlink / telemetry). Each solution is a frozen point of “(module combination) + (three-chain choices) + (firmware skeleton)”.
• Parameters step — all enums, no free-text. The IMU is not a text box where you type “MPU-9250”; it’s MPU-6050 / MPU-9250 / BMI270 / no IMU. Choosing “no IMU” hides the chip selector altogether.
• Review step — if the solution is a two-board layout (e.g. ESP32-S3-CAM + ESP32-S3), you’ll see two firmware targets named separately (controller / camera board); they are not coerced into a single image.

What this domain does not cover

• Flight mixer / attitude loop / PID tuning — the wizard doesn’t write your flight controller. If you’re building a quadcopter or a fixed-wing, fork Flix / Betaflight / Ardupilot instead; this domain hands you the “vehicle/aircraft control system” skeleton, and the attitude loop (whether to have one, how many cascades, what rate) is left to your firmware.
• Race-grade FPV link tuning — pairing and band management for DJI O4 / HDZero / Walksnail VTX-VRX lives in their own official tools. The wizard only tells you “leave this much power and this GPIO for the video board”.
• SLAM / autonomy planning — one layer up. Put it on the SBC and talk to the controller over Topology C’s UART/CAN.

See also

• Browser wizard — the actual 7-step click-through.
• RSHome device tools — domain="vehicle_aircraft_control" as it surfaces in the MCP layer.
• Typical 8-step workflow — running a full build end-to-end.