Quick Start
A practical path from understanding the ESPFlight stack to a controlled first flight.
ESPFlight is an open flight platform, not a pre-certified finished drone. Treat every new board, frame, motor, battery, propeller, and firmware change as something that must be validated on real hardware.
#Platform overview
ESPFlight keeps three core pieces together so you do not have to assemble an unrelated stack before you can start building.
Flight control, stabilization, telemetry, safety state, assisted flight, and Protocol v2.
A known starting point you can study, validate, modify, fabricate, and adapt to your own build.
The companion interface for control, telemetry, configuration, and tuning.
#First build sequence
Validate one layer at a time. This makes it much easier to isolate a hardware, networking, or control problem before everything is combined in the air.
- 1
Understand the stack
Review the platform overview and know which responsibilities belong to hardware, firmware, networking, and the app.
- 2
Build and verify the hardware
Check power rails, sensor orientation, programming access, motor outputs, and the mechanical condition of the frame.
- 3
Flash a clean firmware configuration
Use settings appropriate to the actual board. Keep private Wi-Fi credentials out of public source repositories and shared firmware builds.
- 4
Connect the application
Confirm discovery, controller ownership, telemetry, and basic configuration before any powered flight test.
- 5
Bench-test without propellers
Verify roll and pitch direction, motor mapping, motor direction, ARM / DISARM, and link-loss behavior with the propellers removed.
- 6
Move to controlled flight tests
Start in a clear low-risk area, keep the first hover brief, and change only one tuning variable at a time.
#Hardware guide
Firmware tuning cannot compensate for incorrect power, sensor orientation, motor mapping, or an unstable mechanical platform. Confirm the physical system first.
Verify battery polarity, regulated rails, connector integrity, and voltage under load.
Confirm the sensor orientation matches the firmware configuration and that the axes move in the expected directions.
Confirm each logical output drives the correct physical corner and spins in the intended direction.
Check frame rigidity, motor mounting, propeller condition, loose hardware, and vibration sources.
Use the released ESPFlight schematic, BOM, board files, and firmware notes for exact electrical details. This guide intentionally avoids inventing pinouts or component values that are not part of the published release.
#Assembly & preflight
Propellers come last. Keep them off while checking electronics, sensor direction, motor mapping, and arming behavior.
#Safety
Arming state, link-loss behavior, battery state, attitude guards, command ownership, and assisted-flight transitions are part of the platform contract—not optional polish.
Never treat “it compiled” as “it is flight-safe.” Re-run bench and low-risk validation after meaningful hardware or software changes.
#App & firmware
The current ESPFlight stack uses the application and firmware together. Before flight, confirm that both sides agree on the connection and drone state.
Confirm the control path
Discovery, controller ownership, telemetry, configuration, and ARM / DISARM should behave predictably before powered testing.
Application overview →Confirm the flight state
Review Protocol v2 behavior, failsafe logic, telemetry, and the safety assumptions that apply to the current release.
Firmware overview →#Help & troubleshooting
Start with the layer that failed instead of changing everything at once.
The app cannot find the drone
Confirm the drone is powered, the firmware has joined the expected Wi-Fi network, the phone is on the same network, and discovery traffic is not blocked.
Connected, but control is unavailable
ESPFlight uses a single-controller ownership model. Close another active controller, reconnect, and verify the drone state before arming.
Telemetry works, but attitude looks wrong
Check IMU orientation, axis direction, mounting, and vibration before changing PID values.
The drone is unstable
Return to a prop-off bench check, verify motor mapping and mechanics, then tune incrementally. Do not chase a hardware problem with aggressive PID changes.
#Compatibility direction
A multi-maker ecosystem benefits from explicit device identity and capability information. As ESPFlight expands beyond one reference board, the app should understand what it connected to without guessing.
Future compatibility metadata may include maker or brand identity, product model, board revision, firmware version, protocol version, and supported capabilities. These should become requirements only after they are formally specified and versioned.