This is a good time for an facade type pattern.
Generally in tools like this it’s best to build a common interface spec and then implement adapters to each piece so it’s largely ambivalent to what the underlying class is.
There are downsides to it as well (configuring one very specific piece of one api can sometimes lead to gnarly one off api pieces) but it does let you build libraries like this fairly reliably.
I did try that with the SwerveMotor and SwerveEncoder class. I do not have enough experience to know what will be difficult to manage it since the only interaction with SwerveMotors is through the SwerveModules and there aren’t any vendor specific things in SwerveModule
I made the driveFeedforward public and not final so you can now redefine it if you too
This is interesting, but would need NavX support. I may contemplate a PR if I find time to work on it.
I was thinking of doing that but i am not sure of how to make the initialization not break the program without running another thread and I’d worry about the i2c issue too much.
I just updated YAGSL-Example to have an example which follows a trajectory. It did involve some changes to the library and a new SwerveDriveController named CustomSwerveDriveController
Tested using a Pigeon2, CANCoders, and NEOs using SDS MK4 L2. Basically the same setup as you. Happy to report that it works pretty damn well!
https://drive.google.com/file/d/1Oiq-58GW7FzgFKvzD660fbKhc-MINEru/view?usp=drivesdk
Thank you for this resource, we’re actually considering switching to this due to how easier it is to setup. I’ll be doing PathPlanner tests with it too, so I can report those results soon.
Thank you for testing! I have found that it wasn’t as reliable as 95’s code when testing so I am in the process of rewriting it to follow 95 on that exact setup. Hopefully after the rewrite the angle motors will not snap anymore. The rewrite is going to make extensive use of configuration classes (something i tried really hard to avoid in the initial release). There of course will be more optimizations they don’t take into account and it will be generalized so it works with different encoders/motors/gyroscopes. The end result will likely look very different for configurations but I will try to keep the same UI i have made for this version. I am sorry for the inconvenience!
No worries, being labeled as in beta, I expect things to look different as it matures. Looking forward to the rewrite!
If you’re interested I just finished the rewrite based off of 95’s code. Its on GitHub - BroncBotz3481/YAGSL-Example: Yet Another General Swerve Library Example Project branch ‘rewrite’.
I still need to add back support for other encoders, integrated absolute encoders, other motors, make some fields optional (might not do that), update documentation, write a simple autonomous using trajectories, make a momentum calculator (maybe), and add back shuffleboard widgets. Right now it is MUCH smoother than before and has a completely different JSON layout and attributes.
We have a session tonight, so I can totally port it over to our comp bot.
Our build team is also hard at work finishing wiring up the proto bot with our elevator mechanism on it, so it will be sick to have both of them running.
I’ll absolutely get video of it. Once again, thanks for putting this together!
I also should switch the odometry to using SwerveDrivePoseEstimator, and test 254’s drift fix on a real bot.
Beautiful performance! Really smooth. I was able to mess with it a bit to make it feel like our original swerve code felt to drive. Thanks again! Most likely will do auton stuff either tomorrow or Saturday.
https://drive.google.com/file/d/1TIfCahRFcBuvhQMuxlNC1dD7-tOT0z1d/view?usp=drivesdk
We tested it too! I am sorry the heading PIDF values weren’t working well. We just uploaded a version that uses 95’s teleop drive. I also admitably forgot to include a gyro inversion 
. So we added that as well. Thank you again for testing!
any chance on integration with navx? we have one and would be happy to test 
.
Absolutely! Do you use only Neo’s, CANCoders, and a Pigeon2 as well? I can hash out a NavX module by the end of the day probably so you can test it tomorrow.
we have all NEOs and are using the NavX in place of the pigeon.
We also have CANCoders. Our next meeting would be tuesday evening . How can we assist ?
At first glance we noticed there is no equivalent for setting the components of the gyro .
m_pigeonIMU.setYaw(pos.getRotation().getDegrees());
does not really have an equivalent in the navx library that we could see.
There isn’t one, however there is a reset function which resets the yaw axis to 0. From there i add a offset in my helper function. I just finished the change and published it.
If I remember correctly, the reset function takes a while to complete, so you may be better off with a “poor man’s reset” (i.e. storing an “offset” in code and simply adding that to your measurement)
Good to know! Thank you!
Just updated it to function like that