While attempting to improve our autonomous distance driving by employing a velocity based feedback control using the GetRate() function, we noticed that many of our encoder function calls to retrieve data are reporting inconsistent to our expectations.
GetDistance(): Works without flaw. Currently a mainstay in our autonomous code. This is our main reason to assume our encoder is connected properly
GetRate(): Reports 0(zero) no matter the speed of the encoder physically turning
GetPeriod(): Reports inf no matter the speed of the encoder physically turning. This is odd because this function is necessary for GetDistance() to work according to the encoder.c file
We are calibrating the encoder using SetDistancePerPulse()
We have one encoder per side of a WCD style drive, both side reporting the same.
Encoder sampling is not changed from the default 4X
Both A and B channels for both encoders are connected to the Side Car in ports 6,7,9 and 10 Slot 2 in a 4 slot cRio
All data is being viewed using a cout from the WTX console (currently our main method of debugging).
GetDistance does not use GetPeriod(). It uses GetRaw()
/**
* Get the distance the robot has driven since the last reset.
*
* @return The distance driven since the last reset as scaled by the value from SetDistancePerPulse().
*/
double Encoder::GetDistance()
{
if (StatusIsFatal()) return 0.0;
return GetRaw() * DecodingScaleFactor() * m_distancePerPulse;
}
Slightly backwards here. GetRate() is the one that requires GetPeriod() to work.
Somewhat hard to debug here, since almost all of the implementation for encoders is in the FPGA, and I haven’t seen this before. Still, my hunch is that one of the two encoder lines is not connected/assigned properly. GetDistance() probably works because it is counting off the one good line, but since the other line never fires, a full period is never seen. GetPeriod() returns inf whenever the period is over a certain threshold (side note - if anyone knows what that default threshold is, please tell me. I can’t find it in any of the comments).
Also, if that is the problem, most likely when you fix it your distances will double.
This makes a lot of sense. The confusing part about this theory is that the same output occurs on both encoders and on both robots (comp and practice) for a total of 4 encoders with identical failures. My next step will be to confirm that my channel assignments are correct. Thanks for pointing me in a sane direction.
We are not. I tried to find a reference of the default value and could not locate it. I can’t even find a reference to the units this expects (I assume milliseconds). Any ideas?
Could any value for MinRate actually cause an inf as reported?
If there’s no use of it in the code, it probably isn’t the problem. The default value has been fine for me in the past.
Units for it are the same as what come from GetRate(). Basically, if the value that would come out of GetRate falls below MinRate, the cRIO will assume the motor is stopped, set period to infinity, and rate to 0. The default is low enough though that you should be clearing the minimum by just spinning the shaft by hand though.