encoder PIDController and set

[bmfrc]

Hi,

I'm trying to figure out the how to operate and use an encoder to maintain speed on our shooter.

1. SetDistancePerPulse() - If our wheel circumference is 10cm then we should set SetDistancePerPulse(10/NUMBER_OF_PULSES). Using the GetDistance() will get the total distance in cm and the getrate() will get the cm per second. is that correct?
   
   
2. pulses - We are using http://www.andymark.com/E4T-OEM-Mini...-p/am-3132.htm.
   The spec indicate:
   Cycles per Revolution: 360
   Pulses per Revolution: 1440
   Which one should we use? when we use 10/1440 we get rates and distanses that doesnt make sense. my feeling is that 10/250 make more sense.
   
   
3. decoding scale - what exactly is the decoding scale and how does it affect our calculation?
   
   
4. PIDController.SetSetpoint() - If we trying to get 10cm per second should we set PIDController.SetSetpoint(10) ?
   
   

Thanks a lot for your help!

[ollien]

1. If your wheel RADIUS is 10cm, then you should set setDistancePerPulse(10 * (2 * pi)/PULSES_PER_REVOLUTION). GetDistance will then get the total distance in cm and getRate will get the total cm per second.

2. Use ppr. The reason your values don't make sense is because you used circumference instead of radius.

3. I was never too sharp on this, but I BELIEVE 4X will result in you getting your ppr, while 1X will get you your cpr. In other words, you will get 1440 pulses with 4X and 360 pulses with 1X. I might have them flipped though.

4. Depends on what your PID controller is controlling. If it's controlling speed, sure. This purely depends on if you're feeding rate or distance into your PID controller.

EDIT: Major math error on my part. It should be 10*(2*pi)/PULSES_PER REVOLUTION

[bmfrc]

Originally Posted by ollien

1. If your wheel RADIUS is 10cm, then you should set setDistancePerPulse(10/PULSES_PER_REVOLUTION). GetDistance will then get the total distance in cm and getRate will get the total cm per second.

2. Use ppr. The reason your values don't make sense is because you used circumference instead of radius.

Thanks for your help!!

Are you sure we should use the radius and not the circumference??
AFAK pulses represents degrees, so circumference/ppr will get the distanse per degree or degree fraction.

[ollien]

Originally Posted by bmfrc

Thanks for your help!!

Are you sure we should use the radius and not the circumference??
AFAK pulses represents degrees, so circumference/ppr will get the distanse per degree or degree fraction.

Linear displacement = angular displacement * radius. You may have seen this written as d = Θr in your physics class. You are correct that each pulse represents some number of degrees. In your example, one pulse represents .25 degrees (360/1440).

[ollien]

I'm sorry for any confusion I caused. It's late at night over here and I forgot to check over my work. Haha. If you know the number of pulses per revolution, you therefore know the number of radians per pulse.

RPP = 2*pi/PPR.

Knowing this, combined with d = Θr, we know that each pulse will travel us a linear distance of RPP * r. In your case, this would be (2 * pi)/(1440) * 10 cm, for a 10 cm radiused wheel.

[bmfrc]

Originally Posted by ollien

I'm sorry for any confusion I caused. It's late at night over here and I forgot to check over my work. Haha. If you know the number of pulses per revolution, you therefore know the number of radians per pulse.

RPP = 2*pi/PPR.

Knowing this, combined with d = Θr, we know that each pulse will travel us a linear distance of RPP * r. In your case, this would be (2 * pi)/(1440) * 10 cm, for a 10 cm radiused wheel.

In other words its circumference/ppr :-)

[ollien]

Originally Posted by bmfrc

In other words its circumference/ppr :-)

You know, I never noticed that relationship. I always thought it through as a calculation of distance with radians per tick.

I'll let someone else answer this. I think I've successfully talked myself into a circle here.

[bmfrc]

Originally Posted by ollien

You know, I never noticed that relationship. I always thought it through as a calculation of distance with radians per tick.

I'll let someone else answer this. I think I've successfully talked myself into a circle here.

lol thanks man!!!

[Joe Ross]

1x and 4x decoding affect which edges the FPGA counts, but not the reported distance. When you select 4x, WPILib scales the output to be the same as 1x, ie if DistancePerPulse is 1, in 4x you would get values of 1.0, 1.25, 1.50, 1.75, 2.0, and in 1x you would just get 1.0, 2.0, etc.

The FPGA measures rate by timing successive pulses. In 4x decoding, the next pulse is from the opposite channel, which means that you will see a lot of noise. If you look phase relation specs for the the E4T, the relationship can vary by up to 60 degrees, which means you could get 2/3 of the measurement as noise. It's much better to use 1x decoding for rate, so the same edge is always being counted. It's also better to use a lower resolution encoder, so that there is a longer time period between pulses.

This is based on using the roboRIO for decoding the encoder. If using the Talon SRX, the opposite applies, it's rate algorithm wants a very high resolution encoder (although this might not be an issue with the 2.22 firmware).

[bmfrc]

Thanks Joe!
I'm really new to this stuff..

Originally Posted by Joe Ross

1x and 4x decoding affect which edges the FPGA counts, but not the reported distance. When you select 4x, WPILib scales the output to be the same as 1x, ie if DistancePerPulse is 1, in 4x you would get values of 1.0, 1.25, 1.50, 1.75, 2.0, and in 1x you would just get 1.0, 2.0, etc.

Im not sure i understand the scaling thing.
if 4X output higher resolution to 1.25, 1.50 VS 1, 2 of the 1x, where is the scaling?
Does it affect the DistancePerPulse calculation from our side? we devide the circumference by 360 or 1440?

Originally Posted by Joe Ross

It's much better to use 1x decoding for rate, so the same edge is always being counted. It's also better to use a lower resolution encoder, so that there is a longer time period between pulses.

What about measuring distance? should we use 4x decoding?