CANTalon getEncVel update rate

[Oblarg]

So, in order to aid with PID tuning we log our encoder readings to a file on the roboRIO. The subroutine that writes values to our log file is called from a command that is run by the scheduler in the main robot loop. Previously, we had used CANTalon.getEncVel to log the velocity readings - but we were constantly perplexed because, when doing this, the update rate of the recorded velocity value appeared to be significantly slower than the frequency of the main loop, resulting in plots which looked "step-like" (there'd be 5 constant data points, and then a change in value, and then 4 more data points at the new value, etc).

Today, on a hunch, we changed the logging function to call CANTalon.getSpeed, instead, and the problem went away.

Has anyone else noticed anything like this? It seems bizarre that any of the CANTalon methods would update at a rate slower than the roboRIO's 50hz main loop, given how fast the Talon control loop runs.

[Ken Streeter]

Originally Posted by Oblarg

... we had used CANTalon.getEncVel to log the velocity readings - but we were constantly perplexed because, when doing this, the update rate of the recorded velocity value appeared to be significantly slower than the frequency of the main loop, resulting in plots which looked "step-like" (there'd be 5 constant data points, and then a change in value, and then 4 more data points at the new value, etc).

Today, on a hunch, we changed the logging function to call CANTalon.getSpeed, instead, and the problem went away.

Has anyone else noticed anything like this? It seems bizarre that any of the CANTalon methods would update at a rate slower than the roboRIO's 50hz main loop, given how fast the Talon control loop runs.

Well, the good news is that the behavior you observed with the "step-like" updates of getEncVel every 5 cycles through the RoboRIO loop exactly matches the documented 100ms update rates for the API that fetches the values for the Encoder in the TalonSRX. This is because the Quadrature Encoder Status message is updated every 100ms.

This is described in the Talon SRX Software Reference Manual (see the links at https://www.ctr-electronics.com/talo...ical_resources ). The Quadrature Encoder Status frame is described in section 20.3. Your circumstance is also in the FAQ as question 16.9.

I know it's quite a tome, but there are some valuable things to be learned in the 160+ page Talon SRX Reference Manual.

The key thing to know in your specific usage scenario is that if you ensure your Talon in question is configured with the selected sensor being the Quadrature Encoder, you can then use the various calls like getSpeed() etc., as you found, to get information for the selected sensor, as that is updated every 20ms, as described in section 20.2 of the Talon SRX Reference Manual.

[Oblarg]

Originally Posted by Ken Streeter

Well, the good news is that the behavior you observed with the "step-like" updates of getEncVel every 5 cycles through the RoboRIO loop exactly matches the documented 100ms update rates for the API that fetches the values for the Encoder in the TalonSRX. This is because the Quadrature Encoder Status message is updated every 100ms.

This is described in the Talon SRX Software Reference Manual (see the links at https://www.ctr-electronics.com/talo...ical_resources ). The Quadrature Encoder Status frame is described in section 20.3. Your circumstance is also in the FAQ as question 16.9.

I know it's quite a tome, but there are some valuable things to be learned in the 160+ page Talon SRX Reference Manual.

The key thing to know in your specific usage scenario is that if you ensure your Talon in question is configured with the selected sensor being the Quadrature Encoder, you can then use the various calls like getSpeed() etc., as you found, to get information for the selected sensor, as that is updated every 20ms, as described in section 20.2 of the Talon SRX Reference Manual.

Thanks for the info.

We look things up in the reference manual whenever possible, but if you don't exactly know what to look for it's sufficiently lengthy that it can be difficult to find things. I confess I haven't read it cover-to-cover.

We generally don't like to use getSpeed, because we try to avoid using the Talon's internal unit scaling whenever possible (we like our units in RPS, not RPM, and it is easier just to make sure every function we call gives us native units and scale them ourselves).

[Ken Streeter]

Originally Posted by Oblarg

We generally don't like to use getSpeed, because we try to avoid using the Talon's internal unit scaling whenever possible (we like our units in RPS, not RPM, and it is easier just to make sure every function we call gives us native units and scale them ourselves).

I'm a fan of using all native units, too. getSpeed() continues to report in nativeUnits if one simply never calls "ConfigEncoderCodesPerRev()"

We intentionally do not call ConfigEncoderCodesPerRev() so that we receive sensor positions and velocities in native units, as described in the table in section 17.2.1.

[Oblarg]

Originally Posted by Ken Streeter

I'm a fan of using all native units, too. getSpeed() continues to report in nativeUnits if one simply never calls "ConfigEncoderCodesPerRev()"

We intentionally do not call ConfigEncoderCodesPerRev() so that we receive sensor positions and velocities in native units, as described in the table in section 17.2.1.

Yeah, but we occasionally use the CTRE mag encoder, and so if we call getSpeed we need to have an extra if statement and change our unit scaling (unless there's some way to use the CTRE mag encoder without leveraging the internal unit scaling?).

[ozrien]

Originally Posted by Oblarg

...(unless there's some way to use the CTRE mag encoder without leveraging the internal unit scaling?).

Just select Quadrature, its equivalent to CTREMagEncoderRelative without unit-scaling.

You can still init the selected sensor (quadrature) position with the PulseWidthPosition to benefit from the magnetic absolute position.

[Oblarg]

Originally Posted by ozrien

Just select Quadrature, its equivalent to CTREMagEncoderRelative without unit-scaling.

You can still init the selected sensor (quadrature) position with the PulseWidthPosition to benefit from the magnetic absolute position.

Oh, cool. We'll implement this right away, thanks!