In my previous post, I wrote down a handy way of looking at what happens to the representation of a pitch from the time it leaves a pitchers hand (the things he controls) to the time that representation is given to us by PITCHf/x. In a nutshell, that works out to be: aerodynamic forces and gravity act on it, and PITCHf/x records the locations of the ball in flight at various times, fits a curve to a constant acceleration model, and spits out 8 values (9 really, but y0 gets set to a fixed point). Somewhere in that process, the PITCHf/x system, likely owing to miscalibration issues, performs some unknown to us transform on those pitch parameters before giving us a result.
The transform performed by PITCHf/x can be arbitrarily complex. In this space however I am going to limit the discussion to that of linear transformations on the pitch parameters (in homogenous coordinates so we can do things like translations with a linear operator). This removes from current considerations issues like lens distortion, which I trust Sportvision to have a good handle on. Further simplifying, let's treat the PITCHf/x system as imposing a coordinate system on the real world. This is not exactly what happens, but I believe it to be a close approximation. If we can make this assumption, then we should be able to assume that if we can find a transformation that corrects only the positions, then the same transformation should apply to the velocities, and also to the accelerations (without the translations). Almost at least. We do still have to worry about the effects of air density on those transformations.
But what about deriving such transformations? For the moment, let's ignore the effect of air density, and we'll try to add that effect back in later. If we can do that (or say that our two parks sit at the same elevation and share the same temperature), then deriving a transformation that maps system 1 to system 2 is as simple as writing it down, provided we have a sufficient number of common, non-colinear vectors measured in each system. And that's where it gets tricky. Because in all likelihood we don't have any common vectors between system 1 and system 2. But we might be able to say we have vectors that are close enough to consider common. For instance, we might be able to consider the average initial velocity vector of a given pitchers fastball to righthanders (or lefthanders) as a common vector, provided first that we believe the y0 values of 'release point' map to the same real-world y value. They probably don't. In fact, for the types of transformations I believe are likely, there is no reason to believe that they are. So our best bet for "common" vectors between the two systems are probably going to be the acceleration vectors of pitches, as these are constant* for the duration of the time the ball is in flight. And this is why it's important to note that air density plays a role. However, ignoring air density for the moment, if we have some pitch classification we can believe, we could probably do something like treating the acceleration vector for the average, say 4 seam fastball by pitcher A in system 1 as mapping to the average acceleration vector for his 4 seam fastball in system 2. If we have enough of these kinds of mappings (3 minimum, if we are only working in 3 dimensions and not considering static shifts, 4 if we want to add static shifts, and 5 for full projective transforms) we can solve for a linear transform that maps system 1 to system 2 and vice-versa through the inverse. Preferably we have more than the minimum number of common vectors, in which case the problem is over-determined, and we should employ a least squares solution.
So this is the path I plan on exploring. Expanding this to handle 30 parks rather than 2 could get interesting. But I'm currently about halfway done with the code for comparing just two parks in this manner, and if the results prove fruitful, I'll post about them and get to work on expanding to 30 parks.
Anyway, that's it for now. I'll either have some pretty or awful plots to show next time. We'll see how this goes. Feel free to drop a suggestion in the comments.
*No, they are not really constant, but in both systems, PITCHf/x is fitting the trajectory to one of constant acceleration.
No comments:
Post a Comment