Shooter Aiming Methods

[androb4]

I would like to know if anyone is thinking about making a turret or having a variable angle shooter, like last year.

What would be your method of aiming at the goals?

Also, will just lowering the speed of the shooter wheel, decrease the range or trajectory of the frisbee? Has anyone done any testing with this?

[nathan_hui]

Decreasing the speed of the shooter will decrease the range of the frisbee. As to what it will do to the accuracy, that will require testing of a different sort. We initially used a table and a pool noodle to test shooting - different amounts of accelaration cause different ranges

Aiming at the goals will most likely be done via manual aim (the targets are large enough). Auto aim is doable, but may not be of any advantage (you're driving towards the darned thing, might as well take the time to slew the turret). Not sure about range, but then we were thinking of raising the shooter, so there's that too.

[F22Rapture]

Originally Posted by nathan_hui

Auto aim is doable, but may not be of any advantage (you're driving towards the darned thing, might as well take the time to slew the turret).

Another way to think about it is, "you're writing the autoaim for autonomous anyway, might as well use it for teleop as well"

[Kusha]

The people that are auto aiming:
Do you guys off put vision processing onto something else?

[z_beeblebrox]

I'm thinking of putting vision processing into the operator's brain and combine the best of automatic and manual aiming. Instead of having the computer struggle to identify a target 50' away with different lighting, I want to have the operator look at the camera feed and click the center of the goal. Then, the computer uses that to figure out how much the robot needs to turn and how high to aim the shooter to hit the goal. The output from this will be fed to PID controllers for robot and shooter angles. When the robot has slewed to position and the shooter has spun up to speed, the operator fires a disc and makes corrections if it misses. Then, the operator rapidly fires their remaining 3 discs.

[Lil' Lavery]

Originally Posted by z_beeblebrox

I'm thinking of putting vision processing into the operator's brain and combine the best of automatic and manual aiming. Instead of having the computer struggle to identify a target 50' away with different lighting, I want to have the operator look at the camera feed and click the center of the goal. Then, the computer uses that to figure out how much the robot needs to turn and how high to aim the shooter to hit the goal. The output from this will be fed to PID controllers for robot and shooter angles. When the robot has slewed to position and the shooter has spun up to speed, the operator fires a disc and makes corrections if it misses. Then, the operator rapidly fires their remaining 3 discs.

Certainly an interesting aiming concept. How will your computer know the range of an object based solely on the click of the operator? Are you assuming you're always firing from approximately the same distance from the goal? Are you going to have the operator click&drag a box that can be used to size the goal (and thus determine range)?

Additionally, you're then forcing one of your operators to either move his hands between two input devices (his typical input device and the computer), or be entirely dedicated to the computer (thus leaving both the driving and firing to the other driver). Forcing your operators to have to look at the controls rather than the robot* and move their hands between multiple devices are some of the cardinal sins of OI design for FRC.


*the obvious exception to this is when focusing on a camera feed on the OI.

[z_beeblebrox]

Originally Posted by Lil' Lavery

Certainly an interesting aiming concept. How will your computer know the range of an object based solely on the click of the operator? Are you assuming you're always firing from approximately the same distance from the goal? Are you going to have the operator click&drag a box that can be used to size the goal (and thus determine range)?

Additionally, you're then forcing one of your operators to either move his hands between two input devices (his typical input device and the computer), or be entirely dedicated to the computer (thus leaving both the driving and firing to the other driver). Forcing your operators to have to look at the controls rather than the robot* and move their hands between multiple devices are some of the cardinal sins of OI design for FRC.


*the obvious exception to this is when focusing on a camera feed on the OI.

Since you know the height of the goal and the angle from your shooter to its center, you can use simple trig to find the distance. I would give the operator a USB mouse for their right hand and a joystick (maybe a custom controls box) for their left.

[Lil' Lavery]

Originally Posted by z_beeblebrox

Since you know the height of the goal and the angle from your shooter to its center, you can use simple trig to find the distance. I would give the operator a USB mouse for their right hand and a joystick (maybe a custom controls box) for their left.

So you're assuming that as your distance from the target changes, so will its height in your camera's field of vision at a predictable rate? I'd recheck that assumption if I were you. If you're only moving in the axis orthogonal to the goal, this would be true. But does it hold true once you introduce the second (or third) axes of motion?

[Mr. Lim]

Originally Posted by Lil' Lavery

So you're assuming that as your distance from the target changes, so will its height in your camera's field of vision at a predictable rate? I'd recheck that assumption if I were you. If you're only moving in the axis orthogonal to the goal, this would be true. But does it hold true once you introduce the second (or third) axes of motion?

This is true, and we did it last year with EdgeWalker.

If the camera is kept at a fixed height, and a fixed angle, and you are directly in front of the goal, you've essentially limited your movement to the axis orthogonal to the goal. If you move left and right (perpendicular axis) the shape of the goal becomes trapezoidal, but if you use the centre of the bounding box of the trapezoid as your reference, you can compensate for the additional axis of movement.

The trick is finding a camera height and angle where there is enough change in the goal's height to give you meaningful information - AND where you can keep the goal in the field of view at every spot on the field you want to shoot from.

[jasp]

Last year our team tries vision processing with an non-axis camera and we never used it because it was not as accurate as we wanted and was very slow. If you do try vision processing I suggest using a raspberry pi or something similar.

[jwakeman]

Originally Posted by Kusha

The people that are auto aiming:
Do you guys off put vision processing onto something else?

We had the camera streaming directly to the driver's station/class mate last year. We would do the vision processing there and send relevant coordinate info to the robot to make the position adjustments. Lots of teams did this last year, they gave an example last year that was setup for this.

[Anupam Goli]

Originally Posted by F22Rapture

Another way to think about it is, "you're writing the autoaim for autonomous anyway, might as well use it for teleop as well"

But I don't think you HAVE to auto aim for auton. As long as you're contacting the pyramid, you start out in auto right? You could just start aiming straight at the goal and fire. Granted, it's not the best, but hey, whatever works. Also, auto-aim is just sometimes too much to deal with and test. I'd be perfectly happy if we just had a sweet spot and a little camera crosshair that would guarantee that our shots would go in. My theory on auto aim is that you don't absolutely need it unless you're encontering moving targets.

Also, a rotating shooter is probably much more complicated to do for what it's worth. if you've played catalyst, or done some math, the angle of error for these shots is actually pretty high, compared to previous year's games.

[DjScribbles]

My opinion is that controlling the angle vertically will be more important than rotational angle control. We have wide targets, but they aren't tall.

[Anupam Goli]

Originally Posted by DjScribbles

My opinion is that controlling the angle vertically will be more important than rotational angle control. We have wide targets, but they aren't tall.

Using the speed of the shooter and a table of experimented speeds vs distance can also overcome the short goal height.

[Ether]

Check out this post. It's not directly related to shooter aiming, but it does have some useful qualitative observations about shooter wheel speed and slipping:

http://www.chiefdelphi.com/forums/sh...2&postcount=55