Task/2025 refactor - #27
Conversation
… of unused classes
…dules. removable of dead code. preparing for simulation and dependency injection
6ea7007 to
83680a1
Compare
…mpl vs TeamSparkMaxSimImpl instantiation. enable comment-based spotless toggle support
bc79a2b to
71fc022
Compare
71fc022 to
c14fb8b
Compare
…age in sim results in a tighter turn when changing driving direction. additional variable naming factor and constants
…onstant again for tighter turns in sim. Bypass crash when running ClimbMechanism in sim by using ClosedLoopConfig.FeedbackSensor.kPrimaryEncoder
Task/2025 refactor sim
|
@FumperForrest These are the changes I made as part of a codebase refactor. I'm submitting this as a draft, so let's not merge until we've had a chance to discuss and deploy to the robot to see what broke. I primarily focused on restructuring the subsystems, organizing them into packages, capturing hard-coded values into documented fields and removing dead code. As for the subsystems I introduced the concept of a "context" - where each subsystem accepts an associated "context" object that maintains its properties. I favor that over hard coding the values inline within each subsystem. My hope is that if we establish this pattern going forward, we'll promote a clean separation between the configuration state and the subsystem logic. Also by doing this, we're a step closer to something like a json-based configuration, where we maintain all of these "magic values" within simple json files, making it easier to tweak and track changes. For the context classes I used Lombok and its builders for keeping things clean. We can talk more about that later, but in short each context has a public static "defaults" method which returns an instance of the context with all values set to their original 2025 values - the intention being that when we deploy the refactor, things should behave as they did last year. And for the 2026 subsystems, we can continue to use this pattern... for each new subsystem, we create an associated context. |
f9723d0 to
5727c45
Compare
1bf5ddf to
eb5f3d7
Compare
eb5f3d7 to
c0892a3
Compare
Refactor: simulation-ready swerve, input plumbing, motor abstraction, and package re-org
What changed (high-level)
SwerveModuleSim, proper voltage scaling, and faster azimuth response for crisp direction changes.DrivetrainandSwerveModuleunderfrc.robot.subsystems.drivetrain/*with context objects for tunables and dependency injection.SwerveDriveCommandintocommands/swervedrive/*and added aControllerDelegateto map DS axes/inputs cleanly (works with Sim GUI keyboard).AlgaePIDCommand,ElevatorPIDCommand) and removed legacy variants.*Contextclasses:algae/*,coral/*,climb/*,elevator/*,vision/*. Removed deprecated top-level variants.TeamSparkMax, withTeamSparkMaxImpl(real) andTeamSparkMaxSimImpl(sim) to keep vendor wiring out of subsystems.Robotlifecycle boilerplate.Notable implementation details
SwerveModuleState.optimize()is applied against current module angle before computing volts, ensuring shortest-path steering with correct speed sign flips.getHeading()+getSwerveModulePositions()switch between sim and real sources; pose estimator updated exactly once per loop.Files touched (selected)
subsystems/drivetrain/Drivetrain.java,SwerveModule.java,DrivetrainContext.java,SwerveModuleContext.java,sim/SwerveModuleSim.java,commands/swervedrive/*,support/sparkmax/*.DriveTrain.java, older mechanism files, and several legacy commands replaced by namespaced versions.Behavior improvements
Risks / compatibility
How I tested
x/yspeeds; logs show correct chassis speeds and module angles for pure translation.SwerveDriveCommand#executelogicFollow-ups
SwerveModule.setDesiredState()for even sharper direction snaps.