Swerve wheels misaligned (half of the time)

We’re using YAGSL to make our swerve code. Usually, the drivebase follows the joystick inputs. We encountered an error where the modules stop following these inputs. It happens when we change module angle from one point to another angle around its 90 degrees counterpart.

Here is our code: MainRepository_AlphaLab_8067 - Google Drive
Here is a video of our issue: Enregistrement de l'écran 2024-11-01 151432.mp4 - Google Drive
The problem occurs at 0:07, 0:13 and 0:16
We can also notice that when we ask it to go to a position it stops a bit before reaching it and then gets to it only after we stop giving any input (maybe not related but still a problem we would like to solve)

Note At no point did we give any rotation comand so the robot should technically be only translating . we also noticed that in some cases the diference between the wanted position and the returned position is pretty big and it only solves itself once no input is given like mentionned previously.

What swerve module type are you using?

SDS MK4i NEO using L2 gear ratios and CANcoder

Where did you get your conversion factors from?
You should use the format from the docs.
https://yagsl.gitbook.io/yagsl/configuring-yagsl/standard-conversion-factors?origin=serp_auto#swerve-drive-specialties-sds

Also could you upload your code to github, it makes it easier for us to view.

We already had the good gear ratios (acording to the docs) in our json files, however it was not the case in our subsystem at line 75 (it was set 12.8). We changed it so it matches with the json files. The problem is still there.

also here is the github : GitHub - ALPHALAB8067/MainRepository_AlphaLab_8067: Main Repository pour tout les fichiers en général d'AlphaLab

1 Like

Yeah these aren’t right, please change

to

"conversionFactors": {
	"angle": {"gearRatio": 21.4285714286},
	"drive": {"gearRatio": 6.75, "diameter": 4}
}

These values you supplied here are given as a reference to help you.

which you could supply here if it was uncommented (for now; i am going to require it given through the JSONs soon).

however you don’t supply it and use the constructor here.

Ontop of the conversion factor changes, this seems to be uninverted while the rest are, is this intentional?

Yes it is intentional and the problem is now fixed Thank you so much although i am curious as to why the second observation was previously happening (im referring to the one where the angle motor would not go to the corect position with something that looked like a small offset and he would then snap to the corect position but only after no input is given and we know for a fact that it is not auto centering ) anyway thank you so much once again.

1 Like

It was a side-effect of the invalid conversion factors, if the given is so close to 0 that it doesn’t mean anything then the motor will not turn.

ok but why did it snap back to the correct position after no input ?
this is not important its just out of curiosity.

Honestly I am not sure I suspect a disconnect where the last state is not updated correctly in that condition but idk.

ok thank you