SDS MK4i Single Wheel Alignment Issue

When we power up one wheel sets at the wrong angle. If we manually wiggle it then restart robot code, it aligns with the rest of the wheels. The workaround works every time, but puts an extra step on our drive team. Also, this does not happen every single boot but most of the time.

SETUP: SDS MK4i. NEO motors, CTRE CANCoders, CTRE Pigeon 2. Star CAN topology using Playing with Fusion’s CANStars. The hub having problems is on 3rd of 5 CANStars.

We’ve went through the proper alignment setup numerous times. We don’t think it is the encoder offsets because it does align with the rest of the wheels and drives fine.

Have any of you ever experienced this? Any ideas that what might be causing this?

1 Like

Are there any errors that you are seeing in terms of electrical? Are you seeing any non-nominal signal lights? Are you using a code library or something custom built?

  • We occasionally get a CAN warning on a sparkmax that is on a different star, but that is it.
  • All signal lights on encoders and motor controllers on that hub are normal.
  • Code is a mixture of a few of the shared community libraries. We didn’t mess with any of the alignment stuff, just hardware changes and library updates. (nothing major)

My current thought is that a lag on the CAN network when booting or we send the alignment command but the motor controllers are not online yet.

We’ve experienced this and have roughly the same line of thinking. We “fixed” it by setting the initial position of the spark/neo 10 times in a loop rather than a single time.

for (int i = 0; i < 10; i++) {

or whatever your equivalent is. It’s yet to happen since we implemented this.

1 Like

You might be losing the “set PID” constants on startup. Not having kP configured on a turn motor would do what you describe. Make sure you’re calling burnFlash() CANSparkMax (FRC-REVLib API) which is not documented by REV, but according to CD is quite necessary if you don’t want your sparkmaxes to miss occasional configuration settings.

Like many of the swerve frameworks, we use the a “SwerveModule” class. Each module is configured by passing in the module ID for configuration. I just checked and we do call the burnFlash() on both angle and drive motors, so I think we are good. Thanks for the recommendation!

It sounds like you are having a similar issue to what was identified in Team 364’s Base Falcon Swerve library. The problem there was a race condition between the setting the angle motor inverts and setting the module position from the CANCoder. The fix was to add a 1 second delay after creating the swerve modules and then resetting them to the absolute position.


Nice!! I can’t test right now, but I bet this is going to do the trick. Very similar to @jtrv 's solution but a little more controlled. I’ll update once I can test.

This is what we implemented as well and have had no issues since

Worked like a charm. Thanks @Chris_Ely !

1 Like

Hi, we have this same problem and we have implemented the fix a few weeks ago. However, we went to our event this weekend and we had the problem twice during our matches. Do you have any idea why this could still be happening?

We also added the above fix and were still seeing one module not align correctly. Our fix was to add the reset to absolute function mentioned above in the initialization on disable function.
(Also, we are using falcons but I think the fix would apply for neo users too)

1 Like

Awesome thanks for the idea

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.