pros/cons of wiring sensors to can talon srx
 

Hi,
My team is using can talon srx first time this season. We are running low on dio ports on roborio. We are tossing around ideas to avoid running out of ports and one idea is to wire some sensors directly to the can talon srx. We are thinking of encoders and limit switches mostly. Maybe a pot. From what I can tell, we can read these sensors using can talon class and use the values in our robot code. Even if we don't want to use any close loop control on the talon. To me it looks like a no brainer method to avoid running out of ports. And I like having the option of running closed loop control on the talon if we so choose. We would have to purchase breakout boards/wires and figure out how to hook up the sensors directly to talons. Learning about that is the only downside I see so far(if you can call learning something new a downside).
Any other downsides?

Thanks.
-Maciej

Re: pros/cons of wiring sensors to can talon srx
 

The only con I have comes from having to manage your code in two different places. Your PID tuning/etc comes from the Talon web interface, and the logic code comes from the robot code. Your robot code has to perform all boundary and logic checking prior to sending the desired position value to the SRX.

We have a filter for "maximum speed" on each mechanism as a safety when new kids are learning PID, and that filter is the last line of defense when things go awry.

Even with that said, this year we're putting sensors directly on the SRX's because we're attempting two things we've never done before: a double-jointed arm and a turret. Both are easily coded and tuned while physically off of the robot though.

Re: pros/cons of wiring sensors to can talon srx
 

A lot of this is in the Talon SRX Software Reference Manual...
http://www.ctr-electronics.com/talon...ical_resources
You can also set your gains using robot API(section 10 Talon SRX software ref manual). Also check out all of our examples on our github/software reference manual. Your post suggests that web-interface is the only way.
Talon SRX allows you to cap the maximal outputs during closed-loop (section 10.5). So that means you can do this with SRX Closed-Loop as well.
You mean you have to tell the Talon what position to servo to, which is correct. How else could that work? :)
Section 16.9 talks about that a bit, but yep that's the point. Talons can be used to extend the number of inputs in your control system: limit switches, analog inputs, Pulse-width, and quadrature signals, and more to come. Checkout section 20.5 to tune how often signals get updated.

But I think you'll find the closed-loop examples available for Talon SRX will help quite a bit if you go that route.

Re: pros/cons of wiring sensors to can talon srx
 

We did what you are considering quite a bit this off season. There were no cons for us, although all the sensors are used by the SRX itself and we are getting informational values. Our RIO is almost bare this season!

The SRX manual talks quite a bit about update rates and monitoring the CAN bus for issues if you need to adjust the data rate back to the RIO for some reason.

Not true. You can do everything from within your robot code using the provided API.

Re: pros/cons of wiring sensors to can talon srx
 

One pro for us last year that we implemented mid season was wiring our limit switches for hard stops directly to the Talons.

Twice during the season we had our robot start turning on all the motors randomly in the middle of a match (possibly dead lock) One time a mechanism was damaged a bit because it didn't stop at the hard stop due to the limit switch not being checked. After this we wired the switch directly into the Talon. The next time the robot code crashed/locked up the mechanism still stopped properly when it hit the limit switch and didn't over run the hard stop.

From that experience we basically decided that limit switches for mechanisms that absolutely can not over run their hard stops will be directly wired to Talons to provide an extra level of protection if our code ever crashes or dead locks.