Product Thinker

©2026

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

01

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.

Even at the professional level, a line call is a split-second read on a fast, low trajectory: the call support amateur courts get none of.
Even at the professional level, a line call is a split-second read on a fast, low trajectory: the call support amateur courts get none of.Fig. 01
02

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."

From tracked shuttle to line call
01
Video capture
Each rally capped to a 10-second buffer, one landing event per clip.
02
Candidate landing filtering
Track average velocity and the change in falling motion to isolate the true landing frame from noise in the raw shuttle track.
03
Homography mapping
Map the 2D pixel landing point onto the real court plane using known court reference points.
04
In/out classification
Compare the mapped landing point against the actual line to produce the call.
The landing-detection pipeline I owned: everything after SoloShuttlePose hands off a tracked shuttle position.

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 shipped Owl Eye desktop app: SoloShuttlePose's court grid, pose skeletons, and tracked shuttle position overlaid on a live camera feed, with a challenge button that triggers the landing-detection pipeline.
The shipped Owl Eye desktop app: SoloShuttlePose's court grid, pose skeletons, and tracked shuttle position overlaid on a live camera feed, with a challenge button that triggers the landing-detection pipeline.Fig. 02
03

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.

A homography matrix H maps a point (x, y) on the real-world court plane to its corresponding pixel (x', y') on the camera's image plane, the transform behind turning a tracked pixel into a court position.
A homography matrix H maps a point (x, y) on the real-world court plane to its corresponding pixel (x', y') on the camera's image plane, the transform behind turning a tracked pixel into a court position.Fig. 03
The homography-mapped court boundary with a tracked shot's flight path projected onto real court coordinates: the transform that turns a pixel position into a measurable in/out call.
The homography-mapped court boundary with a tracked shot's flight path projected onto real court coordinates: the transform that turns a pixel position into a measurable in/out call.Fig. 04

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.

Court and net detection at real venues
Field-tested with a tripod-mounted webcam and phone, 1080p at 30fps, at PAC and KC Badminton Club.
Found
Off-the-shelf detection
Could not reliably detect the court or net under real lighting and line-clarity conditions on courts we did not train on.
Shipped
Custom-trained detector + manual fallback
Trained a court-detection model on the specific courts we had access to, keeping manual annotation as a fallback when detection failed.
Real-world testing, not lab conditions, is what surfaced the court-detection gap and forced the fix.

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.

Field testing at PAC (a multipurpose gym floor, not a dedicated badminton venue), with the uneven lighting and line contrast that off-the-shelf court detection struggled with.
Field testing at PAC (a multipurpose gym floor, not a dedicated badminton venue), with the uneven lighting and line contrast that off-the-shelf court detection struggled with.Fig. 05
Field testing at KC Badminton Club: the second venue used to confirm the custom-trained court detector generalized beyond the first gym.
Field testing at KC Badminton Club: the second venue used to confirm the custom-trained court detector generalized beyond the first gym.Fig. 06
04

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.

The fitted drag model against the observed shuttle track for a representative test shot: the comparison behind the ~10cm landing-position error and ~0.75m peak-height gap.
The fitted drag model against the observed shuttle track for a representative test shot: the comparison behind the ~10cm landing-position error and ~0.75m peak-height gap.Fig. 07

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.