Split SwerveController out of SwerveDrive?

[tfield]

I have been thinking about your goals of keeping YAGSL accessible to teams, and I have a few thoughts that I wanted to bounce off you.

Our team was new to swerve bases this year. We looked at a couple of libraries before choosing to go forward with two routes - YAGSL and home-grown. Our off-season drive platform has a switch where we can toggle between the two libraries. YAGSL has been working really well for us once we got over configuration difficulties. The book has become amazing in that regard.

However I am very interested in pursuing the idea of splitting the SwerveController completely out of the SwerveDrive library. I like the idea of having only one single driving function in the base called:

public void drive(ChassisSpeeds velocity, boolean isOpenLoop, Translation2d centerOfRotationMeters)

and even yank heading correction out of it. You may want to rename the velocity param to robotOrientedVelocity to emphasize the fact that a this level, it is only robot-oriented.

That would leave SwerveDrive as a pure abstraction over the nasty math, hardware configuration, telemetry, and simulation, but take all of the higher-level control logic out.

You could then have SwerveController as a completely optional (and independently-configured) component, that takes on those duties.

Adopters would need SwerveDrive, but not SwerveController to implement their own subsystem. You could even consider moving SwerveController into the example code as well.

I'm biased because this is how we're using it, but from our perspective, everything from SwerveDrive on up is not new to us and we're comfortable rolling our own solution, whereas from SwerveDrive on down, we absolutely see the value of YAGSL.

To get to this more focused version you could leave compatibility code in place, with deprecated accessors in it. You could even, arguably, spawn a trimmed-down YAGSL class that is the core of SwerveDrive without all of the convenience methods, and then just deprecate SwerveDrive.

Your team has done excellent work with this platform. I would love to see its focus hone in on the core aspects, and leave the wiring and context to the example library.

I wonder if you think this aligns with your goals. Looking forward to your thoughts.

[thenetworkgrinch]

I have considered this question and all of your points well before you posted this and debated on doing it before the season started.

In short- you are right, SwerveController doesnt need to be here. However I decided against removing it this season bc it's a drastic change. As for all of the drive functions i currently have the aim is to make YAGSL easy to use. If you notice they all tie back to one drove function.

I am conflicted on whether or not to remove it in the future so it will remain until thats resolved. At the earliest it could get removed next season.

[tfield]

That's fair. Definitely don't do anything for this year at this point - you'll have a revolt on your hands!

Even with our own usage, we toy between having our subsystem have the convenience functions and not.

If the library just has the one call though, a subsystem using it could very easily (and without adding complexity) add convenience functions - and from a usability standpoint, the functions would be where teams need them to be.

From that perspective, an important question is this - is SwerveDrive a library that can be used by a subsystem, or is it an entire subsystem itself? I know that now, it kind of fits in between.

[thenetworkgrinch]

SwerveDrive isnt exclusive to command based programming for FRC and I never want it to be. It may perpetually be in a state of both. There is no real hark in the current way its functioning right now, other than a bit of confusion if you dont read the code.