Where it is.
Current build — shooter in progressMay 2026. The frame, drive, and vision system are complete. The ball-shooter is the remaining piece before full integration.
- a.Mechanical frame — near-final buildDone
- b.Ball tracking prototypeDone
- c.Stereo camera calibrationDone
- d.Ball-shooter mechanismOngoing
- e.Ball trajectory predictionOngoing
- f.AI strategy layerOngoing
- g.Full integration + court testing at SquashBustersQueued
- h.Player biomechanical analysis (post-deployment)Queued
From camera
to motor.
Hardware first, then software. Every component, every step in the pipeline — what's done, what's being built, and where we're stuck.
Two OV4689 cameras mounted on the robot's frame, 16 inches apart, each running at approximately 111 frames per second at 720p. Both feed the Jetson Orin Nano over USB simultaneously.
The global shutter is not optional. Rolling-shutter cameras read the sensor line by line — a fast-moving squash ball appears smeared or geometrically warped between scan lines. The OV4689 exposes the entire sensor at once, so each frame is an accurate snapshot regardless of how fast the ball is moving.
The 16-inch separation between the two cameras is the stereo baseline. A wider baseline gives finer depth resolution at distance. Sixteen inches is the practical limit given the robot's frame width. Stereo calibration — determining the precise geometric relationship between both cameras — is complete.
The Jetson Orin Nano is the robot's brain. The entire pipeline — camera ingestion, YOLOv8 inference, stereo triangulation, trajectory prediction, strategy, and motor dispatch — runs on this single board, mounted on the robot. It draws power from a dedicated power bank, isolated from the drive and shooter power systems.
Nothing is offloaded. No frames leave the robot for external processing. A squash ball moves fast enough that any network round-trip — to a server and back — makes the pipeline useless. The Jetson's GPU handles the full inference workload at camera frame rates on-device.
Four mecanum wheels allow the robot to move in any direction — forward, backward, sideways, diagonally — without rotating its body. Each wheel contains angled internal rollers; by varying each wheel's speed and direction independently, the robot produces any planar motion. On a squash court, this lets the robot reach any position quickly without wasting time on turns.
Four dedicated movement motors drive the wheels, controlled through a single motor driver. The drive system runs on a 24V 6-cell battery — its own power supply, independent of compute and delivery.
The Teensy 4.1 microcontroller sits between the Jetson and the motor driver. The Jetson sends high-level movement commands; the Teensy translates those into the precise, timed signals the motor driver needs to run the four movement motors. Separating motor control onto a dedicated MCU keeps the Jetson's processing budget available for the vision pipeline.
Handles wireless communication — remote monitoring and debugging during development. Not in the main control loop between cameras and motors; it runs as a separate interface alongside the pipeline.
The ball shooter uses two flywheel motors — one per flywheel — each controlled by a dedicated ESC (electronic speed controller). The flywheels spin at speed and launch the ball when it passes between them. The shooter runs on a 2s–4s LiPo battery, separate from both the drive system and the compute power supply.
This three-way power split — 24V for drive motors, LiPo for flywheels, power bank for compute — keeps each subsystem's power demand from interfering with the others.
Beam break sensors detect when a ball is present and correctly positioned in the shooter mechanism. This gives the system a hardware-level confirmation that a ball is loaded and ready to fire, so the strategy layer can time shots correctly.
A robotic arm for handling low balls is planned for a future phase. Not designed or built yet, and not required for the initial prototype to function as a drill partner.
Both cameras run simultaneously at approximately 111 frames per second at 720p, feeding raw frames to the Jetson Orin Nano over USB. At 111fps the ball doesn't travel far between consecutive frames — keeping per-frame detection tractable.
A YOLOv8 object detection model runs on each camera's frames independently, finding the squash ball per frame and outputting a bounding box. OpenCV handles ingestion and preprocessing around it. Both cameras run their detection in parallel on the Jetson — nothing is offloaded.
Current per-camera accuracy is approximately 74%. The model is working but not fully optimized — a squash ball is small, fast, and often close in color to the court walls. This number will improve with further training on real court footage.
Combines the two per-camera 2D detections with the calibrated stereo geometry to compute a single 3D position: where the ball actually is in space relative to the robot. Stereo calibration is complete. Triangulation is working but at approximately 53% accuracy.
Takes a running history of 3D ball positions and projects forward — where is the ball going, and when will it arrive? The predictor needs to account for wall bounces, which introduce discontinuities in the path. This is next on the software roadmap, once stereo accuracy is stable enough to provide reliable position data.
Given a predicted ball trajectory, the strategy layer decides where to move on the court and what shot to return. This is what makes Squat a drill partner — it receives a ball and responds with intent. Drill mode determines the behavior: in the drop-drive drill, the robot intercepts a straight drive and returns a dropshot. Follows trajectory prediction in the roadmap.
Movement commands from the Jetson go to the Teensy 4.1, which routes them through the motor driver to the four movement motors. Shot commands go to the ESCs controlling the flywheel motors. Beam break sensors confirm a ball is loaded before the shot fires. The entire dispatch layer is built — it's waiting for the software pipeline above it to be complete.
Everything runs on the Jetson Orin Nano, on the robot. No external server, no cloud, no round-trip. The path from camera frame to motor command has to be short — a squash ball is fast enough that any added latency makes the system useless.