Hi All,
We are attempting to use one of the Rev Hex Encoders for absolute values. We are using the DutyCycle reading to get the value. We have the absolute pin plugged into a DIO port. According to my programming students, we always receive a random, non-repeated value when we restart the robot. I believe we might not be reading it properly, as an absolute encoder should always send the same number. Should the absolute value be read from the PWM slot instead of DIO?
The sensor plugs into the DIO port as you have it. One recommendation is to use the DutyCycleEncoder class as it can give you angle and handle roll over.
Can you give some examples of the data you are reading?
Also how is it wired?
Example, we have the robot disabled right now. The value is .117, when we enable the robot, without changing or moving anything, when we enable, that value jumps to .349. We have a routine built in that, any time we start the robot, the turret rotates to a limit switch, and we Zero the encoder.
What happens if you disable that routine? Does it always start at the same place?
It sounds like this is just things not all starting at the same time. If you start the duty cycle counter when the output is already high, it may* just start counting from there, and end up with too small a number the first pass. I’d either dismiss the first sample, or ensure that it doesn’t start counting until an actual low-to-high transition occurs.
* May in that I haven’t dug into the duty cycle code and don’t know what it’s actually doing.
The duty cycle reading only has a memory of ~1 second.
How it works is it counts the number of rising edges (might be calling, but that wouldn’t matter, and it’s always the same one). Every second, it saves that number as the frequency, and then resets the counter. That is how frequency is computed. This happens continuously.
Additionally, every rising edge it resets a timer counter which runs at 40MHz. Then, on the falling edge, it multiplies how that counter by the current stored frequency, and that gives the perfect period high of the duty cycle, which is reported back to the user.
This is why there is only a memory of about 1 second. Every second, the frequency will refresh. However, if the sensor is actually plugged in the whole time, the frequency should be stable, and I have tested it to be very stable over long periods.
Note that this is only the DutyCycle portion that gets the absolute value. DutyCycle does not support resetting. DutyCycleEncoder adds another counter on top of this, which is used to count rollovers. However, resetting is handled at the high level by resetting the rollover counter, and grabbing the current duty cycle output as an offset. There might be some issues in this logic, as you’re not the first report of that. I will try to take a look into it this week and see if I find anything wrong.
FWIW, we were using the absolute mode of the rev encoder for our hood angle for about a week during our build season and it seemed to work well with the duty cycle encoder class.
We then started having issues with the measured angle value jumping randomly. This first happened while we were driving, but it would continue to happen every couple minutes or so even if the robot was parked. If we power cycle the robot, the angle would be preserved. In other words, once the value jumped to a new position it would hold that position across reboots for a while and then jump again. That feels like an issue inside the rev encoder itself, not the wpi duty cycle class. We changed our control strategy to use a limit switch and the quadrature output on the encoder and haven’t had any issues since, so we haven’t looked at it more.
The same behavior happened on two different encoders. We just wrote it off and found another solution because we could easily do so. I would be interested to know if other teams are seeing similar results with the absolute mode of this encoder. It is very likely to be user error, we just haven’t had time to revisit the issue.
One additional note, we are using the pre-assembled breakout cable from Rev with our encoder.
We also are using the pre-assembled cable. We are using the connector with the white wire. We are using another hex encoder on a different shaft on the bot, and it is maintaining its values. I am wondering if it is an issue with the encoder itself.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.