BowlSense Learn

From Raw IMU Data to Community Ball Stats — How BowlSense Turns Sensor Data Into Useful Insights

We built a pipeline that takes raw accelerometer and gyroscope data from inside a bowling ball and turns it into real trajectory paths, speed profiles, and community-wide ball comparisons. Here's how it works.

Want to compare your own lineup first? Map the balls in your bag with the free Arsenal Builder, then use the community data as context rather than a shopping list. This week we shipped something I've been wanting to build since day one: Community Ball Stats — a page where you can see how a specific ball actually performs across different bowler speeds and rev rates, based on real sensor data from the BowlSense puck.

But getting there required solving a harder problem first: turning raw accelerometer noise into a real ball trajectory. The Problem With Double Integration When you have an IMU (accelerometer + gyroscope) spinning inside a bowling ball at 300+ RPM, the raw data is... a lot.

4,500+ samples at 416Hz, with gravity mixed into every reading, the sensor rotating through all orientations multiple times per second, and tiny accelerometer bias errors that compound every millisecond. The textbook approach is straightforward: subtract gravity, double integrate acceleration to get position. In practice, this fails spectacularly. Accelerometer bias of even 0.

01g accumulates through two layers of integration (velocity then position) and after 2 3 seconds of lane contact, your calculated ball speed drifts to absurd values — some of our test throws showed 260 mph at the pins. The Fix: Physics Constrained Velocity We solved this by splitting the problem in two: Down lane speed (Z axis): Instead of trusting the accelerometer, we use kinematics.

We know the lane is exactly 60 feet. We know the transit time precisely from the IMU timestamps. With a known friction deceleration (~3.2 ft/s for a typical house oil pattern), we can solve for release speed: v0 = (d + 0.5 a T^2) / T . The velocity curve is then just v(t) = v0 a t — simple, clean, physically correct. Lateral motion (X axis): This is where the IMU shines.

The hook shape — that characteristic curve from the foul line out to the breakpoint and back to the pocket — is captured beautifully by the lateral accelerometer. We integrate it with trapezoidal rule and remove linear drift, preserving the curve shape while eliminating bias.

The result: validated against 33 real throws with an Ebonite Aero Dynamix, 28 out of 33 now produce physically plausible trajectories with release speeds in the 13 22 mph range and proper deceleration to the pins. From Trajectory to Community Stats Once you can extract a reliable throw profile (speed, rev rate, axis tilt, hook factor) from every throw, aggregating across users becomes possible. The pipeline: 1.

Capture: Sensor puck records throw inside the ball 2. Analysis: Raw IMU samples run through the axis tracking pipeline — release detection, gravity alignment, axis path computation, impact detection 3. Trajectory: Physics constrained integration produces a lane frame ball path with speed at every point 4. Storage: Throw data syncs to Supabase (your throws stay private, community stats are fully anonymized) 5.

Aggregation: A materialized view buckets throws by ball, speed range, and rev range — computing average hook factor, strike rate, and entry angle The Community Ball Stats page lets you filter by speed and rev rate to see how a ball performs for bowlers in your range. Is a Storm Equinox too much ball for a 14 mph / 200 RPM bowler?

How does the Ebonite Aero Dynamix hook factor change between 16 18 mph and 20+ mph throwers? These are questions the community data can answer once we have more users contributing throws. What's Next Right now the data is seeded from my own 33 test throws — all with the same ball (Aero Dynamix). The next milestones: More balls, more bowlers. The value scales with diversity.