Finding Edges per revolution for Falcon 500 with Talon FX

Technical Motors
1

Hello,

I was working on characterizing a motor. I ran in to a problem because I needed to find the edges per revolution for the motor. I found CPR on the Falcon 500/Talon FX documentation which turns out to be 2048 CPR. Is there a way to switch between CPR and Edges Per Revolution?

Thanks,
hfrughfg

Here is a link to the tech specs:
Link to CTR tech specs page

2

The Talon FX reports 2048 units per rotation. There are no edges because its not an external quadrature sensor. If you include more details on what your trying to accomplish, you will probably get better answers.

1 Like
3

Hello @ozrien ,

I’m trying to build a shooter with 2 falcon 500s with talon fx built-in. I am currently characterizing the motors but I ran into the problem when I was finding the edges per revolution of the flywheel. I know that the ratio to turn the flywheel is 1 rotation of the motor: 1 rotation of the flywheel.

I hope you can help me with this additional information.
Thank you so much!

hfrughfg

4

There is no difference when using Talon FX’s integrated sensor.

The Talon FX reports 2048 units per revolution. If polling the velocity, the velocity will be in units of change-in-pos/100-miliseconds.
https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html#sensor-resolution

You can confirm this experimentally by performing sensor-bring up (Control tab and self-test)
https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html#sensor-check-with-motor-drive

1 Like
5

Thank you!

6

Is TalonFX not a Quadrature encoder? That would explain why there’s no difference.

7

We’ve been struggling with the terminology to use in the characterization tool config/documentation for a while; we settled on “edges” because it is (for now, at least) unambiguous for quadrature encoders (which are most-common).

We’re not overwhelmingly happy with it, though - that it is inaccurate for the Talon sensor is unfortunate (I was not aware that it wasn’t a quadrature encoder until now). Suggestions for how we might resolve the terminology issue would be appreciated; it’s a lingering problem.

8

Encoder Native units?

9

This is consistent within CTRE’s documentation, but unclear in general (WPILib’s Encoder class takes cycles-per-revolution natively, which is something I hope to change for 2021).

1 Like
10

Fair point. I can’t think of anything that wouldn’t be extremely wordy.

11

This is our problem, in a nutshell.

One option is to just rename the variable to encoderResolution and provide a wordy description, but this runs the risk that people won’t read it.

12

Cycles per revolution has the advantage that it doesn’t change the distance based on what kind of decoding selected.

13

If I have a gear ratio after the talon fx sensor does the edges per revolution changes and how do I calculate it?

14

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.