An autonomous indoor drone

Safety and scope

Complete the first ten milestones in simulation. A physical test needs a small craft with propeller guards, eye protection and a clear enclosed area. It also needs a second person and a tested manual disarm. Follow local aviation and radio rules. Never test near people, animals, roads or aircraft.

The operational design domain, or ODD, states where the system is allowed to work. Here it is one mapped indoor room with enough light, dry still air, fixed speed and height limits and no people in the flight space. Leaving those conditions is a failure. The controller must not improvise a new mission.

Fly the complete mission without a physical aircraft

Use PX4 software in the loop with a multicopter model in Gazebo. The flight code runs on the computer and controls a model in a 3D world. A ground station or offboard program can use the same command interface that it will use later, so you can build and fly the software before buying or assembling a craft.

1. Create one bounded indoor world with a take-off pad, walls and three obstacles. Mark the allowed height, speed, flight boundary and landing reserve in the mission configuration.
2. Fly manually in the virtual room first. Then run the waypoint mission and plot the true pose, estimated pose, planned path, clearance and controller outputs.
3. Repeat across saved starts and seeds. Move one obstacle, add sensor delay and noise, interrupt position updates and reduce the battery estimate. Check every hover, landing and disarm rule.
4. If PX4 documents your exact board and simulator pairing, optionally run the flight computer in the loop. Current PX4 hardware-in-the-loop support is not a dependable requirement for every setup. Keep the software test as the release gate when that pairing is unsupported.

Simulation can expose coordinate, planning, timing and recovery errors. It cannot prove real propeller condition, vibration, battery behaviour, radio reliability or sensor calibration. Measure those separately and rerun the test matrix with the model updated. The Simulating Physical Systems course gives the full path from software simulation through hardware in the loop to a guarded field test.

Project milestones

1. Write the mission, ODD and abort conditions.

   State the take-off point, flight space, speed and height limits, goal tolerance and battery reserve. Then state what happens after lost position, stale sensors, missed deadlines, uncertain obstacles or lost communication.

2. Model rigid-body attitude and motor mixing in simulation.

   Define body and world axes, sign conventions, thrust and torque from each rotor, mass and inertia. Unit-test level hover and each pure roll, pitch, yaw and collective command before closing a controller.

   What you need courseDrones courseLinear Algebra
3. Calibrate inertial sensors and attach timestamps.

   Estimate gyro bias and accelerometer scale/orientation. Record acquisition time, units and frame. Inject a known clock offset to prove the estimator notices degraded timing.

4. Estimate attitude and uncertainty.

   Begin with complementary filtering, then compare an EKF if required. Check stationary drift, controlled rotations, innovation and recovery after a disturbed estimate.

   What you need lessonSensor fusion lessonKalman estimation
5. Close and tune the attitude-rate loops in simulation.

   Use step and disturbance tests with realistic delay and motor limits. Plot command, measured rate, error and motor output. A stable hover must handle the range of mass and motor behavior stated in the ODD.

6. Add height and planar position estimation.

   Fuse range, optical flow, visual features or another indoor position source. Keep a numeric uncertainty or a clear quality state. Stop climbing or moving sideways when the measurement becomes stale or disagrees with the other sensors.

7. Build an obstacle map that preserves unknown space.

   Transform depth or range measurements through calibrated sensor, body and world frames. Update an occupancy or distance map, and do not mark unobserved cells free.

   What you need courseComputer Vision lessonOccupancy mapping
8. Plan a collision-free route with clearance.

   Inflate obstacles by vehicle radius plus uncertainty, run A* or another stated planner and reject routes through unknown space. Invalidate the path when the map or localisation frame changes.

9. Follow short trajectory segments and replan.

   Respect speed, acceleration, tilt and stopping-distance limits. Execute a short prefix, re-estimate and replan rather than flying a long open-loop route.

10. Add an independent runtime monitor and minimal-risk states.

    The monitor checks the flight boundary, height, speed, stopping margin, sensor age, estimate agreement, deadlines and battery. Define when to hover, land under control or stop the motors. State when each response is physically possible.

    What you need lessonRuntime assurance courseReal-Time Systems
11. Pass software, hardware and restrained-flight gates.

    Use unit/property tests, recorded replay, simulation fault injection and hardware-in-loop. Then test tethered or inside a suitable cage, with manual disarm and one variable changed at a time.

12. Complete a limited-ODD mission and reproduce it.

    Take off, visit stated waypoints, avoid one changed obstacle and land. Repeat across seeds and starts. Report success, minimum clearance, interventions, latency, battery, localisation loss and every fallback.

2026 extension: vision-language instructions and learned policies

Add learned parts only after the reference mission and monitor pass. A vision-language model may turn “inspect the red marker” into a labelled target or waypoint. A learned policy may propose a short set of moves in simulation. Keep the map, flight boundary, motion limits, stopping margin and low-level control outside the model.

1. Create held-out rooms, objects, instructions and ambiguity cases.

   Include instructions the system must refuse or clarify. Keep adjacent frames and repeated rooms out of the final split.

2. Run proposals in replay and shadow mode.

   Measure whether each target is tied to the right pixels. Count illegal and unreachable proposals, response time and disagreement with the existing planner. Do not allow the model to move the craft yet.

3. Filter actions and count every intervention.

   Reject outputs outside typed limits or the recoverable set. Report unassisted, shielded and human-assisted outcomes separately.

Relevant lessons: learned robot policies, vision-language-action models, and staged learned autonomy evidence.

Review the system in four stages

Completion record

Keep the model, axis and frame rules with all calibration data. Keep estimate plots, controller and timing traces, map and planner test cases, fault results and flight logs. Record every intervention and the final release decision.