Kirby_Bot_2024

A cute pink circular turret bot, competing at Madtown Throwdown 2024.

Code structure

Since we're using AdvantageKit, we follow the IO-layer-based, command-based, project structure similar to Highlander Robotics.

The dependencies we use are (besides WPILib):

• AdvantageKit: logging library (saved to file)
• Monologue: also a logging library, but for sending things to NT for the dashboard
• Phoenix 6 & 5 (for the CANdle): library for interfacing with CTRE hardware
  • CTRE generated swerve
• Choreo: optimized auto path, generated ahead of time
• Pathplanner: dynamic path generation
• ..and Limelight's single-file library

Other than the typical FRC code structure scaffold, we also have GitHub Actions and some scripts to help with deployment.

Constants file and feature flags

I'm a bit pendantic about this because I care about consistence (I don't have OCD I swear) so here's the structure:

• We have our subsystem-specific constants (SubsystemConstants.java) and configs decentralized. This includes
  • Motor configs (e.g. gain values and current limits)
  • Subsystem characteristics (for physics simulation and gear ratios)
  • Position/velocity presets
  • kUse___ = enables/disables a specific feature in the subsystem
• We have our feature flags and otherwise global constants (e.g. logging and controller constants) in the Constants.java file
  • k___Enabled = enables/disables a subsystem
  • Enabling features of a single subsystem should be within the decentralized subsystem constants file (unless it is a feature that spans across multiple subsystems)
• Don't write feature flags for things that you could just straight up not use. Feature flags is the non-scuffed way of "temporarily disabling this code by commenting it out"
  • If you ever find yourself needing to comment some code out, consider creating a feature flag
• Have the feature flag-checking logic outside of your function (or, if it's a subsystem, passed in as a boolean value of enabled for that subsystem's DisabledSubsystem constructor)

How to

...start developing??

git clone https://github.com/Team3256/Kirby_Bot_2024.git
cd Kirby_Bot_2024
# if any of these commands fail, you either
# installed WPILib incorrectly
# or you didn't add ~/wpilib/2024/jdk/bin
./gradlew wrapper
./gradlew build
# or, if you want to simulate teh code
./gradlew simulateJava

Gradle build will automatically run checkers to make sure there are no null pointers within robot container that could cause the robot code to crash when deployed on the robot but it isn't fool-proof so you should still simulate changes to make sure the code doesn't crash.

...run the formatter?

./gradlew spotlessApply

...generate controller maps?

./gradlew simulateJava
# Running simulateJava will dump the controller map onto a file. Quit it right after the program starts
python scripts/gen_controller_map.py
# Now, open the index.html
# (`open` is a macOS-only command)
open scripts/index.html

Developing during comp

Ideally, you're not making any changes during comp but just in case... Branch off main (or the most recent working development branch) and name the branch "event/(the event name)". This will ensure that a commit is created whenever robot code is deployed. After any changes, try simulating and going into both auto and teleOP to make sure nothing crashes. Once you deploy make sure you run either a systems check or if you do not have time check the driver station to make sure the robot code has at least booted up.

Style guide

Check out the WB software manual for some styling stuff: https://docs.google.com/document/d/1stGoEnXgRHY7ff4rGbEselquu_KpRetePAEhrPY2oH0/edit

We use Spotless for formatting (run ./gradlew spotlessApply) and follow conventional commits.

We also have a very nuanced format for doing configs. An example will come soon! See here for now.