A disclaimer:
I have considered for a long time whether to raise any flag since we all like to use that method to have fun with estimating the serve speed. But these days I see iphone/android/pc apps using that very formula, claiming accuracy. Even charging money for those apps without giving proper credit or even mention to maverick1. Or people now challenging others to bets, claiming that the results given by that formula shows they serve 100mph+.
I have a camera recording with 420fps and used my own serve to do the calculations. And that's where the doubts came. Simply stating my servers came up to be too fast. As in, while I have a decent game there's no way I can serve as fast as the calculator shows. So I started digging deeper. I think there are few issues with the calculator (but again, by no means I'm dissing it).
The calculation starts with the assumption that the only force acting on the ball is the horizontal force of the air drag. that is a pretty good assumption. But it also implies that:
Given that it seems that the model needs to be a bit more complicated. One that takes into account the fact that the serve is not hit perfectly horizontal - that way it will make sense that the time to bounce will vary between serves. Unfortunately such model will require solving a pair (or a triple if you want to make it really generic and consider side spin too) of differential equations. Now, these days we have mathematica or matlab and given the right model and initial conditions it will solve it for us without much difficulties.
(I have actually created such mathematica model if one is interested. )
Anyway, the point is, use it with a grain of salt. If the numbers look too good - they probably are......
- this is not to diss the fine work done by maverick1 poster (http://tt.tennis-warehouse.com/showthread.php?t=99228 ) who provided the very elegant formula for calculating initial serve speed based on counting the frames in tennis serve recording. He's done excellent job.
- this is also not about errors due to estimation of how many frames and distance.
- this is about an error in the physics model used to solve the problem. the model is unfortunately too simplistic to be applied to an arbitrary serve (or any other tennis stroke).
I have considered for a long time whether to raise any flag since we all like to use that method to have fun with estimating the serve speed. But these days I see iphone/android/pc apps using that very formula, claiming accuracy. Even charging money for those apps without giving proper credit or even mention to maverick1. Or people now challenging others to bets, claiming that the results given by that formula shows they serve 100mph+.
I have a camera recording with 420fps and used my own serve to do the calculations. And that's where the doubts came. Simply stating my servers came up to be too fast. As in, while I have a decent game there's no way I can serve as fast as the calculator shows. So I started digging deeper. I think there are few issues with the calculator (but again, by no means I'm dissing it).
The calculation starts with the assumption that the only force acting on the ball is the horizontal force of the air drag. that is a pretty good assumption. But it also implies that:
- - the ball was hit perfectly flat, no spin at all. Otherwise there would be a Magnus force effect. that is not a big deal, recreational serve does not have much spin anyway.
- - the ball is hit perfectly in horizontal direction (i.e. neither up or down). That is not a bad assumption either, kind of. Except that if we assume that than we already know how much time it will take the ball to hit the ground given we know how high the initial contact was - because that time is simply as much as it takes a ball to do free fall from such height.
- This is what causes the most error in calculations. For example, if you just hit 'calculate' button on the web site with the formula (meaning accepting reasonable numbers that are there by default) you will get serve speed of 93.3mph (ok, reasonable), and the 'fall due to gravity' of 4.29feet. Obviously that is not practically possible, nobody serves from 4.29 feet height. Since the time to bounce varies between serves than, assuming the same player and therefore the same initial contact point, and the same bounce point, the only variable that can cause the time to vary is the angle of the serve. Which means we cannot really assume a perfectly horizontal serve. I've seen folks trying to estimate a forehand stroke speed - your 'fall to gravity' value that the formula will give you is even more out of whack.
- the air drag coefficient used in that formula is not exactly correct. maverick1 essentially used the reverse of the formula, where he knew the parameters of the serve (initial speed as seen on TV recording, assumed height and distance of contact) to calculate what the air drag coefficient must be for the formula to check out. But due to not taking into consideration the issues listed above the coefficient is not correct. These days you can find many papers on tennis ball drag coefficient, so that value is known.
- - finally, if we do assume that the only force is drag force, and it is acting in horizontal direction, than the only distance we are interested in is the horizontal direction. So we do not really care how high up the serve was hit, we do not want to use 'the hypotenuse of the ball path' - just the distance in the horizontal direction
Given that it seems that the model needs to be a bit more complicated. One that takes into account the fact that the serve is not hit perfectly horizontal - that way it will make sense that the time to bounce will vary between serves. Unfortunately such model will require solving a pair (or a triple if you want to make it really generic and consider side spin too) of differential equations. Now, these days we have mathematica or matlab and given the right model and initial conditions it will solve it for us without much difficulties.
(I have actually created such mathematica model if one is interested. )
Anyway, the point is, use it with a grain of salt. If the numbers look too good - they probably are......