Every subsystem covered in Modules 02 through 05 was designed and verified in isolation — the wing was analyzed for structural loads, the motor was bench-tested for thrust, the autopilot was configured for the sensor suite. Integration is where those individually validated subsystems are assembled into a complete vehicle and confronted with the reality that they must work together simultaneously, in the same physical space, sharing the same power bus, generating vibration and electromagnetic fields that affect each other. Most first-flight anomalies trace back not to subsystem failures, but to integration failures — interactions between subsystems that were never tested together until the first time the complete vehicle was powered up at the flight line.

The integration sequence

Integration is not assembly. Assembly is the physical act of connecting components. Integration is the disciplined process of verifying, at each step, that the system assembled so far behaves as designed before adding the next subsystem. The sequence matters: adding all subsystems at once, then discovering a problem, leaves the engineer unable to identify which subsystem or interaction is responsible. Adding one subsystem at a time, verifying at each step, allows the source of any anomaly to be identified immediately.

The standard integration sequence for a fixed-wing UAS is:

Subsystem bench testing before integration

Every subsystem should be tested to the extent possible before it is installed in the airframe. A subsystem that fails on the bench fails cheaply and quickly — it can be repaired or replaced without disturbing the rest of the vehicle. A subsystem that fails during integrated testing takes the rest of the vehicle offline with it, and diagnosing the failure requires separating it from all the other systems it is now connected to.

The autopilot should be configured, tuned, and verified on the bench with all sensor inputs simulated or connected before the airframe is assembled. The motor-propeller combination should be characterized on the static thrust stand before installation. The power system should be loaded to full flight current draw on the bench to verify that all voltage rails remain within specification under load. The datalink should be ranged on the ground before the vehicle is ready to fly — discovering that the datalink range is 500 m when the mission requires 5 km is not a discovery that should be made at the flight line.

Hardware-in-the-loop simulation

Hardware-in-the-loop (HIL) simulation runs the actual autopilot hardware executing actual flight control software, connected to a flight dynamics simulator rather than a real vehicle. The autopilot sends commands to the simulator, which computes the vehicle response and sends simulated sensor data back to the autopilot. From the autopilot's perspective, it is flying the vehicle; from the engineering team's perspective, the autopilot's behavior can be observed, logged, and analyzed without any risk to hardware or personnel.

HIL simulation serves two critical functions in the integration process. First, it validates the autopilot configuration — confirming that the flight modes, failsafe logic, and control law parameters produce the expected vehicle response before any real-world flight is attempted. A failsafe that triggers the wrong behavior in HIL simulation is caught before it triggers the wrong behavior at 300 m altitude. Second, it allows the complete mission to be flown in simulation, including the pre-planned waypoint sequence, the transition through all planned flight modes, and the behavior at mission completion. If the simulated mission reveals a planning error — a waypoint too close to an obstacle, a mode transition that occurs at the wrong altitude — it is corrected before the vehicle leaves the ground.

Software-in-the-loop vs. hardware-in-the-loop Software-in-the-loop (SIL) simulation runs both the flight control software and the vehicle dynamics model on a single computer — no actual autopilot hardware is involved. SIL is useful for rapidly iterating on control law parameters and mission logic, because the simulation runs faster than real time and no hardware setup is required. HIL uses the actual autopilot hardware and runs in real time, which means it captures hardware-specific behaviors — CPU load, timing jitter, sensor driver behavior — that SIL cannot reproduce. Both have a role in a mature development program: SIL for rapid software iteration, HIL for final pre-flight validation of the complete hardware-software system.

Weight and balance verification

The static margin calculation performed in Module 02 assumed a specific CG location. The actual CG of the assembled vehicle must be measured and compared to the design value before the first flight. A vehicle with a CG that is forward of the design value is more stable than designed — the autopilot may require larger control deflections to maneuver and the control surfaces may be less effective than expected. A vehicle with a CG aft of the design value is less stable — in the extreme case, statically unstable — and the autopilot may be unable to control the vehicle, particularly at high speed or in turbulent conditions.

CG is measured by balancing the vehicle at two points and computing the balance point from the reaction forces, or by hanging the vehicle from a known point and measuring the angle. The measurement must be made with the vehicle in its flight configuration — motor installed, battery at the nominal position, payload installed and at the nominal weight. If the measured CG differs from the design value by more than a few millimeters, the battery or ballast must be repositioned before first flight.

x_cg = (m₁x₁ + m₂x₂ + … + mₙxₙ) / M
x_cg — CG position from datum (mm)  ·  mᵢ — mass of component i (g)  ·  xᵢ — distance of component i from datum (mm)  ·  M — total mass (g)
Build the CG spreadsheet during design. Every component — including wiring harnesses and fasteners — goes in the spreadsheet with its mass and moment arm. The first time the CG is computed should not be the first time the vehicle is assembled.

Servo and control surface verification

Servo and control surface verification is the most consistently skipped step in amateur and semi-professional UAS integration, and it is responsible for a disproportionate number of first-flight losses. The verification confirms three things: that the control surfaces move in the correct direction in response to pilot input and autopilot commands; that the control surface deflection magnitudes match the design values; and that there is no mechanical binding or excessive slop in the linkage throughout the full travel range.

The direction check requires knowing the sign convention of the autopilot's control law. In ArduPlane, for example, aileron stick right commands right roll — the right aileron should go up and the left aileron should go down. If the servos are reversed — either mechanically (the pushrod is on the wrong side of the servo output arm) or electronically (the servo direction is not reversed in the autopilot) — a right roll command produces a left roll response, and the vehicle is unflyable. This error is obvious in the first second of flight and costs the vehicle.

The stabilization check verifies that the autopilot's attitude stabilization works in the correct sense. With the vehicle in stabilize mode and all flight controllers active, tilt the nose up — the elevator should deflect down, commanding nose-down to counter the disturbance. Tilt the left wing down — the left aileron should go down (increasing lift on the left) and the right aileron should go up. If stabilization works in the wrong direction, the autopilot is fighting itself: any disturbance is amplified rather than corrected, and the vehicle diverges immediately on release.

Control surface verification checklist
1. Power on, autopilot in manual mode. Move sticks: confirm each control surface moves in the correct direction and to the correct magnitude. Aileron: right stick → right aileron up, left aileron down. Elevator: back stick → elevator up. Rudder: right pedal → right rudder.
2. Switch to stabilize mode. Tilt nose up → elevator deflects down. Tilt left wing down → left aileron deflects down, right aileron deflects up. Yaw nose right → rudder deflects left. If any stabilization direction is wrong, the control is reversed — fix it before proceeding.
3. Verify maximum control surface deflection matches design specification using a deflection gauge. Document measured deflections for the flight record.
4. Check for mechanical binding throughout the full travel range. Any binding that is present on the ground will be worse in flight — aerodynamic loads add to the servo force requirement. Fix all binding before flight.
5. Check for excessive linkage slop (backlash). More than 1–2 mm of slop at the control surface trailing edge will degrade autopilot control quality and introduce oscillations in stabilized modes.

Electromagnetic compatibility and RF interference

A UAS avionics bay concentrates several high-powered RF emitters (datalink radio, video transmitter, RC receiver, FPV transmitter) in close proximity to sensitive sensors (magnetometer, GPS receiver, barometric altimeter). The electromagnetic environment inside the airframe can corrupt sensor measurements, degrade communication link reliability, and in severe cases reset the autopilot. EMC verification before first flight is not optional — it is the difference between a vehicle that works in the air and one that worked on the bench.

The magnetometer is the most susceptible sensor to EMC interference. Motor current creates a magnetic field that can overwhelm the Earth's field and produce heading errors of tens of degrees. The standard mitigation is physical separation — the magnetometer should be located as far from the motor and power wiring as practical. In fixed-wing aircraft, the GPS-magnetometer unit is typically mounted on a mast above the fuselage, above the motor and ESC fields. The residual interference is then calibrated out using the autopilot's in-flight magnetometer calibration routine. Verifying that the compass heading is stable and accurate during motor run-up on the ground — before any flight attempt — confirms that the separation and calibration are adequate.

The GPS receiver is susceptible to interference from video transmitters, particularly those operating in the 1.2 GHz band near the GPS L1 frequency (1.575 GHz). Running a video transmitter at full power on the bench while observing the GPS satellite count and position accuracy is the appropriate test. A GPS receiver that reports 12 satellites with stable position on the bench but drops to 4 satellites and high HDOP when the video transmitter is powered on has an interference problem that will produce GPS failures in flight.

Pre-flight checklist design and philosophy

A pre-flight checklist is not a formality. It is a structured procedure that ensures every critical item is verified in a specific sequence before the vehicle is committed to flight. Its value comes from the fact that it is followed when the engineer is distracted, rushed, excited, or tired — the conditions under which critical items are most likely to be missed. A checklist that is used consistently prevents the class of accident where a vehicle is lost to something that was not checked because it was obvious, familiar, or assumed.

The checklist should be structured in the order of integration and verification: structural checks first (no loose hardware, all fasteners torqued, access panels secured, no physical damage from transport), then propulsion checks (motor rotation direction, propeller condition and torque, no obstructions in propeller arc), then avionics checks (GPS lock acquired, satellite count adequate, battery voltage above minimum, all sensors reading within normal range), then control surface checks (direction and deflection verified against the pre-defined standard), then mission checks (waypoints loaded and verified, failsafe parameters confirmed, datalink link quality adequate), and finally the go/no-go decision point.

The propeller is always dangerous until it stops Establish and enforce a clear safety zone rule before beginning any ground testing with the propulsion system armed. The propeller should be treated as potentially armed at all times when the battery is connected and the ESC is powered — regardless of whether the throttle is at zero. Accidental throttle inputs, autopilot initialization sequences, and ESC calibration routines have all produced unintended motor starts. Personnel should never be forward of the propeller arc while the battery is connected, and the propeller should be physically removed from the motor whenever work is being performed on the avionics or propulsion system.

Static systems and power-on testing

Before the first flight, a series of static systems tests verify the complete vehicle behavior across all planned operating conditions without leaving the ground. These tests catch the integration failures that bench testing of individual subsystems cannot catch.

Full power static run: The vehicle is secured to the ground (tie-down or test stand), and the motor is run to full throttle for 30–60 seconds while monitoring motor and ESC temperature, battery voltage sag, and GPS satellite count. Confirms that the power system handles full load without thermal issues, that the voltage drop under full load does not trigger low-voltage warnings, and that GPS performance is maintained during motor operation.

Flight mode progression: With the motor at idle, the autopilot is cycled through all planned flight modes, and the vehicle response to each mode transition is observed. The altimeter reads stable altitude. The GPS reports stable position. The EKF status is healthy across all mode transitions. No error messages or warnings appear in the ground station during normal operation. Any anomaly at this stage is investigated before flight.

Failsafe verification: The planned failsafe conditions are deliberately triggered — datalink disabled, RC transmitter powered off, battery voltage artificially lowered to the failsafe threshold — and the vehicle response is confirmed to match the designed failsafe behavior. A failsafe that has not been verified on the ground has not been verified at all.

First flight planning

The first flight is not an operational mission. It is a structured test to confirm that the vehicle flies as designed under benign conditions before any operational use. Planning the first flight with this framing — as a test, not a deployment — produces a much safer and more informative event.

The first flight should be conducted at a site with adequate open area for a safe emergency landing in any direction from the launch point, in calm wind conditions (below 10 knots), in good visibility, and with an experienced pilot or test engineer at the controls or ready to take over. The vehicle should be flown in stabilize mode for the first circuits — not autonomous, not position hold — so that the pilot has direct control and can respond immediately to any anomaly. The flight envelope is expanded gradually: hover or straight-and-level before any turns, turns before any autopilot modes, autopilot modes before any autonomous waypoint missions.

Data logging should be active from the moment the autopilot is powered on until the vehicle is disarmed after landing. Post-flight data review is mandatory — the flight data log is the primary diagnostic tool for understanding vehicle behavior, confirming that measured performance matches predicted performance, and identifying any anomalies that were not apparent to the pilot during the flight. A first flight from which no data was logged is a first flight from which nothing was learned.

First flight data review — what to look for
Airspeed and altitude: confirm that measured values are consistent with the flight profile. An airspeed sensor that reads zero or erratically has a blockage or connection problem. An altitude that jumps by 20 m with no corresponding climb is a barometer anomaly.
Control surface activity: excessive autopilot control surface oscillation (hunting) indicates a control loop that is tuned too aggressively. Slow, drifting corrections indicate a loop that is tuned too conservatively. Both are correctable from the log data.
Battery voltage and current: confirm that the current draw matches the predicted cruise power. A vehicle drawing significantly more power than predicted is either flying faster than intended, flying at a higher drag angle of attack than designed, or has a propulsion efficiency problem.
EKF health: confirm that the EKF maintained healthy status throughout the flight. Any EKF error flags or innovation divergence events in the log indicate sensor problems that must be resolved before operational use.
GPS and position: confirm that the ground track matches the intended flight path, that GPS accuracy was maintained throughout, and that there were no GPS drop-out events. Any GPS anomaly during the first flight is investigated before the second.