Chief Delphi - Speed PID Function

Page 2 of 4

Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Speed PID Function (http://www.chiefdelphi.com/forums/showthread.php?t=101244)

davidthefat

28-01-2012 16:01

Re: Speed PID Function

Quote:

Originally Posted by John_1102 (Post 1115254)

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

28-01-2012 16:03

Re: Speed PID Function

Quote:

Originally Posted by John_1102 (Post 1115254)

At what rpm are you getting this oscillation?

JohnFogarty

28-01-2012 22:52

Re: Speed PID Function

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

Joe Ross

28-01-2012 23:00

Re: Speed PID Function

Quote:

Originally Posted by John_1102 (Post 1115254)

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

29-01-2012 00:04

Re: Speed PID Function

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

29-01-2012 00:32

Re: Speed PID Function

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

29-01-2012 01:10

Re: Speed PID Function

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

29-01-2012 01:11

Re: Speed PID Function

Quote:

Originally Posted by John_1102 (Post 1115671)

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

29-01-2012 01:15

Re: Speed PID Function

Quote:

Originally Posted by John_1102 (Post 1115708)

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

29-01-2012 02:04

Re: Speed PID Function

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

Ether

29-01-2012 03:37

Re: Speed PID Function

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

31-01-2012 22:01

Re: Speed PID Function

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

Code:

    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

31-01-2012 22:05

Re: Speed PID Function

Quote:

Originally Posted by John_1102 (Post 1117459)

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

Code:

    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

31-01-2012 22:23

Re: Speed PID Function

Quote:

Originally Posted by John_1102 (Post 1117459)

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

Code:

    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:

Code:

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

01-02-2012 13:57

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.

All times are GMT -5. The time now is 08:53.

Page 2 of 4

Show 100 post(s) from this thread on one page