Maiden flight

Summary¶

The maiden flight is a structured measurement event, not a demonstration. Its purpose is to collect whatever flight-log data your firmware provides, verify basic structural and electronic health under load, and confirm the build behaves as expected before the flight programme expands to normal operations. The sequence is: hover only, land, inspect, review logs, only then expand. Every deviation from expectation is information — log it, not explain it away. Applies to any build regardless of firmware or frame origin.

Concept¶

What the maiden answers¶

A maiden flight does not answer "does the drone fly?" — acceptance validation already confirmed it should. The maiden answers:

• How does this specific build fly? Motor balance, control response, noise floor — properties of the assembled hardware, not the design.
• Is logging working correctly? The maiden is the first real confirmation the data-collection path (Blackbox flash, dataflash SD, whatever your firmware provides) actually works.
• Where are the weak points? Vibration, motor temperature, anything that only shows up under real load.

Maiden as the first flight in a data series¶

Every subsequent flight builds on the maiden baseline. If a later flight's log looks meaningfully different from the maiden's — a higher noise floor, a hotter motor at the same throttle — something changed in the hardware. The maiden establishes the reference others get compared against.

Reference¶

Maiden flight sequence¶

Pre-maiden (site) - Open outdoor site, well clear of people and obstacles - Confirm GPS fix before arming, if GPS-equipped - Transmitter on before battery connected - Confirm logging is active

Hover sequence (Phase 1) 1. Arm. Apply throttle smoothly — observe lift-off. 2. Hover at low altitude (around 1 m) for 30 seconds. Listen for abnormal sounds. Observe stability. 3. Land. Disarm. Do not continue until Phase 1 inspection is complete.

Post-hover inspection 4. Feel motor housings: warm is acceptable, hot is not. 5. Check any fasteners that took load for looseness. 6. Check for any unexpected vibration marks or contact traces.

If Phase 1 passes — expand carefully 7. A slow low-altitude circuit with gentle inputs. 8. If your firmware has an autonomous return mode (GPS Rescue on Betaflight, RTL on ArduPilot): test it deliberately at low altitude before you ever need it for real. 9. Land. Pull the log.

Post-maiden log review 10. Look at the noise floor and any anomaly the tooling flags. 11. Check for motor imbalance — one motor working noticeably harder than the others at the same command is worth investigating before flying further. 12. Log all findings.

Procedure¶

If a motor is hot after hover¶

Motor temperature noticeably above the others after a short low-throttle hover indicates a problem. Stop. Do not continue the maiden.

Investigate in this order: 1. Verify motor direction is correct for that position. 2. Verify the propeller is seated fully and the nut is torqued. 3. Verify the motor-to-ESC connector is fully mated. 4. Review the log for that motor's output — if it's significantly higher than the others, it's compensating for something else.

If an autonomous return mode doesn't activate¶

1. Verify the preconditions your firmware requires (GPS fix quality, arm-time satellite count, etc.) were actually met.
2. Verify the feature is actually enabled in your configuration.
3. Verify the switch/trigger assignment is correct.

Do not operate in any environment where you're relying on this feature until it's confirmed working.

Rationale¶

Why hover-only for Phase 1¶

Aggressive manoeuvring on the maiden provides no additional information beyond what a clean hover already shows in the log — and adds crash risk before any baseline exists. The flight programme expands only after Phase 1 confirms the build is structurally and electronically sound.

Connections¶

requires: - acceptance-validation related: - pid-tuning-rate-profile leads_to: - pre-flight-check