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.
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.
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?
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?
Based on my interpretation of the Phoenix documentation, the Through Bore Encoder absolute pulse should work:
-
Pulse Width Decoder
- Mentions the decoder is “<1us accurate” which should be compatible with the 1us resolution of the Through Bore Encoder, which is also the same pulse resolution as the SRX Mag Encoder.
- Mentions the “maximum time between edges is 120 ms.” The Through Bore maximum period is 1024us (1.024ms).
-
Confirm Sensor Resolution/Velocity
- This section implies that “Any pulse width encoded position” will work as long as the resolution is configured properly. 1024 for the Through Bore vs 4096 for the Mag Encoder.
It is recommended in the documentation that you check the Self-Test Snapshot to confirm that the Talon is interpreting the correct period of the connected sensor. I see a screen shot of position data from @Cecil but was the period checked using the Self-Test Snapshot?
You’ll need to try and get in contact with @ozrien or @Jacob_C to understand if it is a configuration problem or something else. Try emailing them at [email protected].
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.