Measure your own break speed

[Runnin8]

i LOVE it brilliant idea. especally checking the quality. now just add cueball controle factor, and you probably have the 3 main things of the perfect speed to break at.

Thanks for the compliment, but I can't even begin to say this is it- it will take a community to make that call.

so best speed would be around 13mph? slowest speed to still get a high quality. everything between 13 and 20 gives equal averages, and 20+ is just SO hard to controle, its not worth it.

Given the data presented that is a fair conclusion- for my 8' Olhausen table in the pool room, with 3 year old Granito felt, etc... It'll vary by playing conditions. But the premise is valid across the board. What is missing however, as you then note, is balls pocketed. Much higher percentage at the upper end of the curve. But then again, I only have to make one to keep shooting.

ps did you keep any statistics on the amount of balls potted? (even if that is really in function of the breaker... much more then the speed, but still.. might give interesting results

Its in the data since we captured each lay of balls. In trying to make the experiment doable, all breaks were from the head string with center ball and any breaks resulting in the cueball initially outside of a "good hit" zone were discarded.

ps2 to bad we dont have those camera at home to record quality settings. if everyone contributes , you would have 10.000 records in no time and a very acurate average to draw conclussions from, or could we do it ourselves without the need of expensive equipment? (just take a picture with any digital camera and upload in on a program?)

use it during the 1000 9ball games guiness world records

I used a good quality logitec webcam on the ceiling, cost $79 I think.

One thing that would make it easier is to actually produce a specific piece of code that 1) does automated sound processing of the video file, 2) captures the final frame for video analysis of ball positions, and 3) has an auto calibrate function built in, and 4) performs the analysis. Essentially all the stuff we did manually. Its doable, all the pieces are there, its a matter of priorities.

 

[crappoolguy]

Drew, could you try this and post it on youtube?

 

[atthecat]

Can anyone tell me if I'm calculating this right? I'm not sure.
My distance is 51" minus 2.25 = 48.75

My speed is 00'00''164

So 48.75 divided by 164 = 29.8 MPH???

Is that how you do it?

Thanks for the help.

 

[HomeBrewer]

Fantastic thread. Any plans in the future to move it into a GIS (geographic information system)? I can't think of a better way to conduct the spatial analysis necessary for predicting spread behavior or pocketing likelihood by creating queries based on ball speed, direction, etc. You could run monte carlo simulations, determine statistical significance, everything!

 

[memikey]

Great thread, thanks.

Measuring the 'quality' of the break seems likely to me to be the biggest problem. For example one of the most important factors in determining the quality of the break has surely got to be the position in which the lowest unpotted ball ends up relative to the cue ball.

There's an argument that from the breaker's point of view an untidy break in which there are lots of clusters/balls on rails etc is in fact a far 'better' break than an open spread of balls when he has potted nothing on the break and when the 1 ball is in the open, similarly when he has potted something on the break and the lowest remaining ball isn't readily makeable......and so on.

Then there are questions like for example....are we statistically likely to hook ourselves on the break more often when we break at a speed which we have already determined tends to throw up more clusters or when we break at a speed which we have determined tends to throw up a wider spread?...and so on.

Such things and others can certainly have an effect on determinations of break quality.

Gets the brain cells ticking over though. :smile:

 

[mikeiniowa]

One thing that would make it easier is to actually produce a specific piece of code that 1) does automated sound processing of the video file, 2) captures the final frame for video analysis of ball positions, and 3) has an auto calibrate function built in, and 4) performs the analysis. Essentially all the stuff we did manually. Its doable, all the pieces are there, its a matter of priorities.[/QUOTE]

ok who has came up with the program to do this? hurry up I want one please:grin:

 

[Bob Callahan]

Wow!

Sure beats the old-school technique used by a bunch of guys mentioned here:

http://books.google.com/books?id=tA...esult&ct=result&resnum=1#v=onepage&q=&f=false

Great work!

 

[Jal]

Can anyone tell me if I'm calculating this right? I'm not sure.
My distance is 51" minus 2.25 = 48.75

My speed is 00'00''164

So 48.75 divided by 164 = 29.8 MPH???

Is that how you do it?

Assuming 00'00''164 is the measured time and equal to 0.164 second:

v = 48.75 inches/0.164 sec = 297.256 inches/sec

To convert this to feet/sec divide by 12 inches/foot.

v = [297.256 inches/sec]/[12 inches/foot] = 24.771 feet/sec.

To convert feet/sec to miles/hour divide by [5280 feet/mile]/[3600 sec/hour] = 1.466666 feet/sec/mph:

v = [24.771 feet/sec]/[1.466666 feet/sec/mph] = 16.89 mph

When you convert from one measure such as feet/sec to another, say, inches/sec, tedious though it may be, it helps to write them explicitly at each step of the conversion. They tell you whether you need to multiply or divide by a particular conversion factor during the current step. The same unit in both the numerator and denominator mutually cancel (=1) and you can then drop it for the next step. Example:

[10 feet/sec] x [12 inches/foot] = 120 in units of [feet/sec] x [inches/foot] = 120 inches/sec x feet/foot = 120 inches/sec

since feet/foot is another way of saying foot/foot = 1.

Hope that helps.

Jim