06 / 07 · Case study
Owl Eye
Role
Computer Vision Engineer
Discipline
- Engineering
Context
Sports tech
Year
2025
Owl Eye aims to emulate the functionality of Hawk-eye, an 8-camera, $60–70K USD line-call rig with a single phone camera, accurate enough on clean shots to give amateur badminton the call support only professional tournaments currently get.
As part of a 3-person team, I owned the landing-detection and homography pipeline that turns a tracked 2D shuttle path into an actual in/out call, built on top of an existing open-source shuttle-tracking and pose-estimation model.
$60–70K USD cost of the only existing line-call system (an 8+ camera Hawk-Eye rig), compared to Owl Eye's entire hardware budget of one phone
~10cm landing-position error on a representative test shot, most accurate on lob shots
2 real badminton clubs used for field testing (PAC and KC Badminton Club)
3 person team, in which I owned the landing-detection and homography pipeline
The Problem
Officiating scales down exactly where the disputes scale up
A badminton smash has been clocked at 565 km/h, the fastest recorded shot in any racquet sport, and every one of those shots eventually needs a line call. Professional tournaments handle it with up to ten line judges. Semi-pro events, like the Canadian Nationals, get one or two. Amateur games, where the overwhelming majority of badminton is actually played, get nothing: each player calls their own lines, on shots too fast to see clearly, which is exactly the recipe for the arguments anyone who's played competitive badminton has seen firsthand.
The technology that solves this at the pro level doesn't reach anywhere close to the amateur level. Hawk-Eye needs eight or more fixed cameras, costs $60,000–$70,000 USD to install, still carries a measured error of several millimetres, and struggles on the uneven, multipurpose-gym floors most local courts actually have. SwingVision solves the phone-camera part, but it's built for tennis, and a badminton line call has to work at a completely different flight speed and trajectory shape. Nothing existed for the actual gap: an officiating tool a club player could point their phone at.

Building on an Existing Model, Instead of Around One
The novel problem wasn't shuttle tracking, it was turning a track into a call
Rather than train a shuttlecock detector and pose-estimation model from scratch, the team built Owl Eye on top of SoloShuttlePose, an existing open-source badminton tracking model. That let us put our own engineering time into the piece that didn't already exist anywhere: turning a tracked 2D shuttle path into an actual in-or-out decision. My part of that pipeline was the landing-detection and classification stage, the step between "here's where the shuttle went" and "here's the call."
A separate branch of the pipeline, built by a teammate, took the same tracked positions and reconstructed a full 3D trajectory using a physics-based drag model, useful for shot visualization and stats on a challenged point, but the call itself only needed the landing frame and where it fell relative to the line.

The Decisions That Made a Single Camera Enough
A pixel isn't a court position until you tell it where the lines are
A monocular camera doesn't know where the court lines actually are in the real world, it only knows where they are in the frame. The homography transform is what closes that gap: using a small set of known court reference points, I mapped the landing pixel into real court coordinates, which is what turns "the shuttle looks close to the line on screen" into an actual measurable in/out call. Get that mapping wrong and every downstream number, however precise, is measuring the wrong thing.


The other problem was noise, not geometry. A raw tracked shuttle path has several points that look like a landing, a dip in the trajectory, a bounce, a moment near the ground, and naively taking the lowest point picks the wrong one often enough to matter. I filtered candidates by tracking average velocity and watching for the specific change in falling motion that actually marks a landing, rather than trusting position alone.
That gap only showed up once we left controlled test clips and filmed at two actual badminton clubs. It was a useful reminder that a model trained on clean reference footage doesn't automatically generalize to a gym floor with different lighting and line contrast, and that a manual fallback is worth keeping even after you've shipped an automated fix.


Where It Stands
Honest about which shots it gets right
Owl Eye is most accurate on lob shots, high, clean, parabolic trajectories that give the landing-detection pipeline an unambiguous falling motion to key off. On a representative test shot travelling around 70 km/h, the system landed within roughly 10cm of the true position, with the trajectory model's peak-height estimate off by about 0.75m, most likely from the depth ambiguity that comes with reconstructing a 3D flight path from a single camera. Sliding shots are the clear weak point: the landing-detection logic depends on the shuttle visibly falling and stopping, and a shot that skids rather than drops breaks that assumption.

None of that puts Owl Eye at Hawk-Eye's precision, and it isn't trying to. The honest comparison isn't accuracy-for-accuracy against an $60,000 rig, it's that amateur badminton currently has zero automated call support, and a phone camera that gets close calls right most of the time on the shots that matter most is a real improvement over two players arguing over a shot too fast for either of them to have actually seen.