My team has been using YAGSL to control our swerve. For a while, it was working quite well. Recently, however, the behavior has been pretty inconsistent. When driving straight forward, for example, at least one, if not more, module is several degrees off of its setpoint. I’m fairly sure that it’s not an encoder issue because I’m using Elastic’s swerve widget to visualize the encoder readings, and they reflect the issue as well. Additionally, a recent test showed driving (non-field-relative) straight forward resulted in all modules pointing several degrees off on the same direction, even though the commanded states were clearly straight forward. Again, Elastic’s swerve widget clearly showed this issue as well. I wouldn’t think that it’s an electrical issue because all the motors are still running, just in the wrong ways.
I also found it interesting that, when a module is pointing the wrong way, the drive speed is slower than a module that is pointing the right way.
Finally, not sure if this is relevant or not, but I have run setHeadingCorrection(true), yet the robot does not try any sort of heading correction whatsoever if it is manually rotated by hand.
I’m very sorry if I’ve missed any critical data, I’m quite confused by this whole thing. Thanks for any help!
Usual disclaimer about making sure magnets are not loose.
Also check that the amount of friction is uniform, spin things around, make sure there are no sticking points.
How was this testing done? Up on blocks? On carpet? At full power or only a small percentage?
If just commanding module position (not velocity) is the pointing more consistent? Does it only drift/not hit targets while commanding a velocity?
My initial thought, which I think explains some of the issues, is the PID is not hitting its setpoints (“under tuned” for the system). Could you verify the moudles think they are where they should be (i.e. they are commanded to a few degrees off) or of they are trying and failing to get to a setpoint (i.e. never reaching where they want to be) ?
This sounds like a PID tuning issue, if your encoders are all reflecting the issue. What gain are you using and what PID controller? Have you tried raising your P gain by 50%?
Note that if you tuned the PID on blocks, it’ll underperform on carpet because of the load. Final tuning on carpet is the best way to go.
I have spun all of the modules around a few times and confirmed that there are no sticking points.
The testing is being done up on blocks and at a fraction of power. (30%)
I did confirm that the desired states are where they should be and all of the encoder readings are accurate and consistent at all times. Another test just showed that it drove correctly for a while, but then all of a sudden everything was completely wrong. Then, the front left and rear right modules were correct and the other two were about 90 degrees off. I would also think that it’s a PID issue except for all this inconsistency.
EDIT: I did just change the fraction of power to 80% and the results are unchanged.
is it possible the sparks are momentarily losing power and losing their configs? This is what comes to mind when something works fine until suddenly it doesnt.
It’s interesting that you say that, I happened to notice, after turning the robot on, that all the spark max’s status lights were blinking on and off in sync. This makes perfect sense, I just enjoy blinking lights, lol. Anyway, I come back later and see that they’re no longer in sync. I was a little confused but didn’t think much of it. Just something I noticed.
How is your NavX connected? If it is over the MXP port you should just use navx not navx_mxp_serial. Additionally you probably should set your IMU Inverted, but it depends on how your Rio is mounted.
There is also some weirdness of the offset and Rev hardware, can you attempt by zeroing the absoluteEncoderoffset?
This is not how heading correction works. Heading correction uses the last commanded heading not current heading.
Secondly, there has been a number of new changes to YAGSL regarding controller input, discretization, and some new tuning options. If you can send a link to your code, a video of the robot with the widget and controller in view, and a description of your swerve module type (SwerveX, what gearing? L2, L3, etc) We can try to help further.
Lastly we can offer more immediate help from discord YAGSL
Alright, so after more testing, I’ve determined a consistent issue: When I start the robot, (AKA all encoders calibrated) the wheel goes to the setpoint correctly. (45 deg in this case since I’m using lockPose()) If I turn the wheel 180 degrees and attempt the same setpoint, the wheel is a few degrees off. Another 180 degrees and the error grows by a few degrees. This trend continues the more I turn the wheel. This tells me it’s most likely a conversion factor issue, but I’m still confused about something: Doesn’t YAGSL automatically sync the motor’s encoders with the absolute encoders when the motors aren’t running or something like that? I also tried running syncronizeModuleEncoders() in the periodic() method, but it didn’t seem to change anything. I understand that ultimately the solution should be to change the conversionFactor and/or gearRatio fields in the YAGSL configuration, but I’m still confused as to why this is happening.
Ultimately, this was the issue! Oddly enough, I thought I remembered reading something about this, but then I didnt see it when I looked back, for some reason. Thank you!
This almost certainly is not the actual issue- module azimuth measurements can’t “drift” unless a) something is mechanically skipping or b) there is an incorrect conversion ratio causing an error proportional to the displacement from t=0.