Speed PID Function

[davidthefat]

Originally Posted by John_1102

I just ran a test with my encoder and I get a HUGE amount of oscillation when I'm just pulling the number from the getRate() method even when I'm running at a constant speed.
I can't get a RPM reading with this much oscillation.

Filter it out. But to be honest, it is not even that bad. Our robot has less than a 1-2% margin of error, it just looks huge because the scalar values are huge. One of the former programming mentors told me that Kalman Filter is overkill with such small error for the purposes of FIRST.

[Ether]

Originally Posted by John_1102

I just ran a test with my encoder and I get a HUGE amount of oscillation when I'm just pulling the number from the getRate() method even when I'm running at a constant speed.
I can't get a RPM reading with this much oscillation.

At what rpm are you getting this oscillation?

[JohnFogarty]

http://www.chiefdelphi.com/media/photos/37282?
I am running the Victor at 35%

[Joe Ross]

Originally Posted by John_1102

I just ran a test with my encoder and I get a HUGE amount of oscillation when I'm just pulling the number from the getRate() method even when I'm running at a constant speed.
I can't get a RPM reading with this much oscillation.

When I ran experiments in 2009, I found there's a lot of noise with the FPGA's rate due to phase errors in the encoder. Changing the encoder to 1x decoding decreased this significantly, since it always used the same edge, however it still wasn't clean enough for us. This is equivalent to averaging over one cycle. We implemented a low pass filter and were able to get results that were good enough. Another option would be to calculate the rate from the position, which is equivalent to averaging for the sampling time.

I don't know if the rate implementation has changed since then. Your noise seems a little higher then what I saw before, but that could easily be explained by differences in setup.


Saying that you're running a Victor at 35% doesn't answer Ether's question without also defining what motor you're using. In your chart, what are the units for "data".

[JohnFogarty]

this is where my confusion lies.
I thought the getRate function was reading the RPM's
I guess not.
I looked at the method itself and it shows that the equation for getRate is...

setdistanceperpulse/getPeriod or right now for me.

1/the time between each pulse

What my software mentor told me is that what were going to do is probably sample from the getRaw data encoder function.

since we are getting 2.5 revolutions per second @ 35% power based on a test I did. since there are 1440 pulses per revolution.

[davidthefat]

Well, from a test I have done today, the encoder that came with the KOPs from a previous year outputs 250 ± 5 for every revolution. So it is not directly 360 degrees. Keep that in mind. What I am doing is just using the raw output and getting the RPM from that.

[JohnFogarty]

Yeah I'm going to be using the RAW from now on as well.
I forget...is there is a way of subtracting consecutive samples and dividing them by 2 to find the rate.

[Ether]

Originally Posted by John_1102

this is where my confusion lies.
I thought the getRate function was reading the RPM's
I guess not.
I looked at the method itself and it shows that the equation for getRate is...

setdistanceperpulse/getPeriod or right now for me.

1/the time between each pulse

What my software mentor told me is that what were going to do is probably sample from the getRaw data encoder function.

since we are getting 2.5 revolutions per second @ 35% power based on a test I did. since there are 1440 pulses per revolution.

If your encoder is giving you 1440 pulses per second:

1 RPM = 1/60 rev/sec = 1440/60 pulses/sec = 24 pulses/sec

So RPM = (delta_pulses/dt)/24

...where delta_pulses is the change in the raw count from the previous cycle, and dt is the cycle time in seconds.

Don't forget: you must scale your setpoint to the same units as your process_variable.

[Ether]

Originally Posted by John_1102

Yeah I'm going to be using the RAW from now on as well.
I forget...is there is a way of subtracting consecutive samples and dividing them by 2 to find the rate.

Why would you divide by 2?

If your cycle time is 20 milliseconds (TeleOp) and you have 1440 pulses/rev, then to get RPM you would take the difference in pulses and divide by 24*0.02 = 0.48

[JohnFogarty]

The encoder returns 1440 per REV.
I am getting about 2.5-2.7 REVS a second.

[Ether]

In post #24, "cycle time" is not the time it takes for your encoder to rotate once.

it is the delta time between the two GetRaw() readings you are subtracting to get "delta_pulses" (the change in pulse count).

if you are running the PID in TeleOp, that would be approximately 20 milliseconds.

[JohnFogarty]

I just got a VERY constant rate from using this function I wrote.

    public void getSpeed(){  
        samples[counter] = Shooter_En.getRaw();
        counter++;
        Shooter_En.reset();
        if(samples[9] > 0){
            counter = 0;
            for(int i = 0; i <= 9; i++){
                sum = sum + samples[i];
               }     
            AVG = sum / 10;
            Rate =  AVG / 0.48;
            sum = 0;
        }
    }

[Jared Russell]

Originally Posted by John_1102

I just got a VERY constant rate from using this function I wrote.

    public void getSpeed(){  
        samples[counter] = Shooter_En.getRaw();
        counter++;
        Shooter_En.reset();
        if(samples[9] > 0){
            counter = 0;
            for(int i = 0; i <= 9; i++){
                sum = sum + samples[i];
               }     
            AVG = sum / 10;
            Rate =  AVG / 0.48;
            sum = 0;
        }
    }

Do you notice that the speed you get using this method is slow to respond to changes?

[Ether]

Originally Posted by John_1102

I just got a VERY constant rate from using this function I wrote.

    public void getSpeed(){  
        samples[counter] = Shooter_En.getRaw();
        counter++;
        Shooter_En.reset();
        if(samples[9] > 0){
            counter = 0;
            for(int i = 0; i <= 9; i++){
                sum = sum + samples[i];
               }     
            AVG = sum / 10;
            Rate =  AVG / 0.48;
            sum = 0;
        }
    }

When does samples[9] get reset to zero?

If it's getting reset, you're only getting a new speed every 10 cycles.

If it's not, then once it becomes non-zero it stays that way, and you re-zero the counter every cycle so the filter does nothing (except skew the calculation).

What you want is a circular buffer (ring buffer) that you populate each cycle and use each cycle to get a new speed, like this:

public void getSpeed(){  
  samples[counter++] = Shooter_En.getRaw();
  Shooter_En.reset();
  if(counter>9) counter=0;
  sum=0;
  for(int i = 0; i <= 9; i++) sum += samples[i];
  Rate =  sum / (10* 0.48);
}

[JohnFogarty]

My mentor explained to me this way.
Your first 9 values are going to be very skewed so wait until you have at least 9 values in your array before you start averaging. Now counter is a pointer variable it ONLY points to a position in the array. I add all the values and get an average every time after 9 samples. I haven't tested changing speeds yet. Only constants.