Problems with tuning shooters using AM basketballs on Practice Field?

[carrillo694]

I heard about 20 minutes in to this podcast (http://www.talkshoe.com/talkshoe/web/audioPop.jsp?episodeId=600306&cmd=apop) that teams that tuned their shooters using their own AndyMark basketballs on the practice field encountered tuning issues when they used competition basketballs on the real field.

A speaker in the podcast states that, while their shooter worked perfectly with the balls they used on the practice field, it consistently overshot the hoop when they played on the actual field with the competition balls. The other commentators confirmed this phenomenon as being real.

Have any other teams encountered this issue at any of the past few regionals?

[Grim Tuesday]

I can confirm that we had balls in our shop of varying densities and wear and tear. A new ball would shoot a good 5 feet higher than an old worn out one. Regardless of this, our plan is to re-calibrate our shooter when we get to the event, with whatever kind of ball they have there.

[GaryVoshol]

You might also note that the practice field tends to be the graveyard for balls that are killed on the competition field.

[Tommy F.]

We were having this problem as well at GKC. In practice we would tune our PID setpoints until the ball would make it into the hoop every time, and then when we went on the competition field our balls would overshoot.

We were also using one of our first balls that has suffered some wear and tear. I'll have to remember to bring a newer ball with us to our next regional.

[MrForbes]

We noticed our shooter accuracy getting worse as the regional progressed...one of the possible reasons is the condition of the balls becoming more different as they are used longer. But we have other things to worry about too, like our shooter getting wonked when the robot falls off the bridge (which only happened about 4 or 5 times)

This game has some good challenges, excellent job GDC! :)

[Jared Russell]

The balls on the field were definitely much denser than any of the balls we had been practicing with. We even reserved some brand new balls for practice on the final days of build season, and the balls at the event still flew much further. I do not have a great explanation as for why, since all balls with the FIRST logo are apparently from the same batch. I will say that if you bought balls directly from Gopher Sports, the FIRST balls have both a different density and a different surface finish.

As the event went on, balls were worn/damaged but still (in my opinion) seemed to shoot further than our shop balls.

It's all part of the challenge. Some types of shooters are more susceptible to amplifying ball variation than others. At least one team - 1218 - rigged up a sensor to measure ball squishiness and fed the result to their shooter speed control system.

The most straightforward thing you can probably do about it is make it easy to adjust your shooter to the variation. Use a configuration file to read in new speed setpoints without requiring recompiling code. Or give your drivers a trim wheel to add or subtract from a nominal motor/wheel speed. You will probably get between 1 and 5 practice matches at your event. You want to be able to dial it in in that time!

[MrForbes]

We have a trim control for ours. But I still think our shooter speed control algorithm is flaky, on top of everything else....

[Ryan Caldwell]

we ran into the same thing

we are using single wheel shooter with a stationary pinch bar to compress the ball into the spinning wheel makes for lots of backspin. The video link is what we found with the worn balls vs. new balls. the issue seams to be the compression reaction more than the surface wear. the new balls will take effort to move the air out of while used balls have lots of little nicks and cracks for the air to escape out of thus the force to compress is much less.

Our solution was to reduce the amount of pinch on the ball this limited our distance but greatly increased our consistency from one ball to the next.

http://www.youtube.com/watch?v=4EuePR8i43o&feature=channel

[MrForbes]

That sounds like a good explanation of what's happening.

[JABot67]

Our solution was to reduce the amount of pinch on the ball this limited our distance but greatly increased our consistency from one ball to the next.

This.

We had a consistent shooter in our shop, then decided to try to increase our range by increasing the compression. This greatly reduced our accuracy. We bought a new ball and tried to shoot it; it sailed a couple feet higher than all the old balls we were using. We concluded that the added compression was hurting us.

[JamesCH95]

We've been using an open-ended voltage control (same as 2006) for our 5-roller shooter and were very consistent throughout GSR. Even when fresh balls were put out on the field during eliminations our hybrid was as consistent as before. FWIW I think we're ranked 20-something in Hybrid OPR.

Our program essentially does this:

shooter_speed = 11/system_voltage

We tried a PID loop but couldn't ever get it to behave the way we wanted it to. The issues being that there are huge changes in friction and system inertia when a ball is engaged with the shooter, and our shooter system is slow low-inertia that the PID loop is unstable when under no load no matter how much we tuned it.

[MrForbes]

I'm thinking that this is a good solution to part of our problem. I wonder what the odds of us being able to implement new code on Thursday (AZ regional) are?

[wireties]

We tried a PID loop but couldn't ever get it to behave the way we wanted it to. The issues being that there are huge changes in friction and system inertia when a ball is engaged with the shooter, and our shooter system is slow low-inertia that the PID loop is unstable when under no load no matter how much we tuned it.

So a gain that made it stable with no load did not compensate for the change in load when compressing a ball? Then raising the gain to help made it oscillate under no load? We might have the same problem... what motors do you use?

For teams incorporating a compensation factor - was the factor a simple constant or a constant multiplied by V or maybe V squared?

TIA

[JamesCH95]

I'm thinking that this is a good solution to part of our problem. I wonder what the odds of us being able to implement new code on Thursday (AZ regional) are?

Very high I'd bet. Our student programmed disabled the PID loop and added the voltage control in 10 minutes. I'm no expert, but it seemed very simple.

So a gain that made it stable with no load did not compensate for the change in load when compressing a ball? Then raising the gain to help made it oscillate under no load? We might have the same problem... what motors do you use?

For teams incorporating a compensation factor - was the factor a simple constant or a constant multiplied by V or maybe V squared?

TIA

I believe that's what was happening to us. We're using two RS550s for our shooter. PIDs might work better for other teams with higher-inertia shooters. Our shooter consists of five 4" long rollers made from 0.065" walled aluminum tube, there is hardly any mass/inertia there. We couldn't even get a stable no-load PID loop, it was causing some seriously scary motor arcing.

[wireties]

I believe that's what was happening to us. We're using two RS550s for our shooter. PIDs might work better for other teams with higher-inertia shooters. Our shooter consists of five 4" long rollers made from 0.065" walled aluminum tube, there is hardly any mass/inertia there.

Our shooter uses 2 AM 8" FIRST wheels driven by 2 FP 0673 motors and 2 AM 9015 motors. I was hoping having a lot of torque to spare (the motors barely get warm to the touch) might make it more reliable/tunable - we'll see I reckon.

[JamesCH95]

Our shooter uses 2 AM 8" FIRST wheels driven by 2 FP 0673 motors and 2 AM 9015 motors. I was hoping having a lot of torque to spare (the motors barely get warm to the touch) might make it more reliable/tunable - we'll see I reckon.

They might be, that's considerably more torque/inertia than our shooter.

What I like best about the voltage control is that there is no tuning involved, set it once and don't worry about it after that.

[MrForbes]

We have a single 8" kit wheel driven by a single powerful FP motor. We seem to spend a lot of time waiting for the thing to settle down, we could probably shoot a few more baskets with the simple voltage algorithm. I posted a link to this thread on our team fb page, our programmer should see it.

Ironically today he's doing his science fair project report on the feedback speed control system :rolleyes:

[pfreivald]

We're using 2x two 8" wheels on 1/2" shafts with AM hubs driven by AndyMark motors and Andymark 3.67:1 planetary gearboxes, and our PID is quite stable -- we fed both old and brand new balls through it and it was consistent except for once in a while... The compressibility of the ball didn't seem to influence the throw much.

...I hope that pans out!

[DampRobot]

Could you explain to someone ignorant why controlling with voltage is so much better than PID? I would think that you want constant rpms on the shooter wheels for maximum consistency. More success with a less sophisticated control system seems a little counter-intuitive to me...

[MrForbes]

You're right...except that some of us seem to have built systems that are very difficult to get reliable speed control with. In that case, a consistent open loop system could work better.

[wireties]

Could you explain to someone ignorant why controlling with voltage is so much better than PID? I would think that you want constant rpms on the shooter wheels for maximum consistency. More success with a less sophisticated control system seems a little counter-intuitive to me...


PID is a good solution but it is not magic. The software is only one part of the servo system. In this case one can tune the wheel to free rotate at a selected speed but not have enough gain to recover quickly when a ball slows it down. So one might try to raise the gain. But then the higher gain might create an under-damped or oscillating condition when there is no load.

One approach is too build mechanical gain into the system by using stronger motors or storing energy in a flywheel etc. This gain would have much less phase delay and be more stable (I hope).

HTH

[JamesCH95]

Could you explain to someone ignorant why controlling with voltage is so much better than PID? I would think that you want constant rpms on the shooter wheels for maximum consistency. More success with a less sophisticated control system seems a little counter-intuitive to me...

In a perfect world, a perfectly tuned super-fast PID control would be better than just about anything else. However, an open-loop voltage control scheme works well enough for what we need to do in FRC without requiring any tuning at all. This control has gotten 95 in the top 5% Hybrid OPR.

I think this is definitely a case of "the best is the enemy of good enough." At least for my team this year.

[MrForbes]

This control has gotten 95 in the top 5% Hybrid OPR.

interesting...we're a couple above you with closed loop! But I still think we should give open loop a try.

[wireties]

interesting...we're a couple above you with closed loop! But I still think we should give open loop a try.


Based on this thread, we are definitely gonna have both approaches ready to go!

[JamesCH95]

interesting...we're a couple above you with closed loop! But I still think we should give open loop a try.

Hrm, quite interesting. I don't understand the OPR completely, but it seems like it can be skewed by alliance partner performance, either up or down.

For what it's worth I'd call our autonomous 70-80% reliable, with a large amount of our misses coming from shots spaced too close together where the second ball bounces off of the first. A delay between hybrid shots will be implemented for the Hartford regional.

[MrForbes]

We have a really long delay between shots, waiting for the shooter speed to adjust. Open loop could really speed up our shooting process, hopefully enough to get a few more shots off in teleop

[one4robots]

We also have a driver enabled adjustment button. Each click of the button decreases (or increases) the voltage applied to the shooter by 1/10th of a volt. This results in a decreased (increased) RPM of ~100. So if we find we are overshooting by 5 feet, the human shooter knows to decrease 3 clicks based on data collected during practices.

The problems that are often outside of our control (like ball squishy-ness) are the most valuable learning tools! Thanks, GDC!:)

[KrazyCarl92]

This was a HUGE problem for Team 20 this past weekend at GSR; we went from a 60% shooter in practice to a 3% shooter. Our targetting was working, but we were over shooting the hoop by 4 to 5 feet every time. Come to competition with a plan in place to account for the difference, or you will be sorry.

[Ether]

Ironically today he's doing his science fair project report on the feedback speed control system :rolleyes:

Is that a written report? If so, could you ask him if he'd be willing to post it?

[jblay]

Are there any teams who attended a week 1 event who didn't have an issue with this?

[JamesCH95]

Are there any teams who attended a week 1 event who didn't have an issue with this?

..

We've been using an open-ended voltage control (same as 2006) for our 5-roller shooter and were very consistent throughout GSR. Even when fresh balls were put out on the field during eliminations our hybrid was as consistent as before. FWIW I think we're ranked 20-something in Hybrid OPR.

Our program essentially does this:

shooter_speed = 11/system_voltage

We tried a PID loop but couldn't ever get it to behave the way we wanted it to. The issues being that there are huge changes in friction and system inertia when a ball is engaged with the shooter, and our shooter system is slow low-inertia that the PID loop is unstable when under no load no matter how much we tuned it.

[Chris Hibner]

We have a really long delay between shots, waiting for the shooter speed to adjust. Open loop could really speed up our shooting process, hopefully enough to get a few more shots off in teleop

A good closed loop controller should get your shooter up to speed much faster than an open loop method. After shooting a ball, our shooter is back to shooting speed in a little more than a half second. We spent some time tuning the controller to make it work well, and we have a simple gain scheduler to help out.

We found that the shooter is much more consistent with closed loop control. Some balls slowed the shooter down more than other balls, but the closed loop control reduced this variation quite a bit.

[andreboos]

I plan to implement PID on our withheld launcher tonight. We installed encoders at the last minute to simply measure rate, and the wheel speed is stable within 10% of the average when driving them with a constant percent of battery voltage with a Victor.

Teams that have compensated with system voltage, what sort of stability have you achieved, and what algorithm did you use? My naive approach would be something like 12.0/V_battery*percentage, but a voltage-squared system was mentioned earlier. Would this provide a more stable speed across voltages?

Teams with closed-loop control, what sort of stability have you achieved? I can't imagine that it would be easy to tune PID for a flywheel for stability and rapid convergence. Have you had luck with any sort of feed-forward?

[45Auto]

We're using a closed-loop system (encoder feeding a PID). The feed system is not allowed to advance a ball unless the wheel is within 1% of the target speed. For us, less than 1% makes for an exponentially increasing huge delay between shots, more than 1% shoots faster but has more variance in the impact point.

We're driving 2 8" old kit wheels with 2 775's on Banebot Cim-U-Laters (3.7 to 1).

The wheel spins up to speed and stabilizes from a stop within about 2 seconds. It takes about a second or so between shots for the wheel to re-stabilize at the target RPM and the feed to start advancing again.

It took us about a full weekend plus one full day we were out of school for Mardi-Gras to get it dialed in. The PID loop is VERY picky!

We've only tested with the KOP balls, we're expecting to have to tune it at the regional. Our driver panel is set up to allow tuning without having to go into the code.

Video of testing at the end of week 5:

http://www.youtube.com/watch?v=0hIPcPkDs7s&feature=youtu.be

[MrForbes]

Unfortunately I don't know enough about it to give you any more info...and I haven't had a chance to talk to our programmer or programming mentor since the competition

[Chris Hibner]

I plan to implement PID on our withheld launcher tonight. We installed encoders at the last minute to simply measure rate, and the wheel speed is stable within 10% of the average when driving them with a constant percent of battery voltage with a Victor.

Teams that have compensated with system voltage, what sort of stability have you achieved, and what algorithm did you use? My naive approach would be something like 12.0/V_battery*percentage, but a voltage-squared system was mentioned earlier. Would this provide a more stable speed across voltages?

Teams with closed-loop control, what sort of stability have you achieved? I can't imagine that it would be easy to tune PID for a flywheel for stability and rapid convergence. Have you had luck with any sort of feed-forward?

This is a good post with some nice pictures to help you tune: http://www.chiefdelphi.com/forums/showpost.php?p=1013377&postcount=34

Feed forward is good for improving dynamic response when you expect the setpoint to change rapidly or if your external disturbance change significantly (and predictably) with a change in set point. For a shooter the setpoint is pretty constant or will change slowly, and the disturbance doesn't vastly change with setpoint (yes, the air resistance changes with the square of speed, but the disturbance doesn't change direction like an arm that moves through vertical). We didn't find any need for feed forward. We found with the P&I tuned well the dynamic response was really good.

[IndySam]

Just as an aside, I wish you would change the title of the thread. there is no such thing as AM balls. AndyMark is just the venue FIRST chose to distribute the FIRST game pieces this year. There is no difference between the balls at competition and the balls distributed through AM.

[andreboos]

We're driving 2 8" old kit wheels with 2 775's on Banebot Cim-U-Laters (3.7 to 1).

The wheel spins up to speed and stabilizes from a stop within about 2 seconds. It takes about a second or so between shots for the wheel to re-stabilize at the target RPM and the feed to start advancing again.

Interesting, we're using exactly the same motors, wheels, and gear ratio for our launcher (although we manufactured our own gearboxes). However, when applying a constant voltage, it takes our launcher quite a few seconds (more than 5, at least) to spin up. Maybe our imprecisely machined gearboxes are the culprit here. Does your controller overshoot initially to start the wheels and then decrease to stabilize?

[jblay]

Just as an aside, I wish you would change the title of the thread. there is no such thing as AM balls. AndyMark is just the venue FIRST chose to distribute the FIRST game pieces this year. There is no difference between the balls at competition and the balls distributed through AM.

Well I think part of the original question was if the balls we get from andymark are different when they are fresh out of the box than the fresh ones at the competition because some people have said that this might be the case. This is not meant to slander andymark or anything but instead to see if it is part of the issue teams are having.

[AdamHeard]

A constant voltage applied will spinup slower than a proper closed loop control, and respond slower as well.

Lets say a 6V output results in roughly the steady state speed you desire, when you spinup (both initially and after a shot), you're running the motor at 6V.

Under closed loop control, when you spin up and are below your setpoint, you will get a voltage output higher than 6V (and likely the full ~12V for an appreciable amount of time), resulting in faster response.

[andreboos]

This is a good post with some nice pictures to help you tune: http://www.chiefdelphi.com/forums/showpost.php?p=1013377&postcount=34

Hmm, I tuned our drivetrain with P alone, and found that any amount of I caused significant oscillation. I suppose the I term would would cause an initial overshoot, which we'd want to spin a launcher up quickly, but we wouldn't want that in a drivetrain. I'll update with any progress tonight.

[45Auto]

Interesting, we're using exactly the same motors, wheels, and gear ratio for our launcher (although we manufactured our own gearboxes). However, when applying a constant voltage, it takes our launcher quite a few seconds (more than 5, at least) to spin up. Maybe our imprecisely machined gearboxes are the culprit here. Does your controller overshoot initially to start the wheels and then decrease to stabilize?

If you're applying the constant voltage that it takes to maintain the wheels at speed, then it is going to take a long time to ramp up. It takes very little power to maintain the speed.

Our system has no audible overshoot. Shooting speed is about 50% of max speed, so there is a big reserve of power available to bring the wheels up to speed. I haven't looked at the plots, but I would guess the control loop is ramping down from very near full power as the wheels come up to speed.

[Ether]

Feed forward is good for improving dynamic response when you expect the setpoint to change rapidly or if your external disturbance change significantly (and predictably) with a change in set point.

Feedforward can also be helpful when you are trying to control speed with a canned PID routine that was designed to control the position of a position-integrating plant.

[s_forbes]

It seems like the design of the system (gearing / wheel size / motors / compression / shooting distance) has a larger impact on spin up time than the control system does. Our light, low inertia system spins up in <1 second and is back up to speed after a shot in ~0.5 sec, and shots are pretty consistent at the moment with just a straight PWM value to each Jag. Old and new balls seem just as consistent. Video here (http://www.youtube.com/watch?v=J-tstY5SNw0) of shooter firing off a couple sets of 3 balls, mixed with old and new.

We're still looking into a closed loop control system for the shooter, encoders are already mounted and spitting out data.

It sure is neat to hear how everyone is tackling this problem, I'd like to hear more teams post their results!

[Ether]

Our light, low inertia system spins up in <1 second and is back up to speed after a shot in ~0.5 sec, and shots are pretty consistent at the moment with just a straight PWM value to each Jag.

What's your gear ratio (from motor to wheel) and what motor(s) are you using?

[Ether]

This is a good post with some nice pictures to help you tune: http://www.chiefdelphi.com/forums/showpost.php?p=1013377&postcount=34

These too:

http://vamfun.wordpress.com/2012/02/22/note-precomputing-pid-gains-for-a-velocity-shooter-using-polezero-placement/

http://vamfun.wordpress.com/2012/02/23/note-velocity-pid-loop/

[s_forbes]

What's your gear ratio (from motor to wheel) and what motor(s) are you using?


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!

[Jonathan Norris]

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...

[Ether]

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!

I forgot to ask: what diameter wheels are those?

[Chris Hibner]

Feedforward can also be helpful when you are trying to control speed with a canned PID routine that was designed to control the position of a position-integrating plant.




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.

[s_forbes]

I forgot to ask: what diameter wheels are those?


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. :)

[andreboos]

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.

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?

[Chris Hibner]

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?

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.

[Jared Russell]

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.

[Chris Hibner]

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.

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.

[Alpha Beta]

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

http://www.chiefdelphi.com/forums/showpost.php?p=1137469&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).

[pfreivald]

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).

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).

[AdamHeard]

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).

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.

[pfreivald]

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.

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.

[Ether]

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!

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.

[Chris Hibner]

... (using encoder counts from GetRate, not RPM):

Just in case anyone is interested, if you want to convert the GetRate output to RPM, do the following simple thing:

In Begin.vi where you OPEN your encoder, in the DistancePerCount input, wire in 60 / (EncoderCountsPerRev).

For example, if you are using a 32 count per revolution encoder, wire 1.875 (60/32 = 1.875) into the DistancePerCount input. Now you have RPM.

(The WPI detailed help lies - you don't get Hz from GetRate. Actually, you do get Hz if you don't wire anything into DistancePerCount.)

[pfreivald]

Just in case anyone is interested, if you want to convert the GetRate output to RPM, do the following simple thing:

In Begin.vi where you OPEN your encoder, in the DistancePerCount input, wire in 60 / (EncoderCountsPerRev).

For example, if you are using a 32 count per revolution encoder, wire 1.875 (60/32 = 1.875) into the DistancePerCount input. Now you have RPM.

(The WPI detailed help lies - you don't get Hz from GetRate. Actually, you do get Hz if you don't wire anything into DistancePerCount.)

Well, our RPM values are all wrong, then... but it doesn't matter, because we've calibrated ranges using raw encoder values. We don't care about units as long as it works!

[andreboos]

Well, our RPM values are all wrong, then... but it doesn't matter, because we've calibrated ranges using raw encoder values. We don't care about units as long as it works!

I was wondering how you were launching at .25 RPS :P

[pfreivald]

I was wondering how you were launching at .25 RPS :P

Methinks perhaps you misunderstood either way. Our shooter PID is accurate to within +/- .25 rps... It's difficult to launch balls at that speed!

[MrForbes]

Is that a written report? If so, could you ask him if he'd be willing to post it?


It was a science fair project....and it took Grand Prize :eek: so I guess we'll keep the feedback system on our robot

[Ether]

It was a science fair project....and it took Grand Prize

Well send him my congratulations !!!

[Bruceb]

pfreivald what pid are you using? Is it a canned one or all your own development? What are you using for RPM sensing?
Thanks
Bruce

[pfreivald]

pfreivald what pid are you using? Is it a canned one or all your own development? What are you using for RPM sensing?
Thanks
Bruce

Well, the whole thing abruptly stopped working this morning -- some weird electrical short. Last night on the practice field it was pretty darn consistent! :eek:

We were using the default LabView PID, with the kit/AndyMark encoders for feedback.

[bentjeans]

Just returned from my first competition. What a rush! Wanted to offer a few other points that I haven't caught mentioned in this thread:

1) Many teams have similar shooter designs. They all have some minimum spin up time before they can expect to deliver a good shot. Many then delay second shot for shooter to come back up to speed. This can kill your hybrid mode!! Watch some of the game videos... all three alliancemates fire off their first shot at the same time. The missed shots bouncing off are deflecting what might have been good shots.
1a) We put a toggle switch right on the driver station for whether or not we want a 4 second delay before shooting in autonomous mode. I think the only match where we did not use it, it was because none of our alliancemates had any hybrid shooting capabilities.
1b) Show up to the competition knowing as exactly as possible what time your balls are going to be shot so you can coordinate with alliancemates.

2) If you make it to the elimination rounds, they restock the field with ALL new balls! If your shooting in your last match went great, you're going to be sending them out of the field if you don't make an adjustment and are not a dumper or a catapult.
We were fortunate in two ways on this point. Firstly, we had a student that thought to ask if the balls would be changed. Secondly, we had easily adjustable RPM for shooting.