Inside ZetAI Vision: Reading a Badminton Rally at 240 Frames a Second

A smashed shuttlecock leaves the racket at over 300 kilometres an hour and decelerates faster than almost any object in sport. At 30 frames a second it is a smear across two frames and then it is gone. Nothing useful can be extracted from that.

This is why ZetAI Vision runs at 240fps, and why the frame rate is not a specification detail but the thing the entire design is organised around.

Three problems wearing one coat

"Computer vision for sport" sounds like a single capability. In practice a rally has to be decomposed into three tasks with almost nothing in common.

• Detection and tracking — where are the players, rackets and shuttle in this frame, and which is which across frames. Spatial, per-frame, extremely latency-sensitive.
• Event classification — was that a smash, a drop, a clear or a net shot? Temporal, needs a window of frames, needs to understand intent from body position as much as from ball path.
• Segmentation — where does one rally end and the next begin? Structural, and the one that everything downstream depends on, because a mis-detected rally boundary corrupts every statistic derived from it.

The third is the one that surprises people. Getting the boundary wrong by one shot does not slightly degrade the analysis; it shifts the entire attribution of who won which rally, which invalidates the pattern data completely.

Why edge inference, not cloud

Uploading 240fps video from eight courts to a cloud GPU is not viable at a district venue. The bandwidth does not exist, and even where it does the round trip destroys the latency budget that makes live overlays and auto-scoring possible.

So inference runs at the venue, on hardware next to the cameras. Models are quantised to hit the sub-10ms budget on modest hardware, and what leaves the venue is not video but structured events — a few hundred bytes describing what happened, rather than gigabytes describing what it looked like.

This also matters for a reason that has nothing to do with engineering: raw footage of minors playing sport is data that should not be leaving a school gymnasium unnecessarily. Processing at the edge and transmitting events means the video can stay local by default.

What it produces

• Shot-by-shot rally reconstruction — every stroke, its type, its speed and where it landed.
• Court coverage heat maps — where an athlete actually spends their time, versus where they think they do.
• Movement and recovery patterns — how quickly a player returns to base, and how that degrades through a match.
• Automatic key moments — the long rallies and momentum swings that highlight generation and match analysis both draw from.
• Scoring signals that ZetAI Score uses to propose points to the umpire.

Honest limitations

Vision quality tracks camera placement more than model quality. A single camera at one end of the court produces usable rally segmentation and poor spatial data; two cameras at opposite corners produce good spatial data. We would rather say that than have a federation buy a system and discover it in month two.

Lighting matters enormously — a hall with mixed daylight and fluorescent lighting causes flicker at high frame rates that has to be compensated for. And the models are strongest in the racquet sports, where we have the most labelled data, and thinner in sports we added recently. That gap closes with usage, but it is real today.