Quote:
|
Originally Posted by dlavery
Jon got it right. The problem with the simple "height, angle, distance" method is that it is a very basic analysis of the actual flight dynamics of the ball that does not account for several (legal) variables that can significantly affect the distance traveled. For example, the distance guideline given in the manual is based on the initital constraint of no spin on the ball when it exits the robot. During some experimentation, we found that putting a serious backspin on the ball - while keeping all other performance parameters the same, including the 12m/s exit speed - could increase the distance traveled by up to 30%. If FIRST were to rely on just the "height, angle, distance" analysis, they would incorrectly classify a shooter that put a lot of backspin on a ball, and thereby got increased range, as an illegal solution.
-dave
|
I agree that there are going to be difference due to spin. And I appreciate that FIRST is trying to do the right thing.
My thoughts are basically this. Safety is the main concern. There are 2 aspects to safety: If the balls are exiting too fast, someone could get hurt from a short range direct hit. If the balls go too far, unsuspecting folks will take a hit.
If we classify the exit speed by range, we only take care of the second but not the first.
Or have we?
I don't think there is anything magical about getting hit with a 12m/s Poof ball vs a 15m/s Poof ball (which is 25% higher than the "true" limit). I realize that it would have 56% more energy, but I don't think there is a bright line between what will hurt a human and what won't. Robots are dangerous things as are the machines we use to make them. I don't think even a 15m/s Poof ball is among the more significant risks associated with building and competing FIRST robots.
There is also something to be said for a limit that all teams can easily test for themselves.
I would urge FIRST to go with the angle, height, distance method, knowing that it is going to be wrong in some cases but that an obviously flawed standard that is easily implemented & understood is better than an improved standard that is less easy to implement & yet to be defined in Week 6 of the design/build cycle.
Joe J.