Computer Engineering student building autonomy that flies
I write the flight software that lands a drone on its own launch point using nothing but what the camera remembers.
PRESS 1–8 TO SLEW · SCROLL TO DESCEND · THE DRONE ON THE RAIL IS YOUR POSITION
Computer Engineering at the University of Waterloo. I run the autonomy subteam at the Waterloo Aerial Robotics Group — thirty people, one flight-software stack, and a competition airframe that has to work on the day.
The work I care most about is precision landing without a marker: record what the ground looks like on the way up, match it on the way down, and put the aircraft back where it started. It landed inside 15 cm on the airframe.
COUNTED FROM THE MISSION LOG BELOW — NOT HAND-WRITTEN
Python (6) · Git / CI (5) · NumPy (4) · Docker (3) · OpenCV (3)
SHOWING 08 / 08 SORTIES
PERCEPTION
FLIGHT-VERIFIEDFLOWN ON AIRFRAMENO MARKER, NO GPS FIX — LANDED INSIDE 15 cm
A visual teach-and-repeat precision landing built and flight-tested end to end. On the way up it records an altitude-keyed map of ORB features; on the way down it matches each live frame against the nearest teach frame and flies the aircraft back onto its own launch point. 15 cm in flight test, 2 cm in simulation.
SIMULATION
DEPLOYEDTESTED / RUNNINGUAV SIMULATOR WRITTEN FROM SCRATCH
A software-in-the-loop range built from scratch: PyBullet rigid-body physics for the quadcopter's flight dynamics, bridged to ArduPilot's SITL binary over a UDP JSON protocol so the real flight controller flies a simulated airframe at full rate.
PERCEPTION
FLIGHT-VERIFIEDFLOWN ON AIRFRAMETHE CONTROL LOOP, PROVEN BEFORE THE PERCEPTION CHANGED
Closed-loop descent onto an AprilTag, flown first and deliberately: with a fiducial in the frame the target estimate is effectively ground truth, so any bad behaviour left over belongs to the controller and not to the perception.
FULL-STACK
DEPLOYEDTESTED / RUNNINGCLASSROOM PLATFORM, SHIPPED AND SERVERLESS
A classroom management platform in production: role-based access for admins, teachers and students over a Postgres/Drizzle schema, session auth with OAuth, and an invite-based onboarding flow built on cryptographically secure tokens.
MACHINE LEARNING
COMPLETETESTED / RUNNINGC++ / EIGEN MLP, NO FRAMEWORK, 95.4% ON MNIST
A multilayer perceptron implemented with no ML framework at all: forward pass and backpropagation derived by hand and written straight onto Eigen matrices.
AUTONOMY
IN PROGRESSFLOWN ON AIRFRAME30-PERSON SUBTEAM, ONE FLIGHT-SOFTWARE STACK
Running the autonomy subteam: thirty contributors split into parallel project groups, a flight-software backlog scoped into issues small enough to onboard on, and an architecture that lets those groups land work without stepping on each other.
MACHINE LEARNING
IN PROGRESSNOT FLIGHT-TESTEDLEARNED DESCRIPTORS WHERE ORB GIVES UP
A lightweight 2D convolutional detector–descriptor network (XFeat) with parallel keypoint-detection and 64-dimensional dense-descriptor heads, aimed squarely at the conditions where hand-engineered ORB degrades on the landing pipeline.
FULL-STACK
IN PROGRESSTESTED / RUNNINGPIXELS TO GROUND COORDINATES, LIVE, UNDER 0.5 m
Full-stack, real-time UAV geolocation platform for the 2026 AEAC Firefighting competition: a React/TypeScript operator console over a Flask REST API that turns a target spotted mid-flight into a 3D ground coordinate.
No marker on the ground and no GPS precision to lean on. On the way up the aircraft memorises what the ground looks like at every rung of an altitude ladder. On the way down it matches what it sees against what it remembers, and flies the difference to zero.
It landed inside 15 cm on the airframe and 2 cm in simulation. Everything below this line is measured from the flight itself, not reconstructed — including the part where the classical feature descriptor starts to run out of road.
Cyan crosses are keypoints. The green ring is the alignment cone — max(0.05 m, 0.15 × AGL), which works out to a constant pixel radius for most of the descent, and the dashed ring at twice that is where descent authority reaches zero. The vector from the amber reticle is the correction. Watch the match count fall as the aircraft climbs away from its keyframe, and watch the whole overlay go cold at 1.0 m when the autopilot takes over.
Frame f01, 1 of 12. Lateral error 17.5 centimetres. Scale gap 0.80. 643 matches at 97.4% inliers.
WHAT YOU ARE LOOKING ATLeft is the keyframe recorded on the climb; right is the live frame on the way down. The blue arrow on the right half was drawn by the flight software, in flight — I did not add it. Because it was drawn at a known 250 pixels per metre, it inverts back to the exact lateral correction the controller was given, which is where the centimetre figures come from. The cyan rings are the real ORB correspondences that survived the ratio test and RANSAC. The amber cross is the principal point: the flight code aims the correction from there, not from the middle of the picture.
The teach-and-repeat landing, from the ground. The aircraft is descending on vision alone at 0.1 m/s onto the taped launch point it mapped on the way up; ArduPilot's LAND mode takes the last metre. Unstabilised phone video, tone-mapped and trimmed to the touchdown. It looks slow because it is: 0.1 m/s under vision, tapered further whenever match quality drops. The last metre is the quick part.
BARS ARE RELATIVE ALTITUDE · RIGHT COLUMN IS THE DECODED LATERAL ERROR.
The correction is converging as it comes down: mean decoded error is 26.5 cm across the upper half of the surviving ladder and 17.0 cm across the lower half, over 11 measurable frames. That is the loop closing, and it is what puts touchdown inside 15 cm.
LEFT COLUMN IS σ — TEACH ALTITUDE ÷ REPEAT ALTITUDE. RIGHT IS SURVIVING MATCHES. RED PAIRS ARE THE WIDE-GAP ONES, AND THEY ARE THE ONES THAT STARVE.
This is the argument for MSN-05. ORB is a binary descriptor on an image pyramid, and it bridges neither of the two gaps these frames actually contain: the aircraft sitting well above its keyframe, and the sun moving between takeoff and landing. The worst pair here has only 38 matches left. A learned detector–descriptor is aimed at exactly that hole — the measurements above are why the project exists rather than a guess that it might help.
Every 0.25 m of altitude gained on the way up, the downward camera is undistorted, ORB-described, and filed in a map keyed by height above ground from the rangefinder. The ladder tops out at 7.5 m.
A frame with fewer than 150 keypoints is rejected rather than stored — a dead keyframe is worse than a missing one, because the descent would select it and then stall.
airside/src/nodes/nodes/processor.py; the PI velocity controller in controller.py.BRANCH · non-optimal-targets (opens in a new tab)FULL MISSION LOG · MSN-01Before the marker came out of the frame, the same controller was proven against an AprilTag. With a fiducial in view the target estimate is effectively ground truth, so a bad landing could only be the control loop's fault — which is what made the feature-based work in section 04 debuggable at all. This bay is that descent with the failures I could not inject in flight.
12.00m
TRANSIT
WIND LEAVES A REAL TOUCHDOWN ERROR · PAST 4 m/s THE ALIGNED GATE FAILS. THE OCCLUDER HOLDS HOVER — NO TARGET, FEATURE FLOW DEGRADES.
PLOTTED FROM THE ALTITUDE YOU ACTUALLY FLEW
GROUND OBSERVER · UNSTABILISED · Ground observer · unstabilised, tone-mapped from 10-bit HLGThe AprilTag baseline descent, from the ground. Same controller, same airframe, but with a fiducial in the frame so the target estimate is effectively ground truth — this is the run that proved the control loop before the marker came out.
Every panel above is the same scene through a different pass, projected with pixels = metres · f / altitude and depth = h · √(1 + (r/f)²). The lateral error converges as you descend because that is what the landing controller does — inject a crosswind and watch how much of it the controller gets back before the gear touches.
EVERY LINE IS A GATE THAT ACTUALLY CHANGED — ACQUISITION, LATERAL LOCK, LOSS OF TARGET, TOUCHDOWN. NOTHING HERE IS ON A TIMER.
UWARG — Waterloo Aerial Robotics Group · Waterloo, ON
UWARG — Waterloo Aerial Robotics Group · Waterloo, ON
UW Orbital — Waterloo Satellite Design Team · Waterloo, ON
University of Waterloo · Waterloo, ON
Each bar is missions using the tool ÷ busiest tool, counted from the mission log in section 03 — so it measures how much of the work leaned on something, not how good anyone claims to be. The mission codes under each channel are links: follow them and check.
COURSEWORK, HARDWARE LABS AND SUPPORTING TOOLING. LISTED WITHOUT A SIGNAL LEVEL BECAUSE NO MISSION ABOVE MEASURES THEM.