Hey guys, so I have a couple of questions for encoders.
I wired it correctly because live window shows values for speed.
1)Am I using the setDistancePerPulse() correctly?
2)I am getting 0 for getRate() method, is the code correct?
shooterMotor = new Talon(RobotMap.SHOOTER_MOTOR);
shooterEncoder = new Encoder(RobotMap.SHOOTER_ENCODER_A, RobotMap.SHOOTER_ENCODER_B, true, CounterBase.EncodingType.k4X);
shooterEncoder.setDistancePerPulse(4/360);//4:1 gear ratio
shooterEncoder.setPIDSourceParameter(Encoder.PIDSourceParameter.kRate);
shooterEncoder.start();
Nope. DistancePerPulse is the distance in units that your robot travels, per pulse. So what you need to do is take the circumference of your wheels and divide that by the resolution of your encoder (usually 360 or 250) to give you the distance that your robot will travel forward for every “pulse” of the encoder.
So if you’re using 6" wheels, that would give you a circumference of ~18.85 inches. For every turn of your robot’s wheels, your robot will travel roughly that distance. So you take the number of pulses per revolution of the encoder, and divide 18.849556 by that number, to give you the distance per pulse of the encoder.
I don’t think gear ratio factors into it, since I’m 99% sure the encoder shaft is linked to the output shaft rather than the input gears. This can be fairly trivially tested though I suppose. Or just look up the gearbox manual.
You do not want to use getRate() with a 360 CPR encoder with 4X decoding at shooter wheel speeds.
See the first attachment
*
*
Do this instead:
Connect only Channel A of the encoder to the DSC, and use an up/down counter (from the Counter class) set to count up only. Leave Channel B disconnected.
Well, the encoder is on a different shaft than the motor because we didnt have a way to mount it directly to the motor shaft. Thanks for the clearing though.
Thanks for the tip, I will try that when I get in my school on Monday.
I did not receive the gear ratio from the person who was in charge of the shooter, but it is a higher teeth count on the motor and a lower teeth count for the wheel. And yes, this is for the shooter. Also the encoder wheel has 250 ticks.
On encoders for shooting wheels, you may wish to watch out for the maximum RPM the encoder can handle. There are both electrical and physical issues there.
You can also approach the granularity of the VxWorks timer, which I believe has a resolution of 6 us. Since GetRate() gives you the inverse of the time between the last two ticks, with a resolution of about 6 us, this caused us some issues with oscillation between two substantially different returned values for RPS. Using the FPGA with the ring buffer may help with this, but we opted for the x1 resolution.
For US Digital E4P encoders, the limit is 60,000 rpm or 3,600,000/CPR, whichever is less.
You can also approach the granularity of the VxWorks timer, which I believe has a resolution of 6 us.
The FPGA handles encoders. Vxworks is not involved.
Since GetRate() gives you the inverse of the time between the last two ticks, with a resolution of about 6 us, this caused us some issues with oscillation between two substantially different returned values for RPS.
For a high-speed one-direction application like a shooter wheel, do not use getRate(). Use getPeriod() from the Counter class. Make sure you physically connect only Channel A. Leave Channel B disconnected. Create an up/down counter counting rising edges only.
See the attached example calculation of a 250 CPR encoder set up this way and spinning at 5000 rpm, showing the effect of the 6us polling period of the FPGA when the ring buffer is set to 125 samples (1/2 of a revolution).
Using the FPGA with the ring buffer may help with this, but we opted for the x1 resolution.
1X decoding of an encoder still requires detecting the rising edges of both channels, which limits your speed.
Due to an inventory issue, we were forced to use a 360 CPR encoder to attempt to measure our shooting wheel. We exceeded the CPR limit. Frustrating to watch the RPM graph drop to zero as the wheel accelerates. Other solutions were found.
The FPGA handles encoders. Vxworks is not involved.
According the the documentation, the FPGA is only used when the counter type is set to k4x, not for k2x and/or k1x. From what I can see from perusing the code, this is correct.
For a high-speed one-direction application like a shooter wheel, do not use getRate(). Use getPeriod() from the Counter class. Make sure you physically connect only Channel A. Leave Channel B disconnected. Create an up/down counter counting rising edges only.
getRate() is a derivative of getPeriod(). getPeriod suffers from the same problem, i.e. the period of time between two “clicks” is approaching the resolution of the clock by which those clicks are measured.
The reason we had quad-encoding on this encoder was that at one point we were going to reload discs back through the barrel of the gun, causing us to run the motors backwards and wanting to be sure we knew they were running backwards.
Also, I seem to recall that the PID classes wanted an Encoder and would not accept a Counter. I may be wrong about that.
See the attached example calculation of a 250 CPR encoder set up this way and spinning at 5000 rpm, showing the effect of the 6us polling period of the FPGA when the ring buffer is set to 125 samples (1/2 of a revolution).
1X decoding of an encoder still requires detecting the rising edges of both channels, which limits your speed.
I never found that the handling the second channel caused an appreciable issue for the cRIO. However, the point is well taken that it is extra interrupts and unneeded effort.
The PIDController class only needs a PIDSource and PIDOutput. Counter does not implement PIDSource, but you could always extend it and implement PIDSource.
I seem to recall that the PID classes wanted an Encoder and would not accept a Counter. I may be wrong about that.
Many teams are successfully using home-brew one-count-per-rev counters on their one-directional shooter wheels. Also, PID is not the only game in town.
I never found that the handling the second channel caused an appreciable issue for the cRIO.
Perhaps you did but didn’t realize it:
However, the point is well taken that it is extra interrupts and unneeded effort.
There are no interrupts involved. The FPGA polls the DIO at ~153KHz
Would you be willing to post your modified Counter class? It would be a service to the FRC community. There are other teams/individuals who need some help figuring out how to do this.
