paper: Shooter Wheel Speed Control

[Tom Line]

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.

[Ether]

Originally Posted by Tom Line

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

[Tom Line]

Originally Posted by Ether

http://www.chiefdelphi.com/forums/sh....php?p=1122535

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

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.

[billbo911]

Originally Posted by Tom Line

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.

[Tom Line]

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

[billbo911]

Originally Posted by Tom Line

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.

[Ether]

Originally Posted by Tom Line

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.

[Tom Line]

Originally Posted by Ether

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.

[~Cory~]

Originally Posted by Tom Line

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

We used a gear tooth rather than an encoder.

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

[Chris Hibner]

Originally Posted by Tom Line

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.

[Ether]

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 FPGA¹

2) use those counts to compute speed; do not filter²

3) send either 0.0 or 1.0 to motor controller³ 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 noisy²:

1) use GetRate() to get speed; do not filter²

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

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

² 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

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

[Ether]

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)

[Tom Line]

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.

[kenavt]

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.

[Ether]

Originally Posted by kenavt

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 ?