Why choose which encoder?

I’ve seen different encoders used for different tasks. There are absolute encoders and incremental encoders. Absolute keeping track of angles and incremental the amount of rotations. My question is specific to incremental encoders.

Why do some teams choose a specific encoder over another. For example, why choose a srx mag encoder over a us digital s4t and vice versa. Is it due to how they are wired or is there something else? How many counts per revolution is actually needed for frc?

Those are just two encoders I gave as an example. The question would apply to using a cancoder over a grayhill or vice versa.

1 Like

Oh man, it’s so so so arbitrary. Usually it just comes down to whatever teams have on hand, and what fits in the design. If you don’t have the machining ability to semi-accurately line up parts, then noncontact magnetic encoders like the SRX mag might be out. If you need both absolute and incremental output, then you have to use something like the SRX mag or REV through bore. Things with shafts makes mounting easier and requires less precision. If you need fast feedback for high-gain control systems, you really want a directly wired encoder, discounting things like the CANcoder. Sometimes you might really need the 4096 CPR of a mag/S4T/REV bore/whatever vs 512 PPR of a grayhill/whatever, but that’s not a very common situation.

Usually when I’m designing stuff I’ll just start checking drawers until I find an encoder that will work for what I’m doing :wink:

Personally, I rather like the CUI AMT102 - cheap as hell, and the through bore makes it good for gearboxes.

4 Likes

A lot of teams go with the SRX mag encoder because it’s the easiest to use with the control loops on the TalonSRX; it requires no breakout / soldering. It can also be through-bore with this product from vex. I can’t vouch for the quality of that housing, though. I’ve never used it.

You can also use the fact that it’s both relative and absolute to do some cool stuff with zero-ing your mechanism instantly, without moving it, using just one additional encoder instead of two.

1 Like

I’ll second everything you said. Being able to plug the CTRE mag encoders directly into a TalonSRX is a big help, especially combined with Motion Magic. The one drawback to them is the short cables that are available (hint, hint if you’re reading this, people from CTRE) but otherwise an excellent general solution. We’ve also found them pretty easy to mount, despite not having advanced machining capabilities. They saved our bacon this past season, letting us get accurate movement on both our mechanism elevator (with preset positions for the rocket) and our climbing mechanism.

1 Like

Once you’ve got the technology (absolute/quadrature/etc.) picked out, the only other considerations I take:

  1. Mechanical interface - what’s easiest to attach to the existing mechanism in a robust way?
  2. Electrical interface - what’s the easiest to attach to the controller without custom wiring? There’s occasionally some additional level conversion to do here, but that’s only if you’ve got some very exotic combination (Lookin at you, bosch seat motor).
  3. CPR. If I’m directly measuring the main shoulder joint of an arm, I’d be looking in the 1024+ range. For a shooter wheel, it’s more like 16 or 1. Drivetrain somewhere in-between… basically, just calculate the minimum motion per step, and make sure you’re ok with that.

Arm quick example - 360 deg/(1024 cpr * 4) = 0.083 deg/edge. Yup, that’s a tighter tolerance than mechanical team can guarantee, so I think we’re good.

3 Likes

Also keep in mind if your encoder is behind a reduction then you need to account for that in your CPR calculation. So if you have an arm with a 6:1 chain reduction as the final stage and you put the encoder on the gearbox output (before the chain reduction), then each encoder count represents 1/6 of the angular distance that it would if the encoder were directly on the arm. Generally it’s best practice to put the encoder directly on the thing you’re trying to measure, but if you can’t for whatever reason it’s important to consider the reduction when choosing an encoder.

5 Likes

To potentially oversimplify the problem, I’d suggest the default encoder for all teams to be the CTRE Cancoder or mag encoder with the new hex bore housing (or in a versaplanetary) for easy integration.

If you have good reasons to deviate… Do so… But the above should cover most applications.

This if of course if we’re talking about supplementing a Falcon. The integrated encoder in it should be all you need for most applications.

6 Likes

We’ve been trying to figure out why the old mag encoders needed the 10 pin connector (which is not fun to deal with) but now the Cancoder appears to do the same things over CAN. Is this new technology or does it give up some functionality? It seems they would have used CAN instead of the 10 pin connector all along unless something changed in the technology.
My knowledge base is limited to only knowing how to plug the cable in.

The 10 pin is for wiring directly to a Talon SRX for brushes motors. This is nice for using the fast onboard loop.

The CAN encoder is for more broad applications where you’d prefer the encoder in the CAN network and not wired to a specific controller (could be due to wire length… Could be due to using controllers that won’t allow an encoder to plug in). This won’t let you run control loops as fast, but you don’t need the 1 khz talon control for typical FRC Dynamics.

It is different in that they have to manage CAN on the encoder board, likely with another transceiver chip. So that is some additional complexity. To straight get PWM or A/B/I, which are the ribbon cable signals, they can take that directly from the pins of the standalone magnetic encoder chips (we bought Infineon TLE5012b chips last year to make our own encoders), but offering CAN with the FRC protocol involves a bit more engineering. Mag encoders already have a little additional circuitry for the LED for placement, but I don’t really know if the process to make CAN work can use any of that or not.

To be clear, this is nothing teams need to handle when integrating.

Changed ‘you’ to ‘they’ to clarify it was on the supplier to deal with this change.

If I am interpreting this correctly, it seems CTRE has decided that the 10 pin connector was not needed by most (all?) FRC teams and that the CAN connection is sufficient. CAN is fast/secure enough to run the motion magic and other stuff?
The reason I am thinking this is that the Falcon does not have a 10 pin connector and can only use CAN and it seems like it would have the 10 pin if it was needed. I could be massively wrong on this.
It would be nice to actually see this explained by CTRE but I am unable to find anything in the documentation.

I thought extending the wires would cause signal loss and it’s better to have a short encoder cable.

Since you did say most, I’m curious to know, which applications would it not suffice in?

Since you did say most, I’m curious to know, which applications would it not suffice in?

Any application where it was necessary to know the actual absolute position of your final output without trying to resolve the data through gear ratios and/or other sources of backlash and inaccuracy.

1 Like

Looking at the limited information on the Cancoder… Presumably it will be transmitting velocity and absolute position. and probably pulse counts. Canbus is way too slow for i to be transmitting pulses like a conventional quadrature encoder would. Sorry if I am stating the obvious. Anybody have an idea of the rate it can transmit at using the FRC Canbus?

CTRE’s other CAN sensor product, the CANifier, transmits quadrature inputs at a 10 ms rate by default. So I would suspect the Cancoder would be similar.

2 Likes

Cool. I didn’t think to look there.

With that kind of ribbon cable it should be possible to have a decently long run (three or four feet easily) that could connect a remote encoder at a critical point while letting the Talon stay on the electronic board. We just barely made that work for our elevator last year and only with a lot of finagling about where we placed the Talons.