Computer vision and sports tech: line calling designed in simulation first.
Calling a shot in or out from cameras depends on calibration, timing and how the ball moves, and each can be tested before anyone buys a camera. We built a badminton line-calling digital twin in Python to do that. It is a v0 simulation demo, with no real cameras, courts or matches behind it.
The problem
A camera-based line-calling system has many parts that interact: how many cameras, where they stand, how well they are calibrated, how closely their clocks agree and how the flight of the shuttle is modelled. Buying and installing cameras to find out which choices matter is slow and expensive. A simulation lets the choices be compared first. We would typically build that simulation for a sports technology team, and then carry its findings into the design of a real capture setup. We would start from your sport and the decisions you need to make, such as how accurate a call has to be, how many cameras are practical at your venue and how the cameras are to be kept in step.
Our twin is for badminton and is simulation only, so we would present any result for your sport as simulated until real footage had been tested. The stages of the pipeline would carry across, while the models inside them would be built for your sport. A simulation answers one kind of question: which choices matter, and by how much, before any hardware exists. It does not tell you how a real detector behaves on real footage, and ours does not claim to. We would treat a real detector and real camera footage as the next stage, not as something already done. We would also agree what a useful output looks like, whether a call, a probability or a full track, and how it is shown to the people who use it.
What we've built
Badminton line-calling digital twin
A simulation of four tripod cameras watching two robot players, modelled at 1080p and 120 fps with a 95 degree lens. The image detector is a statistical noise model, not a real vision model, so every number it produces is a simulated one. It is written in Python, with a three.js 3D viewer.
Simulation demo, v0, in a private repository. No real cameras, courts or matches.
| Layer | What we did | Detail |
|---|---|---|
| Calibration | The pipeline calibrates each camera from court landmarks using PnP, and allows for offsets between camera clocks. | PnP calibration from court landmarks · clock offsets handled |
| Tracking | It triangulates the shuttle from several views, splits the track into separate shots and fits a drag model to each shot. | Multi-view triangulation · shot splitting · per-shot drag fit |
| Call | Each landing comes out as an ellipse, with an IN or OUT call and its probability. | |
| Sweep result | In simulation, fitting drag per shot mattered most, with landing error of 23 mm against 1.4 mm across the settings compared. Synchronisation and calibration came next. | Frame rate and camera count mattered little for landings. These are simulated numbers only |
How working with us goes
- 01 Scope We agree what has to be built, where it lives and where the data goes.
- 02 Prototype Working hardware and firmware on your bench, tested against real conditions.
- 03 Pilot A small batch on real sites, with fixes folded back into the design.
- 04 Production Design for manufacture, a production run, and support once it is in the field.
Related
Technical research ·Robotics and automation ·Product development · All sectors →