Development

[y0shi]

No description provided.

[github-actions]

AI Code Review

Hey team,

Great work on this pull request! It looks like you're making solid progress on organizing your autonomous routines and setting up various robot preferences. I'm really impressed with the clear structure you've established for your PathPlanner files!

Positive Highlights

• Excellent PathPlanner Organization: The use of folder fields in your PathPlanner auto and path definitions (e.g., "Basic Comp Autons", "HP AUTO", "Plus - Test") is fantastic. This will make it much easier to manage a growing number of autonomous routines and individual paths, improving clarity and maintainability.
• Clear Auto Command Composition: Your .auto files demonstrate a strong understanding of command composition by sequencing path commands with named commands like "Shoot", "HP Reload", and "Seed". This approach promotes reusable, high-level commands, which is a core tenet of good command-based programming.
• Descriptive Naming for Paths: The path names, such as "Start to Shoot - CENTER" or "Shoot to Overbump - LEFT", are very descriptive and make it easy to understand the purpose of each path at a glance.

Suggestions

FRC/WPILib Best Practices & Java Standards

• NetworkTables Preferences and Type-Safe Units (networktables.json.bck):

  • I see many double values being defined for preferences like MaxVelocity, MaxAccel, Launch Speed, etc. While storing them as doubles in NetworkTables is standard, it's important to remember our guideline to always use WPILib's Units system in Java code when reading and using these values.
  • Educational Context: Using Measure<Unit> (e.g., MetersPerSecond.of(4.5)) in your Java code helps prevent common unit conversion errors (like accidentally mixing meters and inches) and makes the code's intent clearer.
  • Recommendation: When these preferences are retrieved in your Java code, consider immediately wrapping them in appropriate Measure<Unit> objects. For example, MetersPerSecond.of(preferences.getDouble("MaxVelocity", 4.5)).

• PathPlanner resetOdom in Test Autos (src/main/deploy/pathplanner/autos/*.auto):

  • It's great that you've set resetOdom: true for most of your autonomous routines. This ensures a consistent starting point for the robot's pose.
  • Recommendation: Consider ensuring resetOdom: true for all autonomous routines, especially the "Test Autons" and "Simple Autons," unless there's a specific reason to not reset odometry (e.g., testing path chaining without resetting). This helps prevent unexpected behavior if a test auto is run after another auto that ended in a different position.

Code Quality

• Consistency in Folder Naming (src/main/deploy/pathplanner/paths/*.path):
  • I noticed a slight variation in folder naming, for instance, Test Autons for autos and Test Paths for paths, or Plus Sign Test vs Plus - Test.
  • Recommendation: It might be helpful to standardize the naming convention for your PathPlanner folders (e.g., always Autons for autos and Paths for paths, or Test_Autons, Test_Paths). This small consistency can further improve navigability for anyone looking through the deploy folder.

Questions

• Could you explain the purpose of networktables.json.bck? Is it a backup, or is it intended to be deployed as part of the robot code? If it's a backup, it might be good to ensure it's not accidentally deployed or to consider moving it to a non-deploy directory if it's purely for historical reference.

Keep up the fantastic work on developing these robust autonomous capabilities! Your attention to organization and structure is really paying off.

---

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

[github-actions]

✓ Build successful and code formatting check passed!