Today we got a chance to do some more testing and we were able to recreate the switching scenario many times within a few minutes. They didn’t seem to be linked to any hard landings or sharp turns. We tried switching around the wires to some other Spark MAXs but that didn’t help either. The lights continued to show the correct colors based off of the joystick input even if the actual robot was driving the incorrect way. Unfortunately we still have no idea what could have caused this although one of our mentors has a theory that the static build-up on our robot from the carpet could be causing this.
Hi, I’m the CSA who helped them at their event.
In their code they use 2 speedcontrollergroups, and the inversion is set there, not over CAN to the sparkmax. Here’s the relevant wpilib source: https://github.com/wpilibsuite/allwpilib/blob/main/wpilibj/src/main/java/edu/wpi/first/wpilibj/SpeedControllerGroup.java. The inversion is contained entirely within this class, it just calls the set() method in the super, and inverts if the invert flag is set. I also suspected this as a possible root cause, but HQ lead me to conclude it is not.
When the inversion occurs, the DS still reports each joystick axis properly. The sliders on the USB tab move as you’d expect, on the axis you would expect.
We could also replicate this on the practice field. They were not driving the robot hard so a brownout being the root cause is unlikely.
EDIT: Also if it was a sparkmax issue I’d expect each one to invert independently. They always invert as the pair.
Hi! If you haven’t figured it out yet-- I’m Noah Solomon, Spartronics 4915’s programming lead.
Our team had this exact kind of seemingly impossible problem with Neos and Sparkmax – when we got hit during matches the joystick would sort of rotate. Someone eventually suggested that it was that the motor was losing its configuration – our right motors are both inverted, while our left motors are not (and the left/right each have the back motor as a follower).
I made this spreadsheet showing and finally determined that it’s that the motor states are lost – if the right motors went the wrong way always it would move just like it does when the error occurs. We reconfigured the motors using the Rev tools so the flash memory has their states; when the wiring like gets jostled enough they lose power they won’t go back to default. We confirmed that this should solve this by running code that does not set states at the beginning, and the robot driving fine. We also have a button on the joystick that during a match when pressed sets the followers and reversals just in case we are e.g. using a replacement motor/motor controller that is not configured and it breaks.
If configuration is for some reason not working i suppose you could try the kind of dumb sounding higher step of running the motor configuration code in the loop rather than just at the beginning/when a button is pressed (thought that might cause problems e.g. if it causes delay for the motors)
Hope this made sense! We spent like 2 weeks with no clue basically, ask me any questions if you need more help.