Based on the WCP 2026 Competitive Concept for Rebuilt
The documentation for StuyPlus-2026 can be found here.
Files:
src/main/java/com/stuypulse/robot/subsystems/swervesrc/main/java/com/stuypulse/robot/util/HolonomicController.java
We utilize a raised swerve drivetrain with CTRE Phoenix 6 hardware and four swerve modules, letting us independently rotate the wheels. This allows for higher manueverability.
For our MapleSim w/ AdvantageScope, we create a MapleSimSwerveDrivetrain for simulation purposes and publish drivetrain pose, module states, and chassis speeds via NetworkTables.
The robot is driven Field-Centric.
We use both Vision and odometry for pose estimation. Check the vision section for details.
HolonomicController.java, made by the main team 694, is essentially the PID Controller but for the drivetrain.
File: src/main/java/com/stuypulse/robot/subsystems/intake
Our intake is made up of 3 sets of rollers, all connected by belts, which are stowed and deployed with a pivot attached to the roller plate.
It contains the following states:
IDLE: Intake brought up, rollers do not runINTAKE: Intake brought down, rollers run forward on a duty cycleOUTTAKE: Intake brought down, rollers run backward on a duty cycleDOWN: Intake brought down, rollers do not runHOMING_DOWN: Intake pushed down, rollers do not run
Based on an angle and a duty cycle, in the periodic method, we use PID to control our pivot and a duty cycle to control the percentage of power given to the rollers.
In order to stop the fuel from pushing the intake up, we apply something called "pushdown current". This keeps pushing the intake downwards in order to resist the force of the fuel and keep it downwards at the angle we want.
Due to encoder issues when the chain skips, it's quite difficult to detect when the pivot is within tolerance. In order to detect this, we detect stalling to know when to stop. This works in combination with homing down, in which we apply a constant current in order to force the pivot downwards.
File: src/main/java/com/stuypulse/robot/subsystems/feeder
Our feeder is of indexer type, having three lanes for the shooter's three slots. It uses two motors (follower-leader) to guide the fuel from the hopper to the shooter.
It contains the following states:
STOP: Feeder is stoppedFORWARD: Motors run forward on a duty cycle to feed fuel to the shooterREVERSE: Motors run backward on a duty cycle to work with the intake to outtake fuel from the robot
In the periodic method, we use DutyCycleOut to control the percentage of power given to both feeder motors. The feeder is set to only run when aligned to the hub if in SHOOT state. For SOTM/FOTM, it still feeds while moving if needed.
File: src/main/java/com/stuypulse/robot/subsystems/shooter
Our shooter is made up of 3 shooter motors (Left, Center, Right).
The Center and Right motors follow the Left motor.
Important
SOTM (Shoot on the move) and FOTM (Ferry on the move) are low priority.
It contains the following states:
IDLE: Shooter doesn't run.SHOOT: Shooter wheels spin at it's target RPM, interpolated based on distance to hub.SOTM: Shoot on the move. Shooter RPM is interpolated based on distance to hub.FOTM: Ferry on the move. Shooter RPM is interpolated based on distance to hub.FERRY: Shooter wheels spin at it's target RPM, interpolated based on distance to ferry zone.
In the periodic method, the shooter RPM is controlled via VelocityTorqueCurrentFOC control request.
File: src/main/java/com/stuypulse/robot/subsystems/handoff
The handoff is a singular motor that helps the feeder by "handing off" the fuel from the hopper to the feeder indexer lanes.
It contains the following states:
IDLE: Handoff doesn't run.FORWARD: The handoff runs forwardREVERSE: The handoff runs backward
In the periodic method, the handoff motors use DutyCycleOut to control the handoff.
Files:
This uses Limelights from Limelight Vision to use the AprilTags to estimate the pose of the robot. It works in combination with odometry to estimate the pose using gyros and encoders when using megatag 2.
All of the math and code is mostly done within the Limelight itself via LimelightOS. You mainly just need to connect it to your robot and determine the protocol it sends to.
LimelightHelpers.java is a wrapper class for the vision NetworkTables from the Limelight that abstracts many functions for you such as setting pipelines and the pose estimation. You can find the latest version of LimelightHelpers.java here.
Features:
- The robot currently only has one Limelight
- Uses MegaTag localization algorithm
- Commands for switching the Limelight pipeline based on
SunnyandCloudyconditions to increase efficiency.
The usage guide can be found here.
Files:
Additionally, we modified our CommandSwerveDrivetrain.java in order to:
- Replace the normal simulation instance with a
MapleSimSwerveDrivetraininstance - Update the simulation instance with Maplesim's periodic method (
MapleSimSwerveDrivetrain::update) - Publish our simulated swerve module states, chassis speeds, and drivetrain pose to
NetworkTables
MapleSim is a physics simulation tool created in Java for FRC, made by the Shenzhen Robotics Alliance.
It uses the dyn4j physics engine, simulating your Drivetrain as closely as your real code does, the field, and collisions between parts of the world.
It works with AdvantageScope simply for rendering the Poses for all elements in the sim.
We use this for:
- Overall testing our archetype before our Mechanical Engineering department finishes the physical robot
- Visualizing and testing our code logic
- Testing how autons might look on the field
- Helping members understand how the robot will operate
- Visualizing match logs in 3d
The styling in betterjdocs.css is based on a modified version of BetterJDocs.
Credit to @xMrAfonso and @Andre601 for the original file:
https://github.com/xMrAfonso/BetterJDocs
This project is under the MIT License