[RyanCahoon]

Originally Posted by Studentish

Yes, I apologize for being rather vague, so here is a basic explanation of the idea from beginning to end.

The camera produces an image.
Labview renders out undesired colors, leaving desired colors (green or pink).
Generate the image onto the graph.
Use the standard bell curve to generate the numbers for the math required (standard deviation, kurtosis, ect.), also visa-versa for the other color.
Determine if the colors line up enough in the Y values to be one target.
Determine weather the target is indeed the right target (alliance).
Calculate the distance (based on preset values).
Possibly AI intelligence to track ahead of the target based on movement.
Calibration of ball release mechanism for proper distances.

Sounds like the basic idea of tracking to me. Generating algorithm parameters based on empirical testing of your mechanism is the usual approach to programming mechanical systems. A normal curve may in fact be a good model for your shooter, but at some point you'll still have to set arbitrary limits on how far out of alignment you deem to be "close enough" to risk taking a shot; whether these are sensor readings, z-scores based on sensor readings, probabilities based on some complex model that you apply to sensor readings, it all comes down to the fact that you have an imperfect system, and you'll have to make some judgment about what level of risk you want to assume.

On a different note, the idea of tracking ahead of the target has always interested me. I'd be more inclined to polynomial approximations as Qbranch suggested rather than some sort of AI algorithm. In general, I don't think you could get enough data to accurately train such an algorithm, as you'd have to have a different set of data for each robot/driver, and humans are unpredictable enough that I don't think you'd have much luck. Even other humans aren't that good at predicting what we'll do. In my mind, using a second order approximation always seemed to be the best to me. Reasoning: the control point for our systems is essentially the amount of power we're applying to the motors, which is essentially proportional to the amount of acceleration the robot we'll be experiencing, which is a second order parameter of the system. If you're acceleration is changing, there's not much sense in guessing at it, as you're not sure what the program/driver is doing. This is definitely something I'd like to start playing around with in the offseason.

--Ryan