Initial Implementation Code Cleanup

[aidnem]

Purpose The purpose of this addition is to make sure the repository is structured well and isn't too janky before we start adding more specific/advanced features to subsystems.

Project Scope

• [x] Gitignore src/main/java/frc/robot/BuildConstants.java
• [x] Make drivetrain controlled by a feature flag
• [x] Make scoring + intake controlled by a feature flag
• [x] Make sure constants are in the right place
• [x] Make sure subsystems and commands are all in the right folders
• [x] Make RobotContainer structured + ordered correctly
• [x] (after shooter/intake is merged) make sure subsystems play nice in sim and work together without issue.

[aidnem]

@jkleiber How do you want to handle Constants.currentMode? It's used in a few places. Should we keep frc.robot.constants.Constants just for this?

[jkleiber]

@aidnem I think it makes sense to keep it as is (let the software detect if it is in sim or not)

[aidnem]

@jkleiber Sounds good. The only thing is, we won't be able to handle replay mode without having it in constants. I assume we can cross that bridge when we come to it.

[aidnem]

Today at shop I:

• Helped Minh with arm HITL testing (did not get very far but found quite a lot of issues 😭.
• Made scoring and intake controlled by feature flags and disable bindings for them when they're flagged out.
• TODO: FIX THIS! Discovered that none of our advantagekit fields are logging right now in sim on this branch. I'm not sure what's up with this but I'll figure it out at home and see if I can replicate the fix at shop.
• Reviewed + approved Nathan's JSON PR, and discovered what seemed like a problem with our jitpack configuration: main-SNAPSHOT wouldn't get the latest changes so he had to manually add the commit hash. This could've just been lag. TODO: Try to build Nathan's branch tomorrow to see if it was just jitpack having a delay in updating to new commits on main.

[jkleiber]

At some point we should establish some sort of release cadence to point jitpack at releases rather than just whatever the latest version on main is (will help contain regressions and keep configuration management easier)

[aidnem]

@jkleiber could we just use a stable branch or something and point it at that? We could also manually point at tags and then make a little mini-PR to update to the latest version when needed.

[jkleiber]

Making a release off of main is super easy and would be the same as pointing at tags

[aidnem]

Oh yeah I meant tagging commits as releases and then pointing at those, sorry for the confusion