Request TalonSRX Reset API

I am one of the programming mentors for team 2052. This year our team has over 10 new programmers with almost no prior experience, this combined with a brand new TalonSRX API has introduced a number of interesting challenges this year.

One of the larger issues we have encountered is the TalonSRX config setting being persistent across power off/on cycles. Students try different config settings to attempt to accomplish something. They set the value, then when it doesn’t work, they delete that line of code and try a new setting. What they often don’t realize is that the config setting they tried is now “forever” part of the Talon’s behavior. This has the potential to cost programming teams many hours of trying to figure out why their code isn’t working correctly, not realizing that the talon now has max speed limits, ramp rates, or other configurations that are no longer in the code.

The solution is to factory reset the talons periodically. Currently the only way to do this is to press the physical button on the Talon. Perhaps our team is unique in our control board configuration, but we will often stack our talons two high, especially for our drive train which usually has two motors on each side. We stack the left and right talons. This year is better, but in 2016 and 2017, we had so many space issues the talons were pushed into tight corners of the robots, under other mechanical components. This makes it very hard to factory reset the Talons because it means some, or perhaps significant, disassembly of the robot to get to the physical buttons on the Talons.

Yesterday I emailed CTRE support requesting they add a software reset in their API so we could reset all configuration values back to factory defaults, to avoid the need to press the buttons on the Talons. I explained it was a “big problem” (for us) that the only way to baseline a Talon back to a “known state” was to press the physical buttons on the Talon.

The response from CTRE was polite and professional. In the response they said.

  1. It is a poor design decision to place Talons in such a configuration where the reset button is not easily accessible.

  2. It isn’t a “big problem” because I was the first to every request a configuration reset in the software API. They have discussed adding a reset method to the API, but it isn’t certain they will do it and probably won’t add it until next year.

When a previously working robot, suddenly starts to exhibit strange behavior, a great troubleshooting step is to go into version control and rollback your code to the last time you knew the code was working correctly. This is especially true when the software group says it is a hardware issue and the build people say it is a software bug. Before taking apart any parts on the robot, the best thing to do is to get the code back to a “last known good state”. If the old (good) code works, then yes it is a new software bug, if not, something physical happened. Unfortunately rolling back the software isn’t enough with the TalonSRX. You must also factory reset the Talons to ensure you are at a guaranteed “known state”. For us, factory resetting the talons is something we have had to do several time as part of the troubleshooting step of getting back to a “known good state”, and pressing those buttons is not trivial given our control board layout.

I’m writing this CD post for three reasons.

  1. Not everyone realizes that config settings are saved forever. If you accidentally set the wrong config settings, or remove a config that is no longer needed, it isn’t gone. The only thing that is gone when you delete the code is the clue that it was ever set, which can make troubleshooting a challenge. Please share this with your programming team.

  2. The support person at CTRE was awesome. He replied to my email on a Sunday within only a few hours. It was clear that he was interested in our procedures for managing our code and asked several questions in response. CTRE is interested in feedback on their product. If you agree that there should be software option for config reset, or a way to turn off config persistence, please email [email protected] I was surprised I was the only person to email about this feature. Perhaps more people requesting this feature will encourage them to add it. CTRE is super responsive to support and very friendly.

  3. Has any team created their own way of putting all config settings back to default values by finding all config settings, discovering their default values, and then writing code to baseline every value in every slot index? If so, are you willing to share? We have not done this yet. We probably will, but I thought I would ask if anyone has already written the code to do this.

thanks!
-Scott

Scott,

I can attest that our team has hit this issue as well (change a setting, doesn’t work, remove the line of code, wonder at odd behavior, remember again that settings are persistent). I’ll send an email.

To deal with this exact problem, we set all config settings on start up always. We have a list and are willing to share that part of the code. We don’t set a few of the more terrifying settings like the talon frame rate. We aren’t sure what the factory defaults are for all settings, so instead we default to values which make sense as default given our preferences. (Overriding defaults as needed) If anyone has a list of what the actual factory defaults are that would be great. I personally don’t really want a factory reset API call.

Good feedback Ryan. We setup all our configs on start up as well, but you never know what a student may have accidentally set by picking the wrong API (even the scary ones) and deploying code. Would you be in favor of a “don’t persist config settings” feature?

We also worked around this be configuring all talon parameters on startup of the code. We have a custom robotDrive class and all talon configuring for drive motor controllers is done there. Same thing for arm, intake and winch classes.

The whole issue did cause some problems for us until we worked out what was going on.

but it isn’t certain they will do it and probably won’t add it until next year.

Actually my exact response in that email was “If the factory default routine doesn’t unexpectedly break wear leveling, expect it next season”

So the point of this thread is convince CTRE(us) to implement this sooner then next season? I don’t think there is a major benefit to rush this feature out this season.

We’ve been bitten by this. We have two Talons in master/follower configuration running our lift with soft limits at the top and bottom. When we deployed code from the practice bot to the competition bot we realized the ids for the master and follower were flipped. So, we changed them in our robot map. This left the follower with soft limits enabled, but no sensor attached…which meant it could go up, but it couldn’t go down. We added code to disable soft limits on the follower should such a thing happen again.

I have found that reviewing each Talon in the rio’s web interface is a good way to see any config settings at a glance. That’s how we discovered the issue on the follower.

I felt like we were pretty clearly warned about the persistent settings in the migration documentation from CTRE and, especially, in the new API naming. The persistent settings are manipulated with “config*” calls versus “set*” calls. The automatic factory default reset that happened when going from firmware 2.34 to 3.x meant we had a fresh start where we really needed it.

That said, I’d be in favor of adding an API option to reset everything to factory defaults, as long as it can be implemented in a way that doesn’t re-write the parameter storage needlessly. We have several lines of code that put persistent settings back to defaults. It would be nice if could have just removed them after deciding the custom value wasn’t something we wanted to keep.

Joe.

Hi Omar!

I agree, most teams have probably addressed the issue one one way or another by now. I’m not requesting a rush, but would like to see this at some point.

The point of this thread is listed in the original posts. Share a tip for troubleshooting, see if our team is really the only team that struggles with this behavior, and see if anyone has a manual reset option we can borrow.

Thanks again for your excellent response to my email yesterday.

Another alternative would be a Factory Reset on the RIO “web” interface. But since that will likely require an API change to the Talon anyway…

Is it possible for CTRE to publish a sample util that would set every single config to the factory presets?

Sure I guess? It could come in handy if we are playing with some of the more bizarre settings and aren’t sure what the talon factory default is.

To be clear I have no problems with any of the features purposed thus far, but if everything is set on start up, the Talon having persistent set calls doesn’t really matter. (Outside of brake vs coast in the short period before the code starts up, but that shouldn’t matter). Thus, a mistaken API call removed in the code wouldn’t matter. I understand that implementing this solution takes a lot more work, but you can set up your own talon class/vi which sets everything to your defaults or what you explicitly state in the code.

<Evangelizing for ROS>
I really like our structure for initializing Talons and I think it solves some of these problems. We use config files and have a code platform based around ROS, specifically using ROS controllers and instantiating talons as a custom joint type. All settings are set to some defaults we have determined and then config file sets can override those defaults as well as real time sets. This makes it easy to track down issues using source control or just in general. If the talons are behaving strangely, we can either roll back code and test, look at the history for changes to config files, or even run a different launch file (such as one for tuning PID) which uses test config files and instantiates the joints independent from the controller so the values can just be set from command line. That last option doesn’t even require recompiling code.
</Evangelizing for ROS>

This would be really nice if only just to see what all defaults are.

I agree. Just posted.

We’ve had to quickly swap talons around between matches. Add me to the list of making a full default reset to the API as a great need. A helpful step would also be a set of buttons in the Web control panel. Something with confirmation/feedback of the reset.

Thank you for the list of all config settings and the default values Omar. Very helpful.

So are those just the persistent parameters? I don’t see the frame rate stuff, for example …

Those are just the persistent parameters.

The frame rate settings are not persistent and the defaults are already documented here: GitHub - CrossTheRoadElec/Phoenix5-Documentation: Phoenix-Documentation

Closing out this thread, the requested feature is available in latest installer for Java/C++/HERO-C#. Labview will have it in next release. Details here…


… this includes a new config-everything-single-function api, a factory-default routine, and default params for several routines.

Thank you Omar!!