Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

These too:

http://vamfun.wordpress.com/2012/02/...ero-placement/

http://vamfun.wordpress.com/2012/02/...city-pid-loop/

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

Currently we have the top set of wheels driven by an old KOP fisher price (9015 I believe?), 15t:79t reduction using plastic gear from fisher price gearbox. Bottom set of wheels is driven with a Banebots RS550, 17t:79t reduction. We just got two new FP-9015 motors in the mail from AndyMark, we plan to put them on when we have a chance.

I believe our shots in that video were done with the bottom wheels at 90% and top wheels at 40% of full voltage. They stay nice and cool after shooting for a few minutes straight, those air vents work great!

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

This thread is great, another example of why CD is awesome.

Another idea I had (that some teams are probably implementing), is have a control on your driver control system where you can adjust the speed of the shooter on the field. Basically a you could feed the operator input into targeting and range algorithm as a multiplier to speed up or slow down your shooter. This will give the operator some control over the speed of the shooter if the field crew decides to use a new set of balls and all of your shots are flying over the backboard...

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

I forgot to ask: what diameter wheels are those?

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

I suppose that is true. We always make custom PIDs for each situation.

However, with our shooter I found that once we got the PID controller tuned, the I term calculated the equivalent feedforward term before the ramp-up was complete. We were planning on adding feed-forward, but since the I-control did such a good job, we didn't pursue feed-forward any further. The simple gain scheduler made sure the I-control was basically equivalent to it's steady state value by the time the speed hit the target.

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

I forgot to mention, they are 4" wheels. Each shaft has two wheels spaced about 3" apart (so you can imagine where the contact points are on the ball as it's leaving the shooter). It has approximately 1 smidgen of compression on the ball.

Since were are talking about controls in this thread, here's something we learned when playing with shooting speeds for a dual-shaft shooter (2 or 4 wheels) like ours: Running the bottom wheel at near full speed give a good amount of backspin and allows us to adjust the distance of the shot with only the top wheel. The top wheel is set to spin at about 50% free speed for our average shot distance, which puts us right about the range of the motor we want to be for fast spin up times. I think our shots from the key have us running at about 60-70% freespeed for the top wheels, but I'm not certain.

It would be neat to see the calculations for the ideal gearing and motor speed for the fastest spin up time, I think it gets very complicated very quickly! "about 50%" seemed like a close enough starting point for us. :)

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

By gain scheduling, do you mean you adjust PID parameters dynamically as the launcher spins up? Or that the integral value is about zero when the launcher reaches its correct speed?

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

Adjust the PID gains dynamically.

An example from our turret control: if the error is greater than 10 degrees (in an absolute value sense), set I to 0 (and we also reset the integral back to zero). This allows us to use a higher I gain to make the turret reach zero error faster, without too much overshoot caused by the integral storing a lot of error when it first starts to move.

For a shooter, an example would be to have one I for when the error is large (say > than 500 RPM), another I when the error is between 0 and 500 RPM, and another I when the error is negative.

Those are just two examples. There are many ways to play with your gains to improve your controller.

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

We are doing feedforward + PI control and it works well.

Output = Kp*(speed error) + Ki*(sum of speed error) + KFeedforward*RPMSetpoint

Where KFeedforward is simply 1.0 divided by our shooter's free speed at 12V. Output is bounded between [0,1] - we never want our shooter motor running in reverse. Note that the form of this PI controller is NOT the same as the form I had posted a couple years back for doing velocity control; our Ki is more analagous to a position loop's Kp, and our Kp is analagous to a position loop's Kd.

The real key, IMO, is getting a good speed measurement that is stable, responsive, and gives you the resolution you need. There have been several other threads recently which discuss this problem separately.

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

Oh yeah, I forgot to mention that. We also low-pass filter the encoder speed output in order to stabilize the speed measurement. That helps when determining if your shooter has reached steady-state.

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

We are in the open loop control scaled by voltage camp.

http://www.chiefdelphi.com/forums/sh...9&postcount=17

Our rpm control is on a pot so the co-pilot can give it a higher target value initially for spin-up before dialing in the desired shooting distance.

We will do some more playing around with encoders and PID this weekend. Really appreciate the discussion here. My background is not control systems (actually I'm a chemistry teacher).

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

PID for velocity control was totally new to me this year. What worked well for us -- that is to say, what allowed us to tune in our PID relatively quickly -- was this procedure (using encoder counts from GetRate, not RPM):

1. Starting with P only, increase the gain incrementally (we used .01 and steps of .01 in LabView) until you nearly reach the desired rpm (or encoder count), and further increases in P result in no or almost no increase in rpm.

2. Enter a rather large I value (I think we started at .08). (Low I values resulted in massive oscillation and very unstable behavior). Your initial value will probably cause it to very slowly ramp up but eventually reach the target value without overshooting.

3. Decrease the I value until the response is fast and stable. (We ended up tweaking values in the thousandths place at the end, just to refine things as much as possible).

Our end result ramps up very quickly (< 1s), does not overshoot, holds stable at +/- 15 rpm (.25 rps), and ramps back up after a shot with a similar time scale. To be honest, I'm very impressed with how well it works.

The tuning with this method took no more than an hour and a half...

...and FYI, the gain values we ended up with were very, very different than those on our protobot shooter (which was two direct-driven CIMS).

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

As a warning to all, the gain values will vary hugely system to system both from physical differences (friction, inertia, ratios, motors, etc...) and in units (some teams do raw encoder ticks, some teams do rpm, etc.. etc...). DO NOT try to just copy someone's gains that have been posted, or even assume the order of magnitude they used is correct for your purposes.

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

Indeed -- I should have made that more clear, thanks!

That said, the *process* worked rather well using raw encoder values, rpm, and different shooter setups.

Re: Problems with tuning shooters using AM basketballs on Practice Field?
 

Actually, if you let the computer do the calculations (numerically integrating the differential equations) it is fairly simple. The difficult part is deciding how best to model friction and viscous drag, and getting a good estimate for inertia of the system.

If you could provide:

- the motor being used

- the gear ratio from motor to wheel

- velocity-independent and dependent torque losses in the gearing

- the moment of inertia of the wheel

- windage torque losses in the wheel

- and the start and finish speeds between which you want to calculate the elapsed time

... then it wouldn't be too hard to set up the equations and let the computer grind out the answer. This ignores the moment of inertia in the motor's rotor and the gears - which for all but the lightest loads is a reasonable thing to do.

You could run this model with a constant voltage applied (open loop), or you could include a model of your closed-loop control scheme into the equations.