Hello all,
I am currently trying to use the Position closed loop control mode with the Talon SRX and an analog encoder to control a swerve wheel. However, all I get for results is a continuous spinning of the wheel. I have tried changing the PIDs, setting number of Pot turns, and using different units for specifying position. One odd thing I did notice in the web dash is that under self test, a large movement in the wheel only changes the Position (rot) by ~.2 units which doesn’t seem right. Any help on this issue would be much appreciated!
What kind of sensor are using for positioning and how is it connected to the Talon SRX?
A US Digital MA3 absolute encoder. It is connected via a MVRT breakout board. I also realized that the (rot) should only increase by a fraction as it is between 0 and 1 rotation so please disregard that particular “issue”.
If the thing is spinning off to infinity, you probably have an unstable feedback loop due to the sensor and motor being out-of-phase (i.e., sensor forward is not encoder forward). Try calling reverseSensor().
It is hard to make sense of your units to know if that is indicative of a problem without more information; I assume from your claimed value that you are leveraging the Talon’s unit scaling, which means that the units are encoder rotations. This may not be the same as your wheel rotations, depending on how your swerve drive is set up.
We just had the same problem using the US Digital MA3 encoder with 12 bit PWM output. Our arm would go the wrong way when using position control. We called CTRE and found out the problem was due to using Current Limiting Control. Turning off Current limiting fixed the problem but our arm moved awfully fast. Turns out you can use some of the voltage limiting features without problems (ConfigVoltageCompSaturation, EnableVoltageCompensation functions). CTRE is doing testing to try to replicate the problems.
We have had problems with current limiting causing unpredictable/spastic motor behavior in assorted control modes, as well.
When we see it spinning like that the first thing we check is if the encoder is reading backwards. 90% of time that is it.
after that we may need to see code - (we are using swerve again with labview).
I realize this thread got kind of hijacked/necro’d, but I wanted to update on the current limiting issue.
It appears that the problem is caused by not setting ConfigPeakCurrentDuration( duration, timeoutMs).
Duration can even be zero, but it has to be set at least once.
It has to do with the peak current limiting logic in firmware - the factory default value yields an undesired result.
Fixed firmware will be released soon, but for now it will be listed as an errata in the documentation.
Details on the errata here…