What this is: The story of bringing a paused, sensor-only flying drone back to life — FlightRL v3 — and building the small piece of plumbing that records each flight into a file our flight Player can open and replay.
Why it’s here: It captures a course correction. I had shelved the harder-but-truer approach (a drone that flies blind, on its own sensors) in favor of an easier one. Aleks pushed back, and he was right. This entry documents the U-turn and the tooling that came out of it.
Date: 2026-06-15 Ticket: rl-lab dev-log 43 (machine: D2, the GPU box)
Glossary
If you don’t live inside this project, a few of these words will look like noise. Here’s each one in plain English, with a everyday picture to hang it on.
- FlightRL v3 — the version of the drone that actually flies using its sensors, instead of crawling square-by-square across a pre-drawn map. Think of it as the difference between a person walking through a dark house feeling the walls, versus a chess piece hopping between marked grid cells.
- god-map / privileged map — when you hand the agent a perfect, complete map of the world as input. It’s like giving someone the answer key before the exam. Useful sometimes, but it makes “navigation” trivial.
- sensor-only — the opposite: the agent sees nothing but its own rangefinder readings. No map. It has to build its own sense of the room from how far away the walls feel.
- occupancy — a grid that records “wall here, free space there,” cell by cell — like graph paper where each square is shaded if something is in it.
- serializer — a small program that carefully writes data out to a file in a fixed format. It’s the mirror image of a parser (which reads a file and breaks it apart). A serializer packs the suitcase; a parser unpacks it.
- Player / Map Studio — our flight viewer. Load a recorded flight into it and you can watch the drone’s path and the points where it scanned, like replaying a dashcam recording.
- pitch / roll — the forward-back tilt (pitch) and side-to-side tilt (roll) of the drone. A quadcopter tilts in the direction it wants to go, the way you lean a bike into a turn.
1. What I wanted
Aleks made a point that reframed the whole task. If you feed the drone a finished map of the world, then a task like “fly down this corridor” or “round the corner of an L-shaped room” stops meaning anything. It collapses into “follow the line someone already drew for you.” There’s nothing to learn there — the hard part has been done in advance.
The task only becomes real when the drone cannot see the map. It flies on its rangefinders alone, it feels the inertia of its own body, and it decides for itself when to throw out a scanning beam to light up the path ahead. That’s a navigation problem worth training a policy on. Anything less is set dressing.
So the goal for this session was clear: get back to the sensor-only flyer, prove it still works, and give it the ability to record what it does so we can actually watch it.
2. What I tried
The first thing I did was go looking — and it turned out we’d already built exactly this drone. It was called FlightRL, and I had quietly put it on pause a couple of days earlier when I chose the easier, map-in-hand approach instead. With Aleks’s nudge it was obvious the pause had been a mistake.
So the plan became:
- Un-pause it. Pull the FlightRL files back into the active path and run the existing test suite against them to confirm nothing had rotted.
- Write the serializer. Build the program that records a flight into a file the Player understands.
- Document it. Write a short README so future-me (and Aleks) can run it without re-reverse-engineering anything.
- Settle the scanning question. Decide who controls the scan beam — the environment, or the drone itself.
I also renamed the version from v1 to v3, so its number lines up with the rest of the system. Small thing, but mismatched version numbers are a quiet source of confusion later.
3. What happened
The drone came back to life cleanly. The files were all where I’d left them. I ran the tests and everything passed — no quiet breakage from the days it sat idle. That was the best possible outcome: a course correction that costs you nothing because the old work is still good.
The serializer is the real new artifact. It records a flight into a file shaped for our Player. The part I’m most pleased with is the coordinate handling: it converts the drone’s internal coordinates into real meters, matching the convention used by the big Gazebo simulator. That’s what makes the recorded track lie down neatly on the map instead of drifting or scaling wrong. Get that wrong and every replay looks subtly broken; get it right and it just works.
Into each flight file goes a compact record of:
| Field | What it captures |
|---|---|
| Position | Where the drone was, in real meters |
| Velocity | How fast it was moving |
| Sensor readings | What the rangefinders saw at each step |
| Scan events | When and where the drone took a scan |
That last row is the one Aleks specifically asked for — being able to see, on the replay, exactly when and where the drone chose to scan.
I wrote the README (FLIGHTRL.md) — a step-by-step of where everything lives and how to run it.
On the scanning question: right now the scan fan rotates on its own, automatically. The drone doesn’t control it. I proposed flipping this: keep the small rangefinders always on (so it never blindly clips a wall), but let the drone consciously trigger the big scanning beam itself — which is exactly the behavior Aleks was after. That change isn’t done yet, because it alters the drone’s “control panel” (the set of actions it can take), and that’s worth confirming before I commit to it.
4. What’s still missing (the next step)
The honest weak spot today: the drone moves too perfectly. Its speed changes instantly, there’s no inertia, no tilt, no sway. That’s precisely the thing Aleks has been pointing at — it doesn’t move like a real quadcopter, so anything it learns might not transfer.
The fix I’m reaching for next is to borrow the physics from our little game build, which already models acceleration and braking with proper inertia, and to add pitch/roll tilt with some natural sway, modeled on how a real quadcopter behaves. Make the body feel like it has mass, and the navigation problem suddenly has the texture it was missing.
5. How to run it (for you)
cd $RL_LAB_ROOT && source venv/bin/activate && export PYTHONPATH=$RL_LAB_ROOT
python scripts/record_flight.py --steps 300 --policy random --run demo1
Then open the resulting file in the Player (Map Studio). The full details are in FLIGHTRL.md.
6. Sources
- rl-lab dev-log 43 (session notes, machine D2)
FLIGHTRL.md— the new README for the FlightRL v3 setup and run instructionsscripts/record_flight.py— the flight recorder built on the new serializer