Skip to content

DevilBotz2876/Reefscape2025

BranchesTags

Repository files navigation

This is the top-level folder for the DevilBotz robot code

The code uses Java WPILib and the WPILib command-based programming paradigm

Goals/Features

  • Extensibility and Reusability
    • One code base, multiple robots
  • Debuggability
    • Logging
    • Simulation
  • Vision Based Odometry
  • Odometry-based Path Following

General Resources:

Getting Started

  1. Install WPILib
  2. Install Git
    1. Windows
    2. MacOS
  3. Get Code from GitHub
    1. Create GitHub Account (if you don't already have one)
    2. Start WPILib VSCode
    3. Clone Repository
    4. Login to GitHub Account (if prompted)
    5. Repo: https://github.com/DevilBotz2876/XxxYYYY (where Xxx is the name of the FRC game and YYYY is the year E.g. "Reefscape2025"
    • Note: The initial compilation will take a while because of all the dependencies that need to be downloaded. If all works well, in the Terminal view at the bottom, you should see:
  4. Simulating the Code
    1. Starting a Simulation
      • "F5" starts the simulation
        • Alternate Steps:
          • "Ctrl-Shift-P" or "Command-Shift-P"
          • "Simulate Robot Code"
      • Enable: "Sim GUI"
        • If you get the following error: "cannot find frc.robot.main", then:
          • "Ctrl-Shift-P" --> "Clean Language Server Workspace"
      • Optional: Enable DriverStation to better mimic real world usage
    2. Robot Simulation (aka Sim GUI) Overview
      1. Configure XBox Controller
        1. Make sure joystick is in "X-Box Mode". Plug in Joystick.
        2. Verify Joystick is Detected in "System Joysticks" window
          1. On Mac OS: You must connect via a bluetooth wireless enabled controller
        3. Drag controller from "System Joysticks" to "Joysticks" (Joystick[0])
        4. Make sure to "Map Gamepad" is checked
      2. Open 2D Field View
        1. NetworkTables --> "SmartDashboard" --> "Field"
        2. To Hide Swerve Modules:
          1. Click on the "Hamburger Button"
          2. Goto "XModules"
            • Box/Image --> Hidden
            • Arrow Size --> 10% (slider)
      3. Set Robot State
        1. Set Mode to "Teleoperated"
        2. Thumb Controls should now move the robot
    3. 2D Mechanism Simulation
      1. NetworkTables --> "SmartDashboard" --> "Robot 2D Simulation"
    4. Vision Field
      1. NetworkTables --> "SmartDashboard" --> "VisionSystemSim-main" --> Sim Field
    5. Alliance Selection
    6. Autonomous
    7. AdvantageScope

Directory Structure

  • .github/workflows: Contains various GitHub automation scripts that are run automatically at various stages of the code development/ integration process.
  • vendordeps: Contains the various external libraries and versions that the code base utilizes.
  • src/main: All of the robot code and config files are here
    • deploy: Config files, resources, etc that need to be stored directly on the actual robot. These can be read using standard Java File I/O calls
    • java/frc/robot: This is the root of all of the actual Java code for the robot
      • commands/: All commands are stored in this folder
        • common/: Common commands are ones that operate on the Subsystem interface, so doesn't rely on any game specific implementations/APIs.
      • config/: The config directory is used to support multiple robot versions using the same code base.
        • game/(src/main/java/frc/robot/config/game/): Each game will generally have it's own robot configuration.
          • reefscape2025/: game-specific robot configurations are stored here.
            • RobotConfig.java: Defines all of the subsystems and controls required for a "robot". Each robot variant extends RobotConfig and instantiates the subsystems and overrides constants as needed. Implements simulation stubs for all subsystems.
            • RobotConfigPhoenix..java: Robot config for the "Phoenix" robot that instantiates specific subsystems (e.g. drivetrain and vision) using specific hardware IO instances. Everything else not explicitly overrideen will use the default _stub _versions.
            • ...
      • io/: generic low-level hardware IO (e.g. Motors, Limit Switches, Sensors, etc)
        • interfaces/: hardware interfaces that are common for all possible implementations. E.g. a MotorIO would generally have a way to at least setVoltage and get status such as voltage applied and actual amperage used.
          • MotorIO.java: Defines the minimum expected interface (settings, control, and status) for a generic motor.
            • setVoltage(double volts)
            • setVelocity(double velocityRadPerSec, double ffVolts)
            • setPosition(double positionRad, double ffVolts)
            • getPid()
          • GizmoIO.java
          • ArmIO.java
          • ClimberIO.java
          • ...
        • implementations/: Hardware specific implementations of the hardware IO interfaces. Each interface may have one or more implementations depending on manufacturer, model, etc. Each interface must have a simulation stub implementation
          • motor/
            • MotorIOBase.java: The base abstract implementation of the Motor interface. All motor implementations should extend this base class. It implements the following functionality:
              • generates status in other units (e.g. from radians to degrees, RPMs, etc)
              • implements software based velocity and position PID control
            • Stub Implementations - for software bring-up in simulation. Each implements the physics of different types of mechanisms
            • Real Implementations
          • gizmo/
            • GizmoIOStub.java: Dummy/Stub implementation of a "Gizmo"
            • GizmoIOAcme.java: Implementation of the Acme brand/model of a "Gizmo"
          • arm/
            • ArmIOStub.java
            • ArmIOSparkMax.java
            • ...
          • climber/
          • ...
      • subsystems/: subsystems are implemented using one or more Hardware IO instances. E.g. an Arm may contains an instance of a MotorIO connected to gears (to move the Arm up/down) and an AbsoluteEncoderIO (to measure the actual current angle).
        • interfaces/: subsystem interfaces that are common for all possible implementations
        • controls/: All controls including driver, debug, pit, and sysid are defined here. This includes both joystick and GUI-based controls. Contains the logic to connect specific user interfaces (e.g. ShuffleBoard, XBox Controllers, etc) to subsystem functionality. Ideally, the controls should be operating on the subsystem's interface and not the actual implementation.
          • gizmo
            • GizmoControls.java
          • drive
            • DriveControls.java
          • vision
            • VisionControls.java
        • implementations/: Subsystem specific implementations that use one or more hardware IO instances. May need to be configured differently depending on the Robot Configuration. E.g. for an Arm, the absolute encoder offset will likely be different in different implementations of the Arm. The subsystem should provide a mechanism to configure it accordingly.

Note: The content below may be out of date and needs to be reviewed/updated

Useful Resources:

2024

We had 3 different robots with different capabilities for dev/testing purposes:

  1. Sherman: Tank Drive + Initial Arm Prototype
  2. Phoenix: Initial Swerve Drive + Vision Prototype
  3. Inferno: Final Robot
Robot Drive Shooter Intake Arm Auto Climber Vision LED
Sherman Differential SparkMax(2) SparkMax(1) TalonSRX(3) No (stub) No (stub) No (stub) No (stub)
Phoenix Swerve(yagsl) No (stub) No (stub) No (stub) Yes No (stub) Shooter No (stub)
Inferno Swerve(yagsl) SparkMax(2) SparkMax(3) SparkMax(4) Yes SparkMax(7) SparkMax(6) Shooter Intake Right Left Yes

Subsystems

Subsystem and IO interfaces and implementations

Subsystems utilize the AdvantageKit IO Layer paradigm.

Each subsystem is implemented using the following breakdown. Here, assume we have a mechanism called a "Gizmo":

  • Hardware IO
    • Simple Interface (defines the desired hardware functionality)
      • GizmoIO.java 
        public static class GizmoIOInputs {
    public double velocityRadPerSec = 0.0;
    public double appliedVolts = 0.0;
    public double current;
}

void updateInputs(GizmoIOInputs inputs); ← gets current sensor readings

void setVoltage(double volts); ← sets desired voltage
    • One or more Implementation(s)
      • GizmoIOStub.java ← Simulated implementation 
        public class GizmoIOStub implements GizmoIO {
      • GizmoIOSparkMax.java ← SparkMax motor based implementation
      • GizmoIOEtc.java
  • Subsystem (utilizes one or more Hardware IO implementation)
    • Single Interface (defines the desired subsystem functionality)
      • GizmoSubsystem.java
        • Low Level/Debug Controls 
          void runVoltage(double volts);
double getCurrentVoltage();
void add2dSim(Mechanism2d mech2d);
        • High Level Controls 
          Command getTurnOffCommand();
Command getTurnOnCommand();
    • One or more Implementation(s)
      • GizmoSubsystemSimple.java 
        public class GizmoSubsystemSimple implements Gizmo {
    GizmoSubsystemSimple(GizmoIO io); ← an IO instance is passed into the GizmoSubsystemSimple

    void periodic() {
        IO.updateInputs(inputs);
        Logger.processInputs("Intake", inputs)
    }
    ...
}
      • GizmoSubsystemAdvanced.java 
        public class GizmoSubsystemAdvanced implements Gizmo {
    ...
}
      • GizmoSubsystemEtc.java

It is important to note that the same Hardware IO can be shared by completely different subsystems. E.g. we may just want a Hardware IO layer abstraction for basic functionality E.g.

  • MotorIO
    • MotorIOSparkMax
    • MotorIOTalonSRX
  • LimitSwitchIO

And then a subsystem can consist of 1 or more MotorIO instances and 1 or more LimitSwitchIO instances.

Code Flow

  1. Main.java --> Robot.java --> RobotContainer.java
    1. Setup Robot Config
      • A persistent preference with the key "Robot Name" is hard-coded onto the RoboRio flash memory
      • The "Robot Name" key is read from the RoboRio at start and determines which robot config to load.
    2. Setup Controls (Bindings)
    3. Setup Autonomous

Pathplanner

Path and Auto routine configuration files generated by the PathPlanner App

Useful Resources:

Yagsl

YAGSL swerve configuration files for each robot

Useful Resources

Vision

Useful Resources:

  1. Initial Setup
    1. For each camera
      • On the PhotonVision co-processor (e.g.. Raspberry Pi)
        • Assign a unique camera name
        • 2D AprilTag tracking will work out of the box
          • You can get camera relative yaw, pitch, and roll information for each visible/detected AprilTag w/o calibrating the camera
        • 3D AprilTag tracking requires calibration for each resolution:
          • Calibrate FOV
          • Measure location of camera relative to the center of the robot (See Transform3D VisionCamera.VisionCamera)
            • Measure translation (x,y,z)
            • Measure rotation (roll, pitch, yaw)
    2. For each field
      • Load the AprilTag map layout into PhotonVision (See AprilTagFields.class)
  2. Periodically at runtime
    1. For each camera
      • If estimated robot pose is available (i.e. AprilTag is visible and 3D tracking is enabled)

About

No description, website, or topics provided.

Resources

Readme
Activity
Custom properties

Stars

1 star

Watchers

6 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Contributors 8

Languages