We have been having this issue where our autos will reverse on start and we could not figure out what was going on.
Today we figured it out.
When we turn on our robot and push it around, like when we are setting it up on the field, it’s creating a backvoltage generated by the motors and resets the sparkMax controllers.
To ensure this problem does not happen to you, make sure you set all of your motor settings on autoinit and teleopinit.
We haven’t had the issue since.
We make sure we call burnFlash() after configuring our sparkMax controllers (just call this once after making all your configuration changes). I think this is an alternate solution (and perhaps better in case your sparkMax resets during a match).
We have that. It doesn’t solve the issue above. Something else is happening to the controller. BurnFlash() is for maintaining settings through brownouts.
The issue we were having is that the settings are getting corrupted even though they are burnt in.
We don’t have the issue anymore. Resetting the motor settings on autoinit and teleopinit fixes everything.
How did you verify this as the root cause?
OK, I can’t seem to edit my post so I will put everything here and mark it as a solution.
Though all of the things we implemented worked for several matches, it started happening again. What does that mean, IT IS NOT THE SPARKMAX. I was wrong.
So, I tried something else. I RIPPED OUT the RoboRio 2.0 and put in a RoboRio 1.0. Guess what, 5 matches in and NO PROBLEMS. It appears all these issues are the RoboRio 2.0.
Again, how did you verify this is the root cause? This sounds more like coincidence and confirmation bias.
If this is in fact the issue, I have a feeling NI and Rev would like to know more, and a lot of teams will start to get a little nervous.
If it’s just in autonomous and doesn’t affect teleop, it’s more likely just an issue with your autonomous code.
The TeleOps would also not work. We would have to click on Reboot Rio from the Driver Console during the match to get it working again.
Our code is public and quite simple.
FRCTeam5484/2022-FRC-Comp (github.com)
To see the whole sequence, go to the Twitch stream and time index 3:19
FIRST Robotics Competition | Tippecanoe District Event Practice - Twitch
PS, we also could duplicate the problem on the practice field and in the PIT. Every 5 or so times when we disable the robot and re-enable it (in TeleOp), the motor controller would reverse.
PS, its not just a one off RoboRio 2 issue either. This is our second RoboRio 2. I’m done with the RoboRio2 for awhile now.
Whoops, did not realize you were on 5484. I saw what was happening during that match but couldn’t see much from behind the glass.
I will take a look at your code when I can get on a computer.
It was great playing with you this weekend!
FYI, we’re running Spark maxes with the roborio 2.0, so I’m particularly concerned with this issue if it is in fact a problem with the rio. We haven’t had any issues thus far though.
No worries, it has been a frustrating issue. It was great playing with you too!
Do your symptoms match what is described here Neo not working during practice match
Several of the listed issues are issues we were having. I wonder if the SparkMax TimeOut setting would resolve them. I could try to do the “Check every parameter and send it again if it did not set” but at this point, I’m going to stick with the Rio1 which has never had this issue.
Let me be clear, I DO NOT DEFINITIVELY KNOW exactly what the root cause is. All I can say is that the problems stopped after replacing the Rio2 with a Rio1 running the SAME CODE.
I can confirm we had a similar issue with the robot driving randomly or skipping commands in our auto sequential command group.
This issue only happened after someone pushed the robot around while it was on. We resolved this issue by not turning the robot on until it was fully in position.
We use Rio1s with SparkMaxes and NEOs.
Hey @dylan292, We had this problem a long time ago and this was resolved by resetting the encoders before each move sequence. You may be doing that already but I wanted to share just incase you aren’t.
If by reset you mean set the position to zero, we do that.
I call the function to zero them at the start and end of every drive command.
But sometimes when the robot is pushed around while on, it acts like it just doesn’t zero the encoders.
Interesting. I don’t know what is going on. Hopefully, someone smarter than me can figure it out.
Have you tried outputting your encoder positions to SmartDashboard and seeing if its resetting properly?
No and I probably should to be honest. I’m just the only person on my team’s programming team and I have been working on more important stuff.
It’s kinda a non-issue as long as you don’t turn the robot on before it is positioned it seems.
Without seeing any data I am not convinced that what you describe is the actual root cause here. That is why I previously asked OP:
Specifically how was this statement confirmed, since this does not sound like a behavior that makes sense.
The problem is, none of us know what the root cause is. I didn’t create these devices and I didn’t create the libraries that control them. All we can do is test and make hypnosis from the results.
Why am I thinking that it’s possibly a back voltage issue is because when I roll the robot the PDH powers up. This means that the wheels are generating power connected to the motors connected to the spark Max connected to the PDH. And the problems are most prevalent when this action has occurred.
Again, smarter people than me need to figure out what is going on. All I can do is tell you what I’m experiencing in the field. And what I’m doing to work around it.
(Will used to work for REV and is one of the people that originally wrote the SparkMAX libraries)