What this is: A recording session where I flew our autonomous drone twice in simulation, captured video and 2D position tracks, switched between two virtual worlds, and ran a quick flight-controller sanity check.
Why it’s here: It is the first time we put a video, a drawn flight path, and a world-switch checklist side by side. That combination exposed exactly where our current flight policy and our world geometry stop agreeing with each other — useful to have written down.
Date: 2026-06-07 Ticket: simulation dev-log, video session
Glossary
- Flight video — a screen recording of the simulator while the drone flies. Think of it as a dashcam pointed at the virtual world, so I can rewatch a run instead of relying on numbers alone.
- Track (2D track) — a top-down map of where the drone actually went, drawn by joining up its position samples. Like the breadcrumb trail on a hiking GPS: it shows the shape of the path, not just the start and finish.
- Replay — rewatching a recorded run (the video or the track) after it finished, to study behaviour that went by too fast to judge live.
- Gazebo — the 3D physics simulator that hosts the virtual world and the drone.
- SITL — “software in the loop”: the real flight-control software running on a normal computer instead of on a physical board, so we can fly without risking hardware.
- mavros — the bridge that lets ROS2 talk to the flight controller (telemetry in, commands out).
- ROS2 (Jazzy) — the robotics middleware that wires all the pieces together.
- OOD (“out of distribution”) — a situation the drone’s learned behaviour has never really practised. Like a driver who only ever drove one car park suddenly being asked to park in a different, larger one.
- safe-box — a software fence: an allowed region of space. If the drone’s reported position leaves it, the system stops issuing movement commands and just hovers, for safety.
1. What we wanted
The goal was simple to state: get good recordings of the drone flying itself, in two different virtual rooms, and produce both a video and a drawn flight path for each run. Up to now I had been judging runs almost entirely from logs and live watching. I wanted artefacts I could replay and compare later — especially a top-down track, because a path drawn on paper tells you instantly whether the drone is sweeping a room cleanly or wandering.
A secondary goal was to exercise the world-switch checklist I had been writing (docs/world-switch.md): a step-by-step list for moving the same drone from one virtual room into another without surprises. A recording session is the perfect stress test for it.
2. What I did
I flew two runs back to back and recorded each one.
Run #1 — the “home” room. This is the small empty room the current flight behaviour was trained in. It is the drone’s comfort zone, so I expected a clean perimeter sweep.
Run #2 — our own indoor room. This is a larger, more realistic room. The drone’s behaviour had never practised here, so this run is deliberately OOD — I wanted to see how it copes outside its comfort zone.
For each run I captured a video and, separately, logged every position sample and drew it as a 2D track. While doing this I also slipped in a quick flight-controller sanity check (“FC-smoke”) to confirm the sensor bridge was alive.
Here is what each run produced:
| Artefact | Run | Notes |
|---|---|---|
| Flight video | Run #2 (indoor room) | ~180 s screen recording |
| 2D track | Run #1 (empty room) | ~2,400 position samples over ~249 s |
| 2D track | Run #2 (indoor room) | ~6,300 position samples over ~629 s |
| Raw position CSV | both | kept only as the drawn PNG track; the raw rows were temporary |
| World-switch checklist | — | docs/world-switch.md |
3. Results
Run #1 — clean-ish, with a wobble at two walls
Watching live, the take-off was lively and the drone handled the first wall perfectly. But along two of the walls it didn’t glide straight and parallel — it nosed forward and back at an angle, a little zig-zag, with some unnecessary turns. The drawn track confirmed it: the drone does walk the whole perimeter, but with that wobble at two of the walls.
The important part is where this comes from. The mechanics underneath were clean — no command time-outs, the safety guard stayed silent, the motion layer did its job. The wobble is a quirk of the learned behaviour, not of the plumbing. So the fix is not to tune knobs; it’s to swap in the next model version once the learning team delivers it. Run #1’s track is now my baseline: when the new model flies the same room, I can lay the two tracks on top of each other and see whether the wobble is gone.
Run #2 — a lively start, then stuck in place
Run #2 told a more interesting story. The drone started briskly, flew straight down the corridor heading east… and then stopped and “fidgeted” on the spot, roughly in the middle of the room, for the rest of the session.
Reading the logs afterwards, this turned out to be two layers stacked on top of each other:
- The room is bigger than the bridge assumed. Our position-tracking grid was sized for a smaller room. Past a certain distance from the start, the drone was simply off the edge of that grid — so its internal “where have I been” map stopped updating, and its picture of the world froze.
- The safe-box fence kicked in. A little further out, the drone’s reported position crossed the safe-box boundary. As designed, the system then stopped sending it anywhere and held a hover instead — for over ten minutes. The “fidgeting” I saw was just the tiny jitter of that hold-in-place hover.
So Run #2 was not a bug. The safety fence did exactly what it was built to do for rooms up to a certain size. What it exposed is a mismatch between the size of this particular world and the assumptions baked into the bridge — which is, almost word for word, item #3 on my world-switch checklist. The very first real world-switch confirmed the risk the checklist had predicted.
Three small things found and fixed during the session
- The capture script was grabbing the wrong window. It was picking up an invisible 1×1 proxy window instead of the real simulator window, so the recorder saw a zero-size video. Fix: point the capture explicitly at the real “Gazebo Sim” window (and pass the display variables). I documented this rather than auto-patching the script; a longer-term fix is to filter windows by size.
- The flight-controller launch was silently ignoring our sensor config. A small typo in the launch file meant mavros loaded a stock sensor configuration instead of ours, so it was subscribed to none of our sensor topics. The FC-smoke check caught it. Fixed by launching the mavros node directly with our own parameter files. Verification is pending on the next stack start — I didn’t interrupt the live flight to test it.
- A scary-looking mavros “time-jump” error on GUI start is just noise, not a blocker. The reliable way to confirm the link is up is to check the state topic, not to read that log line.
4. Sources
- Engineering journal entry:
claudedrone-git/docs/dev-log/25-flight-videos-and-tracks.md - World-switch checklist:
docs/world-switch.md - Recorded artefacts: flight video and 2D tracks (see the table above)
5. What’s next
- Re-run the FC-smoke check after the mavros fix and confirm our six range sensors and the down-facing sensor all report in — then hand that result to the firmware team.
- Make the position grid and safe-box size per world, passed in at launch, so any room larger than the current limit doesn’t immediately freeze the drone at its boundary. The parameters already exist; they just need to flow through from launch.
- Bring in the next model version once the learning team finishes its multi-seed run, and re-fly Run #1’s room to compare tracks directly.
- The wall wobble from Run #1 isn’t worth fixing on the current model — the new model replaces it anyway — but Run #1’s track stays as the comparison baseline.
- The GPU rendering path survived two more GUI cycles cleanly (only harmless warnings), so video capture with the GUI on is stable enough to keep using.