Feature/feb7 changes

[Orcasphynx]

No description provided.

[github-actions]

✓ Build successful and code formatting check passed!

[github-actions]

AI Code Review

Hey team!

This pull request includes some really exciting changes, especially with the integration of PathPlanner and updates to the vision system. It looks like you're making excellent progress towards a robust autonomous and drive system!

Positive Highlights

• PathPlanner Integration: The setup for PathPlanner autos and paths is fantastic! Using AutoBuilder in RobotContainer and configuring it in DrivetrainSubsystem is a great way to leverage modern trajectory planning.
• Vision System Streamlining: Consolidating to a single front camera and updating CameraConstants and VisionSubsystem for PhotonVision 2025 is a smart move, simplifying the vision pipeline.
• Tunable PID Controllers: Introducing DrivePreferences and factory methods for TranslationPIDController and RotationPIDController is excellent for making the autonomous driving tunable and robust.

Suggestions

Here are a few suggestions to consider as you continue to develop:

FRC/WPILib Best Practices & Architecture

• WheelSlipTest.java - Threading Concerns:
  • File: src/main/java/frc/robot/commands/WheelSlipTest.java
  • Suggestion: The use of ScheduledExecutorService within a WPILib Command is generally discouraged. WPILib's command-based framework is designed around a single-threaded periodic loop, and introducing separate threads that modify robot state can lead to hard-to-debug race conditions, non-deterministic behavior, and issues with deterministic logging/replay (especially if you plan to use AdvantageKit).
  • Why it matters: For reliable robot behavior and easier debugging, it's best to keep all robot logic within the main robot thread or use WPILib's scheduling mechanisms (like Command.runOnce(), WaitCommand, Commands.sequence(), or Commands.run(() -> { ... }, this)) to achieve timed actions.
  • Recommendation: Consider refactoring WheelSlipTest to update the step variable and apply power within its execute() method, perhaps using Timer.getFPGATimestamp() to manage the timing of power increases, or by creating a sequence of commands.
• Thread Priority Management:
  • File: src/main/java/frc/robot/Robot.java
  • Suggestion: Your team's guidelines mention elevating critical threads. It might be helpful to add Thread.currentThread().setPriority(4); in the Robot() constructor to ensure consistent control loop timing.
  • Why it matters: Elevating the priority of the main robot thread can help ensure that critical robot code runs on time, reducing potential latency and improving control loop performance.
• Vision Camera Transform Selection:
  • File: src/main/java/frc/robot/subsystems/vision/CameraConstants.java
  • Suggestion: You've defined both photonCameraTransform_Front_STATIC and _TILTED. How does the robot decide which transform to use? If only one is ever used, the other might be considered dead code. If there's a dynamic choice, it would be great to see the mechanism for that choice implemented, perhaps with a preference or a command to switch.
  • Why it matters: Clearly defining how different configurations are selected improves code clarity and maintainability.

Java Standards & Code Quality

• Logging for Fault Detection:
  • Files: src/main/java/frc/robot/statemachines/DriveState.java (line 55), src/main/java/frc/robot/subsystems/drive/DrivetrainSubsystem.java (printDriveMotorCurrents())
  • Suggestion: For match logging and fault detection, it might be helpful to replace System.out.println() with a dedicated logging framework, such as Logger.recordOutput (Epilogue/AdvantageKit), as per your custom rules.
  • Why it matters: Using a consistent logging framework ensures that all important messages (especially errors and diagnostic data) are recorded in a structured way, which is crucial for post-match analysis and debugging, and prevents console spam during a match.
• Javadoc Documentation:
  • Files: src/main/java/frc/robot/commands/DriveToPose.java, src/main/java/frc/robot/commands/WheelSlipTest.java, src/main/java/frc/robot/subsystems/drive/DrivetrainSubsystem.java (new public methods)
  • Suggestion: Consider adding Javadoc comments to new classes, public methods, and complex sections of code. For example, DriveToPose and WheelSlipTest would benefit from class-level Javadoc explaining their purpose, and the new public methods in DrivetrainSubsystem could use method-level Javadoc.
  • Why it matters: Good documentation helps other team members (and your future self!) understand the code's purpose, how to use it, and any important considerations.

Type-Safe Units

• Alignment Tolerances:
  • File: src/main/java/frc/robot/subsystems/drive/DriveConstants.java (lines 28-29)
  • Suggestion: Your guidelines emphasize using WPILib's Units system. It might be helpful to define TRANSLATION_ALIGN_TOLERANCE and ROTATION_ALIGN_TOLERANCE using type-safe units (e.g., Meters.of(0.01) and Degrees.of(1.0)) to prevent potential conversion errors and improve clarity.
  • Why it matters: Type-safe units make your code more robust by catching unit-related mistakes at compile time, ensuring that physical quantities are always handled correctly.

Questions

• It looks like SignalLogger calls were removed from Robot.java. Is there a plan to integrate AdvantageKit or Epilogue for comprehensive logging instead, as mentioned in the guidelines?

Overall, this is a really solid set of changes that significantly improves the robot's autonomous capabilities and sets a great foundation for future development. Keep up the fantastic work!

---

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