Project: Robotic Air Hockey Table
Overview: The overall goal of this project is to build and program a robot to play a miniature version of air hockey
Project Criteria:
Must Haves:
Ability to block player shots
Ability to shoot at the opposing player’s goal
Ability to track the puck location in real-time
Should Have:
Just as fast or faster than the general human player
Variation in shot types
Nice to Have:
Track score
Have multiple difficulties
Build Updates
Build Update: 5/5/2025
My code and Unity can finally interact! Currently, all that’s happening is that when the puck crosses to the program’s side, Unity takes two screenshots, counting the time between them, then runs the main Python script. I can then compare the output of the trajectory with the simulated trajectory. The program does output the G-code location for the collision position, but there is more work needed to convert raw G-code into “Unity-friendly” coordinates.
Next steps are to define a consistent home position for the G-code and then make a Unity script to read the output and move the mallet to the correct location.
As of now, I am graduating from college, so I will be moving and won’t have access to my computer as I move. Once I’m moved in and setup I’ll start working on it again
Build Update: 4/24/2025
I decided to use Unity as it’s a free software I’m familiar with, and after doing some research online, I found that it’s not the worst option as far as robotic simulators go. In the long term, I’d like to learn Isaac Sim for a future project, but for now, I think stimulating in Unity will work if I can tune the parameters correctly.
As far as progress, I spent some time teaching myself some basic modeling skills in Blender. Using this, I tried to make a realistic hockey table, as close as I can to the one I plan to use in the final project. I also used this to make the puck and mallets. I wrote some simple code to allow me to move one of the mallets with my mouse and to simulate the “bounciness” of the puck.
Build Update: 4/15/2025
In my spare time, I’ve been trying to get the shooting logic to work. The interception logic now dynamically selects optimal strike points using a scoring system that balances timing, shot type, and goal alignment. The select_optimal_point() function evaluates candidate points along the puck’s trajectory, prioritizing direct shots to the goal’s center (highest scoring) and bounce shots off walls (risk-reward balance). Corner collisions occasionally cause erratic velocity vectors due to rounding errors in normalizing reflection angles. This is because I’m trying to use a simpler calculation due to the hardware restrictions of the Raspberry Pi. The intercept code still isn’t perfect, but with some tuning, I think it’ll work fine for this application.
Next, I think I’m going to look into simulating the gantry and image collection, as I don’t plan on buying the air hockey table just ye,t because I am graduating soon and will have to move.
Build Update: 3/23/2025
So it’s been awhile! I’ve been packed with school so I decided to put my projects to the side. Now I’m back!
I’m still waiting for the Raspberry Pi to get delivered. The package got lost in the mail so I’ve been waiting for Amazon to send a new one, which should be in the next week or so. In the meantime, I’ve started experimenting with the trajectory prediction software that’s going to run on the Raspberry Pi. I started by finding a top-down picture of an air hockey table that very closely resembles the table I will eventually buy. I then made multiple copies with the puck in different positions. This will hopefully stimulate the “movement” between frames.
The program tracks an air hockey puck's movement between two images to calculate its velocity and predict its future trajectory, accounting for the puck's radius and table geometry. It uses OpenCV to detect the table boundaries and puck position, then simulates bounces off both flat edges and rounded corners. The final visualization overlays the predicted path on the image with velocity metrics.
Build Update: 2/21/2025
Rewrote the speed test to use the FastAccelStepper library and the program determined that the max speed and acceleration the gantry could reach was:
Max Tested Speed: 36000
Max Tested Acceleration: 150000
Once again the steppers should be able to move faster. While the FastAccelStepper library can reach up to 200,000 steps per second, that is only with an ESP board. The board can’t reliably push faster speeds due to Arduino Mega’s 16MHz processor. While the gantry is moving fast, it’s not fast enough to meet my required criteria.
I will eventually need an Arduino to run the image processing and trajectory planning so I’m looking into using Klipper and a Bigtree stepper control board.
Build Update: 2/15/2025
After a ton of research, I found this table. It outlines all the microcontroller stepper driver libraries and the maximum speeds they can drive steppers. turns out Accelsteper has a max speed of 4000 steps/sec. I’m going to switch to FastAccelStepper to drive the steppers. Time to rewrite the entire codebase!
Build Update: 2/9/2025
Began running speed tests with an Arduino, TMC2209 Stepper drivers, and the AccelStepper Library to characterize the max speed and acceleration. I made a program that incrementally increases the speed and measures the time it takes to reach two points. It continuously does this until the time doesn’t increase then begins increasing acceleration the same way. Once that maxes out it repeats the process, starting with speed until increasing the speed and acceleration don’t affect the travel time.
That being said the gantry is not going as fast as it should be
Build Update: 2/5/2025
The connection between the two gantry sections wasn’t stiff enough for the required application. Add 10mmx10mm aluminum extrusion between the two gantry sections
Build Update: 2/1/2025
Finished Design of the CoreXY Gantry. Beginning to 3D printing all the components and start initial assembly.