Swerve Drive MK3 with Neo's and CanCoders

So my team has been working on Swerve drive for the past couple of months, and we are using the SDS MK3 modules with NEO’s and CanCoders(not the srx mag encoders)

We have a couple of main problems

  1. The wheels keep getting out of alignment after driving for a short amount of time.

  2. The Modules will start to spin uncontrollably after driving for a little bit.

  3. The robot moves with joystick inputs but not in the correct directions ( the robot mostly just moves randomly when you use the joysticks)

I will be posting a video and the code soon please let me know anything I can try to fix these problems

Main.java (775 Bytes) Robot.java (5.5 KB) SwerveDrive.java (3.3 KB) WheelDrive.java (2.2 KB)


I see that you have a smartdashboard printout of your module absolute angle. Does it read zero when the wheels are pointed forward? If you rotate them by hand does it go 90 if you rotate them counter clockwise 90 degrees. Then -90 if you rotate them clockwise 90 degrees?

We used the configMagnetOffset function to make the absolute angle be 0 when the wheels were forward. It appears you might be doing this another way, but I’m not certain.



Where did you come up with the inverse kinematics for the swerve because they don’t seem quite right?

It looks like the Cancoder is set to be in a range from -180 to +180 but you check if the set point is < 0 and increase it by 180 if it is and if it is greater than 180 you subtract 180. This is limiting your motors to only 180 degrees of their travel. This can still work but if you move your wheel 180 degrees from the set point you need to flip the direction of the wheel as well.

1 Like

How could I go about making sure the wheel direction is correct. AKA how do you make sure the wheels aren’t going to fight each other.

No it does not read zero. When the wheels are forward all the encoders are at different measurements even after resting their offset through Phoenix Tuner.

That could be at least part of your problem. What we did was use a straight edge and point all of the wheels forward. We then read the absolute position.


We then recorded that value and stored this value in as a constant as our angleZero (it is different for each module)

Then when the module was constructed we used the.


This made all of our modules absolute position 0 when pointed forward.

Hope that is helpful. I didn’t run through the kinematics, but if those are off it can cause some strange things as well. We have just been using WPILib built in swerve kinematics.

1 Like

Tip the robot on its side and try to drive forward. See if the wheels are all spinning the same direction or different directions. First I would make sure your encoder zeros are right though.

I thought you can’t use CanCoders as the feedback device for any sparkmax PID loops.

You can’t use the CANCoder with the on board Spark Max PID loops.

You can do the following with the combination.

  1. Run the PID loop on the RoboRio with the CANCoder as the sensor.

  2. Use the CANCoder to get an absolute position and then compare that to the current position of the Spark Max built in encoder. Then use the built in encoders to control the onboard PID loops. I haven’t tried this, but have heard other teams that do. Some have said they periodically recheck the absolute position and make corrections, but I am not sure if that is required.

1 Like

This is how we ran our hood and turret angle controllers in 2020. Works great, and avoids any can bus lag during the regular control loop. The only other time we recheck the absolute position sensor is after a brownout.

This is how we ran our MK2 modules with NEOs in 2019 except with the MA3 as the encoder. It worked well. We actually had our steering NEO Spark Maxs controlled over PWM back then.

This is currently how we are running our MK3s with Falcons. Other teams like 2741 have shown NEOs can be ran with the same strategy very well.