In the past, we typically didn’t save settings like offsets and inversion in the motor controller and opted to do it all in RIO code.
Using Tuner X and Swerve generator this year, it seems to save a lot of stuff in motor controller config. I’m guessing it is to be compatible with WPI lib’s?
We are experiencing a lot of failures where the config is lost. We have not traced what is causing it. We have had 2 NEO vortex’s lose it’s PID gains. On one NEO it happened all of the time. On a second, it just happened yesterday once. And we have had 2 Kraken motors lose it’s inversion settings.
I can’t tell if that is code, i.e. someone is changing inversion of the motor in the code and just forgot about it, or if it is hardware. We did change out the motor and also move the motor to a different PDH slot. It has yet to come back but we haven’t fully tested everything and run it hard.
I’m just wondering with all of these issues with the config changing, wondering if it’s better to change the inversion in code, i.e. negate the command and also burn PID gains on INIT or even have a button in joystick that will burn it or have an auto detection algorithm that checks config every few seconds to see if it has changed.
Wondering if other teams are running into similar config issues. We never had this much problems with Falcons or normal NEO’s last year and years past when I coached other teams.
So, I cant directly speak to NEOs/SPARKs due to my unfamiliarity with REVlib and the implications of the SPARKs ‘burn flash’ requirement for config persistence. However, for TalonFXs, it is ALLWAYS advisable to set ALL motor configs in code. Persistence of motor configs, while an awesome feature for reliability, shoud not be relied upon. Additionally, this shoud be done once on boot due to the blocking nature of most config calls. Furthermore, make shure to directly set all values important to that motor’s operation and use case, even if the default configs are acceptable to you, having those values obviously and directly exposed in code is extremely valuable.
Some teams have implemented wrappers over REVLib and CTRE (less-so since Phoenix 6) to ensure configurations are set. This process is annoying and not really worth it most of the time. For REV most of the missing configuration options trace back to when they’re supposed to be set, unfortunately you can’t verify easily with REV’s current API however you will get errors when you try to set something and it times out, so if you wrap it and then reconfigure it per setting until there is no error returned you are good.
I experienced the same issue, our motor inversion settings on one of our NEO’s would frequently just not be set. I had to put a periodic check to make sure the setting were properly set.