Skip to content

Feature/sys#15

Merged
y0shi merged 2 commits intodevelopmentfrom
feature/sysID
Feb 7, 2026
Merged

Feature/sys#15
y0shi merged 2 commits intodevelopmentfrom
feature/sysID

Conversation

@Orcasphynx
Copy link
Collaborator

No description provided.

@github-actions
Copy link

github-actions bot commented Feb 6, 2026

AI Code Review

Hey team!

This pull request makes excellent progress in organizing the drivetrain subsystem, centralizing constants, and integrating SysId routines. It significantly improves the clarity and maintainability of the drive code, which is fantastic!

Positive Highlights

  1. Excellent Code Organization: The creation of DriveConstants, DriveMotorConfigs, and SteerMotorConfigs is a fantastic step towards centralizing and organizing drivetrain parameters. This makes the code much more readable and easier to tune.
  2. Robust SysId Integration: Moving the SysId routines into DrivetrainSubsystem as command factory methods (sysIdSteer(), sysIdTranslation()) is a clean and effective way to manage characterization. The use of timeouts for these routines is also a great safety measure.
  3. Improved Driver Control: Implementing squared joystick inputs for drive control (using Math.copySign and Math.pow) is a smart change that often leads to more precise and intuitive robot control at varying speeds.

Suggestions

Code Quality & Java Standards

  • Javadoc Documentation: It might be helpful to add Javadoc comments to the new classes (DriveConstants, DriveMotorConfigs, SteerMotorConfigs) and their public/protected methods and constants. This will greatly help future team members understand their purpose and usage. For example, a simple Javadoc on DriveMotorConfigs could explain that it holds placeholder PID/FF values for the drive motors, to be updated after SysId.
    • Files: src/main/java/frc/robot/subsystems/drive/DriveConstants.java, src/main/java/frc/robot/subsystems/drive/DriveMotorConfigs.java, src/main/java/frc/robot/subsystems/drive/SteerMotorConfigs.java, src/main/java/frc/robot/subsystems/drive/DrivetrainSubsystem.java
  • Constant Placeholders: In src/main/java/frc/robot/subsystems/drive/DriveMotorConfigs.java, the kP, kD, kS, kV, kA values are currently all 0. Consider adding a comment indicating that these are placeholders to be updated after running SysId for the drive motors. This helps clarify the intent for anyone looking at the values.

FRC/WPILib Best Practices & Team-Specific Guidelines

  • Type-Safe Units for Telemetry: In src/main/java/frc/robot/RobotContainer.java, the import static edu.wpi.first.units.Units.*; was removed. However, the Telemetry logger = new Telemetry(DriveConstants.MAX_DRIVE_SPEED); line still uses DriveConstants.MAX_DRIVE_SPEED, which is defined using MetersPerSecond. It might be beneficial to re-add the import and ensure Telemetry's constructor explicitly accepts a Measure<Velocity<Distance>> to fully adhere to our "Always use WPILib's Units system" guideline. If Telemetry is designed to take a raw double (assuming meters per second), then this is fine, but it's good to be explicit.
    • File: src/main/java/frc/robot/RobotContainer.java (Line 23, and potentially the Telemetry class definition).
  • SysId Command Clarity: The sysIdSteer() and sysIdTranslation() commands in src/main/java/frc/robot/subsystems/drive/DrivetrainSubsystem.java chain all four SysId routines (quasistatic forward/reverse, dynamic forward/reverse) into a single command. While SysIdRoutine is designed to handle this, for characterization, it's often easier to analyze the data if each phase (e.g., "quasistatic forward") is run as a distinct command. This helps ensure separate log entries for each phase. If the intent is to run all four sequentially with a single button press for convenience, that's perfectly fine, but just something to keep in mind for data analysis.
    • File: src/main/java/frc/robot/subsystems/drive/DrivetrainSubsystem.java (Lines 44, 61)

Questions

  • Could you clarify the expected input type for the Telemetry constructor? Does it anticipate a raw double representing speed in meters per second, or a Measure<Velocity<Distance>> object from WPILib's units system? This would help ensure we're consistently using type-safe units.

Keep up the fantastic work! This is a solid set of changes that will make the drivetrain much more robust and easier to manage. Looking forward to seeing it in action!


This review was automatically generated by AI. Please use your judgment and feel free to discuss any suggestions!

@github-actions
Copy link

github-actions bot commented Feb 6, 2026

✓ Build successful and code formatting check passed!

@y0shi y0shi merged commit 27c0fc6 into development Feb 7, 2026
2 checks passed
@y0shi y0shi deleted the feature/sysID branch February 7, 2026 00:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants