FPV racing: timing, cameras, recognition
The timer counts laps, the cameras decide for themselves whom to film, and the judge sees evidence instead of an argument
The challenge
A MultiGP-style FPV race means eight pilots in the air at once, a lap in a few seconds and a camera operator who cannot keep up with any of the drones. The timer records passes but does not explain why a lap came out impossibly fast: a reflected signal or a cut corner. Disputes with pilots are settled on someone's word, the footage is hit-and-miss, and after the event there is nothing worth posting.
Dmytro organised these competitions himself: placed the cameras, filmed, went through the footage. So the system grew out of the field rather than out of a specification; every feature answers a question that had already come up on race day.
What was built: three modules
- ✓ Timing and judging: lap counting from an ImmersionRC LapRF 8-Way timer, a review queue for the judge, spoken announcements, a scoreboard for the team and the pilots
- ✓ Cameras and automatic filming: PTZ cameras, detection of people and drones, a director that picks the live shot by itself, recording and editing of vertical clips for social media
- ✓ Flight analysis: breakdown of the drone-camera video into events, a route map from a reference run, comparison of pilots' lines; a separate partner build bound to one machine
- ✓ The virtual-laprf bridge: the system speaks LapRF outward, so LiveTime and FPVTrackside accept it as a regular device
How the hardware talks
The LapRF timer is connected over Ethernet; the protocol was decoded down to the codec and checksums, the device clock is synchronised with the server, and lap counting survives reconnects and timer restarts. For development without hardware there is a simulator that behaves like the real device.
The cameras live on a single Cat6 cable: PoE+ carries power, RTSP the video, VISCA over IP the motor control. A PTZ is aimed by a controller that reads the position back from the camera instead of guessing it from the picture. Every device is described in one config; adding a camera is a few lines.
What recognition does
A scout-and-sniper scheme: wide static cameras find the target in the overall view, the PTZ brings it in close. One detection model processes frames from all cameras in a single pass on Apple Silicon. Each camera owns its zone: one person gets a close-up, several make the camera pull back, and if they still do not fit it asks a neighbour to cover.
Drones are tracked as motion against a static background with a Kalman filter that predicts the next position. Team members' faces are recognised so a person can be pinned to a camera; spectators' emotions tell the director where the interesting moment is. The director holds a shot for at least a few seconds so the feed does not twitch on every detection.
What a race day looks like
- The network comes up from the PoE switch; cameras are found by MAC address because their IPs change after a reboot. The health page says in a second what has not come up.
- The server finds the timer on the network by itself, spreads the pilots across Raceband frequencies with maximum separation and calibrates sensitivity to the noise floor.
- During a heat, laps are counted and announced by voice, the scoreboard is open on the team's phones, the director switches cameras and recording never stops; the footage matters more than the analytics because it cannot be re-shot.
- The judge sees not "violations" but grounds for review with evidence: an over-fast lap, a discarded pass, a lost link, a mismatch between the timer and the video. Every ruling goes into the log.
- After the event, the drone-camera videos go into a folder; the analyser picks up new files by itself, builds the route map and compares the pilots' lines. Vertical clips for social media are cut from the recordings.
The result
- ✓ The LapRF protocol was verified on a live device with no unparsed records; the logs survive a hard kill intact
- ✓ Disputes with pilots are replaced by evidence: the judge opens the clip instead of hearing versions
- ✓ Filming runs without an operator at every camera, and after the event there is material for social media
- ✓ The team stays in LiveTime or FPVTrackside; new sensors do not break the usual workflow
Stack
Python · ImmersionRC LapRF protocol · VISCA over IP · RTSP · PoE+ · YOLO11 · OpenCV · PyAV · Kalman filter · Apple Silicon (Metal) · Ed25519 · Nuitka · LiveTime / FPVTrackside
The unusual part
The same person organises the competition, places the cameras, decodes the timer protocol and writes the detection. So the system has no just-in-case features, only what was needed on the track.
FAQ
Does the system replace LiveTime or FPVTrackside?
No, and it does not try to. They handle heats, brackets and results well. Our system speaks the LapRF protocol outward, so LiveTime and FPVTrackside accept it as an ordinary timer and the team keeps its usual workflow.
Does the automation penalise a pilot on its own?
No. The system penalises nobody; it shows the judge a reason to review and the evidence: an impossibly fast lap, a discarded pass, a lost link to the timer, a conflict between the timer and the video. The decision is always human, and every verdict goes into the log.
Can the video analysis be handed to a partner club?
Yes, there is a separate build: the analysis module alone, without cameras or the director. It is bound to a specific machine, has a licence expiry and its own build number, so it cannot quietly spread as copies.