After many weeks of head-scratching, we finally managed to address some of our Swerve issues. Here is a quick overview of everything we did:
Found out that all the relative encoders were moving in the opposite direction as the absolute, so we inverted the angle motors
To counteract this, we negated the double supplier in DriveCommands to ensure that the translation wasn’t inverted
We also found that this broke field-oriented drive, so we had to negate the gyro reading to fix that
All of these are kind of duct-tape/band-aid solutions to the real swerve issues, and it’s kind of coming back to bite us in the rear so to speak. Now, we have fully functional teleop driving.
However, in odometry, forward and backward are inverted (moving forward is back and vice versa) but not right and left (right is right and vice versa), and of course rotation is inverted in odometry as well.
I added Pathplanner back in, but whenever I start up the autonomous, the bot teleports outside of the field in the AdvantageKit odometry reading (with field picture). And moving on to the autos themselves,
Of course, the inverted rotation was expected given the inverted gyro. However, when told to rotate 180°, it only rotates 10-20°
On a similar note, the path also randomly stops midway through without fully finishing.
Any input on the origins of any of these issues (or on the swerve issues in general) would be greatly appreciated, along with general code critiques as well.
Which swerve modules are you using? Knowing which modules would help identify if you really need to invert your motors/encoders or not.
If you’re odometry is inverted, but you are driving correctly, you should probably invert your joystick inputs instead of the gyro/motors. If you are calling the Pigeon2.getYaw() that should return the correct rotation direction (Counter-Clockwise positive) without inverting it. This aligns with the WPILib coordinate system, which is what PathPlanner expects.
For updating odometry, I see in your code that you don’t use a pose estimator/odometry object. Is there a particular reason why you opted for this route? It seems like it would be much more robust approach to use a pose estimator, as the estimated robot pose from those classes is what most path following/trajectory libraries expect. The example AdvantageKit swerve project opts to use one if you need an example.
We’re using Mk4i’s. The issue with not inverting the gyro is that it causes the relative and absolute encoders to not move together (eg. abs increases and relative decreases), so it makes the swerve setpoints quite funky. With respect to odometry, we grabbed this code straight from the AdvantageKit template, but I see they have added it as a feature recently, so I’ll definitely be adding that in as well.
This is wrong. Pigeon2.getYaw() returns CW+ and needs to be inverted. The getRotation2d() method, on the other hand, does return a value that’s CCW+ so it doesn’t need to be inverted.
I suggest you take a look at this new documentation page about the WPILib coordinate system, then go through everything and verify it is correct.
No, its CCW+. I thought I had a similar issue related to this recently and CTRE said it is CCW+ and confirmed that it is CCW+. Pigeon2.getAngle() returns CW+.
