advantagekit

📁 yeti-robotics/robot-skills 📅 4 days ago
3
总安装量
3
周安装量
#61029
全站排名
安装命令
npx skills add https://github.com/yeti-robotics/robot-skills --skill advantagekit

Agent 安装分布

opencode 3
gemini-cli 3
github-copilot 3
codex 3
kimi-cli 3
cursor 3

Skill 文档

AdvantageKit (2026)

Documentation sourced from docs.advantagekit.org. AdvantageKit is developed by Littleton Robotics (FRC 6328).

Core IO Layer Pattern

Every hardware-interacting subsystem uses three pieces:

  1. IO interface — declares updateInputs() and output methods
  2. IOInputs inner class — annotated @AutoLog, holds all sensor values
  3. Subsystem — depends on IO, calls processInputs in periodic()

The @AutoLog annotation generates a <ClassName>AutoLogged class — always instantiate the generated class, not the original.

// DriveIO.java
public interface DriveIO {
    @AutoLog
    class DriveIOInputs {
        public double leftPositionRad = 0.0;
        public double rightPositionRad = 0.0;
        public double leftVelocityRadPerSec = 0.0;
        public double rightVelocityRadPerSec = 0.0;
        public double[] appliedVolts = new double[] {};
    }

    default void updateInputs(DriveIOInputs inputs) {}
    default void setVoltage(double leftVolts, double rightVolts) {}
}

// Drive.java
public class Drive extends SubsystemBase {
    private final DriveIO io;
    private final DriveIOInputsAutoLogged inputs = new DriveIOInputsAutoLogged();

    public Drive(DriveIO io) {
        this.io = io;
    }

    @Override
    public void periodic() {
        io.updateInputs(inputs);
        Logger.processInputs("Drive", inputs);
        // All logic uses inputs.leftPositionRad, etc. — never calls hardware directly
    }

    public void setVoltage(double left, double right) {
        io.setVoltage(left, right);
    }
}

IO Implementations

  • DriveIOSparkMax — real hardware, talks to CAN devices
  • DriveIOSim — physics simulation
  • DriveIO (interface default) — no-op for replay / unit tests

Inject the correct implementation in RobotContainer based on Robot.isReal() / isSimulation().

Logger Initialization Order

Rule: call Logger.start() before instantiating any subsystem or RobotContainer.

public class Robot extends LoggedRobot {
    private RobotContainer robotContainer;

    @Override
    public void robotInit() {
        // Configure data receivers BEFORE start()
        Logger.addDataReceiver(new WPILOGWriter());
        Logger.addDataReceiver(new NT4Publisher());
        Logger.start(); // ← must be first

        robotContainer = new RobotContainer(); // ← safe to create subsystems now
    }
}

Key Rules

Rule Reason
Hardware access only inside IO implementations Ensures all inputs are logged and replayable
Use Timer.getTimestamp() not Timer.getFPGATimestamp() FPGA timestamps are non-deterministic
Call logging APIs from main thread only recordOutput / processInputs are not thread-safe
Don’t read subsystem inputs in constructors Inputs are stale until first periodic()
Test replay regularly during development Catches non-determinism early

Output Logging

Log computed values for post-match analysis:

Logger.recordOutput("Drive/LeftVelocityError", setpoint - inputs.leftVelocityRadPerSec);
Logger.recordOutput("Odometry/Robot", poseEstimator.getEstimatedPosition());
Logger.recordOutput("Mechanism", mechanism2d);

See references/output-logging.md for replay-based output generation and version control integration.

Common Issues

See references/common-issues.md for detailed guidance on:

  • Non-deterministic data sources (NetworkTables, YAGSL, random, maps)
  • Multithreading constraints
  • Uninitialized inputs in constructors

Recording Inputs (Detail)

See references/recording-inputs.md for:

  • @AutoLog annotation and AutoLogged class naming
  • Units in input fields (naming convention vs. Measure types)
  • IO implementation structure (real / sim / replay no-op)
  • Dashboard inputs — LoggedDashboardChooser, LoggedNetworkNumber, etc.
  • Coprocessor / vision data via IO layer