We are new to using absolute encoders to measure position, and since REV provided some through bore encoders through FIRST Choice, we figured we would give them a try. Since there are no direct interfaces with the SRX data port, we were wondering what wires we need to splice in to enable absolute positioning through the SRX. The encoder breakout board from CTRE only breaks out channel A and B, but do we need to add both the Index pin and the ABS pin? Does the SRX even accept the REV encoder’s digital pulse for absolute positioning?
It can be made to work, but it’s not going to be easy or give you the kind of encoder input you’d get with a CTRE mag encoder that’s made to plug directly into a Talon SRX. What you need is the mag encoder and a CTRE Hex Bore Mag Encoder Housing. That will do the same job as the Rev encoder but interface much more effectively with the Talon.
If you’re not using too many of them, you can plug them directly into the RoboRIO. Obviously you won’t get the Talon’s processing at that point, though.
If all you need is absolute position, you will need three wires:
- +V (Red)
- GND (Black)
- ABS (White)
You would need to connect the encoder ABS wire to the Talon SRX Index pin. There are a number of breakouts that make this pin available.
*The 6-pin JST on the Swyft breakout is NOT compatible with the Through Bore Encoder. You would have to make a custom cable.
Alternatively, you could take an SRX ribbon cable and solder the necessary wires to our JST PH 6-Pin Breakout Board. This gives you the 2x5 connector that plugs into the SRX on one end, and a connector to plug in the Through Bore Encoder on the other.
It should accept it without issue. It is my understanding you just need to set the kSensorUnitsPerRotation to 1024 for the Through Bore Encoder.
2 Likes
So I soldered the +V to 3.3 volts, GND to GND and the ABS to the Quadrature Index pin. The encoder seems to be working as it should, but it throws massive spikes in the data. I attached a plot of the sensor as I slowly moved the encoder one way and another. You can see it moves slowly down and all of a sudden jumps 4000 sensor units. While writing this post, it gradually increased from around 500 units to 40,000 units while not moving and the robot disabled (reading the sensor in Periodic Tasks [using LabVIEW]).
I tried plugging in the second encoder we received and got the same results. Did we wire it wrong? Or should we find alternative ways to measure the feedback with the SRX?
1293 (which received a shipment of Swyft products to evaluate last year) is using their boards this year to interface with the REV encoders we got in FIRST Choice.
Since both are JST PH connectors, we (well, I–everyone else was doing stuff) used a small screwdriver to liberate the crimped wires out of the FTC 4-pin cable in the encoder bag. We then removed all the wires out of the Swyft connector, then inserted the REV wires into the Swyft connector in the right sequence. Still waiting for our programmers to have code ready, but everything looks quite promising.
Failing that, there’s always heat shrink solder.
1 Like
We are seeing the same kind of issues with our Rev hex encoder connected to a Talon SRX. We used an Adafruit 2x5 breakout board and just ignored the silk screen labels. We soldered the 6 pin JST cable directly to it. We connected +V (red) to 3.3v, GND (black) to GND, and ABS (white) to encoder Index.
Enabling the robot and just leaving the encoder sit still, the position returned will constantly increase over time. It will fluctuate for a little bit, then suddenly jump up, and repeats this. We’ve tried two different encoders, two Talons, and resoldered our cable a few times. Nothing seems to be making a difference in the sporadic values we are seeing.
Glad to see that we aren’t the only ones having this issue. At this point it seems that we will have to go with a potentiometer instead and hope that the issue is either fixed in the near future or by next season.
Are you able to plug the encoder into the roboRIO and see if you’re seeing the same behavior using the DutyCycleEncoder class?
1 Like
We tried connecting our encoder to the roboRIO using the supplied breakout cable. The value returned from this was way more stable, and did not grow over time (we left it enabled for several minutes, and saw nothing more than minor fluctuations).
To rule out other factors, I tried powering the encoder with the 5v line instead of 3.3v when connected to the Talon, but we saw the same behavior. Do we need to do anything with the other lines connecting back to the Talon data port, such as connecting the A/B lines to ground, or putting a pull-up/pull-down resistor on the Index line we are using?
One other interesting thing I saw. The Rev Hex encoder updates it’s absolute PWM output at a rate of 975.6 Hz. Looking at the CTRE Mag Encoder, it outputs at a rate of 244 Hz. We did not see these jumping issues when using the Mag encoder with the Talon.
Does anyone know what the sampling rate of the Talon is on its Encoder Index pin for an Absolute Encoder outputting in PWM? Could there be a problem of the Talon not reading the Hex Bore encoder output fast enough?
I don’t know exactly how the Talon SRX interprets pulses. Their section on Sensor Resolution seems to imply that you can use any pulse width encoded position signal by configuring the sensor resolution appropriately (1024 for the Through Bore vs. 4096 for the Mag Encoder), but this is a question for @ozrien at CTRE.
Using the duty cycle class, the value seems much more stable than on the Talon, but the value is never truly stable. We are seeing a change of around .0005 raw sensor units constantly (we would probably never use this much precision in the device anyway). We can definitely use this value, we will just have to construct our own PID loop instead of using the Talon’s onboard capabilities.
The pulse width is a 10-bit value with 1us changes between measurements, where the roboRIO can sample at 25ns. So I suspect that if you round off the remaining bits of resolution you would find that your sensor measurement is quite stable.
Did anyone have success using this encoder for absolute position? I also tried to wire it to a MACH breakout board, but it is not giving a stable reading.
Nope. We hooked it up to the roborio and the reading was perfect.
I’m not getting any reading that way. Did I connect it wrong?
The code is very simple:
private DutyCycleEncoder encoder = new DutyCycleEncoder(0);
SmartDashboard.putData(encoder);
I’m not getting any errors, but only zero reading.
You need to connect it to the DIO, not PWM.
Yeah, I see that now! I should have removed the protective tape (facepalm)
This is really disappointing because we cannot use any of the closed-loop features of the Talons if we need absolute position. @ozrien or @dyanoshak, are we just out of luck?