The pivot — drone → courtside gimbal (and a lesson)

Here’s where the project hit its biggest wall, and I want to log it honestly because the recovery taught me more than any milestone.

I was about to spec a drone. Then I actually researched drone law in Qatar and found out it’s one of the strictest regimes in the world: every single flight needs a QCAA permit (owning a drone gives you no right to fly it), and there’s a privacy law (Penal Code Art. 333) against filming people without consent, penalties up to two years. For a system whose whole job is filming school matches full of players and spectators, that’s not a paperwork hurdle, it’s a wall. My original picture a drone autonomously filming matches was effectively dead.

The lesson, written down so I don’t forget it: research the constraints of the real world before you fall in love with a plan. I’d validated the software to machine precision, but I almost skipped checking whether the deployment was even legal. Check the boring stuff first.

So I swapped the drone for a 3-DOF gimbal on a rail: a motorised camera mount (pan / tilt / roll) that slides along a track, parked courtside. No permit. Same filming-consent terms my existing fixed cameras already navigate. And it runs every match, not the one-off a permitted drone flight would’ve been. It’s more deployable than the drone ever was.

A gimbal is also a categorically real difference from just pointing a camera, for one optical reason that isn’t arguable: a fixed camera can only ever crop the pixels it already has, but a gimbal physically moves the lens real parallax, a real push-in that changes perspective, footage that simply doesn’t exist in a static feed. The human directs the intent (“orbit that player,” “push in”) and the system, which understands the scene, executes the move. That’s the thing a fixed camera can’t do, and it survived the pivot completely intact.

M9 — the gimbal’s brain (software)

Stardance just opened a hardware track, but this milestone was deliberately software: adapt the system to the gimbal before the parts arrive, so the maths is proven when the hardware lands.

The beautiful part: because I’d kept the architecture cleanly separated for nine milestones, the drone→gimbal pivot touched exactly one layer. The gesture engine, the scene tracking, the intent commands, the flight-path engine, the live bridge all unchanged. The only new code is a converter that takes an ideal 3D camera pose and works out what the gimbal can physically do with it: pan/tilt/roll angles to aim, plus a position along the rail.

And it stays honest, which is the whole point. A gimbal at a fixed pivot can rotate perfectly but can’t translate so a true orbit (circling a subject) is impossible without the camera leaving its rail. The converter proves this with numbers instead of faking it: a follow shot aims with 0.00° error and zero positional gap (the rig does it cleanly), while an attempted orbit still aims perfectly but reports a 9.05-unit gap, flagged out-of-reach on every frame the system refuses to pretend it can do something the hardware can’t.

Honest problems that will probably come up: this is geometry on a perfect simulator. The real gimbal will have motor speed limits, inertia, and backlash, it won’t snap to an angle instantly. That’s the hardware phase’s problem, and I’m not pretending the clean sim is the real rig.

Up next: the glove parts are shipping. When they land, the build goes physical. breadboard, sensors, solder. Then the gimbal it is