|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
paper: Shooter Wheel Speed Control
Last edited by Ether : 16-04-2012 at 14:15. Reason: this post not created not by me, but automatically by vBulletion when someone else posted a comment |
|
#2
|
|||||
|
|||||
|
Re: paper: Shooter Wheel Speed Control
An ingenious way of shooter motor control, definitely. Seems like this should have been the first thing our team thought of, over the glamor of PID!
My only question would be the precision of the "Bang Bang" speed controller over a well-tuned PID loop (how close one is the target speed). That would obviously depend on the "small overshoot" Ether talks about due to execution cycles only being ran so fast. Does anyone have data about how precise this speed control method can be? How fast would you want this cycle to run? I might be able to get some data on this precision with various execution cycle times by the end of the week on our practice robot. Last edited by kenavt : 15-04-2012 at 15:17. Reason: Actually make sense |
|
#3
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
The key is getting a noise-free speed signal. The paper discusses how to do this for speeds typical of shooter wheels. Quote:
|
|
#4
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
I've created a LabView version of this control system. It is written to match what Ether has in his original document and revisions.
I won't have the ability to actually test it for a couple of weeks. With this version you can set the execution cycle time quite easily because it runs in Periodic Tasks.vi. Without actually tessting, I think one key to making this work well is a large enough moment of inertia. Actual testing should reveal what "enough" is. I'm writing this on a moblie device, so I can't add my vi's but will edit this later today and add them when I'm at home. |
|
#5
|
|||||
|
|||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
I'm also worried about adversely affecting the motors with this sort of harsh treatment (fast sequence of full and no voltage). I might tune the voltage ramp to prevent this occurrence primarily, as well as preventing the Jags from shutting down. This will be something I discuss with the mechanical side of my team. Last edited by kenavt : 15-04-2012 at 16:53. |
|
#6
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
|
|
#7
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
But what about the controllers? The switching in the Victors and the Jags is slightly different. The Jags short the motor leads during the OFF portion of the PWM cycle, whereas the Vics open the leads. Since the Vic's switching method involves applying full voltage during the ON portion of the PWM cycle, and opening the leads during the OFF portion of the cycle, it seems to stand to reason that they are designed to handle that treatment. So commanding full volts and 0 volts alternately at 50Hz shouldn't be an issue. Anyone care to comment? On the other hand, the Jags short the motor leads during the OFF portion of the duty cycle. The only time the leads are open (other than for a fleeting moment during the PWM cycle to prevent shoot-through current) is if they are in coast mode and a zero command is given. I am assuming the Jags are built to handle that condition repeatedly. Perhaps someone with intimate knowledge of the design could comment. Because of the Jag's switching method (shorting the leads during the OFF portion of the PWM cycle), using a voltage ramp (for decreasing voltage) creates a problem for the bang-bang control method. If the voltage is ramped down (instead of being allowed to be commanded immediately to zero), it may cause dynamic braking when the wheel speed (and thus the motor speed) is high and the voltage is low but not zero. For the bang-bang method, you do not want dynamic braking. Quote:
Quote:
|
|
#8
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
The wheel we are using is a 4 inch diameter by 4 inch width wheel, made out of the hub of a plaction wheel and 4 inch diameter PVC pipe, so it should have significantly less inertia than the 6 or 8 inch wheels that many teams are using. |
|
#9
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
Would you mind posting the following additional information please: - what motor(s) - total gear ratio from motor to wheel. - Jag or Vic? - coast or brake mode? - voltage ramp rate? - what encoder model, and where mounted - what language - 1x 2x or 4x decoding? - Counter or Encoder class? - to measure RPM, are you measuring the time between consecutive counts, or are you dividing the counts by the delta time? - if dividing counts by delta time (see above item), how are you computing the delta time - what execution cycle update rate? - what wheel rpm value were you trying to control - please elaborate a bit more on the nature of the oscillations: amplitude, frequency, etc Last edited by Ether : 15-04-2012 at 20:30. |
|
#10
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
Wow, THANK YOU! I am no LabView Guru either so I had no idea there was that much variation in the timing of "Wait" loops. It definitely explains much of the noise issues we saw this year while measuring our shooters rate. So, based on the paper from 358 linked above, I modified my LabView version of the Bang-Bang control to use "Timed Structure". It has been refined to allow the enabling of a positive, adjustable, slew rate limiter. The limiter will maintain the same slew rate limit even if the loop timing is modified. It also has a tuneable IIR filter for the RPM reading, if necessary. This thread will not allow me to attach the files, so you can get them here. |
|
#11
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
Quote:
|
|
#12
|
|||||
|
|||||
|
Re: paper: Shooter Wheel Speed Control
This method is roughly equivalent to using a PID controller with Kp set to something very large (with Ki = Kd = 0) and the output limited to the range [0,1]. That might be the quickest way for many to implement this. We use a non-zero Ki and a feedforward term on our wheel, but then we have a very light shooter wheel assembly and don't rely on the "flywheel" aspect as much as many teams.
I would be interested in hearing whether teams find that this method works better when running at a 200Hz loop rate (the maximum update frequency for Jags) than at the ~50Hz "xxxPeriodic()" loop rate. Intuitively, I would think it would make a big difference. The built-in WPIlib PIDController classes make this easy to implement. Last edited by Jared Russell : 16-04-2012 at 08:19. |
|
#13
|
||||||
|
||||||
|
Re: paper: Shooter Wheel Speed Control
We switched to this type of speed control (thanks for the post, Martin).
One thing that we found that is important: do NOT filter the encoder signal. Let it come in without any averaging or filtering. Here are some reasons why: 1) The inertia of the wheel and the on/off method of controlling the motor will filter out the noise naturally (mechanically), so why bother. Your control will be precise as long as the noise is zero-mean. If the noise isn't zero-mean, then if you put in a filter your filter output will be offset by the noise mean anyway, so the filter doesn't buy you anything. 2) The noise on the encoder signal serves to give you more resolution on your output and gives you more precise speed control. That sounds like it's impossible, but it's true. What you ideally want is as many on/off transitions as possible. The noise helps this to happen. The effect is similar to the theory behind sigma delta modulators. 3) Unless your filter and your mechanical system are phase matched, your shooter speed will oscillate, much like what was described by John a few posts above. We experienced this first hand when we first tried this approach. I noticed the oscillation and said "duh! I forgot to remove the filter." We removed the filtering and voila - perfect speed control. One important note: if you use your shooter speed as an input to some sort of shooting logic (for example: don't allow the robot to shoot unless the speed is within a certain tolerance of the commanded speed), then you should definitely filter the signal going into the shooting logic. Just bypass the filter for your speed controller. Last edited by Chris Hibner : 16-04-2012 at 08:57. |
|
#14
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
We started to look into this. After about an hour we came up with a few tests. We have an average of +- 18.2 rpm change from the target rpm.
Raw data is in this white paper: http://www.chiefdelphi.com/media/papers/2667 |
|
#15
|
||||
|
||||
|
Re: paper: Shooter Wheel Speed Control
Quote:
Would you mind posting the following additional information please? - what motor(s) PS: You have some interesting noise on your sensor signal. Look at cells B57 & B58 for example. Last edited by Ether : 17-04-2012 at 10:58. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|