Shooter Speed Lookup Table

[joecaraccio]

Utilizing the shooter speed effectively might be truly the most difficult point of our software this year. From testing the shooter the past week we now know a few things for sure:

• There is going to be a 'window' of speeds that we can hit at a certain distance
• We may be able to shoot a quantity of balls quicker than we originally thought at various distances.

We need to develop either an equation, or some sort of lookup table that can QUICKLY get us as a range of shooter speeds we can be at and make the shot.

For example, lets say our vision system estimates our distance at 10 feet away. There is a min and a max speed (via our encoder) that we should be able to hit the shot. If our trajectory lies pretty flat, that max speed might be close to the shooters max speed.

The shooter should be able to take the distance argument, call our speed lookup table and receive a min and a max acceptable speed to shoot at. Then check if we are already there, and if so send the ball, if not, command the shooter to the maximum velocity and continuously check the speed for the shot.

I think from testing last we may find that our pid in the talon firmware recovers really quickly, and we may be able to set our shooter to the max speed of that range, and then just run the storage belt at a decent pace to offload all the balls. The system likely doesn't need to be as complicated as we might have initially thought.

[ajwharton]

Agreed, although a simple distance/aimpoint static doping table might be the most efficient. We can do some real world testing with the final gun and come up with the holdover numbers in a few minutes

[joecaraccio]

@ajwharton actually that would definitely be the most efficient.

[ajwharton]

Until then, we can have a simple placeholder table. I'd suggest no more than 5-10 distance intervals with a corresponding double delta factor. Since the gun has no elevator, it'll have to be a voltage delta factor for the firing motor.

[Nick-P-Orr]

@joecaraccio just to add, when we go about testing the distance|shooter velocity, we can try to find a spot to hit that inner port if we wanna have that option in auto. I’m thinking from what we’ve seen in testing, we probably will just have the shooter max out around 15 feet with how it arcs.

Agreed on the table, i think it’ll be easy to adjust when testing and from a code standpoint probably not too bad to implement.

[maxh65000]

We could model our data table with an equation and then use that to calculate our motor velocity.

[joecaraccio]

definitely Max. only X factor is going to be how well we can fit a curve to the data points we take.

[maxh65000]

77 added a singleton for this but does not have actual data.

[joecaraccio]

Nice Job with this Max. Simple and effective. @maxh65000

[maxh65000]

This is integrated now but needs actual values

[joecaraccio]

@maxh65000 if you collect values for the non production turret... just make sure you note so