Talon SRX Position Control

We are planning to use a couple different closed loop control (Talon SRX with Redline encoders and SRX encoders) this year. We are testing the position command and have had trouble getting it to work. At one point we did have it working, but wanted to reduce the speed and try to ramp up and down. We used a long ramp period just to make sure we could see it. It started to work, ramped up and down and but then reversed direction. It kept doing that until we killed the program. Based on some previous posts it sounds like maybe there is an issue with the current limit. At any rate, we commented the ramping setting out, but kept having the problem. So we restored the config to factory default (using Phoenix Tuner), and now it won’t work at all. Is there a guide for the config setting for a particular control type (position, magic motion, etc.)? Or maybe a .json file? Any help is appreciated. Thanks!

1 Like

Steps

Sounds like you are doing things out of order.

Do this first to ensure CAN bus is wired correctly…
https://phoenix-documentation.readthedocs.io/en/latest/ch08_BringUpCAN.html
Then do this to ensure motor, talon, and linkage is healthy…
https://phoenix-documentation.readthedocs.io/en/latest/ch13_MC.html
Then do this to ensure talon sensor is healthy…
https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html
Then follow this for closed-loop and tuning…
https://phoenix-documentation.readthedocs.io/en/latest/ch16_ClosedLoop.html

I strongly recommend motion-magic over regular closed-loop position. It’s only a couple more configs and the result is much better.

Examples

Language examples here…


LabVIEW examples here…

Ramping

I don’t recommend applying a motor output ramp when closed-looping. Using motion magic to control the velocity/accel is a laudable approach, whereas simple ramping the motor output can lag the closed-loop response.

Makes sense?

3 Likes

Yeah, I think so. Obviously we don’t want a lag in the response. We were hoping to start with something a little simpler and work our way up to motion-magic, but we can start there. We’ll try working through the list posted. Thank you for the help!

Thirding cutting straight to motion magic - conceptually it’s a little bit more to understand but ultimately it’s much simpler to tune and have desirable results.

If you’re looking for some conceptual background or practical examples I’d recommend skimming through this University day series from team 195 - https://youtu.be/4rbT-oscpx0

Our software lead got some Command-Based motion magic stuff working this last weekend. It’s the first year we’re trying MotionMagic on the Talons (we have just used PIDController) in the past from wpilib. Given our robot’s geometry, we were accurate to within about 1/3 of inch over a 90 inch run with our DriveMM command.

Here’s the link to our Github, feel free to take what you want or follow along as we improve our autonomous code. Our goal is to spend the sandstorm in full autonomous still. A lofty goal, hopefully we can pull it off.

1 Like

Wow, thank you! We’ll take a look. This is our 3rd year as a team and the first year we’re doing PID controlling at all. Hoping we can get it working. We did get some help from CTRE. It wasn’t working because all the gains were set to zero. I’m not sure why that would make it not work at since the documentation suggests that you start with zero, however using the values in the CTRE example got us heading in the right direction. Used the info in the Motion Control page from there to tune our test motor.