Shooter consistency

[Kevin Sevcik]

Originally Posted by F22Rapture

Would the line tracking photoswitch from 2011 work, or is there another sensor that would be a better choice?

Yes, though it's a little slow. You typically need a pretty wide stripe to get it to work. Too narrow a stripe and it won't register. Practically speaking, you can make the stripe take up half of whatever surface you're sensing and it'll work fine.

[DampRobot]

Be fair warned, our software folk had a ton of trouble with the battery voltage dropping too low when we used the KOP photogates, to then point where they gave bad data. We were running 2 CIMs on our shooter, and the voltage the sensors were seeing dropped from 13v to 10v when we spun them up to full speed.

[Ether]

Originally Posted by DampRobot

our software folk had a ton of trouble with the battery voltage dropping too low when we used the KOP photogates,

Read the last two paragraphs on page 2

Not sure if this rule exception is valid in 2013.

[fb39ca4]

Originally Posted by Ether

Read the last two paragraphs on page 2

Not sure if this rule exception is valid in 2013.

I don't see anything in the rules about it, so I would say no. It wouldn't hurt to contact FIRST and see if they can add the exception back in.

[Ether]

Originally Posted by Kevin Sevcik

Yes, though it's a little slow. You typically need a pretty wide stripe to get it to work. Too narrow a stripe and it won't register. Practically speaking, you can make the stripe take up half of whatever surface you're sensing and it'll work fine.

FWIW, the Rockwell catalog for the 42EF model sensor lists the "Response Time" as "1 to 16 ms".

It's not clear whether those numbers mean

a) the pulse width must be 1 to 16ms in order to be reliably detected, or

b) it takes the sensor 1 to 16ms to respond to a pulse (and the required pulse width is left unspecified, or

c) something else.

You need the stripe width to be 1/12 of a revolution at the point of sensing in order for it to be under the sensor for 1ms when the wheel is spinning at 5000 rpm.

[faust1706]

many teams had great accuracy this year. What was really amazing is that both main types of shooters, linear and semicircle, worked great. 1706's shooter was deadly this year, but sadly teams caught on in eliminations and played excellent defense, a well earned victory. http://www.youtube.com/watch?v=U5PgpTQCgBc

[MUDavid]

This is what we learned at our 2nd MAR district and we ended up with the most Autonomous points. We had the same problem. Make 3 in Autonomous and then for some strange reason, frisbees were high. So we said, slow down the speed. Didn't seem to help. Our analysis was that at slower speeds with the frisbee encountering a lot of air resistance, the frisbee had a tendency to "float" and end up high. We cranked up the speed (within reason - there may be a point of diminishing returns) and adjusted our angle. If you can not adjust your angle, then position your robot differently (works great when shooting from the side of the pyramid). This works. Watch how other teams shoot. Keep it simple and good luck!

[dheerm]

our team was having trouble with encoders as well. Yes different battery voltages do matter when sending a value to a Victor because the value sent to the victor is the equivalent of a percentage of your current voltage. So to try to get a better measurement, I tried a last minute fix.


Wheel Motor Voltage = Value sent to Victor * Battery Voltage.

Therefore, Value Sent to Victor(Or other speed controller) = (End Voltage / Battery Voltage).

All you have to tune is the End Voltage that you want your wheel to have. Batter Voltage can be calculated (in Java) by instantiating a DriverStation object and using the getVoltage() method.

Same method should be in other API's.

It didn't give us 100% consistency but it did significantly improve it. There are of course other variables.

[Kevin Sevcik]

Originally Posted by dheerm

our team was having trouble with encoders as well. Yes different battery voltages do matter when sending a value to a Victor because the value sent to the victor is the equivalent of a percentage of your current voltage. So to try to get a better measurement, I tried a last minute fix.


Wheel Motor Voltage = Value sent to Victor * Battery Voltage.

Therefore, Value Sent to Victor(Or other speed controller) = (End Voltage / Battery Voltage).

All you have to tune is the End Voltage that you want your wheel to have. Batter Voltage can be calculated (in Java) by instantiating a DriverStation object and using the getVoltage() method.

Same method should be in other API's.

It didn't give us 100% consistency but it did significantly improve it. There are of course other variables.

I'd recommend caution with this technique. You can end up with some interesting interactions since you'll be drawing more power, which will drop the voltage more, which will draw more power, etc. etc.

[pyroslev]

You can have the best shooter consistency but you have to feed it first.

195 at Virginia could snipe cross field, but they suffered one flaw. THe hopper into the shooter was poorly fed. They had to jostle the robot to get it down several times, that threw off the aim.

1610 had jam issues twice and two different ways. They could get up close enough to the bar and touch it to line up but if the hopper jammed, it was for naught.

I saw another half dozen such jams, poor feeding issues, etc.

Great shooter or not, consistent or not, your hopper/feeder has got to provide the Frisbee.