On the field, is there any way to identify the goals via sensor input or is it all going to be calibration and rough line-following? There’s got to be something…
I’ve thought about using an ultrasonic sensor to determine distance from the goal, but there’s no way that I know of to point the robot at a goal and have it know whether that goal is red or blue.
A few things come to mind.
If you need to get close rather than your starting tile, the diagonal lines do not extent the entire length so you have to start in your tile and race to the other end (crashing into the other robot doing the same thing). Not sure how good of a shooter we can make without game elements to test with. 
Next, not sure how the ultrasonics will react to the curved surface of the pipe. Do you need the ultrasonic at a specific height to get good bounce back? Otherwise the waves go into the floor or up to the ceiling?
Looks like some tests will be needed before committing to a design.
Possible designs:
-
Stay in the loading zone and shoot - optimal but long distance probably very hard
-
Run up and shoot, then run back home for more - most likely we will see this from a lot of teams.
-
Scoopers with a dump high enough to clear the pipe
-
Pushers ramming balls under the bar
-
defense bots to disrupt designs of #2-4 folks
#1 will be the fastest and most reliable in auton, therefore it’s the VEX U answer.
It seems the extra 25 balls are available only for match drive time, not auton time. Auton time robots need to go scoop up balls off the floor after the 4 are shot. Four shots are what you get up front per bot. Maybe one feeds the other four so it can shoot 8.
A friend of mine and I are going to start working on an internal simulation of sorts. The program will use the position and rotation of the robot on field to automatically turn the robot toward the goal. Then, with some physics, calculate the power needed for the motor to shoot the ball straight into the high goal. (we are using a flywheel) Although hard to do, this seems fairly reliable if you get some shaft encoders and a lot of calibration.
My idea was to place the ultrasonic sensor at the same level as the middle of the post, so the signal would theoretically bounce off of it and return to the sensor. However, in practice, I’m sure there are a lot of limitations compared to a program that can track the robot’s position. It could be a good way to re-calibrate that system if your robot is pushed off course.