We are first year with swerve (SDS Modules) and it has been going pretty good until our last match at Wilsonville. Our robot drove straight out during auto as expected but right at the end slewed into an arc. Auto ended and teleop started and right away the robot was undrivable. We observed that one of the swerve modules had moved into the 45 degree position for rotation (uncommanded as far as we can tell) while the other 3 modules remained in straight ahead alignment. The module would not leave the 45 orientation no matter what steering input was tried. It even ignored our routine that aligns the modules to correct starting orientation. So we were pretty much done as the robot could not maneuver while dragging the 45 degree wheel.
At the end of the match we took the robot back the pits to trouble shoot but on enabling, all of the modules aligned correctly and we could drive it successfully. We know which module was at 45 as it’s motor was very hot from trying to drive at cross direction to the rest of the motors. Logging showed no errors or any other clue except for very high battery usage leading to brownout indications. Note that while these errors were being logged, the robot was driving and working quite hard against the dragging module. So I can’t say of the high battery usage indicates a cause or was the result of the 45 motor struggling to rotate against the direction of travel.
So at this point we do not have a cause for this failure. We will be testing this further today but any thoughts would be appreciated.
We had the same thing happen on one of our SDS Mk4i modules this weekend while practicing. Found a portion of a drilled-out rivet stuck between the steering gears. Given what you said about the motor being hot and the logging info you described (was the steering motor also hot?) I would not be surprised to learn this was a mechanical issue.
We had an issue with one module sometimes doing this. It was as if it was getting the wrong info from our CanCoders. We implemented a 1 second delay in the constructor of the swerve modules before assigning the value to the turning motor. This doesn’t slow anything down as we put it on a new thread and it does it as soon as the robot code boots up. This has seemed to have fixed it. I don’t know that this will fix your problem though if it drove fine to start with.
Sensors are cancoders, code is moderately customized version of SDS example code. The drive motor was hot, steering not hot. The loose screw or stray rivet is a good thought will check further for that at lab today. It’s strange as the bot drove correctly past the charge station before the module changed orientation and the bot “swerved” off line and after that acted frozen in the 45 orientation. Again, ran fine when back in pits and we really looked it over and found nothing.
Woodworker21, in your reply, what “value” are you referring to?
Neos. We are still investigating but the cancoder on the module that failed to work correctly may have a lose solder connection. Not sure how that would completely explain the behavior but it obviously should be fixed as it could cause some sort of failure. We will be taking it apart today and fixing the connection.
If your code does any configuration of the NEO, such as setting PID values, does it call .burnFlash()? I’m thinking it’s possible that there was a power failure on that Neo and it reset to the settings that were last burned to flash.
I imagine it’s possible that a power failure could happen and it just reset the relative encoder on the NEO. But if that happened and the settings were burned, I would expect the wheel to be in the wrong position but it would move. Using your reset button would fix an issue like that.
By reset button, do you mean our button that aligns the wheels to starting orientation? We do not flash the settings set in the SparkMax controllers during our start up. That idea is new to me. But it does make sense in that power loss would go back to whatever is in the SM memory. The loose wire is not power but the can wire to the cancoder on that module.
I’m not sure I know how this could have caused the failure either.
But, one suggestion you may want to look into to avoid this concern is to use the motor encoders for steering control rather than the Cancoder. You still need the Cancoder to detect the initial angular position of the modules at initialization. But once you know the starting position, you can use the motor encoder to keep track of the position from that point onward.
I’m not sure what the standard swerve libraries use for steering angle control loop. But we switched to using the motor encoder in 2020 (when the NEO 550s came out and we could use them for steering). We used to suffer from encoder reliability when closing the loop on the absolute encoder. Since switching to the motor encoder, we have never had an issue with module orientation.
Have you tried adding a delay before zeroing your modules based on the absolute encoders? It seems like this is a common issue where the cancoders are not given enough time to boot to produce good sensor measurements. You can use Timer.delay(1). We actually still have the problem after implementing this but we are adding a button to rezero the modules in the match as well as we will add a reset the modules call inside our disabledInit() method.
You should consider burning flash on startup, or performing your setup with the REV Hardware Client and burning it to flash. If the motor loses power, it will revert to the burned configuration.
The OP said they were using a “moderately customized version of the SDS example code,” so I assumed they were already doing this.
The OP said the problem happened suddenly in the middle of a match. The delay only helps with the initial position. The OP also said the wheel wouldn’t move. If the initial position was wrong, the wheel still moves, but it moves to the wrong position because the offset is incorrect.