Does anyone have a mk4i neo swerve drive code

I have asked around and people usually just say to convert the falcon examples to neo, but everytime I do it, it ends up not working.
Does anyone have Neo MK4i swerve drive code base code?

We are using Neos, PWM Sparkmaxes, Cancoders, and MK4i swerve modules.


1706 has NEO Swerve code from 2022, but it’s for MK4s I believe.


do you think it would still work?


From SDS’s website the gearing appears the same across the MK4 and MK4I modules, so I don’t see why not.

1 Like

awesome thanks :slight_smile:

Also you could check out:

1 Like

I’m pretty sure 1706 used mk2s this year so it might not work very well

1 Like

Correct with analog absolute encoders from us digital so the code would need to be adapted to using can coders

A lot of times when the swerve isn’t working right you will want to double check your module IDs for all of your can IDs and your cancoder IDs are all lined up. We had the translation motors on two of our module switched on a demo bot one time and you would tune the swerve offsets and it would work until the optimize function would go to flip one of the modules translation directions and then the swerve would fight itself I am not proud of how long that took to figure out.


I have our own team’s code. If you would like please contact me on Discord and I can send it to you as well as explain how it all works.

My Discord: Rezq#8253

If you don’t want any help from me here is the repository: Files · main · FRC1622 / public / 2022_TGRobot · GitLab
You will have to sort through the code and find what you specifically need for swerve because it has more code than just swerve.

GitHub - fondyfire2194/SwerveBase2022Fall: Team 4201 Layover2022 converted to MK4i with CANSparkMax drives and NEO motors

Pretty much what you are looking for except CANSparkMax instead of PWM

Teleop operation works. Auto not started.

I’m pretty sure the defacto Neo swerve code is 3512’s, which is for regular MK4’s not inverses, but converting the code should be easy. It also is meant for CAN Spark Maxes, but again, that should be fairly easy to convert. Take a peek at Nick’s reply.


I would not say that lol, ours is very much still in development (aka robot doesn’t drive currently).

Do not copy our code.

Good to know. I remember seeing somewhere that 3512’s was the way to go on the Unofficial FRC Discord. Thanks for the correction.

What is CANSparkMax? I have only heard of PWMSparkMax.

SparkMaxes can be controlled in two ways, CAN and PWM. If its a SparkMax on the CAN Bus then you control it using the CANSparkMax class but if it’s being controlled by PWM you control it using the PWMSparkMax class. It depends on how electrical decides to wire your robot although CAN is better since it allows for two way communication instead of just one way (the SparkMax can send data back to the RoboRio).

1 Like

The picture shows our prototype chassis with 2 - CanSparkmax at each corner mounted on the printable mount.
The green yellow wiring is the canbus. One pair comes into each swerve module and one leaves. The 2 drives and the cancoder are linked right at the module. So wiring is simplified and more information is available in code. Other wiring to module is the 1 power cable for each drive.

First test

1 Like

General update: Made a lot of headway in development on the repo, so I recently pushed my new changes to the repo (basically switches to onboard PID on the SparkMax to reduce roboRIO usage). I’m also recently found some mechanical issues in one of our swerve modules (most likely cause for our problems at this point) and that a team was able to get our code to work. We’ll (hopefully) do more testing tomorrow.


Update on yesterday (life stuff got into the way, sorry for the late post): Yep, turned out the Xbox controller we were using to drive was doing some weird stuff. Switching to a different controller fixed our issue. We were able to get swerving yesterday with our code.


I’m from team 6081. We’re also using MK4i NEO swerve and this code got our robot running! Thanks a lot! We are having one problem though. The estimated position of the robot will move thousands of meters when the robot barely moves an inch. The individual drive encoders all read correctly, so I’m assuming something is wrong with how it calculates its position. Any ideas?