Tonight at Muskegon competition, we updated our spark maxes to the latest firmware version-- 1.1.33. Our robot and our code was working fine before the update. However, when we turned the robot back on after the spark max update, the PID loop we had running on a talon SRX, which was wired into the can network along with our spark max, was behaving erratically. The PID would go at varying speeds, to varying positions. It didn’t seem to have any rhyme or reason to it.
As the only thing that had changed was our spark max version, we reverted them to 1.1.31. Our PID loop was still behaving oddly. It didn’t resume normal function until we returned it to factory default.
Does anyone have any idea of what happened here? Any help would be appreciated.
A few questions to help us get a better idea about your system:
- Are your SPARK MAXes connected via CAN inline with the Talons?
- Have you tried replacing the Talon to see if it’s just that one controller?
- Are you able to use the Phoenix Tuner to manually run the Talon(s) that is behaving erratically?
- NOTE: Running a “Self-Test” on the affected controller(s) from the Tuner should also provide some meaningful insight
In your code, do you follow the best practice of using the talon software commands to return it to factory default and then re-set your gains, slots, current limiting, etc?
1706 can confirm this issue and solution. Seemes to only show if if you have very tight pid control loop. This didnt show up in our elevator, but did on our differential swerve code. Here we are controlling 8 neos to within 1 or 2 rpm. Those were having extreem issues. Started ok for a match then steadily got worse till it was almost not driveable.
Credit to Lutheran Roboteers (4329) for giving us the heads up on this post.
That seems slightly different. OP is having issues with Talon SRX PID loops, not SPARK MAX PID loops.
I’m interested in your issue, though. Could you describe it in more detail? We had something that sounds like it might be similar with our own swerve, though it’s a traditional coaxial.
The Spark MAXES are connected inline with the Talons. We haven’t replaced the Talon, seeing as that after a factory reset it returned to its prior functionality. The Phoenix tuner could be used to manually run the talon that was behaving erratically, and a self-test was run. All values returned normally.
Let this be a lesson to always run a “Talon.configFactoryDefault();” in your robot init. We do this and it has completely eliminated wacky and difficult-to-debug behavior.
Agreed, but we did see red flashing lights on the talon SRX, indicating a fault, even though it was working well. Seems like it was a CAN fault of some sort. After the factory reset and reverting the firmware on the Sparks, the red flashing lights went away on the SRX and the pid issue seemed to go away on the spark. Very strange problem.
That’s a new one. We currently have our arm off our robot as it fits in our withholding allowance, and we updated the SPARK MAXs for it to 1.1.33… but, due to the nature of withholding, we haven’t actually tested them with mixed back in with Talons yet. I’ll be on the lookout for that issue; thanks for the heads-up.
@dyanoshak @Will_Toth would rev have any insight into the issue with the spark maxes and talon srxes?
There isn’t a whole lot of insight I can give about how other CAN devices behave, but I can give a few notes about v1.1.33 and our CAN communication:
- There were no changes to any of the CAN communication between v1.1.31 and v1.1.33
- The SPARK MAX and associated roboRIO API operates within its own CAN ID space (manufacturer ID = REV) while other devices use a CAN ID space according to their own assigned manufacturer ID. The only exception to this are received commands from either a broadcast source or the configured follower
Any ideas on why a flash of microcode would solve the issue? It was a very clear and repeatable problem that was solved by re-flashing the microcode. It did show up again, so I now agree that it may not be that release, but something is still going on that is fixed at least temporarily by a re-flash of microcode.
Which version did you re-flash, did you go from v1.1.33 to the same v1.1.33? In that case I don’t expect any differences in performance, as nothing has changed.
Can you provide details on how to re-create the issue to see if we can do the same here?
sent you a message
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.