The `command3` example project contains a program that could plausibly
play in the 2026 rebuilt game. It includes nested mechanisms (`Intake`
has an inner `IntakeWrist` and `IntakeRoller` and is similar to the v2
superstructure concept), swerve drive with localization and path
following (albeit stubbed for sake of example), opmodes and
opmode-scoped commands, and command-scoped triggers.
The template projects are basic skeletons. The larger template includes
a basic command that just increments and prints a counter variable every
time it runs.
The hatchbot v3 example has been refactored to be more idiomatic:
- `RobotContainer` removed
- "Subsystem" names in packages, comments, and classes has been replaced
with "Mechanism"
- Some v2-specific comments and structures have been reworded or deleted
- The Drive mechanism now provides commands for arcade drive and driving
a distance, instead of exposing public methods that write directly to
hardware (which broke encapsulation and made it possible to issue
conflicting hardware requests)
Move various "examples" into snippets. Several examples that were less
than a full mechanism or robot were moved to snippets. `arcadedrive` and
`tankdrive` were removed in favor of their Gamepad variants. `hidrumble`
was removed due to being too simple. `potentiometerpid` was removed
because of low utility. `gyromecanum` replaced `mecanumdrive` for
deduplication and because very few teams run holonomic drivetrains
without gyros.
Easier then the last one that put everything in a sub namespace. By
prefixing the name less things break, and intellisense will be less
confusing to new users during the transition.
User code:
- OpModeRobot used as the robot base class
- LinearOpMode and PeriodicOpMode are provided opmode base classes
- In Java, annotations can be used to automatically register opmode classes
Additional user code functionality:
- OpMode (string) is available in addition to the overall
auto/teleop/test robot mode
- OpMode does not indicate enable (enable/disable is still separate)
- The HAL API uses integer UIDs; these are exposed at the user API level
as well for faster checks
- User code creates opmodes on startup (these have name, category,
description, etc).
DS:
- DS will present opmode selection lists for auto and teleop for
match/practice. During a match, the DS will automatically activate the
selected opmode in the corresponding match period.
- For testing, an overall mode is selected (e.g. teleop/auto/test) and a
single opmode is selected
Future work:
- Command framework support/integration
- Python annotation support
- Unit tests (needs race-free DS sim updates)
- Porting of examples
Co-authored-by: Joseph Eng <91924258+KangarooKoala@users.noreply.github.com>
