Advanced / Developer Learning Path

# Developer route

1. 1

   Start from a reproducible baseline

   Use Developer Overview and Build From Source before making code changes.

   Checkpoint: you can reproduce the validated Firmware v1.0.0 environment before introducing modifications.

2. 2

   Map repository responsibilities

   Read Repository Structure and System Architecture.

   Checkpoint: you know which layer owns control, IMU, safety, networking, altitude assistance and configuration responsibilities.

3. 3

   Change firmware with the control/safety model in mind

   Use Stabilization & Control Loop, Safety Model and Safety & Failsafe.

   Checkpoint: the change preserves explicit control-state and safety behavior or documents/validates an intentional difference.

4. 4

   Integrate through documented contracts

   Use Protocol 2, Telemetry Protocol, Configuration Protocol and Controller Ownership.

   Checkpoint: your integration follows the documented v1 transport/state contracts and respects the trusted-network security boundary.

5. 5

   Design compatible hardware deliberately

   Use Schematic & PCB, Pinout, Power System, Sensors and Compatibility.

   Checkpoint: electrical interfaces, pin assignments, sensor support, motor outputs, power behavior and required firmware changes are understood.

6. 6

   Validate before calling the change compatible

   Return to Bench Test, relevant troubleshooting pages and the validated baseline after meaningful changes.

   Checkpoint: modified behavior has an explicit validation path and a known-good comparison point.

7. 7

   Contribute or productize with clear boundaries

   Use Contributing for upstream work. For independent products, review the licensing and brand rules linked below.

   Checkpoint: technical licensing and ESPFlight branding are treated as separate concerns.

# Firmware development

# Hardware development

ESPFlight-compatible hardware does not need to look identical to the Hardware Reference. Compatibility depends on the electrical, firmware and protocol behavior documented in Compatibility.

# Protocol / integration

The public v1 developer documentation covers the current Protocol 2 command contract, telemetry envelope, configuration messages and controller ownership. Do not assume undocumented fields or behaviors.

# Independent products

ESPFlight open technology can be used as a foundation for independent boards, kits, educational products and compatible systems subject to the applicable licenses. Independent products must use their own branding and must not imply official ESPFlight endorsement.