PID functionality on the Talon SRX?

[CadetGizmo]

Hi everyone! First time poster here, so sorry in advance if I'm practicing any ill-advised posting methods.

Our team is considering incorporating PID controllers for either an off-season project or possibly this year's game.

So, I'd like to hear from some people on here who have had past experience with this system! The main things that I'm worried about are pros and cons of the system, but I'd also love to hear anyone's personal experiences with using PID controllers!

[tr6scott]

I might suggest that you post the details of the application where you would want to do this, and then ask for feedback from the community.

The success of the PID solution is all in the details.

If you read the manual, in section 18 they have the code that is running on the Talon SRX.

http://www.ctr-electronics.com/Talon...e%20Manual.pdf

[CadetGizmo]

Ah, yes, sorry. Currently we don't have a type of driving system that we want to implement the PIDs on, but rather the general idea of using PIDs on a drive base in general. We have a 6 CIM lying around as of now, and PID functionality might be a fun project.

[Ari423]

Maybe someone can explain, I never understood the benefit of using PID through the talons (or jags). You have the downside of not being able to see the encoder data on the roboRIO, but what is the upside?

[TheHolyHades1]

Originally Posted by Ari423

Maybe someone can explain, I never understood the benefit of using PID through the talons (or jags). You have the downside of not being able to see the encoder data on the roboRIO, but what is the upside?

With the Talons, you get PID built in. It can run in a tight closed loop, possibly faster than you can with the RoboRIO if you're doing a lot of processing on it. Also, it's harder to get the timing right on the roborio than on the talon which serves as a dedicated processor - along the same lines, it's harder to count all of the encoder ticks, especially if you're using a high tick encoder.

Also, as it turns out, you *can* get the encoder (sensor) data back from the Talon(SRX), in either 20 ms or 100 ms intervals by default. The 100ms intervals will stay (in a different control frame), but you can customize the 20ms interval for the sensor frame.

In short, I think it's just easier to get up and running with that if you're not in the mood to spend hours and hours testing timing code and don't really care to do super advanced control loops.

[GeeTwo]

Also, as you do this, you may want to rethink the placement of the motor controller. If you aren't using encoders at all, or are connecting them to the 'RIO, you'll usually want the motor controller to be on the control board to minimize the number of wires being run out to the motors. With the encoder wires going to the Talon, you may want to move it out closer to the motor and sensor. The combined powered wire run (PDP to Talon to motor) is the main run you want to keep short to reduce resistance losses. Reducing the length of sensor and CAN wires is secondary.

[Levansic]

PID (PIDF) on the Talon SRX is awesome! Now is the time to dive in on an off-season project to figure them out.

We used them for position and speed control this year. They delivered on the promise that the Jaguars couldn't. As GeeTwo said, they pass the data back to the roborio. The onboard loops are very tight, and wiring is really simplified using CAN. We taped over our DIO and AIO ports on the roborio, as we didn't need the FOD traps. The Talon SRX handled the switch IO for limits with the same breakout that we attached the encoder with.

I know that CTRE was working on some cool new expansion sensors for the SRX, which will just make them that much cooler. I don't want to get into those details, as they haven't announced new products yet. There is a lot of upside for this controller. You would do well to learn how to exploit its functionality now, way before build season.

[Chris_Elston]

Originally Posted by CadetGizmo

Hi everyone! First time poster here, so sorry in advance if I'm practicing any ill-advised posting methods.

Our team is considering incorporating PID controllers for either an off-season project or possibly this year's game.

So, I'd like to hear from some people on here who have had past experience with this system! The main things that I'm worried about are pros and cons of the system, but I'd also love to hear anyone's personal experiences with using PID controllers!

We used the Talon SRX and the built in PID this year. Our take is we aren't one of those teams who want to write something from ground up. We tend to look around and not re-invent the wheel if someone has a product that will help us build our robot faster. Our goal is to always have a working robot in 5 WEEKS. Struggling for a couple of weeks with ground-up written software is not for us.

We are EXTREMELY happy with the performance, software, and features of the Talon SRX. I know without these on our robot, our robot would not have been as consistent as it was. PIDs help eliminate driver error with pre-written routines in your machine.

The main advantage our team sees is the following:

1. The processing of your PID loops are handled in a secondary microprocessor, in this example the Talon SRX. Your RIO only sends "commands" to the Talon SRX once you have your Talon "tuned".

2. You're not writing code in your RIO to handle complex PID. For example, the Talon SRX has built in ACCEL and DECEL handling. Here is a demo video from our elevator. The driver just pressed one button on our driver station, and an "automation" routine or a "state logic" machine took over and sent values to the Talon SRX which positions to go to. Look how smooth the ACCEL and DECEL is in the Talon SRX.
https://www.flickr.com/photos/teamth...7653103659130/

3. Something that really, really worried us...It is CAN BUS. If the CAN BUS goes down, we would be screwed. But after 3 District Events, 1 State Champs, and the World Champs, so far...no problems with CAN BUS on our competition robot. We had CAN BUS problems on our practice robot, but I think that is because the CAN BUS wires got tugged too hard one time or snagged on something.


I also disagree with the encoders not being able to be seen, you can see everything about the Talon's SRX. One time, we was troubleshooting the Talon SRX missing encoder counts, so we made this video for troubleshooting help. It turns out it was a software RESET in the RIO that was being called in a loop that was causing the counts to reset (our fault, not the Talon SRX), so we resolved this problem, however you can see the encoder counts LIVE in the video.
https://dl.dropboxusercontent.com/u/...lly-moving.MOV

[asid61]

Originally Posted by Chris_Elston

2. You're not writing code in your RIO to handle complex PID. For example, the Talon SRX has built in ACCEL and DECEL handling. Here is a demo video from our elevator. The driver just pressed one button on our driver station, and an "automation" routine or a "state logic" machine took over and sent values to the Talon SRX which positions to go to. Look how smooth the ACCEL and DECEL is in the Talon SRX.
https://www.flickr.com/photos/teamth...7653103659130/

So are you implementing special code (state logic) on the RIO, or is that entire movement all programmed into the Talon? That is extremely smooth!

[Chris_Elston]

Originally Posted by asid61

So are you implementing special code (state logic) on the RIO, or is that entire movement all programmed into the Talon?

You write all your State Logic in the RIO.

Basically something like this...Let's use the video as reference:

State 1
Grip CAN

State 2
Send Position to Talon SRX = 10,000 counts or "30 inches".

State 3
Retract Drawer

State 4
Send Position to Talon SRX = 9,000 counts or "28 inches".

State 5
Ungrip CAN

etc...

Basically, at those states, you use the Talon SRX library to send position values to the Talon SRX over CAN BUS. It's really easy. Prior to sending commands, you need to TUNE your mechanical system until it's stable, then you can just issue commands or presets to the Talon SRX after that.

The manual referenced above already, is the bible to the Talon SRX library.

[asid61]

Originally Posted by Chris_Elston

You write all your State Logic in the RIO.

Basically something like this...Let's use the video as reference:

State 1
Grip CAN

State 2
Send Position to Talon SRX = 10,000 counts or "30 inches".

State 3
Retract Drawer

State 4
Send Position to Talon SRX = 9,000 counts or "28 inches".

State 5
Ungrip CAN

etc...

Basically, at those states, you use the Talon SRX library to send position values to the Talon SRX over CAN BUS. It's really easy. Prior to sending commands, you need to TUNE your mechanical system until it's stable, then you can just issue commands or presets to the Talon SRX after that.

The manual referenced above already, is the bible to the Talon SRX library.

Oh wow, so all you're doing is just executing one command after another. All the smoothness comes form the Talon. Definitely trying this! Thank you.

[Chris_Elston]

Originally Posted by asid61

Oh wow, so all you're doing is just executing one command after another. All the smoothness comes form the Talon. Definitely trying this!

CORRECT. That's what I mean, the TALON has built in ACCEL and DECEL into their PID algorithms. You can set how smooth or aggressive you want it by another TALON SRX library control. I believe if memory serves me, you use the "SET RAMP RATE" VI.

[Ken Streeter]

Originally Posted by CadetGizmo

Our team is considering incorporating PID controllers for either an off-season project or possibly this year's game.

So, I'd like to hear from some people on here who have had past experience with this system! The main things that I'm worried about are pros and cons of the system, but I'd also love to hear anyone's personal experiences with using PID controllers!

Last year, 1519 used the PIDF control loops in the Talon SRX in our mecanum drive code, as well as for our elevator. We were very happy with its performance, both in teleop and autonomous. Our autonomous performance last year probably speaks for itself.

We'd be happy to provide more info -- look us up at one of the fall off-season events (we're planning to attend River Rage and Battle of the Bay) and we'll be glad to give you more details.

If we're selected as a Beta Test team this fall, we'll probably also have an "open house" event again this year (like the one that 1073 hosted for us last year!) and could provide more details at that time, too.

Lastly, if you want some personal help at one of your meetings, you're sufficiently close by that I could come over if you'd like.