OCCRA
Go to Post “Hey, why are those numbers showing, it must be a game hint!” Listen, please – it’s not a game hint. Our game hints typically start with something like “This is a game hint!” - Frank - pwnageNick [more]
Home
Go Back   Chief Delphi > CD-Media > White Papers
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

photos

papers

everything



Shooter Wheel Speed Control

Ether

By: Ether
New: 04-12-2012 02:53 PM
Updated: 02-21-2014 08:38 AM
Total downloads: 1282 times


Control shooter wheel speed without PID.

Bang-Bang speed control for shooter wheel is simple, fast, accurate, stable, and requires little or no tuning.

.
.

Attached Files

  • pdf How Does It Work?

    How does it work.pdf

    downloaddownload file

    uploaded: 04-12-2012 04:01 PM
    filetype: pdf
    filesize: 93.85kb
    downloads: 904


  • pdf Shooter Wheel Speed Control (Rev_F 2/10/2013)

    Shooter Wheel Speed Control (rev F).pdf

    downloaddownload file

    uploaded: 02-10-2013 04:17 PM
    filetype: pdf
    filesize: 154.67kb
    downloads: 376



Recent Downloaders

  • Guest

Discussion

view entire thread

Reply

04-15-2012 02:12 PM

kenavt


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



04-15-2012 03:26 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by kenavt View Post
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?
Kudos to Martin for bringing this up. He reports +/- 15 RPM. I've been told of similar results using a Victor.

The key is getting a noise-free speed signal. The paper discusses how to do this for speeds typical of shooter wheels.

Quote:
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.
Excellent. Please do post any data you generate. If you'd like a second set of eyes to look at your code, PM me and I'd be more than happy to take a look and provide feedback.




04-15-2012 03:33 PM

billbo911


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



04-15-2012 03:50 PM

kenavt


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
Kudos to Martin for bringing this up. He reports +/- 15 RPM. I've been told of similar results using a Victor.

The key is getting a noise-free speed signal. The paper discusses how to do this for speeds typical of shooter wheels.

Excellent. Please do post any data you generate. If you'd like a second set of eyes to look at your code, PM me and I'd be more than happy to take a look and provide feedback.
With our current PID loop, we're achieving around +/- 5 RPM with Jaguars. It would be great to achieve that sort of precision with this method, but with a faster ramp-up after shots or when first starting up the shooter.

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.



04-15-2012 03:51 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by billbo911 View Post
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.
I'm not a LabVIEW guru, so I can't say for sure, but I think you've captured the main idea. I do have one suggestion though: read Team 358's document Timing Is Everything. For a clean speed signal, consider replacing that Wait with a Timed Structure.




04-15-2012 04:30 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by kenavt View Post
I'm also worried about adversely affecting the motors with this sort of harsh treatment (fast sequence of full and no voltage).
You do realize that with their PWM output, the Victors are applying full and no voltage at 150Hz to the motors all the time, right? ...I wouldn't worry about the motors.

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:
I might tune the voltage ramp to prevent this occurrence primarily, as well as preventing the Jags from shutting down.
Adding excessive voltage ramping may adversely affect the bang-bang's dynamic response and accuracy.

Quote:
This will be something I discuss with the mechanical side of my team.
I think it's an electronic issue, not mechanical.





04-15-2012 05:10 PM

John


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by billbo911 View Post
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.
During the season we used PID (with a feed-forward and other modifications) to control our shooter, giving us our speed to +/- 20 RPM (out of around 4000 max). Yesterday I tried to implement the "bang-bang" controller in order to compare it to our PID loop. It seems our shooter does not have sufficient inertia to maintain a stable speed, as it oscillates uncontrollably.

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.



04-15-2012 06:56 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by John View Post
Yesterday I tried to implement the "bang-bang" controller in order to compare it to our PID loop. It seems our shooter does not have sufficient inertia to maintain a stable speed, as it oscillates uncontrollably.
That doesn't sound right at all. Something is amiss.

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




04-15-2012 07:07 PM

billbo911


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
I'm not a LabVIEW guru, so I can't say for sure, but I think you've captured the main idea. I do have one suggestion though: read Team 358's document Timing Is Everything. For a clean speed signal, consider replacing that Wait with a Timed Structure.


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



04-15-2012 10:23 PM

John


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
- what motor(s)

- total gear ratio from motor to wheel.

- Jag or Vic?

- coast or brake mode?

- voltage ramp rate?
2 FP 0968-9015 motors. About a 3:1 reduction. Victors, coast. No voltage ramp (Does it need one?).
Quote:
- 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
This might be the problem. We are using a light sensor and a single strip of reflective tape to determine rate (one count per revolution). We used the Counter (labview) to determine rate by measuring time between counts. The execution rate was 20ms. I tried commanding wheel speeds between 2600 and 3600 rpm (the extremes of our shooter during competition). 20ms*(2600rpm * (1minute/60000ms)) = .867 rev/cycle. If the speed updates less often than the power command, would that throw it off? Thanks



04-16-2012 07:17 AM

Jared Russell


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



04-16-2012 07:52 AM

Chris Hibner


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



04-16-2012 09:55 PM

~Cory~


Unread 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



04-16-2012 10:03 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by ~Cory~ View Post
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
Thank you for posting the data.

Would you mind posting the following additional information please?
- what motor(s)

- total gear ratio from motor to wheel(s).

- what type and diameter wheel(s)?

- Jag or Vic?

- coast or brake mode?

- voltage ramp rate? symmetric or up only?

- 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

- encoder signal not filtered?

- what execution cycle update rate?


PS: You have some interesting noise on your sensor signal. Look at cells B57 & B58 for example.




04-17-2012 12:17 PM

nighterfighter


Unread Re: paper: Shooter Wheel Speed Control

Hi all, I was the programmer for 1771, and I played around with this method a lot. (Differing ramp rates, update times, etc.)

Our hardware set up was originally 1 FP motor in CIMulator to power the wheel.

The code didn't run in the main tele-op loop, I had it run in its own task. It was set to read the encoder value and change the motor voltage every .05 seconds.

I had the CANJaguar voltage ramp rate set to 110 volts per second.

An important thing that I didn't see mentioned, was WHERE the encoder got read.

We plugged the encoder directly into the Jaguar, and used the CANJaguar's GetSpeed() function.

We believe that having it go directly to the Jaguar, NOT the cRIO's FPGA, allowed it to be read faster. This may or may not have been true.

Of course all these values will change based on your shooter wheel.

As for the RPM consistancy-
When reading the values, we saw an average of 15 RPM difference from our set point for the RPM. If we had more time to dedicate to JUST tuning that, I feel we could have gotten a little bit more accuracy on that.



04-17-2012 01:04 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
When reading the values, we saw an average of 15 RPM difference from our set point for the RPM. If we had more time to dedicate to JUST tuning that, I feel we could have gotten a little bit more accuracy on that.
You didn't mention, but I assume you had the Jag set for coast mode, not brake, correct?

If you get a chance, try getting rid of the voltage ramp*, and increase the update rate to 20ms instead of 50ms.

Quote:
We believe that having it go directly to the Jaguar, NOT the cRIO's FPGA, allowed it to be read faster.
I would think that reading the FPGA would be much faster than talking to the Jag via CAN bus. Does anyone have numbers for this?



*unless you need the voltage ramp to keep the Jag from shutting down at spinup. If so, try turning off the Jag's voltage ramp and put a ramp in the cRIO instead, and make it active only in the increasing direction, and only for speeds below the necessary spinup speed.



04-17-2012 01:20 PM

billbo911


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
If you get a chance, try getting rid of the voltage ramp*, and increase the update rate to 20ms instead of 50ms.


[i]
*unless you need the voltage ramp to keep the Jag from shutting down at spinup. If so, try turning off the Jag's voltage ramp and put a ramp in the cRIO instead, and make it active only in the increasing direction, and only for speeds below the necessary spinup speed.
I can easily see that setting the "Slew Rate Limiter" to only apply in a positive direction when the wheel is below a certain RPM could have a big benefit.

With the largest current loads taking place in the first few loops when starting from 0 RPM, that is when the Jag. would shut down. So, if the limiter only applied when the wheel was below, say 100 RPM, then you would always get full power pulses to maintain the desired RPM.
Easy enough to do in LabView. I'll update my .vi's and have them posted shortly!



04-17-2012 01:27 PM

nighterfighter


Unread Re: paper: Shooter Wheel Speed Control

Yes, it was coast mode, both on the jumper, and it is set to coast mode in our code.

When we didn't have a ramp rate, we found that our RPM was less consistent, but I can try again. Although,from what we noticed, there was no ramp down, only ramping up.

As for the CAN vs FPGA, we aren't sure. We used 2CAN, as we read that it its much faster than the serial form of CAN. And this shouldn't matter but it was th last jaguar in our chain. (The sixth jaguar)

All of this was done with a single motor. At the north Carolina regional, we added a second motor and jag. We had the same code, and would justave the output to the new jaguar.
We found that it became less consistent, but after we tweaked the values, we got it tuned back. One thing we did try was having the second motor in brake mode, this worked and controlled the RPM nicely, but it got too hot for our liking.



04-17-2012 01:30 PM

nighterfighter


Unread Re: paper: Shooter Wheel Speed Control

As for the biggest loads being in the initial spin up, I made it where we always spun at a minimum of 500 RPM, so it would never have to pull too much current again.



04-17-2012 01:50 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
As for the biggest loads being in the initial spin up, I made it where we always spun at a minimum of 500 RPM, so it would never have to pull too much current again.
Are you talking about the bang-bang controller here? And are you saying that you did not set the motor voltage to 0, but rather set it to some small non-zero value, even when at the control point?




04-17-2012 02:01 PM

nighterfighter


Unread Re: paper: Shooter Wheel Speed Control

Sorry, should have been more specific.

I told the set point to be 500 RPM, using the bang bang controller.

For ramping down, I told it to go to zero. We never noticed a ramp down, it went straight to zero.



04-17-2012 02:01 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by nighterfighter View Post
As for the CAN vs FPGA, we aren't sure. We used 2CAN, as we read that it its much faster than the serial form of CAN.
Just to be clear: CAN is a serial protocol. 2CAN also uses serial protocols (Ethernet on the cRIO side and CAN on the other).

What you meant is that Ethernet (2CAN) is faster than the RS232 connection from the cRIO to the Jag. No argument there.

But I'd bet a hundred bucks that reading the FPGA is faster than querying the Jag for speed.

Quote:
One thing we did try was having the second motor in brake mode ... but it got too hot for our liking.
That's one reason why the paper says don't use brake mode.




04-17-2012 02:03 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by nighterfighter View Post
We never noticed a ramp down, it went straight to zero.
How could you tell?




04-17-2012 02:12 PM

nighterfighter


Unread Re: paper: Shooter Wheel Speed Control

The 2CAN Web page showed it drop to zero throttle. And the jaguar leds didn't blink, just went straight to yellow.

Yes that's what I meant with the 2CAN. You are probably correct about the FPGA thing. I think another reason we decided to have the Jag report it was due to the encoder problems with the FPGA from previous years.

And no arguments about the brake mode, we were getting desperate...



04-17-2012 02:50 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by nighterfighter View Post
The 2CAN Web page showed it drop to zero throttle.
I'm not familiar with the "2CAN Web page". To what does the pronoun "it" in the sentence above refer? If it's the motor_command (throttle), then yes it drops to zero. The ramping is done on the Jag's output.

Quote:
And the jaguar leds didn't blink, just went straight to yellow
If the ramp rate is 63ms to go from 12v to zero (the Jag default), I don't know if you'd even see it blink.




04-17-2012 02:55 PM

nighterfighter


Unread Re: paper: Shooter Wheel Speed Control

The 2CAN has a web page interface that displays each Jaguar, lets you set a new CAN ID, and displays the output of the throttle, voltage being output, temperature, current, and a few other things.

I was referring to the Jaguar itself, yes.

I have noticed the blinking when ramping up, but not ramping down. It might be it is changing too fast I suppose.

I think we have an old oscilloscope lying around, I can hook the output to that if it would help, (assuming I can find it).



04-17-2012 04:32 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by billbo911 View Post
I can easily see that setting the "Slew Rate Limiter" to only apply in a positive direction when the wheel is below a certain RPM could have a big benefit.

With the largest current loads taking place in the first few loops when starting from 0 RPM, that is when the Jag. would shut down. So, if the limiter only applied when the wheel was below, say 100 RPM, then you would always get full power pulses to maintain the desired RPM.
Easy enough to do in LabView. I'll update my .vi's and have them posted shortly!
Here's the logic I had in mind:

Code:
if (measured_speed >= target_speed) motor_command = 0.0;

else if (measured_speed >= spinup_speed) motor_command = 1.0;

else motor_command = low_command;
Make "spinup_speed" as low as possible and "low_command" as high as possible, without causing the Jag to shutdown.




04-17-2012 05:20 PM

billbo911


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
Here's the logic I had in mind:

Code:
if (measured_speed >= target_speed) motor_command = 0.0;

else if (measured_speed >= spinup_speed) motor_command = 1.0;

else motor_command = low_command;
Make "spinup_speed" and "low_command" as high as possible.


Again, this would be very easy to implement in LabView.

Here's my thoughts on why I didn't jump on this as an option:
1) There can easily be periods of 20+ seconds when the shooter wheel is not being used in a match. During that time, you are just consuming power, even though it may be a small amount, that may be needed later in a match.

2) Depending on where the shooter is in relation to a camera, if you use it as we did, the extra vibration the shooter may be creating can interfere in the imaging process, thus your aim.

3) If a slew rate limiter is used below a certain threshold, then you avoid the possibility of tripping the over-current in the Jag. (Not an issue with a Victor.)

If there is enough interest, I will most certainly create a version that follows the minimum continuous RPM model. Who knows, I might just become a fan of it too.



04-17-2012 05:44 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by billbo911 View Post
Again, this would be very easy to implement in LabView.

Here's my thoughts on why I didn't jump on this as an option:
1) There can easily be periods of 20+ seconds when the shooter wheel is not being used in a match. During that time, you are just consuming power, even though it may be a small amount, that may be needed later in a match.

2) Depending on where the shooter is in relation to a camera, if you use it as we did, the extra vibration the shooter may be creating can interfere in the imaging process, thus your aim.

3) If a slew rate limiter is used below a certain threshold, then you avoid the possibility of tripping the over-current in the Jag. (Not an issue with a Victor.)

If there is enough interest, I will most certainly create a version that follows the minimum continuous RPM model. Who knows, I might just become a fan of it too.
I should have been clearer:

The "low_command" is a tuning constant, not the target speed, and was not intended to be so low that it tops out at a speed below the "spinup_speed". "low_command" should be as high as possible (without causing the motor controller to shut down), and at the very least, high enough that it briskly accelerates up to (and beyond) spinup_speed, at which point the full voltage is applied.

Many shooter wheel setups can handle application of full voltage to the motor even at zero RPM, but some can't. It's a function of the gear ratio and the wheel inertia and the motor being used. For such setups, simply set spinup_speed=0.0

The code I posted was for those shooter setups that can't handle a full 12 volts being applied at zero RPM, but could, for example, handle, say, 8 volts at zero RPM and 12 volts at 1000 RPM. For that example, you would set spinup_speed to 1000 RPM and low_command to 8 volts. Simple, and gets the job done.

With the code I posted, the minimum continuous RPM is simply commanded as the target speed by each team's software to whatever they want it to be, and the code I posted will bang-bang regulate at that speed. That target speed can be zero if the team so desires.


For really finicky setups (e.g. high inertia wheel, not much gear ratio, high stall current motor), you could always add a third "else" statement:

Code:
if (measured_speed >= target_speed) motor_command = 0.0;

else if (measured_speed >= spinup_speed) motor_command = 1.0;

else if (measured_speed >= medium_speed) motor_command = medium_command;

else motor_command = low_command;





04-17-2012 06:26 PM

billbo911


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
I should have been clearer:

The "low_command" is a tuning constant, not the target speed, and was not intended to be so low that it tops out at a speed below the "spinup_speed". "low_command" should be high enough that it briskly accelerates up to (and beyond) spinup_speed, at which point the full voltage is applied.

Many shooter wheel setups can handle application of full voltage to the motor even at zero RPM, but some can't. It's a function of the gear ratio and the wheel inertia and the motor being used. For such setups, simply set spinup_speed=0.0

The code I posted was for those shooter setups that can't handle a full 12 volts being applied at zero RPM, but could, for example, handle, say, 8 volts at zero RPM and 12 volts at 1000 RPM. For that example, you would set spinup_speed to 1000 RPM and low_command to 8 volts. Simple, and gets the job done.

With the code I posted, the minimum continuous RPM is simply commanded as the target speed by each team's software to whatever they want it to be, and the code I posted will bang-bang regulate at that speed. That target speed can be zero if the team so desires.


For really finicky setups (e.g. high inertia wheel, not much gear ratio), you could always add a third "else" statement:

Code:
if (measured_speed >= target_speed) motor_command = 0.0;

else if (measured_speed >= spinup_speed) motor_command = 1.0;

else if (measured_speed >= medium_speed) motor_command = medium_command;

else motor_command = low_command;



Got it. So, in essence, you want the absolute maximum acceleration possible, for the particular shooter design, that it can handle without tripping the over-current.

With the version I added today, you can set the trip point for low to high acceleration as well as the rate of slew rate limiter. By tuning these two, you can achieve almost exactly what you are describing. The only difference is the start up voltage will be a ramp, with an adjustable slope, instead of a step from 0v. Granted, it is not the absolute fastest acceleration you can get, but I doubt the differences will be noticeable in actual performance. You will see it on a scope, but that's pretty much it. I'm guessing a only few millisecond difference between the two designs from 0 RPM to target RPM in the 2500-4000 range.



04-17-2012 09:11 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

I'm interested in teams claiming +/- 15 rpm accuracy.

We've implemented robust PID control, and today implemented bang-bang control as a second option.

We tried 4 different high speed encoders, 2 bourn, 1 grayhill, and 1 honeywell. The noise in our 'best' situation (completely unfiltered running off the get rate from the encoder, encoder set to 1x decoding, get rate in a timed loop of 10ms) was +/- 60 RPM.

The best the bang-bang loop could do completely unfiltered was around +/- 100 RPM.

The best the PID loop could do completey unfiltered was arond +/- 80 RPM.

The PID loop spins up in 3 seconds. The bang-bang in about 1.5 seconds.

I'm curious what teams are using to measure their system to gain +/- 15 RPM accuracy without noise problems.

Should we be using an IIR or moving average filter to filter the incoming rate from the encoder to minimize noise effect on the bang-bang? (That's the geekiest sentence I've typed in a long time).



04-17-2012 09:17 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
Thank you for posting the data.

Would you mind posting the following additional information please?
- what motor(s)

- total gear ratio from motor to wheel(s).

- what type and diameter wheel(s)?

- Jag or Vic?

- coast or brake mode?

- voltage ramp rate? symmetric or up only?

- 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

- encoder signal not filtered?

- what execution cycle update rate?


PS: You have some interesting noise on your sensor signal. Look at cells B57 & B58 for example.


Is there any specific reason to use a counter class rather than encoder class?



04-17-2012 09:28 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
Is there any specific reason to use a counter class rather than encoder class?
For the shooter wheel application, you don't need the extra channel for direction. Less wiring, frees up a channel on the DS.

Just curious: did you try using the encoder as described on pages 1 & 2 in revA of the paper?




04-17-2012 09:52 PM

billbo911


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
I'm interested in teams claiming +/- 15 rpm accuracy.

We've implemented robust PID control, and today implemented bang-bang control as a second option.

We tried 4 different high speed encoders, 2 bourn, 1 grayhill, and 1 honeywell. The noise in our 'best' situation (completely unfiltered running off the get rate from the encoder, encoder set to 1x decoding, get rate in a timed loop of 10ms) was +/- 60 RPM.

The best the bang-bang loop could do completely unfiltered was around +/- 100 RPM.

The best the PID loop could do completey unfiltered was arond +/- 80 RPM.

The PID loop spins up in 3 seconds. The bang-bang in about 1.5 seconds.

I'm curious what teams are using to measure their system to gain +/- 15 RPM accuracy without noise problems.

Should we be using an IIR or moving average filter to filter the incoming rate from the encoder to minimize noise effect on the bang-bang? (That's the geekiest sentence I've typed in a long time).
Ether pointed this out to me. Using the "Wait" timing loops is not as reliable for timing events as you might think. Read this paper call Timing is everything by team 358.
I truly believe you can get much more reliable rate control simply by switching to a "Timed Structure" instead of a "Wait" loop.



04-17-2012 10:15 PM

Chris Hibner


Unread Re: paper: Shooter Wheel Speed Control

Tom,

We're using Victor speed controllers and running the controller in a 30 ms timed loop. We are using a high-quality internal ball-bearing encoder (can't remember the brand), 32 counts per rev, 1x decoding. No filtering on the encoder signal going into the bang-bang controller.

Our shooter logic uses a single pole IIR filter at about 0.5 Hz on the encoder signal. The output of the IIR filter shows noise of about +/- 15-20 RPM. The mean appears to be right at our desired speed. Our practice robot with a really bad gearbox was about 50 RPM less than the desired speed.

I haven't done a data log to actually calculate the mean and noise level with our competition robot, but it looks really good. Our shooter logic requires the filtered shooter speed to be within 30 RPM for more than 4 consecutive samples before we'll shoot a ball. We do have data logging for each shot and shooter speed has not been an issue for delaying shots (aim is usually the long lead time).

The biggest upside we found when switching to this control method is getting the shooter to slow quickly. When we were using PID, shooter speed was often delaying shots, especially if we enabled the shooter and then moved closer to the goal. The I term was always adding some power to the motor which delayed the slow down time. The bang-bang controller completely cuts the power in this case so the slow down can't really be any faster, unless you apply negative power (which probably isn't a great idea).



04-17-2012 10:22 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Chris Hibner View Post
The bang-bang controller completely cuts the power in this case so the slow down can't really be any faster, unless you apply negative power (which probably isn't a great idea).
... or use brake mode instead of coast mode. This will slow you down real quick. But things may get too hot.




04-17-2012 10:34 PM

Chris Hibner


Unread Re: paper: Shooter Wheel Speed Control

Ether makes a good point. You'll probably also find your final speed to be less than your desired speed if you use brake mode (see my comment above on our practice robot with the bad gearbox - extra friction caused the actual speed to be less than the desired speed).

A couple of more things to note:

1) Originally, we accidentally hooked up the output of our IIR filter to the bang-bang controller "actual speed" input. The results were not very good. The shooter speed oscillated quite a bit. When you think about it, the oscillations make sense: the phase delay of the IIR filter made the controller stay at 1.0 for too long even if the actual instantaneous speed dictated that the power be 0.0 (or vice versa).

2) Speed controller resolution: Consider that a Victor speed controller has 254 discrete output states (two states are reserved). If the top speed of your shooter is about 5000 RPM (for a shot from the bridge), the best resolution you can do with a constant power command is about 20 RPM (imagine if your PID controller output a very nice steady PWM command). However, if your PWM command dithers the right amount, you can gain resolution on your shooter speed. Don't believe me? Just consider that we're getting tons of resolution to control various speeds just based on commanding 1's and 0's to the power. (I actually submitted a white paper on this topic a number of years ago, which makes me especially upset with myself that I didn't think of this type of controller until Martin mentioned it. Grrr.). Anyway, that extra dithering of the output is why I advocate not filtering the encoder signal input to the bang-bang controller.



04-17-2012 10:39 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Chris Hibner View Post
Tom,

We're using Victor speed controllers and running the controller in a 30 ms timed loop. We are using a high-quality internal ball-bearing encoder (can't remember the brand), 32 counts per rev, 1x decoding. No filtering on the encoder signal going into the bang-bang controller.

Our shooter logic uses a single pole IIR filter at about 0.5 Hz on the encoder signal. The output of the IIR filter shows noise of about +/- 15-20 RPM. The mean appears to be right at our desired speed. Our practice robot with a really bad gearbox was about 50 RPM less than the desired speed.

I haven't done a data log to actually calculate the mean and noise level with our competition robot, but it looks really good. Our shooter logic requires the filtered shooter speed to be within 30 RPM for more than 4 consecutive samples before we'll shoot a ball. We do have data logging for each shot and shooter speed has not been an issue for delaying shots (aim is usually the long lead time).

The biggest upside we found when switching to this control method is getting the shooter to slow quickly. When we were using PID, shooter speed was often delaying shots, especially if we enabled the shooter and then moved closer to the goal. The I term was always adding some power to the motor which delayed the slow down time. The bang-bang controller completely cuts the power in this case so the slow down can't really be any faster, unless you apply negative power (which probably isn't a great idea).
That explains a decent amount.

We've been using the unfiltered signal, which is fairly noisy. Filtering that should bring it more inline. I'll try that tomorrow with our moving average filter and try a bang-bang again.

Our encoders are all 128 counts per revolution, but they are geared so that we get 55 counts per shooter revolution.

We are using the timed structure set at a 10ms loop rate in periodic tasks (not a while loop with a wait). We did not see much of an improvement moving to a timed structure because our cpu utilization is usually around 70% and our periodic loops have been running fairly consistently (we flag an error message on our driverstation LCD whenever they get too far out of whack).

To give you an idea, we were using a check of +/- 100 rpm for 4 consecutive counts and still getting good distance accuracy from the key. That tells me that our actually speed is fairly accurate, but the noise is masking it. The filter should help.



04-17-2012 10:42 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Chris Hibner View Post
(I actually submitted a white paper on this topic a number of years ago, which makes me especially upset with myself that I didn't think of this type of controller until Martin mentioned it. Grrr.)
I feel your pain. I wrote a paper on it when I was in grad school back in the early '70s.




04-18-2012 12:27 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control


For a setup with the shooter wheel speed sensor (encoder) plugged directly into the Jag, could some please estimate (or better yet provide test data for) the elapsed times (t1, t2, t3) for the following sequence of events?

a) at t=0, send a request to the Jag via CAN for a speed signal
b) at t=t1, receive the requested speed signal from the Jag via CAN
c) at t=t2, send a new command (based on the speed signal) to the Jag via CAN
d) at t=t3, the Jag receives the new command



04-18-2012 02:17 PM

mjcoss


Unread Re: paper: Shooter Wheel Speed Control

We have the setup that you're looking for, and I'd be willing to run the test. I'm just not sure how to collect the test data. Do you know if the elapse time for a command is just when the "SetSpeed()" function returns?

So that
t1 = GetClock();
jag->SetSpeed(500);
t2 = GetClock();
elapse time = t2 -t1

Or are you looking for something more complicated? We're currently running the PID loop on the Jaguar, and I'd wish I'd seen this earlier. I might have changed what we were doing as this looks like it might get us what we wanted without the headaches of the PID controls on the Jaguars.


Quote:
Originally Posted by Ether View Post

For a setup with the shooter wheel speed sensor (encoder) plugged directly into the Jag, could some please estimate (or better yet provide test data for) the elapsed times (t1, t2, t3) for the following sequence of events?
a) at t=0, send a request to the Jag via CAN for a speed signal
b) at t=t1, receive the requested speed signal from the Jag via CAN
c) at t=t2, send a new command (based on the speed signal) to the Jag via CAN
d) at t=t3, the Jag receives the new command



04-18-2012 03:01 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by mjcoss View Post
So that
t1 = GetClock();
jag->SetSpeed(500);
t2 = GetClock();
elapse time = t2 -t1
Thanks for the offer.

No, the elapsed times I am looking for are:

dt1: how long does it take from the time you ask the Jaguar what the motor speed is, to the time you read the answer that comes back

dt2: how long does it take from the time you read the answer, to the time your code sends a new command to the Jag

dt3: how long does it take from the time you send a new command to the Jag, to when it receives the command.

If you aren't doing all three operations in the same execution cycle, please mention that too.

If you aren't reading the speed from the Jag and sending a new command based on that speed, you would have to add that code to get what I'm looking for.




04-18-2012 05:07 PM

mjcoss


Unread Re: paper: Shooter Wheel Speed Control

The question is how to get at that information and what kind of accuracy are you looking for. Note that we are using C++, so ...

GetSpeed() returns the current measured encoder speed as reported from the Jaguar. So the total round trip time can be gotten from grabbing the time before and after the call. This is, of course, not very fine grain and includes the time spent being packaged in an Ethernet frame, going to the 2CAN, being unpackaged, put on the CAN bus, out to the Jaguar, and back again.

dt2 is a bit trickier. We aren't using your speed control method but rather are running the PID loop on the Jaguar. Each time through our TeleopPeriodic loop, we update the set point. Our periodic loop will do some work if no packet arrives from the driver station, but for the most part we update based on the arrival of new data from the driver station. We don't check to see what the set point currently is, we just reset it to the requested value.

dt3 is even trickier, if not unknowable. Again we could use the total round trip time of the Set() command which is used to register the current set point, but that includes the time to the Jaguar, and the return ack across the CAN bus, and thru the 2CAN and back up the ethernet stack and to the CANJaguar module.

Finally there is a lot of checking that I've added to around the Set() operation. Every Set() is followed by a CAN bus message requesting the fault status of the Jaguar, and then a CAN bus message requesting the PowerCycled flag. If a brown out occurred then the Jaguar configuration is reloaded.

When I get a chance I think I'll implement you're speed controller and see how it does relative to running the PID on the Jaguars as we currently are doing.


Quote:
Originally Posted by Ether View Post
Thanks for the offer.

No, the elapsed times I am looking for are:

dt1: how long does it take from the time you ask the Jaguar what the motor speed is, to the time you read the answer that comes back

dt2: how long does it take from the time you read the answer, to the time your code sends a new command to the Jag

dt3: how long does it take from the time you send a new command to the Jag, to when it receives the command.

If you aren't doing all three operations in the same execution cycle, please mention that too.

If you aren't reading the speed from the Jag and sending a new command based on that speed, you would have to add that code to get what I'm looking for.




04-18-2012 08:24 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
GetSpeed() returns the current measured encoder speed as reported from the Jaguar. So the total round trip time can be gotten from grabbing the time before and after the call. This is, of course, not very fine grain and includes the time spent being packaged in an Ethernet frame, going to the 2CAN, being unpackaged, put on the CAN bus, out to the Jaguar, and back again.
This is what I'm looking for, because this elapsed time (or perhaps half of it) causes phase lag in the process variable. If you could run this one test it would be helpful.




04-18-2012 08:40 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

Success in one area, and failure in another.

We've changed where our encoder is mounted and subsequently doubled the count rate. Our biggest problem appears to be the use of the Labview (and therefore WPI) Encoder getrate to get the instantaneous rate. The getrate returns horribly noisy data, presumably because of a very short measurement period.

We now calculate our own getrate, and that has completely smoothed the encoder input signal. This, in turn has smoothed both our PID and our bang-bang. We can switch back and forth with the click of the button. The best tuning of the bang-bang (combination of filter and slew rate) nets us approximately +/- 60 RPM. Our PID is around +/-25, which I'm very happy with. The bang-bang gets up to speed is about 2.0 seconds. The PID is about 2.5 seconds.

We do still see the same slow drop off from a high speed to a low speed with PID. However, we don't ever have an issue with that because once the fire button is pushed the drivetrain is zeroed and the pneumatic brakes are engaged. That's the polite reminder to the driver not to try driving while we're shooting

This is a 400% improvement in our RPM repeatability from shot to shot. We'll see if it translates on the field at nationals. Thanks to Ether and Chris for keeping the ideas flowing.



04-18-2012 09:39 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
Our biggest problem appears to be the use of the Labview (and therefore WPI) Encoder getrate to get the instantaneous rate. The getrate returns horribly noisy data, presumably because of a very short measurement period.
http://www.chiefdelphi.com/forums/sh....php?p=1122535

http://www.chiefdelphi.com/forums/sh...0&postcount=35




04-18-2012 10:33 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

Interesting. Even though I'm on the forums almost every day, I still miss things. I hadn't seen those posts.

At least we understand it. Better now than a week from now, that's for sure.



04-19-2012 12:00 AM

billbo911


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
Success in one area, and failure in another.

We've changed where our encoder is mounted and subsequently doubled the count rate. Our biggest problem appears to be the use of the Labview (and therefore WPI) Encoder getrate to get the instantaneous rate. The getrate returns horribly noisy data, presumably because of a very short measurement period.

We now calculate our own getrate, and that has completely smoothed the encoder input signal. This, in turn has smoothed both our PID and our bang-bang. We can switch back and forth with the click of the button. The best tuning of the bang-bang (combination of filter and slew rate) nets us approximately +/- 60 RPM. Our PID is around +/-25, which I'm very happy with. The bang-bang gets up to speed is about 2.0 seconds. The PID is about 2.5 seconds.

We do still see the same slow drop off from a high speed to a low speed with PID. However, we don't ever have an issue with that because once the fire button is pushed the drivetrain is zeroed and the pneumatic brakes are engaged. That's the polite reminder to the driver not to try driving while we're shooting

This is a 400% improvement in our RPM repeatability from shot to shot. We'll see if it translates on the field at nationals. Thanks to Ether and Chris for keeping the ideas flowing.
Tom,
Thanks for posting this. Even if it helps no-one else, it does validate the approach I took with the vi's I created.
In them, I calculate the rate based off the counts/period. The period is fixed by the Timed Structure, so the measurements should be consistent.

By comparison, the WPI GetRate appears to be calculating the rate based on the period of two pulses.

Based on the shooter we currently are using:
360 counts/rev.
Sampled every 10ms.

180 counts translates to 3000 RPM.

That means 180 pulses are used to determine the rate instead of just two. The variability of those 180 pulses is averaged out over 10ms vs. the variability of just two pulses in one sample. It makes perfect sense that calculating your rate is a less noise prone process.



04-19-2012 09:37 AM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

We did modify your slew rate calculator from the labview .vi. Most specifically, we modify the last output value with the max change amount, not the input value. I believe that may have been an error in your code.

Here's our version:
http://www.chiefdelphi.com/media/papers/download/3412



04-19-2012 10:38 AM

billbo911


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
We did modify your slew rate calculator from the labview .vi. Most specifically, we modify the last output value with the max change amount, not the input value. I believe that may have been an error in your code.

Here's our version:
http://www.chiefdelphi.com/media/papers/download/3412
An error in my code??? Say it ain't so!

You are correct, that change would make a BIG difference. Thanks for spotting it and correcting it. I'll remove my incorrect version to prevent others from having issues.

BTW, I have uploaded a newer version that completely removes the slew rate limiter and replaces it with a two step, low and full power, version. This new version will allow tuning that both prevents the Jag over current AND allows absolute maximum acceleration from 0 RPM to target RPM.

If you have an opportunity to test it, I would love to hear your take on it.
I will not be able to test it on our robot for another few days.



04-19-2012 12:13 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
The best tuning of the bang-bang (combination of filter and slew rate) nets us approximately +/- 60 RPM.
Try this: get rid of the speed filter*, get rid of the time-based slew around the control point, and put all three of these operations in the 10ms Timed Structure, in this order, with no other code:
1) read encoder counts from FPGA

2) compute (unfiltered) speed

3) send either 0.0 or 1.0 to motor controller** depending on whether unfiltered speed is above or below the setpoint

* you can filter the speed for purposes of display or logging or control of other logic (such as when to shoot), but don't use the filtered speed for the bang-bang logic

** get rid of all possible overhead in the library, like "motor safe" etc.





04-19-2012 12:54 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
Try this: get rid of the speed filter*, get rid of the time-based slew around the control point, and put all three of these operations in the 10ms Timed Structure, in this order, with no other code:
1) read encoder counts from FPGA

2) compute (unfiltered) speed

3) send either 0.0 or 1.0 to motor controller** depending on whether unfiltered speed is above or below the setpoint

* you can filter the speed for purposes of display or logging or control of other logic (such as when to shoot), but don't use the filtered speed for the bang-bang logic

** get rid of all possible overhead in the library, like "motor safe" etc.



Reading the encoder with the getrate from the labview getrate ntroduces a large amount of noise that counteracts any positive effect from the bang-bang (for us). What you suggest is how we started out, and there's a huge amount of error (+/-100rpm).

We'll play around a bit more at 10ms using our own rate calculation and not the FPGA. Perhaps that will improve our results.



04-19-2012 12:58 PM

~Cory~


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
Is there any specific reason to use a counter class rather than encoder class?
We used a gear tooth rather than an encoder.

Quote:
Originally Posted by Ether
Thank you for posting the data.

Would you mind posting the following additional information please?
- what motor(s)

- total gear ratio from motor to wheel(s).

- what type and diameter wheel(s)?

- Jag or Vic?

- coast or brake mode?

- voltage ramp rate? symmetric or up only?

- 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

- encoder signal not filtered?

- what execution cycle update rate?


PS: You have some interesting noise on your sensor signal. Look at cells B57 & B58 for example.
We will be working on this again tonight and I will repost updated information over the weekend



04-19-2012 01:06 PM

Chris Hibner


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
Reading the encoder with the getrate from the labview getrate ntroduces a large amount of noise that counteracts any positive effect from the bang-bang (for us). What you suggest is how we started out, and there's a huge amount of error (+/-100rpm).

Strike that last statement. We'll play around a bit more at 10ms using our own rate calculation and not the FPGA. Perhaps that will improve our results.
When you say +/- 100 RPM, do you mean that as: a) noise in the measured RPM, b) slow oscillations of 100 RPM, or c) your steady state (highly filtered) RPM settles at 100 RPM from your target?


We run the unfiltered encoder speed into the bang-bang controller and the speed noise is on the order of +/- 200 RPM at that stage. Once the shooter reaches it's target speed, our heavily filtered encoder speed reads about +/- 15 RPM of noise, but the unfiltered encoder speed going into the controller is still its usual +/- 200 RPM. We keep 2 versions of the speed in our software - one unfiltered to use for input to the controller, and one heavily filtered to use as the input to our "okay to shoot" logic.

Important note: we do NOT rate limit the PWM command to our Victor speed controller. We send it a steady stream of 1.0 or 0.0.
Another important note: our shooter wheel has a fair amount of inertia.



04-19-2012 01:43 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Reading the encoder with the getrate from the labview getrate ntroduces a large amount of noise that counteracts any positive effect from the bang-bang (for us). What you suggest is how we started out, and there's a huge amount of error (+/-100rpm).

We'll play around a bit more at 10ms using our own rate calculation and not the FPGA. Perhaps that will improve our results.
I think there's a misunderstanding. When I said "read encoder counts from FPGA" I meant read the counts, not the rate. Then use those counts to compute the rate.

The important thing is to do the steps, in this order, one after the other, in the Timed Structure, at 10ms, with no other code in the structure:
1) read encoder counts from FPGA1

2) use those counts to compute speed; do not filter2

3) send either 0.0 or 1.0 to motor controller3 depending on whether the unfiltered speed from step 2 is above or below the setpoint. no slew rate limiting (no voltage ramping)



... Then, if the above works, try using the GetRate() like Chris suggested, even if it's noisy2:
1) use GetRate() to get speed; do not filter2

2) send either 0.0 or 1.0 to motor controller3 depending on whether unfiltered GetRate() speed is above or below the setpoint. no slew rate limiting (no voltage ramping)



1 read encoder counts using Encoder::Get() or Counter::Get() methods in the Encoder or Counter classes, respectively

2 you can filter the speed signal for display purposes or to control other logic like when to shoot etc, but do not use filtered speed for the bang-bang logic for this test

3 try to send the motor command as directly as possible to the motor controller, bypassing as much overhead as possible which might introduce lag. disable "motor safe" and any other overhead in library code which sends the 0.0 or 1.0 command to the motor controller.






04-19-2012 05:18 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control


Tom Line:
We'll play around a bit more at 10ms using our own rate calculation and not the FPGA.


Ether:
I was assuming that your rate calculation involved getting the encoder counts and dividing by the elapsed time, is that right? If so, when you call a library function to get the encoder counts, you are getting them from the FPGA.




Reading the encoder with the getrate from the labview getrate ntroduces a large amount of noise that counteracts any positive effect from the bang-bang (for us).

I think that may be due to lag and filtering. I think it would be worthwhile to test that in the context of my previous post.



What you suggest is how we started out, and there's a huge amount of error (+/-100rpm).

Please clarify what this +/-100RPM number means (see Chris' post)





04-19-2012 06:55 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

Specifically, when I say RPM, I mean RPM as measured from our encoder. If we use the 'getrate' from the encoder get .vi, we get horrid noise. We now measure distance over 30 ms to calculate the actual rate. This is far more stable, though we do see a spike every second or two that I'm going to filter out as Chris suggested for our shooter enabling code.

As much as I'd like to keep messing about, we installed a new shooter transmission today and a more accurate turret potentiometer, and we're going to be tuning it for the next three days so we have a setup ready for nationals. I suspect we'll stick with PID for now.



04-19-2012 09:20 PM

kenavt


Unread Re: paper: Shooter Wheel Speed Control

When it comes to getting the shooter velocity, we have a prox sensor that registers one raised edge per shooter rotation, and then we use the Counter class in LabVIEW to handle the input. This uses the FPGA to calculate the MS time between raised edges of the input (don't have access to the code and the specific VI) and we just convert that to RPM.

Something like that may be possible with these encoders, if the FPGA can register all of the raised edges. The only issue we have found is that we occasionally get very large times resulting in astronomical RPMs (nearing 100,000 I believe). We just throw those out and feed in the last code cycle's RPM value.

It doesn't look like I'll have a chance to write code to test, or use Bill's, on a robot before Championship.



04-19-2012 09:37 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by kenavt View Post
When it comes to getting the shooter velocity, we have a prox sensor that registers one raised edge per shooter rotation, and then we use the Counter class in LabVIEW to handle the input. This uses the FPGA to calculate the MS time between raised edges of the input (don't have access to the code and the specific VI) and we just convert that to RPM.
What is "MS" time ?




04-19-2012 09:45 PM

kenavt


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
What is "MS" time ?


Sorry, that is misleading. I meant milliseconds.

Specifically, we are using the WPI_CounterGet.vi, and the Period (sec) output, then dividing 60 by that output to obtain RPM. If you had more than one rising edge per wheel rotation, you could presumably multiply by that factor to obtain RPM.

It seems like the FPGA can track 38,000 pulses per second. (http://forums.usfirst.org/showthread.php?t=11589)



04-19-2012 10:13 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by kenavt View Post
Sorry, that is misleading. I meant milliseconds.
I don't have LabVIEW here. I hope you don't mean millisecond resolution. At 5000 RPM, millisecond resolution would give you an RPM resolution of ~+/-350 RPM

Also, with only one pulse per rev, at 2000 RPM you would be getting stale speed data half the time at 50Hz execution frequency (TeleOp).




04-21-2012 04:09 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Chris Hibner View Post
When you say +/- 100 RPM, do you mean that as: a) noise in the measured RPM, b) slow oscillations of 100 RPM, or c) your steady state (highly filtered) RPM settles at 100 RPM from your target?


We run the unfiltered encoder speed into the bang-bang controller and the speed noise is on the order of +/- 200 RPM at that stage. Once the shooter reaches it's target speed, our heavily filtered encoder speed reads about +/- 15 RPM of noise, but the unfiltered encoder speed going into the controller is still its usual +/- 200 RPM. We keep 2 versions of the speed in our software - one unfiltered to use for input to the controller, and one heavily filtered to use as the input to our "okay to shoot" logic.

Important note: we do NOT rate limit the PWM command to our Victor speed controller. We send it a steady stream of 1.0 or 0.0.
Another important note: our shooter wheel has a fair amount of inertia.
Chris, now you've got me really really curious. How are you filtering?

The only filtering I'm used to is floating average with X number of samples. However, that introduces significant lag. Are you using something more exotic?

I've read up on IIR and FIR, and frankly I haven't found a decent English-language explanation of what they DO.



04-21-2012 04:26 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
The only filtering I'm used to is floating average with X number of samples...

I've read up on IIR and FIR, and frankly I haven't found a decent English-language explanation of what they DO.
If what you're doing is saving X samples and averaging them, then that is an FIR filter.

The basic difference between FIR and IIR is that FIR uses only the sampled values, whereas IIR uses the sampled values and the previous filtered value(s).

A simple example of an IIR filter would be:

new_filtered_value = (new_sample_value + previous_filtered_value) / 2

The above is a special case (where K=1/2) of the
so-called "exponentially weighted" IIR filter (commonly used):

new_filtered_value = (1-K)*new_sample_value + K*previous_filtered_value

... where "K" is a tuning constant which varies from 0 to 1.

when K=0, there is no filtering. as you increase K towards 1, the filtering gets more aggressive.





04-21-2012 09:51 PM

Chris Hibner


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
Chris, now you've got me really really curious. How are you filtering?

The only filtering I'm used to is floating average with X number of samples. However, that introduces significant lag. Are you using something more exotic?

I've read up on IIR and FIR, and frankly I haven't found a decent English-language explanation of what they DO.
IIR filtering is related to one of my favorite jokes (explaining the difference between math/science and engineering):

There's a game show and the contestants are a mathematician and an engineer (both male).

The host explains the game as follows: There's a beautiful model on the other side of the room. For each question the contestants answer correctly, they get to move half way toward the beautiful model.

At that point the mathematician throws his hands up in the air in anger: "What's the point! If I move halfway there every time, I can never get to the model! This is pointless." Then he storms off the stage.

The host then turns to the engineer and says, "after hearing that, why are you sticking around? You can never get to the model!"

The engineer says, "while everything he said was theoretically correct, I can get close enough for practical purposes."

(rim shot and laugh track here)

How does this relate to IIR filtering? The part of "you move x-fraction of the way toward the goal" is what IIR filtering is about. It's called "infinite impulse response" because you can NEVER get to the goal because you always approach it at a fixed fraction of the way there.


FIR filtering (Finite Impulse Response) means you actually get to achieve your goal (hence the "finite"). If the game show were changed to: "the model is 100 feel away and you get to move 10 feet closer with each answer", that would be an FIR filter - in 10 answers you would get to the final result.

(my answer about how we're filtering is in a future post - I didn't want to clutter my joke with too much other stuff)



04-22-2012 03:49 PM

Tom Line


Unread Re: paper: Shooter Wheel Speed Control

We've settled on PID because we simply can't get the bang-bang method to give us better results. The real issue that I think I've hit is mechanical - we're at the limits of what our system can provide. No matter how we play with gains, filtering, etc, we're struggling to get the shooter more than +/- 40 to 60 rpm (actual RPM, not filtered much at all other than to remove big spikes that are obvious errors).

Filtering the speed before our 'enable shooting' vi really doesn't help shooter run any more consistently - it just makes it easier for us to check the limits.

I did put a 4 sample moving average in to filter the pid input. That helped with some of the oscillation. We also turned down our proportional gain (we wrote a velocity PID, we're not using the position PID) to help some of the oscillation. The shooter still spins up in around 2 seconds, but that helped the oscillation as well.

I had hoped to manage a major improvement before nationals. We've improved our velocity control probably 50%, but other folks are reporting numbers that are still close to 100% better than ours. That means that in real time ball shooting, we're seeing something like +/- 1 foot in height when hitting the backboard.



04-22-2012 04:10 PM

NeatNit


Unread Re: paper: Shooter Wheel Speed Control

Hey, I didn't read the whole thread but just wanted to mention that this will not work with a Spike. I haven't tested, but a while ago I read into how the Spike works and it cannot coast, it either powers the motor or breaks.



04-22-2012 04:16 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by NeatNit View Post
Hey, I didn't read the whole thread but just wanted to mention that this will not work with a Spike. I haven't tested, but a while ago I read into how the Spike works and it cannot coast, it either powers the motor or breaks.
Not true for this application, since motor is being driven in one direction only.

Connect one lead of the motor to the PDB(-), and run the other lead through one relay in the Spike to the PDB(+).

anyone: Is this FRC legal?


See ensuing posts. Doh!




04-22-2012 04:29 PM

NeatNit


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
Not true for this application, since motor is being driven in one direction only.

Connect one lead of the motor to the PDB(-), and run the other lead through one relay in the Spike to the PDB(+).

anyone: Is this FRC legal?

Either way, the SPIKE can connect that side of the motor to either + or -, so wouldn't it still break when both sides are connected to -? (regardless of one passing through a SPIKE and whatnot)

I could of course be very wrong



04-22-2012 04:32 PM

nighterfighter


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
Not true for this application, since motor is being driven in one direction only.

Connect one lead of the motor to the PDB(-), and run the other lead through one relay in the Spike to the PDB(+).

anyone: Is this FRC legal?


It wouldn't be FRC legal.

Also, because a Spike is a mechanical relay, don't they have a limit as to how quickly they can switch to ON/OFF?



04-22-2012 05:02 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by nighterfighter View Post
It wouldn't be FRC legal.
When you make such a statement, you should reference the rule you have in mind.




04-22-2012 05:04 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by nighterfighter View Post
Spike is a mechanical relay
I'm not saying you're wrong, but what is your source for this information?




04-22-2012 05:06 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by NeatNit View Post
Either way, the SPIKE can connect that side of the motor to either + or -, so wouldn't it still break when both sides are connected to -? (regardless of one passing through a SPIKE and whatnot)

I could of course be very wrong
No, you're right.



04-22-2012 05:10 PM

nighterfighter


Unread Re: paper: Shooter Wheel Speed Control

I think the rule violation would either be:

Quote:
[R47]

Custom circuits shall not directly alter the power pathways between the battery, PD Board, speed controllers, relays, motors, or other elements of the Robot control system (including the power pathways to other sensors or circuits). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the Robot’s electrical system is acceptable, if the effect on the Robot outputs is inconsequential.
Or, more likely this one:

Quote:
[R50]

All electrical loads (motors, actuators, compressors, electric solenoids) must be supplied by an approved power regulating device (speed controller, relay module, or Digital Sidecar PWM port) that is controlled by the cRIO on the Robot.

Each CIM motor and Fisher-Price motor must be connected to one and only one approved speed controller. These motors must not be connected to relay modules.
Servos must be directly connected to the PWM ports on the Digital Sidecar. They must not be connected to speed controllers or relay modules.
If used, the compressor must be connected to one and only one approved relay module.
Each other electrical load (motor or actuator) must be supplied by one and only one approved speed controller, or one and only one relay module.
Electric solenoids may alternatively be supplied by a Solenoid Breakout Board connected to the NI 9472 cRIO module, which is powered by 12V.
As for the Spike, I'm not sure.

I remember hearing/reading about it being one, and it seems to behave like any electro-mechanical relay I've used also. (Mainly, the clicking sound when it switches)



04-22-2012 05:16 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by nighterfighter View Post
I think the rule violation would either be... Or, more likely this one...
Neither of those rules seem to apply unambiguously in this case. The first rule you cited arguably doesn't apply ("custom circuit") and the second rule explicitly allows a Spike to be used to control certain motors.


Quote:
(Mainly, the clicking sound when it switches)
Well that seems like a dead giveaway. I've never listened to one. (And if I had, I probably couldn't hear it anyway).




04-22-2012 05:21 PM

Ether


Unread Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by nighterfighter View Post
because a Spike is a mechanical relay, don't they have a limit as to how quickly they can switch to ON/OFF?
Yes, I would think so. See footnote2 on Page1 of Rev C of the paper.




04-22-2012 09:52 PM

team222badbrad


Unread Re: paper: Shooter Wheel Speed Control

I just want to thank all of you that have posted useful information in this thread. It has helped us greatly! We only have one student programmer and one mentor that do programming on our team.

For the first time this season we finally have a "smart" shooter...

It took us three nights this past week to get things sorted. At first we tried a banner sensor, but it only had 12 "ticks" per rev at random reflective tape spacings.

Saturday we connected up a Grayhill 64 bit encoder to the wheel axle.

We were able to get it somewhat tuned in for fender shooting.

See Here:
https://www.facebook.com/photo.php?v...4&notif_t=like

The only current downside is that the encoder is rated for only 5000 RPM's and we exceed that.

FYI we are using two Banebot 775's for the drive, two victors, and two Shepherd 6" wheels.



view entire thread

Reply

Tags

loading ...



All times are GMT -5. The time now is 04:28 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi