Pool Playing Robot

I'm playing pool and think "Robots are doing brain surgery, how is one not yet playing pool?"

"If one were to be made, what would it look like?"

I start sketching...

It doesn't take long to realize that the first challenge to making a pool playing robot is to circumnavigate the pool table legs. Pool tables are super heavy, If a robot is going to come from underneath the table, it will need to get around some big, strong table legs.

Robot designs get very complicated when they have to bob in and out of table legs. I struggle with this challenge for a long time. Then, I see someone holding a bouquet of flowers and think, "Support the table from one pedestal in the center and you can eliminate the table legs altogether." I draw it up.

I see an artist laser cutting and then stacking layers of cardboard to make flowing and unique shapes. Later, I see a construction site with a perfect rectangular stack of plywood. I think, "If I can laser cut plywood, I could stack the pieces into a pedestal big enough to support a pool table."

I find a laser cutter that can cut wood one sixth that of construction site plywood. Thus begins the one-sixth scale mini-Judith project.

I realize I traded one challenge for another with the pedestal decision. Sure there are no table legs, but where am I going to find a three foot inner-diameter bearing?

Discouraged, I tell a student the challenge and he suggests making a bearing. Pool balls are there and the idea develops to use pool balls as ball-bearings. Slingshot ammo is one sixth the size of a pool ball.

The motion platform feels like a blank canvas for design ideas to access and shoot the balls. I do a lot more sketching and then it pours rain outside for a few days straight. Work gets canceled. I stay home and build a prototype.

I talk with a science teacher using stop motion video to have students learn about proteins. I am inspired to test the geometry of the Judith prototype using stop motion. The geometry seems to work for straight forward shots.

It feels like time to start adding programmable motion control to the system.

I'm doing a 3D-printer repair and it hits me that 3D-printer belts are really good, really cheap and readily available. One of those, a little razzle-dazzle gear designing and voila', servo/belt control of the platform motion.

I redesign the prototype with servos, belts and gears at the points of rotation to add programmable motion.

While doing so, I stumble across an easy win. It turns out that the "parked under the table" orientations, and the "perpendicular to the table" orientations are regular stops for pool playing robots. Adding two tabs to a layer of the table pedestal and placing two switches on the motion platform is a simple way to reliably detect those positions.

We certainly need a camera looking down on the table to see what is going on in the game. The trouble is with the cables connected to the camera. Aren't they going to tangle as the platform spins around the table?

That question is yet to be answered. I decided to suspend a mirror above the table and to put a camera on the platform at an angle. The PixyCam is a great tool to test the idea on a 1/6th scale and 3D printing an angled Pixy mount is easy enough.

The Pixy sees and recognizes pool balls by color and provides identity and location data. Here, I'm showing pool ball identity and location data being received through the Arduino serial terminal.

As a bonus, the Pixy gives angle data if two color swatches are placed next to one another. One way to use this feature is to put dials with paired color swatches in view of the Pixy. If we then link position commands to the angle data of the color swatches, we can give Judith "remote" commands simply by turning the dials.

This scale model consists of two independent Arduino based motion systems. The first controls the coarse motions of the machine and the second is responsible for the finer motions of aligning the shooting mechanism with the cue ball.

The coarse motion system controls the platform and the two linked "bicep" servos that lift the rest of the machine. As the lifting motion must be slow, I used VarSpeedServo libraries to control the servo speed.

There are two switches positioned to identify both parked and perpendicular platform orientations. The code moves the platform between the perpendicular and parallel positions while slowly raising and lowering the biceps. Ball location data is collected through the PixyCam when the platform is perpendicular to the table.

The second system connects to the first system with an "extender" arm that is fitted with a Flora LSM9DS0 sensor. (Special thanks to the Adafruit support forum for help with the LSM9DSO sensor.) The extender servo tracks the Flora sensors angle data to maintain target angle positions. The shooting mechanism is represented here by a tilt/pan system driven by a PixyCamera trained on the cue ball color. The code posted drives the extender arm to target angles while the tilt/pan system tracks the cue ball.

Thanks to the supportive forum at Allaboutcircuits.com, I've been able to make progress on the shooting mechanism. I'm doubling the coil count and adding position control. It should be smoother and stronger in no time.

I have yet to write a strategic shooting algorithm.

I proposed the challenge of making shot commands based on ball data to a computer science student and he came up with a fascinating bit of code that first finds all possible shots and then selects the shot to take based on which has the largest margin of error. I have a lot to learn in the computer science department and am excited to do so.

Thank you for looking at my project.

Please comment with your thoughts and ideas!