Non Electrical Engineering asking for possible solutions to a problem

non-powered

Honestly a vision system is a good solution. What more could you ask for: you've got a continuous-color green backdrop to do object detection, all the balls are different colors or have a highly-visible white stripe. No need to try modifying the balls.

Other solutions require a highly modified table and ball set; maybe if you had a pressure-sensitive matrix under the padding, you could track the location of each ball in realtime if your system was fast enough. There are a lot of quick motions on a pool table, but you're helped by the fact that no two pressure points can be closer than the diameter of a pool ball. Pool balls are decently weighty too. Radio-triangulating would be exceptionally difficult at that distance and with so many points, also complicated by the fact that the balls will be spinning along and changing the signal strength as the antenna rotates. Some kind of radio-detection grid under the table would be pretty intensive and also difficult to get any good resolution out of.

"> > I'm writing software to track billiard balls on a pool table. I need an

Vision might be the easiest but there may be a couple of problems to overcome. Consider that if the stripes wind up horizontal, they would look just like the solid colored balls from the top If the balls were striped with two striped that are perpendicular to each other. That may help. Also, you would have to of course use green felt and not blue.

Could be done.

There are numerous solutions: Visual will be the cheapest, Software can compensate for the angle of the camera if it is not dead center above, but looking from aside. The calculatrions are not all that complex, particularly compared to the complexety of the entire task, which is not necessarily that complex.

How fast do you need to know all the positions? Real time or analysis after a shot. i.e. that data can be collected real time and analyzed real time or analyzed after the fact. The first is necessary for intercepting things, the later is fine for post mortem analysis.

Yes it is possible to implant location devices for tracking, but, you're talking some significant $ for the whole setup. Video should do fine.

Marc Reinig System Solutions

non-powered

Actually, the pool balls stripes are usually pretty wide, and extend down from both poles with the wide colored band in the middle. There is no angle you can view a striped pool ball from, and not be able to tell both that it is striped and what color it is. The video system merely needs to separate the balls from the backdrop, detect the various colored areas correponding to each ball, if a colored area's shape is too odd to be a sphere, add the adjoining white area and attempt to match that shape. The software would need to sort shapes starting with the easily identified circles (as they would be in front relative to the camera), then use those to know where to account for one ball's image being occluded by another. Of course this is less of a problem if the camera is mounted directly above the table.

Optimize the processing algorithm enough, and the computer might have time to pick up a cue and get in a few shots as well!

That is one of the problems I had considered too. There are others, like when all the balls are in the rack, it might be hard to tell where one ball ends and another begins. Plus a ball or several balls could be in a pocket, I'd have to code for where the pockets are so I don't look for balls there and think they are on the table. There is also the problem of the shooter and the cue stick being on the table interfering with the recognition system. The camera would have to be solidly mounted and any slight movements might mean a recalibration in the software of where the pool table is (of course, unless I can just scan and find it myself). I'd need to be able to find the edges of the playing surface which can be difficult since the felt rides a couple inches up the rail.

I'm hoping this uses a sort of standardized system so that one person can build a database of shots that he makes and his percentage of making them. His next door neighbor can also do the same on his table and the coordinates work out the same. I'd have to adjust for how big the table is in the video and do some calculations to compensate for different zooms if my software knows how big the table is physically.

Ultimately, what I want to see/sell is a service to people like ESPN2 (who occasionally show billiards on TV) to make pool more TV friendly. You never watch a baseball game without getting all sorts of percentages. If there was a player shooting a game winning shot, it would be nice if the announcers could say how often he has shot it in the past and how often he made it. Also, something that would make pool more TV friendly is if I could communicate how hard (speed of the cue ball) the shooter hit the break shot with. It's those little things that I think would make pool more TV friendly and entertaining for people to watch. Plus, people at home could setup the same shots and try things themselves and measure their break speed too.

The speed things (tracking a cue ball during a shot) is why I needed several iterations per second. Of course, a video camera will easily do between 24 and 30fps. I suspect that would be perfect for my purposes. However, I doubt I will be able to perform the analysis of the data in real-time. There will have to be some delay. That is just a side-effect of me having to look for the balls rather than having a system where the location of the balls are communicated to me.

See comments inline...

The angle will not be the only issue, but also the level of zoom (how much of the total viewer screen is the table taking up). If I don't, then ball coordinates couldn't be "universal". In other words, you and your neighbor both have the same setup, but he is zoomed a little closer to the table. Unless I compensate for that (which I plan to do since I will know the physical size of the table), our coordinates wouldn't match and we couldn't setup each others shots on our own tables.

I suppose analysis can be postponed. I'm wanting to be able to communicate how hard someone hit a shot (like the break shot for instance). Maybe I would communicate that the break shot was hit at 24mph or 18 feet/s. Who knows, but that sort of thing would make pool a bit more TV friendly.

Since the table is a known geometry, you don't need to know the angle or the level of zoom. That can be easily determined as long as you can see at least three corners or pockets that are not in a straight line. Actually, as long as you can see any three items whose position doesn't change and that are not in a strait line you can acurately determine the positions of any thing else in the field of view.

Marc Reinig System Solutions

I agree with Guy that any modification to the balls is probably an unacceptable implementation.

Video is probably the best choice. How do they track the cars on NASCAR races when they put the little markers on the video? It seems that the update rate is too fast for GPS, so it must be pure video processing (possibly coupled with konwledge of the camera azimuth and declination). That algorithm probably applies to this problem, too.

Kevin

Getting back to the billiard balls, one could adapt a tracking algorithm from a defense radar system that detect object in orbit, tracks them, and then employ that data to make predictions.

NORAD and others use these algorithms to distinguish and tag orbiting unknown objects, and then track them. The algorithms are a bit complex and would require considerable programming skill to duplicate, but lie well within the capabilities of modern desktop computers. Many of the algorithms themselves are now unclassified and in the public domain.

Harry C.

Thanks for the links Guy. I'll take a look at them and see what I can find.

One of the kids at my lab last summer implemented something very similar (he built an automated fooseball table with a 60 dollar webcam. He used the webcam to capture the table and then wrote a c-script to track the balls via color. His project was limited by the fps of the camera, but the computer processor accomodated for delay errors by the camera. I think for the sole purpose of tracking billiard balls this will work,

Ji Zhang