View Single Post
  #8   Spotlight this post!  
Unread 13-09-2015, 14:52
Chris_Elston's Avatar
Chris_Elston Chris_Elston is offline
Controls Engineer
AKA: chakorules
FRC #1501 (Team THRUST)
Team Role: Engineer
 
Join Date: Feb 2004
Rookie Year: 2001
Location: Huntington, Indiana
Posts: 751
Chris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond reputeChris_Elston has a reputation beyond repute
Re: PID functionality on the Talon SRX?

Quote:
Originally Posted by CadetGizmo View Post
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
__________________
Team T.H.R.U.S.T. 1501
Download all of our past robot's source code here:Repository

Favorite CD quote:
"That can't be their 'bot. not nearly enough (if any) rivets to be a 1501 machine." ~RogerR: Team #1369