We created a swerve via BaseNeoSwerve and we tuned it for our robot and it works in teleop. However when we make a auto path with pathplanner it runs the path but every path runs approximately 3 times longer than it should, e.g. 1 meter goes 3 meters. So it appears to be a unit conversion problem but we can not seen to find where to make the adjustment.
This is our code: https://github.com/FireIslandFRC/BaseNeoSwerve
Any insight would be helpful!
Our team is dealing with the same problem right now. If we figure it out we’ll let you know!
Is it also a 3x difference? Would you mind sharing your code to see similarities that could be the problem?
That means your drive encoders are not calibrated properly. In other words, the encoders need to return SI units (m and m/s) for distance and velocity. It seems your methods for encoders do not do so.
We calibrated our drive motor encoders on sample trajectories enough that our straight 1m trajectory is within 0.002m of error, 3m straight trajectory is within 0.03m error, 3 m straight + holonomic 90 degree trajectory is within 0.03m error from straight. Granted, these are slow trajectories (2m/s max V, 0.9 m/s^2 max A), but still, that seemed pretty good.
Thank you, will check next practice!
Do you know how to find the distance of the encoders on Neos and Spark Maxs?
So, REV really does not like you to work with RAW units, like CTR components do.
That means you basically say in NEO setup - my encoder goes from blah1 to blah2 in one full revolution. What the blah1 and blah2 are - that’s up to you. Could be degrees, could be meters, could be just arbitrary numbers. Just need to be a pair of doubles.
In the past I always calibrated that to some SI units to make it easier to use with the other components. For instance, if I use encoder on the arm shaft, I would calibrate it, so NEO will get me degrees of rotation. For linear motion I calibrated it to be meters, accounting for gearbox as well.
If your encoder provides relative or absolute values, NEO can be “explained” as much as well, with the ability to handle the rollover correctly.
To provide you a code example - here a branch of our test code that does NEO Swerve with the Duty Cycle encoders for Angle (those are built by Helix Labs), and built-in encoders for drive.
Note that with built-in encoders on NEO you cannot change sensor phase (because they are also used to handle brushless motion). So check the configureDriveMotor method.
The line starting with
driveEncoder.setPositionConversionFactor
sets the encoder output, and getDriveEncoderPositionSI method recalculates it into meters. Why do I need two? It was easier to calibrate the PID routines this way 
for auto trajectory driving.
We developed this code for our sister team, so we left it to them to recalculate PID constants if they want everything to be nice and neat.
And remember the main rule of PID - if you apply positive power,
which means with inverted motors and/or inability to change sensor phase you will rely on software methods to invert the numbers if needed.
We tried this but I think our main problem is deeper in the code. We went drastic and changed wheel size in code to a crazy value, we also changed gear ratios, and also messed with PID. Nothing happened, the path is running the exact same. Any advice?