Re: Shooting on the run
 

I'd go search for a poll last year about capping the vision tetra in autonomous, but I don't have the time.

If you feel inclined to do so, I bet a whole heck of a lot of people were saying they could do it.

Could anyone? No.

Re: Shooting on the run
 

To know speed, you must have an accleremotor or an encoder, as I said. Robot turning requires gyro, angle of rotator in relation to the robot requires a POT, and the tracking stuff requires the camera. I hope all teams will have the camera at least semi-working, but using all the other data is alot to ask for.

You must know your speed in your current direction, relate this to how fast you are moving to/from the goal, and change your shooter speed/rotation to account for it. Is your shooter or rotator going to be able to move/change speed fast enough to keep up? By the time it gets in position, your robot might be well past the point that required those parameters. Also, what happens if your robot is not moving at a constant speed? You must now make a part of your code to account for acceleration in addition to velocity, even more of a pain. As an added bonus, a strong hit from another robot always has the possibility of throwing off your data (you may think parallel to the goal is 5 degrees past the original angle you thought of), compromising the whole system.

All of these calculations and compensations are possible. I don't think there is enough time in 6 weeks to do them all and test them properly though. I say less than 5 teams are able to do this well, and at least 4 of them will be from teams that used the camera very effectively in autonomous last year.

Re: Shooting on the run
 

It's not that I mind that you posted it here, and it seems like you had a fine rationale. I was just curious as to the reason, thanks for the reply =).

Re: Shooting on the run
 

Knowing your current vector is important, but setting up encoders or the GTS is not hard. You could also consider having a lookup table of PWM values to approx.. speed (of course, this would not be very accurate, but it might work with some tweaking). You could also see how many pixels the target moves each frame and use this in combination with your distance from the target to deduce an approx. speed. A tachometer could be used as an analog input to get speed as well.

You need to also know the current direction, but the gyro is so easy to setup this couldn't be a problem. Acceleration is, in my mind, irrelevant, because the ball does not retain the acceleration of the robot once it has left the turret, just the velocity of the robot at the point it left. And being bumped by a robot won't occur continuously, nevertheless it will be a factor that is impossible to account for.

[If you need help with either encoders, gyro, or the GTS there are plenty of help posts and Kevin's code is well documented and clear]

However, your point about never being able to move the turret accurately and fast enough to have it in the position to fire after doing the calculations is my worst fire. I can't test any of this stuff because our robot is ages away from being ready. In my mind, its the the most difficult problem to overcome. Of course, any one who has mode can feel free to give us some hints. :)

Good Luck,
Robinson