on the (in)accuracy of frame counting method for serve speed calculation

A disclaimer:

• 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......

Does your 420 FPS camera actually record exactly at 420?
Seems humidity, temperature, battery level, kind of battery all make a difference, just to add to the variables you listed.

You make a good point about the time to bounce varying based on the angle--I think that's going to result in kick serves being estimated as slower than flat serves with the same initial mph.

I'm not so sure that the fact that "fall due to gravity" is sometimes given as 4 feet means that the model is wrong-- seems like that's just saying how much of the ball's downward motion over the course of its flight to the bounce point can be attributed to gravity (as opposed to serving angle and topspin, which also contribute).

The calculator is saying that a ball hit horizontally would have fallen X distance due to gravity by the time it reached the airspace over the bounce point. Right?

Also, can you explain a little more why the assumption of a horizontal serve would result in an overly generous estimate of initial speed? Not casting doubt, I just am not following it.

jmnk said:

[*] 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.

Click to expand...

Not sure what you mean by it being known as it changes with temp and altitude, right?

If we know how much a ball slows from one side to the other in general, which seems plenty consistent for our purposes, how can it be that hard to figure a simple estimate based on distance/time? Every method we have will have some error, but this should be close enough for discussion and comparison between players, right?

Does your 420 FPS camera actually record exactly at 420?
Seems humidity, temperature, battery level, kind of battery all make a difference, just to add to the variables you listed.

Click to expand...

Modern Camera's will record at certain speeds - they do not vary the way you imagine. You might have dark photos or blurry photos but its taking picture at those intervals. A go pro can do some pretty high framerates nowadays too. So having a good formula for serves would be useful..

Jmnk, one problem with your very intricate post. The app is accurate. If you take a video of a serve from a pro match clocked on a radar gun, the app will give you the same speed as the radar gun within a couple mph.

jmnk,

The physicist in me wants to agree with you that a more realistic physics model would get us better results. But we don't really want to use a model that's going to require us to use matlab (or at least I don't).

If people are +or- a few mph as compared to radar results, that's good enough for me.

Topspin Shot said:

Jmnk, one problem with your very intricate post. The app is accurate. If you take a video of a serve from a pro match clocked on a radar gun, the app will give you the same speed as the radar gun within a couple mph.

Click to expand...

Agreed. How has nobody else mentioned this? Can someone explain why Nickzor was getting the exact same serve speeds as shown in pro matches with the frame counting method? He was getting them within like 1-2 mph too

It is accurate. There is proof out there. Alves if I remember right tried the frame count method with Drakulie's serve and got pretty much the same result as the radar.

Ballinbob said:

It is accurate. There is proof out there. Alves if I remember right tried the frame count method with Drakulie's serve and got pretty much the same result as the radar.

Click to expand...

I did, though I haven't tried it with any other radar-clocked serves. But it sounds like other people have done so with encouraging results.

I'd still be interested in hearing a little more about jmnk's objections, just to have a sense of what kinds of errors he thinks are actually occurring.

Avles said:

I'd still be interested in hearing a little more about jmnk's objections, just to have a sense of what kinds of errors he thinks are actually occurring.

Click to expand...

I'm sure there are plenty of tiny errors, but just expect they don't add up to much.

Could be. I think the biggest issues would be--

1. Figuring out distance from racquet to bounce.
2. Whether to add a fraction of a frame with 30 fps video
3. Spinny arcing serves vs. flat serves

But if jmnk thinks there's something in the model which is causing it to overstate serve speed I'd like to see an example or a more explicit explanation of how that would happen.

Just to clarify. I'm not affiliated with any iPhone/android app, nor with any radar manufacturer. Just so we get that out of the way.

Avles said:

You make a good point about the time to bounce varying based on the angle--I think that's going to result in kick serves being estimated as slower than flat serves with the same initial mph.

I'm not so sure that the fact that "fall due to gravity" is sometimes given as 4 feet means that the model is wrong-- seems like that's just saying how much of the ball's downward motion over the course of its flight to the bounce point can be attributed to gravity (as opposed to serving angle and topspin, which also contribute).

Click to expand...

Unfortunately yes, it does mean that the model is not accurate. The model assumes that the ball is hit completely horizontal. But if you assume that than you DO NOT NEED to measure any time till bounce from the video. Why? Because an object propelled forward, in horizontal direction, in the presence of the gravity, will reach the the earth at the exact same moment as the same object just free-falling (i.e. just simply dropped). So if you know the height of the contact point - and the model requires that you enter that, than you do not need to measure the time. You can easily calculate how much time a tennis ball free falling from a height H will take to reach the ground.

Avles said:

The calculator is saying that a ball hit horizontally would have fallen X distance due to gravity by the time it reached the airspace over the bounce point. Right?

Click to expand...

yes. What the calculator does is this:
1.assume horizontal hit with no spin.
2.use the formula to calculate the the initial speed
3.since the video gives us the time till bounce - it also calculates, using the very same formula, what was the height the ball was struck from.
4. that's where the discrepancy arises. Because the time from video is way less than it would have been for a free-falling ball. As such, the formula gives you 'distance due to gravity' which is way less than it actually was (for default numbers on the web site, the ball was struck from height about 8.5 feet, but the formula says the fall due to gravity is only 4.29feet.)[/QUOTE]

Avles said:

Also, can you explain a little more why the assumption of a horizontal serve would result in an overly generous estimate of initial speed? Not casting doubt, I just am not following it.

Click to expand...

this is not as easy to estimate. I'm comfortable saying that the model is not accurate, I'm less comfortable estimating what the error is. The thing to consider is that a minuscule change in any values entered: height, distance, time, angle of impact, spin, etc has tremendous effect on the calculated result. In other words, given the same time to bounce, and the distance to bounce, I can modify angle and spin of the serve such, that the initial speed will vary greatly (and obviously the serve is still good, in and over the net). It is just a very complex physics model.

5263 said:

Not sure what you mean by it being known as it changes with temp and altitude, right?

If we know how much a ball slows from one side to the other in general, which seems plenty consistent for our purposes, how can it be that hard to figure a simple estimate based on distance/time? Every method we have will have some error, but this should be close enough for discussion and comparison between players, right?

Click to expand...

Not exactly. air drag coefficient is a function of the nature of the ball surface (fuzz), the ball spin, and the ball speed. It is actually surprisingly constant within tennis serve parameters (60-140mph, ~2000-5000rpm). The force caused by air drag does indeed than also depends on temp and altitude, the formula uses sane values for those. Maverick used a very clever trick to figure out what this coefficient is - but unfortunately since his formula is not that accurate, the coefficient is not accurate either. And using the wrong coefficient again cause the serve speed results not to be correct.

Topspin Shot said:

Jmnk, one problem with your very intricate post. The app is accurate. If you take a video of a serve from a pro match clocked on a radar gun, the app will give you the same speed as the radar gun within a couple mph.

Click to expand...

ok, if you think so, fine with me. It is possible that for SOME serves the numbers happen to be correct. But it is a coincidence.

WildVolley said:

jmnk,

The physicist in me wants to agree with you that a more realistic physics model would get us better results. But we don't really want to use a model that's going to require us to use matlab (or at least I don't).

If people are +or- a few mph as compared to radar results, that's good enough for me.

Click to expand...

I kind of agree. that's why I did not want to mention that issue at all. But it just started to bother me that there are non-free apps that use that formula and claim it is accurate. It's just not.

Ballinbob said:

Agreed. How has nobody else mentioned this? Can someone explain why Nickzor was getting the exact same serve speeds as shown in pro matches with the frame counting method? He was getting them within like 1-2 mph too

It is accurate. There is proof out there. Alves if I remember right tried the frame count method with Drakulie's serve and got pretty much the same result as the radar.

Click to expand...

the only proof you need is to go over the physics model that Maverick posted on his site. It is clear (and to Maverick's credit he does not hide it) that the formula assumes no spin, horizontal only serve. You just can't use that for any other serve. i mean you can - but what you get as a result is a wrong number (although i agree that in some cases, by coincidence, it may appear to be accurate)

5263 said:

I'm sure there are plenty of tiny errors, but just expect they don't add up to much.

Click to expand...

I suppose it depends on what 'much' is. for 30fps video, just changing the number of frames till bounce by 1 frame makes about 6mph difference. changing the distance by 1 foot makes about 2mph difference. these do add up.

By anyway, my issue is not with how accurately you can measure the time and distance. I'm trying to point out that even if you measure those very accurately, the formula does not provide an accurate result.

jmnk said:

Unfortunately yes, it does mean that the model is not accurate. The model assumes that the ball is hit completely horizontal.

Click to expand...

I don't see how the model assumes that. The page suggests that you add some extra distance for the vertical component of the ball's motion. Where does it say or imply that the ball is hit completely horizontal?

But if you assume that than you DO NOT NEED to measure any time till bounce from the video. Why? Because an object propelled forward, in horizontal direction, in the presence of the gravity, will reach the the earth at the exact same moment as the same object just free-falling (i.e. just simply dropped). So if you know the height of the contact point - and the model requires that you enter that, than you do not need to measure the time.

Click to expand...

This makes no sense to me. The calculator does not ask you to "enter the height of the contact point" although it does say to add a little distance to account for vertical motion.

And you do need to measure the time, because the time it takes for the ball to reach the ground depends on how fast the serve is going, as well as on gravity. This is because the serve is not perfectly horizontal. The serve is hit downwards. So serve speed (along with spin) will affect the amount of time it takes to reach the ground.

yes. What the calculator does is this:

1.assume horizontal hit with no spin.
2.use the formula to calculate the the initial speed
3.since the video gives us the time till bounce - it also calculates, using the very same formula, what was the height the ball was struck from.
4. that's where the discrepancy arises. Because the time from video is way less than it would have been for a free-falling ball. As such, the formula gives you 'distance due to gravity' which is way less than it actually was (for default numbers on the web site, the ball was struck from height about 8.5 feet, but the formula says the fall due to gravity is only 4.29feet.)

Click to expand...

Ok...you seem to be saying that the number the calculator gives for "fall due to gravity" is supposed to tell us the height at which the model thinks the ball was struck. I think you're wrong here.

What "fall due to gravity" means here is that in .52 seconds a tennis ball in free fall will fall 4.29 feet. This does not imply or assume that the serve being measured was struck from a height of 4.29 feet, because (as I said above) gravity is not the only influence on the time it takes for a serve to reach the ground. Serve trajectory (and hence serve speed) will also play a role.

Again, I do not see how the model is assuming that the serve is hit perfectly horizontally. It does seem to assume that the serve travels in a straight line, rather than an arc. But that doesn't mean it's assuming a horizontal serve.

this is not as easy to estimate. I'm comfortable saying that the model is not accurate, I'm less comfortable estimating what the error is.

Click to expand...

You can't provide a plausible example of how the flaws you claim in the model are affecting its results?

Avles said:

I don't see how the model assumes that. The page suggests that you add some extra distance for the vertical component of the ball's motion. Where does it say or imply that the ball is hit completely horizontal?

This makes no sense to me. The calculator does not ask you to "enter the height of the contact point" although it does say to add a little distance to account for vertical motion.

Click to expand...

That is the crux of the issue. Compare the equation used to derive the formula (here: http://donthireddy.us/tennis/speed.html, under 'The full derivation' section) with the description and discussion here: http://www.physics.usyd.edu.au/~cross/TRAJECTORIES/42.%20Ball%20Trajectories.pdf, formula 42.a4 on that page. It's not for the faint of heart (math wise) but it is clear that Maverick's formula assumes a horizontal serve.

The fact that the web page suggests you should some distance due to vertical component is just another error in the model. In fact, in this formula, the ONLY distance you should be adding in in pure horizontal direction.

Avles said:

And you do need to measure the time, because the time it takes for the ball to reach the ground depends on how fast the serve is going, as well as on gravity. This is because the serve is not perfectly horizontal. The serve is hit downwards. So serve speed (along with spin) will affect the amount of time it takes to reach the ground.

Click to expand...

well, yes indeed. But the model does assume it is a pure horizontal serve with no spin. Therefore it will give a proper result for only such serves. As you are pointing out, almost no serve is hit without the spin, or without being hit slightly downwards. Which is exactly why the model is not applicable to a majority of serves.

Avles said:

Ok...you seem to be saying that the number the calculator gives for "fall due to gravity" is supposed to tell us the height at which the model thinks the ball was struck. I think you're wrong here.

What "fall due to gravity" means here is that in .52 seconds a tennis ball in free fall will fall 4.29 feet. This does not imply or assume that the serve being measured was struck from a height of 4.29 feet, because (as I said above) gravity is not the only influence on the time it takes for a serve to reach the ground. Serve trajectory (and hence serve speed) will also play a role. Again, I do not see how the model is assuming that the serve is hit perfectly horizontally. It does seem to assume that the serve travels in a straight line, rather than an arc. But that doesn't mean it's assuming a horizontal serve.

Click to expand...

I like your thinking. You are getting it. See, 'the fall due to gravity' number comes from the fact that this is the ONLY height the ball would need to be struck from, in pure horizontal direction, for the ball to hit the ground after time T. Since that is obviously NOT the height the serve was struck from, it means indeed that the serve was not horizontal. But the formula, in order to calculate the initial speed, ASSUMES that the serve WAS horizontal. Thus the contradiction. I mean you do need to understand the formula used, and convince yourself/prove to yourself that the formula is only valid for an object struck in horizontal direction only. Once you see that you understand the contradiction.
The more generic formula, that takes into account angle of the hit and the spin, is a set of three second order differential equations that cannot be solved analytically. but MATHEMATICA/MATLAB/etc can solve it numerically fairly easily (well, once you set up the equations, which is not trivial).

Avles said:

You can't provide a plausible example of how the flaws you claim in the model are affecting its results?

Click to expand...

since you insist. The default numbers on the page result in a serve about 93.3mph. Taking into account a downward angle of the serve, and relatively modest spin, I can 'create' a serve that is only 85mph, but will hit the exact spot (distance traveled 60feet) after exactly the same time (~0.52s). All due to taking into account the spin, and the angle.

But I really like your thinking.

The derivation shows projectile motion with drag in one dimension. The 4.29 ft of fall due to gravity is the amount the ball would have fallen in 0.52 seconds if it had been struck horizontally.

The assumption of a horizontally struck ball underestimates the true serve speed as it does not consider the vertical component of the serve.

To estimate the error, we have to consider the angle at which the serve was struck. Consider the angle the racquet makes with the vertical to be theta. Let V be the initial velocity imparted on the ball, then the velocity of the vertical component would be Vsin(theta). This theta varies depending on the height of the player. A taller player with be hitting down the ball more and thus resulting in a larger theta. As an example let's assume theta = 15 degrees. Let W be velocity ignoring the vertical component, then W=Vcos(theta)=0.96V.

As we can see, based on the strike angle, the error from the horizontal assumption can be quite small. It would interesting to see the error for the taller serving pros.

jmnk said:

I kind of agree. that's why I did not want to mention that issue at all. But it just started to bother me that there are non-free apps that use that formula and claim it is accurate. It's just not.

Click to expand...

Looking at your critique in more detail, it is very good.

Have you ever tested your matlab model against radar?

Just thinking off the top of my head, are there any easy corrections that could be made like nootles is attempting above to correct for the time in flight due to being hit down toward the court?

I can see that topspin serves are going to be very hard to correct without estimating spin rates.

After reviewing Maverick's web page, I think both jmnk and I were wrong about the assumptions made for the calculations. The standard practice for projectile motion is to separate the vertical and horizontal dimensions. However, in Maverick's calculation, he assumes the trajectory to be one dimensional. It is assumed that after the ball leaves the racquet, the ball travels in a straight path. This is supported by the way he details an estimate of the distance:

"Estimate of the distance traveled in the air by your serve. The distance from the middle of the baseline to the cross of the service T is 60 feet; the distance from the middle of the baseline to the wide coners of the service box is 61.5 ft. The fact that the serve is hit from a height of 8 or 9 feet increases the distance by 0.5 ft. But typically serves are struck a little inside the baseline, so you have to reduce by that distance. If your serve lands about a foot inside the service line, you have to estimate and subtract that distance as well."

As you can see, he is describing how to estimate the distance the ball traveled in a straight path in the air. The added 0.5 ft due to hitting it higher off the ground is his estimate to increase the flight path due to height.

With this assumption, the formula actually over estimates your serve speed. The force of gravity, while small compared to drag, still affects the ball. The real trajectory of the ball is not a straight line but a downward curve. If we look at the default calculation shown, the ball traveled 4.29 ft in the vertical direction that cannot be attributed to any factors in the model.

Estimation of the error is hard in this case. Because the actual path is a curve, the component of gravity in the direction of the ball is constantly changing. But amount of fall due to gravity can be seen as a gauge for the error. The smaller the fall due to gravity is, the more accurate the serve speed.

Maverick decided to neglect gravity because it is a vertical force and thus "doesn't significantly affect the calculation." While it does not significantly affect the calculation, this is actually due to the fact that gravity is a very weak force compared to drag at high velocities. If you softly push a serve, you can clearly see the curved trajectory, and thus the effects of gravity.

Aside from errors in the model, I feel we should also address the errors coming from the measurements. The parameters are: frame rate of camera, distance, number of frames, and drag coefficient.

The frame rate of the camera should be fairly accurate, so we can assume no error here.

The number of frames can only be off by + or - 0.5. If the ball lands in between frames 15 or 16, simply choose 15.5. The velocity is inversely proportional to the number of frames. At lower number of frames, the error is greater. The speed calculated using 10 frames will be 1.05 times greater than the speed calculated using 10.5 frames. However, speed calculated at 15.5 frames will be about 1.032 times greater than the speed calculated using 16 frames. For better accuracy, a high frame rate camera is highly desired. At 120 frames, the speed is only about 1.004 times higher than 120.5 frames.

I include drag as an source of error because not all environments are the same. I'm not sure as to the error in the measurement of drag. The drag used in the calculation is estimated using a know serve of Sampras, however this only gives the drag in the conditions the serve was hit in. With the amount of studies available, I think we can find a fairly accurate drag coefficient applicable to the most of us.

Lastly, the distance traveled. It is important to use the correct distance in the calculation. Because of the exponential term the formula will be quiet sensitive to the distance. If we look at the default calculations on the site, a change of 3 inches, will result in a difference of almost 0.5 mph.

nootles said:

Lastly, the distance traveled. It is important to use the correct distance in the calculation. Because of the exponential term the formula will be quiet sensitive to the distance. If we look at the default calculations on the site, a change of 3 inches, will result in a difference of almost 0.5 mph.

Click to expand...

Thanks for your analysis. If the model just uses a linear path, is the least error calculated by estimating a linear path from racket contact to court? I realize ignoring spin, that the ball will tend to trace a parabolic curve due to gravity.

WildVolley said:

Thanks for your analysis. If the model just uses a linear path, is the least error calculated by estimating a linear path from racket contact to court? I realize ignoring spin, that the ball will tend to trace a parabolic curve due to gravity.

Click to expand...

The model assumes a linear path, there will be inherent error with that assumption. Working within the model, you should be using a linear path from racquet contact to court.

nootles said:

After reviewing Maverick's web page, I think both jmnk and I were wrong about the assumptions made for the calculations. The standard practice for projectile motion is to separate the vertical and horizontal dimensions. However, in Maverick's calculation, he assumes the trajectory to be one dimensional. It is assumed that after the ball leaves the racquet, the ball travels in a straight path.

Click to expand...

hmm, not sure why you are saying I was wrong about Maverick's assumptions. Yes, in physics you do break down vectors (like speed) into tri-dimension components. In some case you can get away with two dimensional components; horizontal an vertical.
Maverick model assumes that the serve is struck horizontally. And it also neglect vertical component that the ball, struck horizontally, would acquire due to gravity. But indeed that component due to gravity is not going to be that great. However neglecting vertical component due to the serve being struck downward is a bigger error. That is the biggest source of inaccuracy.

nootles said:

I include drag as an source of error because not all environments are the same. I'm not sure as to the error in the measurement of drag. The drag used in the calculation is estimated using a know serve of Sampras, however this only gives the drag in the conditions the serve was hit in. With the amount of studies available, I think we can find a fairly accurate drag coefficient applicable to the most of us.

Click to expand...

the problem with calculated drag coefficient stems from the fact that it was calculated using the wrong formula for the Sampras serve. The calculation would be correct only in the Sampras' serve was horizontal - but it is not. The error is actually quite significant.

nootles said:

Lastly, the distance traveled. It is important to use the correct distance in the calculation. Because of the exponential term the formula will be quiet sensitive to the distance. If we look at the default calculations on the site, a change of 3 inches, will result in a difference of almost 0.5 mph.

Click to expand...

Very true. but as I've noted in the first post, the measurements error are just that, they cannot be avoided, they can be minimized - but that is not really why I'm saying that the formula is not accurate.

WildVolley said:

Looking at your critique in more detail, it is very good.

Have you ever tested your matlab model against radar?

Just thinking off the top of my head, are there any easy corrections that could be made like nootles is attempting above to correct for the time in flight due to being hit down toward the court?

I can see that topspin serves are going to be very hard to correct without estimating spin rates.

Click to expand...

thanks for kind words. I do not have a radar. i do have some slow speed recordings from a tennis tournament where the serve speeds were displayed. It just very tedious to go over those and check against the model. I may do it at some pint, but I have not done it so far.

jmnk said:

hmm, not sure why you are saying I was wrong about Maverick's assumptions. Yes, in physics you do break down vectors (like speed) into tri-dimension components. In some case you can get away with two dimensional components; horizontal an vertical.
Maverick model assumes that the serve is struck horizontally. And it also neglect vertical component that the ball, struck horizontally, would acquire due to gravity. But indeed that component due to gravity is not going to be that great. However neglecting vertical component due to the serve being struck downward is a bigger error. That is the biggest source of inaccuracy.


the problem with calculated drag coefficient stems from the fact that it was calculated using the wrong formula for the Sampras serve. The calculation would be correct only in the Sampras' serve was horizontal - but it is not. The error is actually quite significant.

Click to expand...

Maverick does not assume the ball was struck horizontally. He assumes the ball to be struck at an angle but then travels in a straight line. A flat serve without spin is essentially two dimensional. Since the effects of gravity is small, he choose to ignore it and treat the trajectory as a one dimensional line from contact with the racquet to the landing point. The standard approach to projectile motion is to indeed break down the forces into horizontal and vertical components. In that particular approach, the initial velocity vector V=(V_x, V_y) will have a horizontal and vertical component. However, there are infinitely many orthonormal basis for Euclidean Space. Rather than using the standard basis of (1,0);(0,1) for R^2, we can use (V_x,V_y)/|V|;(-V_y,V_x)/|V| as a new basis. If we apply the change of basis, the vector V will be (|V|,0) in terms of the new basis. Since speed is rotationally invariant, this transformation allows us to simplify the problem to just one dimensions.

The drag coefficient calculated using Sampras' serve was done under these same conditions.

At the very least, if someone uses the frame counting method directly from the web site, he should enter ONLY horizontal distance under "Distance traveled in air".
In other words, if you are assuming that you are hitting the serve from inside 1foot of the baseline, and it hit the court 1 foot before the service line, than you should enter 58 under 'Distance traveled in air'. This is because the formula really calculates horizontal speed component only, so any distance in non-horizontal direction should not be taken into consideration. As counter intuitive as it may seem, the height the ball was struck from is irrelevant when using this formula.

Similarly, when using iphone's servespeedapp, you should enter 0 under 'select player's height'. This should prevent the app from considering non-horizontal distance the ball has traveled. (Although I do not own this app, so I do not really know what will happen when you select 0 at this step. Or if the app even has option to select 0).

nootles said:

Maverick does not assume the ball was struck horizontally. He assumes the ball to be struck at an angle but then travels in a straight line. A flat serve without spin is essentially two dimensional. Since the effects of gravity is small, he choose to ignore it and treat the trajectory as a one dimensional line from contact with the racquet to the landing point. The standard approach to projectile motion is to indeed break down the forces into horizontal and vertical components. In that particular approach, the initial velocity vector V=(V_x, V_y) will have a horizontal and vertical component. However, there are infinitely many orthonormal basis for Euclidean Space. Rather than using the standard basis of (1,0);(0,1) for R^2, we can use (V_x,V_y)/|V|;(-V_y,V_x)/|V| as a new basis. If we apply the change of basis, the vector V will be (|V|,0) in terms of the new basis. Since speed is rotationally invariant, this transformation allows us to simplify the problem to just one dimensions.

The drag coefficient calculated using Sampras' serve was done under these same conditions.

Click to expand...

well, that's great that you think so. I'm not going to argue with you on this point as I'm confident that the formula he has used is only valid if the ball is struck horizontally. Compare the equation used to derive the formula (here: http://donthireddy.us/tennis/speed.html, under 'The full derivation' section) with the description and discussion here: http://www.physics.usyd.edu.au/~cros...ajectories.pdf, formula 42.a4 on that page.
Neglecting gravity is one thing. Assuming horizontal serve is another. These are sort of independent assumptions. the formula does both, and both lead to errors.

(@nootles - since I doubt anybody else understands your point, so between two of us. I get your point about changing the frame of reference such that any serve can be considered horizontal (i.e. parallel to the X-axis.). But if you do that than you need to recalculate the distance from the point of the serve to the bounce point in that new frame of reference. The more the serve is hit downward, the less that distance is going to be in the new frame of reference. the model does not do that. I suppose it could be done, although I doubt you are going to end up with anything simpler. BTW - the best paper on the ball trajectory topic I have found is this: http://goff-j.web.lynchburg.edu/Goff_Carre_AJP_2009.pdf. It is on soccer ball, and it has few errors as well, but it is a very solid theoretical discussion of tri-dimensional trajectory.)

You can easily try an experiment. Drop the tennis ball from 9 feet, just a free fall. Enter the distance traveled in air into equation, and enter the time it took for the ball to reach the ground. If the formula was correct you should get 0 as the initial speed. Because at free fall the initial speed in any direction is 0.

jmnk said:

well, that's great that you think so. I'm not going to argue with you on this point as I'm confident that the formula he has used is only valid if the ball is struck horizontally. Compare the equation used to derive the formula (here: http://donthireddy.us/tennis/speed.html, under 'The full derivation' section) with the description and discussion here: http://www.physics.usyd.edu.au/~cros...ajectories.pdf, formula 42.a4 on that page.
Neglecting gravity is one thing. Assuming horizontal serve is another. These are sort of independent assumptions. the formula does both, and both lead to errors.

You can easily try an experiment. Drop the tennis ball from 9 feet, just a free fall. Enter the distance traveled in air into equation, and enter the time it took for the ball to reach the ground. If the formula was correct you should get 0 as the initial speed. Because at free fall the initial speed in any direction is 0.

Click to expand...

I understand that the formula on Maverick's site is exactly the same as the formula for the horizontal component of a projectile. But just because two equations are exactly the same, does not mean that have the same interpretation. Suppose to drop a block in a infinitely long vacuum, the equation of motion y(t)=-1/2 gt^2, where g is the gravitational constant. Now suppose you take the same block and accelerated it by g constantly in the horizontal direction on a friction-less surface. The equation of motion will be x(t)=1/2 gt^2. The two equations differ by "-" simply due to the fact that falling is considered to be negative in the y direction. If we were to look at these in two dimensions, the position vector for free fall would be (0, -1/2 gt^2) and the position vector for the slide would be (1/2 gt^2,0). These are simply 90 degree rotations of each other. Since the trajectories of these two systems are essentially one dimensional, we can just use the one dimensional equation of 1/2 gt^2 to describe both systems.

The same principle can be applied to Maverick's model. By assuming a one dimensional path from the contact to the landing, the two dimensional problem can be reduced to a one dimensional problem by a rotation of the coordinate axis.

In your example of free fall, the error is from neglecting the effects of gravity. Since the model ignores gravity, it rectifies the fact that the particle moved by giving it initial velocity. This is a fundamental error in assumptions that the model is based on, rather than the model itself.

nootles said:

I understand that the formula on Maverick's site is exactly the same as the formula for the horizontal component of a projectile. But just because two equations are exactly the same, does not mean that have the same interpretation. Suppose to drop a block in a infinitely long vacuum, the equation of motion y(t)=-1/2 gt^2, where g is the gravitational constant. Now suppose you take the same block and accelerated it by g constantly in the horizontal direction on a friction-less surface. The equation of motion will be x(t)=1/2 gt^2. The two equations differ by "-" simply due to the fact that falling is considered to be negative in the y direction. If we were to look at these in two dimensions, the position vector for free fall would be (0, -1/2 gt^2) and the position vector for the slide would be (1/2 gt^2,0). These are simply 90 degree rotations of each other. Since the trajectories of these two systems are essentially one dimensional, we can just use the one dimensional equation of 1/2 gt^2 to describe both systems.

The same principle can be applied to Maverick's model. By assuming a one dimensional path from the contact to the landing, the two dimensional problem can be reduced to a one dimensional problem by a rotation of the coordinate axis.

In your example of free fall, the error is from neglecting the effects of gravity. Since the model ignores gravity, it rectifies the fact that the particle moved by giving it initial velocity. This is a fundamental error in assumptions that the model is based on, rather than the model itself.

Click to expand...

Yes, I get that. Please re-read the rest of my previous post:
"
@nootles - since I doubt anybody else understands your point, so between two of us. I get your point about changing the frame of reference such that any serve can be considered horizontal (i.e. parallel to the X-axis.). But if you do that than you need to recalculate the distance from the point of the serve to the bounce point in that new frame of reference. The more the serve is hit downward, the less that distance is going to be in the new frame of reference. the model does not do that. I suppose it could be done, although I doubt you are going to end up with anything simpler.
"

jmnk said:

Yes, I get that. Please re-read the rest of my previous post:
"
@nootles - since I doubt anybody else understands your point, so between two of us. I get your point about changing the frame of reference such that any serve can be considered horizontal (i.e. parallel to the X-axis.). But if you do that than you need to recalculate the distance from the point of the serve to the bounce point in that new frame of reference. The more the serve is hit downward, the less that distance is going to be in the new frame of reference. the model does not do that. I suppose it could be done, although I doubt you are going to end up with anything simpler.
"

Click to expand...

His formula does include the distance from contact to landing. If you read number 2 on the top of the page. One part specifically says "[t]he fact that the serve is hit from a height of 8 or 9 feet increases the distance by 0.5 ft."
Suppose you are standing at the center mark and serves down the tee and lands right at the corner. Suppose to make contact directly above the center mark 8 ft off the ground. The horizontal distance from center to tee is 60 ft. By the Pythagorean Theorem, the distance between the two points is sqrt(60^2+8^2), this is approximately 60.53ft. So Maverick indeed does tell you to calculate the distance of the flight path and not just the horizontal distance traveled.

nootles said:

His formula does include the distance from contact to landing. If you read number 2 on the top of the page. One part specifically says "[t]he fact that the serve is hit from a height of 8 or 9 feet increases the distance by 0.5 ft."
Suppose you are standing at the center mark and serves down the tee and lands right at the corner. Suppose to make contact directly above the center mark 8 ft off the ground. The horizontal distance from center to tee is 60 ft. By the Pythagorean Theorem, the distance between the two points is sqrt(60^2+8^2), this is approximately 60.53ft. So Maverick indeed does tell you to calculate the distance of the flight path and not just the horizontal distance traveled.

Click to expand...

I quickly set up a calculator to do this in excel. In the key, you need to enter estimates on the contact point and estimates on the impact point and it uses the Pythagorean theorem to calculate a straight line distance from contact to impact.

On the other thread, there were many estimates using the calculator, but it wasn't at all clear what distances were being estimated and entered. I believe with one video I calculated it 5 mph slower than someone else (based on the given frame count), most likely because I estimated a reduce distance.

WildVolley said:

I quickly set up a calculator to do this in excel. In the key, you need to enter estimates on the contact point and estimates on the impact point and it uses the Pythagorean theorem to calculate a straight line distance from contact to impact.

On the other thread, there were many estimates using the calculator, but it wasn't at all clear what distances were being estimated and entered. I believe with one video I calculated it 5 mph slower than someone else (based on the given frame count), most likely because I estimated a reduce distance.

Click to expand...

Getting the proper distance is really important. Because of the exponential term, the error will be magnified. I think doing the calculation based on just video recordings can lead to large errors. Give most recordings are from a single angle, it will be really hard to judge proper point of contact and proper landing. It can be useful if you have two people keeping track of where the ball was hit and where it landed and have the distance measure immediately.