The thought experiment
Walk into any neighborhood lane and look at the scoring console. Half of it
is Eisenhower-era electromechanics with a CRT bolted on. The other half
works fine until someone moves the ball-return camera and now the system
thinks every spare is a strike. The actual data — ten pins, two throws, ten
frames — is trivial. The instrument that captures it is the part that drifts.
Bowling Ball is the AK-mee™ answer to that drift. A pin-deck-aimed depth
sensor plus an edge-inference Jetson plus a pico projector throws the
score back onto the lane surface where the bowler is already looking. No
console replacement. No lane retrofit. Calibration is one geometry pass per
install.
Why this is a paper concept and not a build
The hardware is solved. The depth sensor and the inference pipeline came off
the Project Sand bench. The chassis re-uses the AK-mee FDM enclosure pattern
we run on every Jetson-class build. The projector was characterized for
Sand and the lane geometry is a tighter, easier mapping than the sandbox's.
What we don't have is a lane. AK-mee runs in Pittsburgh, not in a bowling
alley, and the project is paused at the architecture-and-prose stage until
the right partner — a small alley operator, a league, a coaching outfit, a
bowling-equipment vendor — wants to put a sensor over a real pin deck and
put the score on a real surface. When that conversation happens, we have the
design. Until it does, this lives on the shelf as an architecture proof
point — same fleet, same bench, different target.
Capability proof points
Even as a paper concept, Bowling Ball demonstrates the AK-mee pattern that
customers can read off the page:
- Hardware reuse across application domains. The Sand bench, retargeted in days. We design our sensor stacks to outlast the original use case.
- Edge inference on constrained hardware. Pin classification + tracking runs on the Jetson with no cloud round-trip — the lane has questionable Wi-Fi, the bench doesn't care.
- Projector overlay as a UI surface. The display is the lane. No new console, no app to install, no second screen to look at.
- Containerized vision pipeline. The same Docker image that runs Sand's terrain overlay runs Bowling Ball's pin classifier with a swapped model — reproducible from a single Makefile.
Lessons
A paper concept is a real deliverable.
Not every project gets built. Some get scoped, drawn, and shelved with a clean hand-off so when the right partner shows up, the team picks it up where the architecture left it. Bowling Ball is in that bucket — fully scoped, ready to break ground, waiting on a real lane and a real reason.
Sand and Bowling Ball share a sensor stack on purpose.
Same depth sensor. Same Jetson. Same projector. Same containerized vision pipeline. The sandbox is one geometry; the bowling lane is another; the inference target — pin-down/pin-up classification with frame-by-frame tracking — slots into the same architecture with a swapped model and a recalibrated projector mapping. Reusing the bench is the reason this is a paper concept and not a six-month build.
Score is just a downstream of detection + tracking.
The hard part isn't the scoreboard. It's reliably classifying ten pins as standing or fallen across glare, motion blur, overlapping geometry, and the brief moment the bowling ball is in the same frame as the pins. Once detection + tracking is solid, the rules engine that turns frames into a Yahtzee-style scorecard is a hundred lines of state machine.
The pico projector earns its keep on the second visit.
First visit, the projector renders the score. Second visit, it renders the lane angle for league players, the spare-pickup geometry for casual bowlers, the per-pin pickup-difficulty heat-map for anyone who likes nerd graphics on their bowling. The same projector that overlaid terrain on Project Sand becomes the coaching surface here. That's the leverage paper concepts give you — same hardware, more uses.
