For some reason our code decided to blow up today. We never got the absolute to work correctly but we got by with realigning every power cycle. Today for some reason even the realign is not working either.
Further details on the observed behavior, expected behavior, things you have tried, etc. Would be helpful in trouble shooting. Bonus points for video/pictures of an error.
(Just trying to get some more details and have an objective reference for anyone trying to help)
The swerve tends to move correctly when we directly align the wheels as I said before. But when not adjusting the wheels trying to use the absolute boot feature the angle motors get all out of wack. We do have the encoders set to boot absolute in both the config file and on phoenix tuner. I did find a thread talking about this exact issue previously but it appeared to me that our swerve base already had this implemented. We have tried to wait a while just to make sure the encoders boot correctly but with no success. Not really sure what else to try. One thing worth noting is if we deploy robot code we always have to power cycle the bot and realign. Not really sure what else to try.
You do need to change the deploy/swerve files. These files configure your swerve drive entirely, like your motor ID’s, absolute magnetic encoder offsets, imu ID, etc. We made a easier configurator at YAGSL Tuning Webpage which eleveates some of the headaches of generating the configs.
The default drive scheme in YAGSL-Example is designed to test the swerve drive and is sub-optimal for competition use. The left stick controls translations in the x and y direction. The right stick controls the heading of the robot. If everything is tuned correctly this will work. If this works then your autonomous should work too if you configured the heading PID with the same one as your config files.
There are some inversion difficulties too teams with Falcon’s have experienced, for example you may need to set p in controllerproperties.json to negative if invertIMU in swervedrive.json doesn’t work. Or you may need to set p in pidfproperties.json to negative if inverting the drive motors causes issues with odometry.
I have documented every feature I could in the features discussion it also includes information on how the library should be used and how to use the features.
The good news is they are using NEOs , with Cancoders and pigeon.
This is why I recommended YAGSL because they didn’t have falcons.
They’ll need to identify and plug in the IDs to there moters in the corresponding json files in the deploy folder.
The stack trace says FileNotFoundException: /home/lvuser/deploy/swerve/neo/swervedrive.json meaning you are trying to access your configs from /home/lvuuser/deploy/swerve/neo AKA deploy/swerve/neo which doesn’t exist or have the files in it.
That is because I accidentally left in something I never implemented because it was fixed later (encoder inversion). If you regenerate your module configs from the tuner page in a moment that will fix it. If you want to modify each module json remove the encoder entry from the inverted dictionary.
Thank you for letting me know about the error, sorry you experienced it!
It seems to be that the pigeon 2 “type” is broken. I can’t tell if its my error but every time I deploy I get a PigeonIMU error. I do have the “id” field set as my can id and the “canbus” field set to null.
Null is not supposed to be in quotes, null means that its not on an alternate CANBus and is not a string type. With it as a string you are trying to use the CANBus named “null”