I have what I think is working swerve code, and I’m trying to make sure all the constants are correct. At the moment, I have code that is able to move laterally, but when I try to turn it, the front right and back left move in the right direction whereas the front left and back right are opposate. The problem is that if I change the front left to turn correctly, it no longer moves laterally correctly. I’m wondering if this stems from the way in which I got values for
Aboslute encoder reversed
Absolute Encoder offset
Turning Motor Reversed
Driving Motor Reversed
I’m wondering if there’s a better or “correct” way to get these values.
So if I understand correctly you have an initial staring position of:
| |
| |
Which drives forward and back as you would expect.
You can strafe:
— —
— —
Which also works
But when you try to spin in place , with the expectation of :
/ \
\ /
You instead get the configuration below? (If this is the case ensure module 1 is the corner you expect to to be (CAN IDs, code references, etc), module 2 is the corner you expect, etc). Then realign (see below).
\ \
\ \
Or do the front right and back left drive the wrong direction but are pointing the right way (wheel spins backwards)? (If this is the case the absolute offset is 180° off, you will need to realign the wheels with a straight edge. I would adopt a rule like “bevels on the right”)
The robot was doing the latter. I tried changing the absolute encoder offset, but then if I did that, the strafing would no longer work. What ended up working was changing the order in the toSwerveModuleStates function returned. It says it returns the modules in an order of fl, fr, bl, br. After swapping FL and BR, my code worked. I tested it with Feild Oriented drive and it worked too so I’m not sure if there is a problem with my code or the wpilib code. I was trying to find the source code for the function but was unsuccessful.
Ok so I had a similar problem and my problem was that the encoders should be inverted and when you invert them, the offset has to be set as (2* Math.PI - angleOffSET) in case you are using radians, but for a more clear debug you should follow these steps:
Send the absolute and relative position to you shuffleboard so you can see if they match.
If they match, then you should open a new Timed Skeleton Advance project and just create the motor, the encoder and put the value of the absolute and relative encoder and see if when you turn manually the motor, both of the values are going to the same direction (meaning that they are increasing or deacrising equally)
If they don’t increase equally (one increases and the other one decreases) it means that one of the encoders is wrongly inverted, so you should invert it and check again
My guess is that your problem kinf of goes in this way, but if this isn’t the problem, let me know and we can chat over dm in discord and I can give you a more adequate help.