Lately we’ve been experiencing an issue where our robot will boot up and the spark maxes will have changed their follower configurations. The lead motor will be set to be following the follower motor and the follower will be set to be following the lead, causing no motors to spin. We can fix this by connecting over usb, changing the follower configs and burning flash, but this will be bugged again after a couple days. Our robot code is also setting followers, and we’ve checked that the followers it is setting match the followers that we want. Any ideas?
Similar thing resulted in our robot destroying itself last year in our first match of first competition. Hadn’t showed up until then but then it continued to happen randomly through the day. Just the worst! Make sure in your code after instantiating the motor that you set all the parameters for the motors (leader, follower, inverted, etc…) and then use the BurnFlash() method. This was it for us. There are certain times the spark maxs will go back to default settings otherwise unless you’ve done the BurnFlash() thing in the code. Be thankful it showed up before competion!
I wish that worked, unfortunately our lead motors end up following our follower motors so I’m not sure how to burn the flash with them not having a follower.
Can you point me to that in your code, I’m not seeing it.
I agree with @aveeser, the best-practice on robot initialization for SPARK Max motor controllers is to reset factory defaults, set your configuration, and then burn flash. In java, it would look something like this:
leader = new CANSparkMax(DEVICE_ID_LEADER, kBrushless);
leader.restoreFactoryDefaults();
// Set any parameters you need, like inverts, PID, etc
leader.burnFlash();
follower = new CANSparkMax(DEVICE_ID_FOLLOWER, kBrushless);
follower.restoreFactoryDefaults();
follower.follow(leader);
// Set any other parameters you need
follower.burnFlash();
You can get away with setting any configuration with the REV Client and not calling restoreFactoryDefault() or burnFlash(), but there are a few reasons why I recommend this:
If you need to swap controllers, this will ensure the configuration gets applied automatically. You connect with USB and set the ID, and the other settings will come from your code. No need to manually copy configuration.
The settings are version controlled (since you’re using Git), so if tomorrow something isn’t working, you can go back to today’s code and see what changed, including the settings.
If a SPARK Max loses power, it will revert to the last flashed configuration. This means if you set configuration in your code, but don’t call burnFlash(), those settings are lost if you have a power blip where the controller restarts but your code doesn’t (brown-out).
If you don’t call restoreFactoryDefaults() you risk having some old settings if you swap controllers, or having some settings someone set with REV Client.
Well, you have to choose. Risk failing to save your parameters sometimes in your code, or never try to save them in your code at all. At least if you call burnFlash() it will succeed sometimes. In most cases, you’re just saving the same settings over again, so an occasional failure is fine.
It really has to be a cascade of circumstances for any consequence of burnFlash() failing. With burnFlash(), three things have to happen:
You have to change a setting that hasn’t been burned yet.
The call to burnFlash() has to fail.
The motor controller has to have a power issue that results in reverting to the burned settings.
Without burn flash, only two things have to go wrong (1 and 3.)
For your problem specifically, I really question if your follower settings in the REV client are the same as your code. It seems like they’re different and sometimes it’s reverting to the last settings you burned in the REV client. What if you comment the follower configuration out in your code, does it run the right way?
There are several other topics about burnFlash(), and various workarounds for failures.
When you’re checking, also check that the leader is not configured to follow anything.
This is just a theory, and I don’t have a robot to confirm if this is possible.
Let’s say in the REV client you configured the leader to follow the follower at one point, by mistake. Then, you catch it and go in and configure the follower to follow the leader, without changing the leader’s configuration. (Or the leader SPARK Max you put on the robot was previous configured as a follower on another robot, and the settings weren’t factory reset.)
Now assume that follower.follow(leader) configures the follower to follow the leader, and the leader not to follow anything. (This is just an assumption.)
At this point, the code is right, but the burned configuration is wrong. You can open the follower’s configuration in the REV client and confirm that it’s following the leader, but the leader is also following the follower.
For us, it wasn’t just a motor “forgetting” if it was a leader or follower, it was also them “forgetting” if they were inverted or not, which can kind of look like the same problem sometimes. So be sure to set all that stuff in the code and burn it … or it will burn you!