-
-
Main Dashboard The main dashboard provides easy access to Outpace Baseball’s AI-powered pitching analysis features.
-
AI-Powered Pitching Feedback
-
Language Selection Supports multiple languages to make AI-powered pitching analysis accessible to players worldwide.
-
Interactive AI Pitching Coach Allows users to ask questions and receive AI-powered guidance on pitching mechanics and training.
-
3D Pitch Trajectory Visualization Visualizes pitch trajectories in 3D to help players better understand ball movement.
-
Two-Pitch Comparison
-
Pitch Quality Radar Chart
-
Pitch Quality Comparison
Inspiration
Baseball players at every level want to improve their velocity, mechanics and consistency, but detailed pitching analysis usually needs radar guns, motion-capture systems or professional coaching. As someone passionate about both baseball and AI, I wanted to build an affordable tool that gives players data-driven feedback from video recorded with an ordinary camera. That idea became Outpace Baseball.
What it does
Outpace Baseball analyzes a pitching video and presents:
- Estimated release velocity. Velocity is computed from flight time $t$ and travel distance $d$ with a quadratic air-drag model, so it estimates the speed at release rather than the average speed:
$$v_0 = \frac{e^{k d} - 1}{k\,t}, \qquad k = \frac{C_d\,\rho\,A}{2m} \approx 0.0052\ \text{m}^{-1}$$
- Pose-based mechanics feedback. Lead-knee angle, elbow angle, arm slot and stride length are turned into a rule-based mechanics score and coaching messages (no language model is involved in this part).
- Pitch comparison and history. Two pitches can be compared side by side, with a Stuff+ prototype radar chart, estimated movement and spin, and an illustrative 3D spin-axis view. These movement and spin values are estimates and have not been validated.
- AI Pitching Coach. A chat powered by Amazon Nova 2 Lite on Amazon Bedrock answers questions about the computed results. It receives the metrics and the question, never the video.
- Amazon S3 storage. Uploaded videos are stored in S3 and can be loaded back into the app, and a metrics-only result summary is saved for later reference.
How I built it
The app is written in Python with Streamlit. OpenCV 5.0.0 handles the video layer: capture and metadata (frame rate, size), frame seeking for the release snapshot and frame scrubber, drawing skeletons, motion trails and overlays, and writing annotated videos. YOLO11n-pose extracts the pitcher's keypoints, which drive the mechanics rules and the estimate of the pitcher's extension and pitch distance (using a perspective correction for smartphone footage). Amazon S3 and Amazon Bedrock are used through boto3, with a sidebar status panel showing the AWS configuration and connection check.
The public demo runs on Streamlit Community Cloud. The repository also contains a Dockerfile, an EC2 user-data script, least-privilege IAM policies and a deployment guide; I have not yet verified the EC2 deployment.
Results
I compared the velocity estimates with an SSK Multi Speed Tester IV radar gun on three pitches from the same pitcher and camera setup. The estimates were 97.34, 99.75 and 102.73 km/h against radar readings of 98, 98 and 102 km/h, a mean absolute error of 1.05 km/h. This is a very small sample with fixed release and arrival frames, and at about 30 fps a one-frame difference changes the result by roughly 5 km/h, so I treat it as a consistency check of the model, not as a general accuracy claim. The repository has 36 unit tests and a smoke test that reproduces the sample velocities. The technical report describes the method, the failure cases and the limitations in detail.
Challenges I faced
- Timing resolution. Velocity depends on release and arrival frames, so low-frame-rate video limits accuracy.
- Ball detection. The ball is small and fast. The sample videos use tracking data, but for new uploads the app estimates release from wrist motion and assumes a flight time, so those speeds are not independent measurements. Real OpenCV-based ball detection is the most important next step.
- Cloud integration. The demo host has an ephemeral filesystem, so I added an S3 round trip (upload, load back, result summaries), moved secrets handling into the app, and made failures visible instead of silent.
- Presenting estimates honestly. Spin, movement and Stuff+ are model-based estimates, and the interface and report say so.
What I learned
Connecting computer vision, AWS services and a usable interface taught me that reliability and clear communication matter as much as the models. Validating against a real instrument, even on three pitches, showed me where the estimate is trustworthy and where it is not.
What's next
- Collect a larger, more diverse radar-labelled dataset with several frame rates and pitchers.
- Detect and track the ball with OpenCV so release and arrival are observed instead of assumed.
- Run and measure the Docker/EC2 deployment on AWS.
- Validate the spin and movement estimates.
