feat(auto): auto programs #14
Conversation
Co-authored-by: Brenden Freier <iam@baconi.ng>
i'm not 100% sure on the module's X locations, but im fairly confident because it looks very close in pathplanner Co-authored-by: Brenden Freier <iam@baconi.ng>
Baconing
added
Kind/Enhancement
WalkthroughThis pull request updates deployment configurations and robot behavior. The changes ensure that obsolete files are removed during deployment by toggling the delete flag. Multiple autonomous routine and path configuration files have been added or modified to reflect updated paths, waypoints, and commands. Adjustments to robot settings and physical constants—including a dynamic motor speed calculation—were made. Finally, the autonomous mode selection in the robot code was streamlined, and unused initialization code was removed from the drive subsystem. Changes
Sequence Diagram(s)sequenceDiagram
participant R as Robot
participant AC as autoChooser
participant S as CommandScheduler
R->>AC: Initialize via AutoBuilder.buildAutoChooser()
AC-->>R: Provide the selected autonomous Command
R->>S: Schedule the returned Command for autonomous mode
Suggested reviewers
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/main/kotlin/org/frc5183/constants/PhysicalConstants.kt (1)
109-122: Well-organized maximum constraints block.
Keeping max acceleration and angular definitions together improves readability. If you haven’t already, measure these values through swerve characterization to ensure more precise control.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (20)
build.gradle.kts(1 hunks)deploy/pathplanner/autos/Left Coral.auto(1 hunks)deploy/pathplanner/autos/Left Cower.auto(1 hunks)deploy/pathplanner/autos/Middle Coral.auto(1 hunks)deploy/pathplanner/autos/Right Coral.auto(1 hunks)deploy/pathplanner/autos/Right Cower.auto(1 hunks)deploy/pathplanner/paths/Left Coral.path(1 hunks)deploy/pathplanner/paths/Left Cower.path(1 hunks)deploy/pathplanner/paths/Middle Coral.path(1 hunks)deploy/pathplanner/paths/Right Coral.path(1 hunks)deploy/pathplanner/paths/Right Cower.path(1 hunks)deploy/pathplanner/settings.json(2 hunks)src/main/kotlin/org/frc5183/Robot.kt(4 hunks)src/main/kotlin/org/frc5183/constants/AutoConstants.kt(2 hunks)src/main/kotlin/org/frc5183/constants/PhysicalConstants.kt(1 hunks)src/main/kotlin/org/frc5183/constants/swerve/modules/BackLeftSwerveModuleConstants.kt(1 hunks)src/main/kotlin/org/frc5183/constants/swerve/modules/BackRightSwerveModuleConstants.kt(1 hunks)src/main/kotlin/org/frc5183/constants/swerve/modules/FrontLeftSwerveModuleConstants.kt(1 hunks)src/main/kotlin/org/frc5183/constants/swerve/modules/FrontRightSwerveModuleConstants.kt(1 hunks)src/main/kotlin/org/frc5183/subsystems/drive/SwerveDriveSubsystem.kt(0 hunks)
💤 Files with no reviewable changes (1)
- src/main/kotlin/org/frc5183/subsystems/drive/SwerveDriveSubsystem.kt
✅ Files skipped from review due to trivial changes (5)
- deploy/pathplanner/autos/Left Cower.auto
- deploy/pathplanner/paths/Left Coral.path
- deploy/pathplanner/autos/Right Cower.auto
- deploy/pathplanner/autos/Right Coral.auto
- deploy/pathplanner/paths/Right Cower.path
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (20)
deploy/pathplanner/autos/Left Coral.auto (1)
1-25:❓ Verification inconclusive
New autonomous routine looks well-structured
This new autonomous routine follows the correct format for PathPlanner 2025.0. The sequential command structure that follows the "Left Coral" path and then executes the "Shoot Coral" command is clear and straightforward.
Make sure that the "Left Coral" path and "Shoot Coral" command referenced here are properly defined elsewhere in the codebase.
🏁 Script executed:
#!/bin/bash # Check if the referenced path and command exist echo "Checking for 'Left Coral' path..." fd "Left Coral.path" deploy/pathplanner/paths/ echo "Checking for 'Shoot Coral' command definition..." rg "Shoot Coral" src/ -A 10 --type java --type kotlinLength of output: 341
Autonomous Routine Structure Verified – Please Verify "Shoot Coral" Command Definition
- The JSON structure for PathPlanner 2025.0 is correct and the sequential command structure is clear.
- The "Left Coral" path was confirmed to exist at
deploy/pathplanner/paths/Left Coral.path.- However, our search for a "Shoot Coral" command definition (in Java/Kotlin source files) returned no results. Please manually verify that "Shoot Coral" is properly defined elsewhere in the codebase (e.g., in configuration files or another supported location) to ensure the command executes as intended.
build.gradle.kts (1)
49-49: Good deployment hygiene practiceChanging
deleteOldFilestotrueensures that old, unused files are removed from the RoboRIO during deployment. This is particularly important when managing autonomous routines and paths to prevent confusion or errors from outdated files.deploy/pathplanner/autos/Middle Coral.auto (1)
1-25:✅ Verification successful
Well-formed autonomous routine configuration
This autonomous routine for "Middle Coral" follows the correct PathPlanner format and maintains consistency with other auto routines. The sequential commands to follow the "Middle Coral" path and then execute "Shoot Coral" are clearly defined.
Verify that the "Middle Coral" path exists in the project:
🏁 Script executed:
#!/bin/bash # Check if the referenced path exists echo "Checking for 'Middle Coral' path..." fd "Middle Coral.path" deploy/pathplanner/paths/Length of output: 180
Final Review Comment: Autonomous Routine Configuration Approved
The "Middle Coral" autonomous routine configuration is well-formed and consistent with other auto routines. The verification has confirmed that the expected path file (
deploy/pathplanner/paths/Middle Coral.path) exists in the project. No changes are needed.src/main/kotlin/org/frc5183/constants/AutoConstants.kt (2)
48-49: Fixed comma syntaxThe added comma after
PhysicalConstants.OPTIMAL_VOLTAGEensures proper syntax for the constructor call.
27-27:✅ Verification successful
Using consistent speed constants
Good change to use
PhysicalConstants.MAX_SPEEDdirectly, which provides a more consistent approach to speed calculations throughout the codebase.Let's verify how MAX_SPEED is defined in PhysicalConstants:
🏁 Script executed:
#!/bin/bash # Check the definition of MAX_SPEED in PhysicalConstants rg "MAX_SPEED" src/main/kotlin/org/frc5183/constants/PhysicalConstants.kt -A 5Length of output: 312
Consistent use of speed constants verified
The update to usePhysicalConstants.MAX_SPEEDdirectly inAutoConstants.ktis confirmed by its clear definition inPhysicalConstants.kt(usingUnits.MetersPerSecondwith an appropriate formula). This centralized approach ensures consistent speed calculations throughout the codebase.src/main/kotlin/org/frc5183/constants/swerve/modules/FrontLeftSwerveModuleConstants.kt (1)
16-17: Coordinate update for front left module looks correctThe update to (12.5, 12.0) for the front left module follows the expected coordinate convention for a swerve drive, placing it in the front left quadrant of the robot.
src/main/kotlin/org/frc5183/constants/swerve/modules/FrontRightSwerveModuleConstants.kt (1)
16-17: Coordinate update for front right module looks correctThe update to (12.5, -12.0) for the front right module follows the expected coordinate convention for a swerve drive, placing it in the front right quadrant of the robot.
src/main/kotlin/org/frc5183/constants/swerve/modules/BackRightSwerveModuleConstants.kt (1)
16-17: Coordinate update for back right module looks correctThe update to (-12.5, -12.0) for the back right module follows the expected coordinate convention for a swerve drive, placing it in the back right quadrant of the robot.
deploy/pathplanner/paths/Left Cower.path (1)
1-54: Path configuration looks well-structuredThis new path configuration for "Left Cower" defines a clear trajectory from the "Left Start Point" to the specified end point. The path uses appropriate constraints for velocity, acceleration, and angular movement that align with the global settings.
A couple of observations:
- The version "2025.0" indicates this is using a newer version of PathPlanner
- The waypoints are precisely defined with proper control points for smooth trajectory generation
deploy/pathplanner/paths/Middle Coral.path (1)
6-7: Waypoint positioning adjustments look reasonableThe coordinate changes for the Middle Coral path create a straight-line path along the same y-coordinate (4.011881408691406). This should result in simpler, more predictable robot movement.
The addition of the "Middle Start Point" link will help maintain consistency if the starting position needs to be adjusted globally in the future.
Also applies to: 11-12, 15-15, 19-20, 23-24
deploy/pathplanner/paths/Right Coral.path (1)
1-54: Path configuration is well-definedThe "Right Coral" path creates a trajectory from the "Right Start Point" with appropriate control points for a smooth path. The final rotation of 61.6° at the goal end state is intentional and likely positions the robot correctly for a shooting position.
All constraints appear to use the global settings (useDefaultConstraints: true), which maintains consistency with other paths.
deploy/pathplanner/settings.json (1)
2-3: Robot physical parameters updated to match actual hardwareThe changes to the robot's physical dimensions, mass, wheel radius, and module positions appear to be calibrations to match the actual hardware. A few key observations:
- The swerve module positions now form a rectangle that's wider than it is long (0.636m × 0.6096m)
- The maximum drive speed (5.39496 m/s) is now more realistic given the smaller wheel radius
- The reduced mass (35kg vs 50kg) will affect trajectory following and should improve acceleration
These changes should result in more accurate path following during autonomous routines.
Also applies to: 12-12, 15-15, 17-17, 21-28
src/main/kotlin/org/frc5183/Robot.kt (6)
3-4: Check if the new imports are fully utilized.
While these imports look correct, verify thatNamedCommandsis actually referenced. If not, removing the unused import can reduce clutter.
62-65: Great clarity on brake timer usage.
The comment clearly explains the purpose of the timer, and the instantiation seems correct. No further issues noted.
67-67: Streamlined approach using LoggedDashboardChooser looks good.
Replacing the old enum-based auto mode selection with a chooser-based system is simpler and more flexible.
129-130: Ensure auto routines are displayed and accessible.
The call toSmartDashboard.putDataensures the user can view and select autonomous routines. This is a clean integration with the new auto command approach.
165-165: Consistent scheduling of autonomous commands.
Canceling all commands before scheduling the chosen auto ensures a fresh state. This is best practice for FRC autonomous.
169-169: Confirm removal of any needed autonomous updates.
If the autonomous commands handle all periodic tasks, leaving this method empty is fine. However, ensure any essential per-cycle logic has been moved to commands.src/main/kotlin/org/frc5183/constants/PhysicalConstants.kt (2)
90-90: Validate the updated wheel diameter.
Ensure that the 4-inch wheel diameter is accurate. If it differs from real hardware, the calculated speeds may be off.
91-108: Effective calculation of MAX_SPEED.
Your formula for theoretical max speed is appropriate. Note that real-world friction and battery voltage drops may lower the actual top speed. Consider verifying the final speed through on-field testing.
| override val LOCATION: Translation2d | ||
| = Translation2d(Units.Inches.of(12.25), Units.Inches.of(-15.0)) | ||
| = Translation2d(Units.Inches.of(12.5), Units.Inches.of(-12.0)) |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Potential coordinate error in BackLeftSwerveModuleConstants
The coordinates (12.5, -12.0) for the back left module appear incorrect. Based on standard swerve drive coordinate conventions, the back left module should be in the (-X, +Y) quadrant. The current coordinates place it in the same position as the front right module, which isn't physically possible.
Consider updating to something like: Translation2d(Units.Inches.of(-12.5), Units.Inches.of(12.0))
🏁 Script executed:
#!/bin/bash
# Check the coordinates of all swerve modules to verify
echo "Checking all swerve module locations for consistency..."
# Find all SwerveModuleConstants files
fd ".*SwerveModuleConstants.kt" src/main/kotlin/org/frc5183/constants/swerve/modules/Length of output: 634
Swerve Module Coordinate Correction Needed for BackLeftSwerveModuleConstants.kt
- The current definition:
places the back left module in the same quadrant as the front right module.
override val LOCATION: Translation2d = Translation2d(Units.Inches.of(12.5), Units.Inches.of(-12.0))
- Based on standard swerve drive conventions (with the back left module expected in the (-X, +Y) quadrant), please update this value. For example, consider changing it to:
override val LOCATION: Translation2d = Translation2d(Units.Inches.of(-12.5), Units.Inches.of(12.0))
- Verify that this modification restores symmetry across all module constants.
works okay but i need to merge for more progress
Summary by CodeRabbit
Deployment Improvements
Autonomous Routines & Paths
Robot Performance Enhancements