How do you aim your shooter?

[Salik Syed]

just wondering how are all you other teams plannign to aim your ball shooting mechanism?

[sanddrag]

We have a custom turntable driven by sprocket, chain, and globe motor. It rides on steel and teflon balls. It has about 160 degrees of rotation. On top of the turntable is a tilt mechanism actuated by the van door motor and driven by sprocket and chain. It can go from 0 to 45 degrees.

Of course, all this is just theoretical. We have not even started building it yet. :ahh:

[Donut]

For control of the rotator, we will be using a joystick to rotate back and forth manually, or will allow the camera to rotate it to face the goal (we have a switch that allows us to change between manual and automatic control). For the speed (we are adjusting speed not angle), we will use a series of 4 push buttons to change a desired speed by small or large intervals for manual control, and the camera will once again change the speed based on automatic control.

Mechanically, the speed control requires nothing extra than what we already had (one of the big CIM motors driving one flywheel), the rotator control will be done using a van door (or window) motor, driven by either a chain-sprocket connection or a belt drive (not sure which).

[Pat234]

We are using the camera linked to a globe motor to control the tilt through a 30 degree range of motion and the pan angle will be controlled through the drive train to line the robot up accordingly. These both will be controlled through the camera while on offense however the drivers will have some capability to override the camera controls.

[kawelch]

Luck and prayer

[Jared Russell]

Complete auto aim.

[Sachiel7]

We plan to allow the possibility of manual control, but we are focusing on having fully automated aiming utilizing the camera, to shoot on the fly.

[Spindash54]

Aim? Who needs to aim? We just hit the fire button and relax... :)

[bbehnke]

for our angle adjustment we are using a cam (off-set center circle) to move a plate up and own and for yaw we are using a lazy suzan design and a automatic aim from the camera. the only thing manual is when you want to shoot the balls into the goal and winning the game :)

[Salik Syed]

So it seems many teams ARE going the automated aiming route...

[Madison]

for our angle adjustment we are using a cam (off-set center circle) to move a plate up and own and for yaw we are using a lazy suzan design and a automatic aim from the camera. the only thing manual is when you want to shoot the balls into the goal and winning the game :)

How do you compensate for the cams varying radius as it moves? The rate at which your pitch changes is never constant.

[Alan Anderson]

How do you compensate for the cams varying radius as it moves? The rate at which your pitch changes is never constant.
Many things are nonlinear in this system. Camera tilt angle is not proportional to distance. Distance is not proportional to the required pitch angle. Pitch angle can be, but is not necessarily, proportional to the cam position.

Fortunately, the nonlinearities are all irrelevant if you forego detailed computation and just make a simple lookup table that converts the measured camera tilt directly to the desired pitch adjustment. Creating that table is as easy as moving the robot forward and backwards, measuring the camera tilt, and manually tweaking the pitch adjustment until it works the way you want.

[DjAlamose]

Many things are nonlinear in this system. Camera tilt angle is not proportional to distance. Distance is not proportional to the required pitch angle. Pitch angle can be, but is not necessarily, proportional to the cam position.

I don't know where you got this from but good luck then.

We have our robot fully automated for just about everything. All you need are the equations for speed, angle, height, and distance. Once you have those the RC can control the robot fully based on where it is. In reality you dont need the camera if your robot can keep track of where it is on the field at all times (much easier to use cmucam).

But we plan on haveing 3 different modes for our shooter, fire, off, and store. Can't give details other than 270 degrees, 4 balls per second, and 2 shooting angles. Pneumatics and window motors will be used for aiming the shooter as well as the small cim motors which will provide the speed for throwing the ball, vary that and you can send the ball just about anywhere.

[Jared Russell]

I don't know where you got this from but good luck then.

We have our robot fully automated for just about everything. All you need are the equations for speed, angle, height, and distance. Once you have those the RC can control the robot fully based on where it is. In reality you dont need the camera if your robot can keep track of where it is on the field at all times (much easier to use cmucam).

But we plan on haveing 3 different modes for our shooter, fire, off, and store. Can't give details other than 270 degrees, 4 balls per second, and 2 shooting angles. Pneumatics and window motors will be used for aiming the shooter as well as the small cim motors which will provide the speed for throwing the ball, vary that and you can send the ball just about anywhere.

Finding a reliable ball kinematics equation that takes into account spin and air resistance is VERY hard to do on the RC (but not impossible). And that's not even taking into account the trig needed for angle adjustments and converting the x and y coordinates of the target seen by the camera to angles. Try doing the math yourself - in order to get a full-fidelity representation of what your camera sees, you not only need to convert between pixel offset and angle (which is fairly easy), but also take into account that the 2D space represented by the camera's data feedback is in actuality a representation of 3D space. To combine all of these factors together, you have to use some matrix math.

It is MUCH simpler to use look-up tables, and in addition they are always going to be faster. They do all the dirty work of physics for you.

Our team's solution is to slave camera pan to the turret (turret rotation controlled by a feedback loop) and use a constant camera tilt. Then, a look up table for flywheel speed is indexed by the y pixel offset of the target. With the right choice of camera tilt angle and lens, you can see the goal from pretty much anywhere that you could realistically shoot from. It really doesn't get much simpler than that.

[Parker]

[QUOTE=sanddrag] On top of the turntable is a tilt mechanism actuated by the van door motor and driven by sprocket and chain. It can go from 0 to 45 degrees.

You might run into problems shooting close to the center goal with only 0-45 degrees of rotation. If you want to aim at the lower goal just turn down the speed of your shooter.

[Ethulin]

So it seems many teams ARE going the automated aiming route...

I have a feeling this is going to be VERY similiar to last year with the green tetras. Many teams try it, may teams fail. One team that half/sorta does it!

Our shooter does not aim. No, I am not being dumb, we really do have a shooter and it really does not aim.

[Jared Russell]

I think that this year the success rate of teams using the camera will be MUCH higher than last - the illuminated, elevated target really works wonders.

Still, you better alot the better part of a week to program the thing and tune all your feedback systems if you want it to work (especially if you're using empirical look-up-table data, which is the simplest way).

[ForgottenSalad]

Fortunately, the nonlinearities are all irrelevant if you forego detailed computation and just make a simple lookup table that converts the measured camera tilt directly to the desired pitch adjustment. Creating that table is as easy as moving the robot forward and backwards, measuring the camera tilt, and manually tweaking the pitch adjustment until it works the way you want.

Our planned course of action is to be aiming with the camera, but instead of messing with equations, doing just that, working with a lookup table and simply testing, testing, testing to get the values needed. After the camera positions the turret, operator will manually fire. As a backup, though, we will have the option for the robot operator to manually aim via atari (subject to be replaced with other) joystick and have some sort of sensor feedback (still undecided) on the dashboard to help give the op a better idea of where it's aimed.

Although we still lack a robot to begin getting values for the table. :rolleyes:

[Sachiel7]

That is 100% exactly our plan as well ^
Cept we plan to calculate a base set of values for our lookup table and tweak as nessicary. As for where we're both going to find an atari paddle, we're not there yet.
:D

[BrianR]

I have a feeling this is going to be VERY similiar to last year with the green tetras. Many teams try it, may teams fail. One team that half/sorta does it!

Our shooter does not aim. No, I am not being dumb, we really do have a shooter and it really does not aim.

If you asked me, this sounds as if you are going to get really close to the goal, i.e. on the ramp, and simply shoot from such close a range that there is no need to aim.

[greencactus3]

If you asked me, this sounds as if you are going to get really close to the goal, i.e. on the ramp, and simply shoot from such close a range that there is no need to aim.
or they shoot so many balls at a time or rapidly that they can hope the majority goes in or that the operator can compensate for each missed shot.

[Salik Syed]

we also determined that a lookup table based on camera tilt angle would be the easiest method