Talon SRX Encoders

[JML]

Our team is using 8 Talon SRX Motor controllers to drive our robot with a swerve drive drive train. there are quadrature encoders on the wheels for rotation, which are wired into breakout boards on the Talon SRX Controllers. This created an inconsistency in the drive as compared to when they are plugged directly into the RoboRIO, as the encoder values are 4 times higher than we would expect them to be, so we divided them by four to simply test if the system would work, but there is still some shakyness in the wheels.

According to the Talon SRX software manual (http://content.vexrobotics.com/vexpro/pdf/Talon-SRX-Software-Reference-Manual-20150201.pdf) (Page 66):

17.1. (Quadrature) Encoder Position
When measuring the position of a Quadrature Encoder, the position is measured in 4X encoder
edges. For example, if a US Digital Encoder with a 360 cycles per revolution (CPR) will count
1440 units per rotation when read using “Encoder Position” or “Sensor Position”.

The velocity units of a Quadrature Encoder is the change in Encoder Position per TvelMea
(TvelMeas=0.1sec). For example, if a US Digital Encoder (CPR=360) spins at 20 rotations per
second, this will result in a velocity of 2880 (28800 position units per second).

It was brought up that the Talons could be summing together four values, or the input could be lagging behind by four ticks, which would cause the issue we are seeing. If anyone knows how this functionality is implemented or if we could "turn it off" that would be very helpful, I cant seem to find anything in the talon documentation about this, other than the section i posted, i will check the roboRIO web interface as soon as i get to our robot to see if it is something about it there

[Jefferson]

Our team is using 8 Talon SRX Motor controllers to drive our robot with a swerve drive drive train. there are quadrature encoders on the wheels for rotation, which are wired into breakout boards on the Talon SRX Controllers. This created an inconsistency in the drive as compared to when they are plugged directly into the RoboRIO, as the encoder values are 4 times higher than we would expect them to be, so we divided them by four to simply test if the system would work, but there is still some shakyness in the wheels.

According to the Talon SRX software manual (http://content.vexrobotics.com/vexpro/pdf/Talon-SRX-Software-Reference-Manual-20150201.pdf) (Page 66):



It was brought up that the Talons could be summing together four values, or the input could be lagging behind by four ticks, which would cause the issue we are seeing. If anyone knows how this functionality is implemented or if we could "turn it off" that would be very helpful, I cant seem to find anything in the talon documentation about this, other than the section i posted, i will check the roboRIO web interface as soon as i get to our robot to see if it is something about it there

The Talons are always in 4X mode, and I don't believe there is a way to change that. I'm guessing the encoder objects on the roboRIO are in 1X mode. Is there an issue with simply multiplying your setpoint by 4?

[Levansic]

What is the time delay in the loop that sends motor commands?

Using the Talons with encoders requires communication over CAN. There will be more latency than issuing a PWM command. In human-scale timing, it is imperceptible, but it is enough to make control loops appear to behave differently if the assumption is that you have a very fast and very consistent timing in your loop.

I don't know what programming language you are using, but for our team using LabView, we decoupled our control loops from the loop issuing motor commands. In this way, our correcting control runs as fast as we can get new data from our feedback sensor (a gyro), and the motor commands are issued more slowly, which allows for the CAN latency.

One last thing you may want to look at is the PIDF tuning on the talon itself. The PID on the talon runs at a very fast rate. The coefficients used on it will not be the same as what you would use on the RoboRio. You have to tune those to the motors and gearing attached. You may have an aggressive or unstable set of coefficients loaded on the Talons, which may be just fine when running on the RoboRio, or vice versa. I would reccomend making a program that ramps the speed up and down in both directions to tune the PID parameters. Step functions are fine for setting the P and I terms, but really good control can be attained by further tuning the D and F with a sawtooth input.

[Alan Anderson]

Are you doing the closed-loop control in the roboRIO code, and just using the Talon SRX as a way to read the encoder values? Doing that will result in some sensor lag, because the CAN communication is not instantaneous. The Talon status frames from the Talons are sent periodically. If you have enough CAN bandwidth, you can change their rate to be sent more often, which should help.

[ozrien]

but there is still some shakyness in the wheels.
Jlyon, I think you need to better explain that. I would put the RIO encoders into 4X mode and retest so you can compare apples to apples.

or the input could be lagging behind by four ticks
4 Ticks? That sounds pretty accurate to me. Unless your encoders are very low resolution.

Please read section 16.9 if the observation is that the Talon encoders are "behind" the RIO encoders only when encoders are spinning. In which case do the math to see what 20ms of lag (at your RPM) should do in terms of encoder difference If that's a problem tweak the status frame rate to be faster (section 20.5).

If you problem is that there is error between Rio and Talon when the encoders are still then the root-cause has nothing to do with the frame rate.

If you're using LabVIEW (you didn't mention what language you were using) avoid calling Motor-Enable continuously since that will re-set the sensor position.