Re: Shooter consistency
 

What is your wheel diameter, what motors are you using, and are you giving 100% voltage to each one?

Re: Shooter consistency
 

How are you decoding the signal ?

Re: Shooter consistency
 

In theory the arc changes with changing launch speed. But if the shot distance is short enough and the launch speed is fast enough then the change in the arc may be small enough to allow some variation in speed and still score.

Re: Shooter consistency
 

Wheel Diameter: 4.875" Orange Banebots
Motors: 1 CIM 1 Mini CIM.
Both get 100% voltage. Minor (~4-5 feet) performance change between 2 mini-CIMs and 1 mini one full like we have now.

We were *shocked* at how easy it was. I was planning on making something very similar to what Jared described and doing a bang-bang controller on the final wheel, but we just don't need it at all.

Re: Shooter consistency
 

I'd agree with your original assessment. You're probably way past the point of diminishing returns on wheel speed, so slowing it down doesn't have much of a difference.

Re: Shooter consistency
 

Our discs fly in a very flat trajectory at the ranges we specifically target (all the way from just in front of the goal to about midfield). So flat, in fact, that our auto-aiming function simply aligns our shooter's angle so that the goal is in a constant place in the image frame coming from the arm-mounted camera. I had anticipated nonlinearities requiring a range-to-offset table (e.g. assume shot drop at longer distances and different trajectories at higher angles, etc.), but this turned out to be unnecessary.

Our shot trajectory is not very different with our nominal setup (3000 and 4700RPM) than if we run both wheels at 100% voltage open loop (~6000RPM). The real benefit of speed control/measurement in this application is that we can maintain a high rate of fire with consistent shots (we know exactly when we can fire the next shot), and we manage the wear on our BaneBots wheels by limiting the slip on the disc (and balancing the wear between the front to back wheels).

Re: Shooter consistency
 

You are correct; last year our team had to change from Optical encoders to the US Digital EP4 Encoders but we use 360 count encoders last year and this year.

Re: Shooter consistency
 

I wanted to update this post with some more info we found yesterday.

While the S5 encoder from US digital states a maximum rpm of 10,000, they only state that is for the bearings. In practice, we're seeing a loss of signal around 8600-8800 rpm. The sensor will begin missing counts and you will see a drop in rpm feedback as you increase the speed of the motor above that.

As a backup, we tried one of the $12 allied electric photo switches (more info on specifics elsewhere - just do a search). They don't have a response time listed so we had low hopes, and it didn't work.

We then switched to allen bradley photo switches from 2011. We have half the wheel colored black, the other half with reflective tape. We have extremely good feedback up to our max speed of around 11,500 rpm.

It appears, however, that this sensor is not widely available anymore. Does anyone have a source with reasonable shipping times? Is there a drop-in replacement that anyone is aware of?

Re: Shooter consistency
 

Tom,

I personally have had a lot of success with Banner's QS18VN6D (IR) and QS18VN6LV (Visible Light - Red) sensors for these types of FRC applications.

They are close to a drop-in replacement for the ABs, but these only need 12V.

Sourcing them for us has been easy and fast because they used to come in the KoP, and being an older team we've built up a stockpile of them. You could probably call up one of more generous very old MI teams, and there's a good chance they'll have a bunch kicking around.

Else, you can order them direct from Banner at http://www.bannerengineering.com

We're using the QS18VN6D (IR) right now on our 2013 robot.

Sometimes it's easier to prototype with the QS18VN6LV (Visible Light - Red) since you can see the light being emitted, making alignment much easier. Even though the specs say it is supposed to be used w/ retro reflective tape, at close ranges (i.e. < 1ft) a black/white painted/coloured regular diffuse surface will work fine.

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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

Re: Shooter consistency
 

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!

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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.