Swerve Does Not Respect Offsets and Being Strange

Technical Java
,
1

We are having an issue with setting the offsets of our swerve modules. On enable, they will sometimes go the offsets and claim to be in the correct position, even if they are not. Other times, they will turn to positions that are not the offsets and do not even claim to be correct. All of the CANCoders seem to be working fine with green lights and good reports from self tests.

I saw this but it is already set to boot to absolute.

This specific hardware all worked together last year and updating the wpilib version did necessitate a few changes but I am not sure if that would have any effect.

Code

Update with additional information:
We have managed to isolate one module and get it to behave with some PID tuning. This has had the effect of making everything a bit sluggish (having a delay when responding to inputs or lack of input).

@nstrike We are not using YAGSL right now, but when we were you said that the CANCoder errors that we were getting were indication of an encoder issue. Could these issues still exist and be causing problems even if the light is green and the self test is good?

2

What library are you using?

3

I do not know exactly. It was forked from 2194 who in turn got it from 4201. I kind of assume that it has some basis in SDS but have no way to confirm that. Do you know how to identify it?

4

Are you attempting to configure the offsets in pheonix tuner as a parameter?

If they are green and self-test reports they are good then it’s not likely an error with the cancoders. Assuming that you read correct values when manually turning the swerve modules.

If you soldered the CANCoder yourself you may have an issue with the connectivity sometimes under pressure/moving wires.

5

I have just gotten the offsets to work by tuning the PID a bit. The offsets are configured in the code, but I have gotten the actual number from phoenix tuner.

We did solder the CANCoders, but I do not see any issues other than the occasional “CAN frame too stale”.

6

Some things are working now. There are two issues that I can see.

  1. The azimuth has a tendency to drift after running for a while. They snap back to zero positions on code restart so I assume this is the NEO550 internal encoder drifting.

  2. The rear drive motors sometimes run the wrong direction. Sometimes they are correct, sometimes wrong. The only consistent thing is that they seem to always be correct when running in the forward/backward direction.

7

I KNOW WHAT THE ISSUE IS! Democat had msde their library have a resetToAbsolute function which synchronized the absolute encoders to the local encoders when the current velocity/requested velocity is 0 and has been for X amount of time. This is because sometimes the absolute encoder doesn’t act correctly sometimes but always fixes itself shortly later.

3 Likes
8

This function was a saving grace for our team. We had to make our own version since we don’t use Democat but it does the exact same thing.

Slapped it into TeleopInit for Robot.java plus a manual button just in case and worked like a charm ever since.

9

It does not look like we have a resetToAbsolute(). What exactly needs to be added to get that?

10

I programmed mine to simply synchronize the encoders when velocity was 0 and the count was above 5 (to have a denounce so i wouldn’t get too high of a CAN utilization). Synchronization is simple too.

If you don’t want to go this route you may have good luck delaying your startup fetch of the absolute encoders by a second.

11

I tried implementing this, but there were so many references that I just went back to the source of your features and tried YAGSL again. This is working now, not noticing much azimuth drift over time.

However the rear modules are still sometimes spinning drive in the wrong direction when in strafe. This is not always and the forward/backward is still fine. It seems that whatever direction they go in first will be correct and the second will not. Not sure how related to this issue it is, but one of the modules is just a little weird sometimes as when drivebase::lock is called it goes perpendicular but other times it seems fine.

Also I do not understand how the two axis rotation is supposed to work, but once activated, it will lock into a spin and keep running after no input has been given. Is this how it is supposed to work?

Looks like the reversing might be happening when the encoder number goes below zero. The dashboard displays a negative for a little bit before correcting to a ~300s number.

12

You may have bad encoders then, sorry it wasn’t caught by the Pheonix Tuner!

13

Just found that the CAN IDs of the two problematic motors had been flipped. This seemed to solve that issue on the one I am able to test.

Would you be able to explain what the two yaw input axes in AbsoluteDrive() do?

14

i am not sure what you are referring to, could you post the segment?

15

The two heading axes that are passed through AbsoluteDrive() as
() → -driverXbox.getRightX(),
() → -driverXbox.getRightY(),

I have never seen anything like this before and it does some strange things.

AbsoluteFieldDrive() looks like what I am used to with the only heading supplier being () → driverXbox.getRawAxis(2).

16

These values are used to get the angle of the joystick and set the heading to that angle.

17

I get that. Just a bit confused as to why it takes two DoubleSuppliers whereas AbsoluteFieldDrive() only has one.

It seems like the module I was unable to test last night is going correctly in the forward/backward direction now, but strafe is wrong and when put into rotate or lock() it is rotated the wrong way by 90 degrees.

18

In AbsoluteFieldDrive it converts a single axis to desired rotation instead of it matching the stick’s orientation

19

I have gotten the problematic module to rotate to the correct positions by telling it that it is rear right (it is rear left). The strafe still has the drive motor going the wrong way.

20

Are you using MK4i’s?