Dev #29
Dev #29
Conversation
WalkthroughSwaps reef-facing camera, replaces several digital limits with duty‑cycle distance sensors, refactors Arm/Elevator states and safety, adds coral-autonomy toggles and reset commands, adds servo stop hooks, extends reef-clock autonomous options, and retunes many PID/geometry/constants across subsystems. Changes
Sequence Diagram(s)sequenceDiagram
participant Driver
participant OperatorConstants as Operator Triggers
participant GeneralCommands
participant CoralCollection as CoralCollectionCommands
Driver->>OperatorConstants: press coral toggle/reset inputs
OperatorConstants->>GeneralCommands: run toggle InstantCommand
GeneralCommands->>CoralCollection: flip SHOULD_LOAD_CORAL / SHOULD_USE flags
note right of CoralCollection: flags gate collection/load/autonomous flows
sequenceDiagram
participant Operator
participant ResetTriggers as Reset Triggers
participant IntakeCmd as IntakeCommands
participant ArmCmd as ArmElevatorCommands
participant ClimberCmd as ClimberCommands
participant Swerve as SwerveCommands
Operator->>ResetTriggers: hold reset combos
alt Intake reset
ResetTriggers->>IntakeCmd: resetIntakePositionCommand()
IntakeCmd->>Swerve: run open-loop (0,0,0)
IntakeCmd->>Intake: set voltage then reset encoder
else Elevator reset
ResetTriggers->>ArmCmd: resetElevatorPositionCommand()
ArmCmd->>Swerve: run open-loop (0,0,0)
ArmCmd->>ArmElevator: move then reset encoder
else Climber reset
ResetTriggers->>ClimberCmd: resetClimberPositionCommand()
ClimberCmd->>Swerve: run open-loop (0,0,0)
ClimberCmd->>Climber: set voltage then reset encoder
end
sequenceDiagram
participant Auto as AutonomousCommands
participant Pose as Camera/PoseEstimator
participant Drive as Swerve
participant Arm as ArmElevator
participant Intake
participant Transporter
participant EndEff as EndEffector
Auto->>Pose: calculateClosestOpenScoringPose(reefClockPositions)
Pose-->>Auto: scoring/no-hit pose
Auto->>Drive: drive to reef (option: stay-behind-algae)
Auto->>Arm: prepare scoring state (wait/continue gating)
Auto->>Intake: collect coral if flags allow
Intake->>Transporter: feed coral
Auto->>EndEff: score coral if SHOULD_SCORE enabled
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Nitpick comments (5)
src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java (1)
157-170: Servo configuration disabled without explanation.All servo PWM boundary configuration has been commented out. This aligns with the servo control being disabled in Climber.java. If this is temporary, add a TODO comment. If permanent, remove the dead code and the unused servo PWM constants at lines 53-58.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (1)
20-20: Consider making SHOULD_CALIBRATE_ELEVATOR configurable.The calibration flag is hardcoded as
false. For SysID workflows or debugging, consider exposing this through a dashboard toggle or constants file so it can be changed without recompiling.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (3)
63-67: Document tuning for reduced real-robot motion limits.Real robot velocity decreased from simulation values (2.4614 -> 2.5 rps, relatively close) but acceleration dramatically reduced (67.2344 -> 7 rps², ~90% reduction). Document whether this is:
- A safety measure due to mechanical constraints
- Based on empirical tuning to prevent oscillation
- A temporary conservative limit
This massive reduction suggests the arm may have stability issues at higher accelerations on real hardware.
111-111: Document SysID voltage reduction.
ARM_SYSID_CONFIGvoltage reduced from 3V to 1.5V. This is a 50% reduction in characterization voltage. Document whether this change is due to:
- Safety concerns during characterization
- Previous voltage causing excessive acceleration
- Improved motor characterization at lower voltages
117-117: Document SysID voltage reduction.
ELEVATOR_SYSID_CONFIGvoltage reduced from 3V to 2V. Ensure this provides sufficient data for accurate characterization while remaining safe.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
src/main/java/frc/trigon/robot/RobotContainer.java(1 hunks)src/main/java/frc/trigon/robot/constants/OperatorConstants.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/MotorSubsystem.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(11 hunks)src/main/java/frc/trigon/robot/subsystems/climber/Climber.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java(8 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java(3 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.javasrc/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (5)
src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (1)
TransporterConstants(20-119)
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (2)
src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(10-67)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (2)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(27-372)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(35-118)
src/main/java/frc/trigon/robot/RobotContainer.java (2)
src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(10-67)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(15-78)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
🔇 Additional comments (28)
src/main/java/frc/trigon/robot/subsystems/MotorSubsystem.java (1)
30-30: Clarify hardcoded logging and improve TODO
- Extensive logging is now always enabled on real hardware (previously sim-only), so
updateMechanism()will run each periodic cycle—this may impact performance.- The comment “AHAHAHAHAHHA” is unclear; replace it with a descriptive note or remove it.
- Confirm if using
truehere is intentional for debugging. If not, revert toRobotHardwareStats.isSimulation():- private static final LoggedNetworkBoolean ENABLE_EXTENSIVE_LOGGING = new LoggedNetworkBoolean("/SmartDashboard/EnableExtensiveLogging", true);//TODO: AHAHAHAHAHHA + private static final LoggedNetworkBoolean ENABLE_EXTENSIVE_LOGGING = new LoggedNetworkBoolean("/SmartDashboard/EnableExtensiveLogging", RobotHardwareStats.isSimulation());src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (3)
69-70: Verify angle bounds are logically correct.MINIMUM_ANGLE is 0° and MAXIMUM_ANGLE is -127°. This is unusual since "maximum" is numerically less than "minimum". Confirm this matches the physical mechanism's rotation direction and that downstream code correctly handles this inverted range.
226-227: State voltage polarities reversed.COLLECT voltage changed from 5 to -8 and EJECT voltage changed from -5 to 5. Verify these changes align with the mechanical direction of the intake mechanism and that all command code expecting these states has been updated accordingly.
36-38: No DIO channel conflicts detected.No other
DigitalInput(3|4|5)instantiations found outside IntakeConstants.java.src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (2)
3-6: LGTM: Explicit imports improve clarity.Replacing the wildcard import with explicit imports makes dependencies clear and avoids namespace pollution.
24-27: LGTM: Fluent API usage is cleaner.Calling
repeatedly()directly on theSequentialCommandGroupis more idiomatic than wrapping it in aRepeatCommand. The behavior is equivalent.src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (2)
105-108: Verify motor voltage polarity changes.Multiple transporter states have had their motor voltages' signs flipped:
- COLLECT: right motor 5 → -4
- ALIGN_CORAL: right motor 5 → -5
- HOLD_CORAL: right motor 1 → -1
- EJECT: both motors flipped
Confirm these changes align with the mechanical behavior and that command logic expecting these states has been updated.
24-24: No DIO channel conflict detected. Channel 6 is not referenced by any other sensor constant or DigitalInput.src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
47-47: LGTM: Keybinding updated to avoid conflict.Moving CORAL_COLLECTION_TRIGGER from
c()toz()avoids conflict with CLIMB_TRIGGER which usesc()at line 52.src/main/java/frc/trigon/robot/RobotContainer.java (1)
78-78: LGTM: Debugging trigger added.The debugging trigger provides a useful tool for testing ArmElevator positions while ignoring constraints.
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
21-21: No DIO channel 0 conflicts detected. Confirmed no other_CHANNELconstants are set to 0 across the Java codebase.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (9)
131-131: Verify correctness of subtractFrom180Degrees for reversed state.The logic now uses
subtractFrom180Degrees(targetState.targetAngle)when reversed. Given the new angle range (-90° to 270°) and the method's implementation (180° - angle), verify this produces the intended mechanical positions for all state angles, especially negative ones like REST (-90°) which would become 270°.Example calculations:
- REST (-90°) reversed: 180° - (-90°) = 270° ✓
- PREPARE_SCORE_L1 (20°) reversed: 180° - 20° = 160° ✓
- SCORE_L4 (10°) reversed: 180° - 10° = 170° ✓
However, confirm these angles are mechanically valid and safe for your robot's geometry.
150-151: Confirm ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET is correctly applied.The offset is added to the encoder reading. Given that
ANGLE_ENCODER_GRAVITY_OFFSETis set in the CANcoder configuration (line 321 in Constants) andARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETis computed asUnits.degreesToRotations(-23.56) - ANGLE_ENCODER_GRAVITY_OFFSET, verify this produces the correct absolute angle for your robot's zero position.Calculation chain:
- CANcoder applies
ANGLE_ENCODER_GRAVITY_OFFSET = -0.059326171875asMagnetOffset- Reading is then adjusted by
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = degreesToRotations(-23.56) - (-0.059326171875)- Net effect: reading is shifted by approximately
degreesToRotations(-23.56)from gravity-downConfirm this matches your intended zero position (horizontal? vertical?).
217-224: Verify safety angle calculation with new coordinate system.The calculation now uses
-90°as baseline (line 222) and addskCCW_90deg(line 223). With the new angle range (-90° to 270°), confirm this produces correct minimum safe angles across all elevator heights, especially at the extremes.Example: At maximum elevator height (1.382m):
heightFromSafeZone = 1.382 - 0.05 = 1.332mcosOfMinimumSafeAngle = 1.332 / 0.52 = 2.56(clamped to 1)acos(1) = 0- Result:
0 - 90° = -90°At minimum height (0m + 0.05m safety):
heightFromSafeZone = 0cosOfMinimumSafeAngle = 0acos(0) = 90°- Result:
90° - 90° = 0°This matches
MAXIMUM_ARM_SAFE_ANGLE = 0°, confirming the safety logic is consistent.
226-234: Verify elevator safety calculation with adjusted arm angle.Line 227 adds
kCCW_90degto the current arm angle before taking cosine. Confirm this correctly accounts for the new coordinate system where the arm's zero position has changed.With the new offsets:
- If arm is at physical horizontal (0° in new system), angle + 90° = 90°, cos(90°) = 0 ✓
- If arm is at -90° (pointing down), angle + 90° = 0°, cos(0°) = 1 ✓
- If arm is at 90° (pointing up), angle + 90° = 180°, cos(180°) = -1 (negative elevation contribution)
Verify this matches your intended safety logic for the elevator minimum height calculation.
240-242: Renamed method is correct.The change from
subtractFrom360DegreestosubtractFrom180Degreesaligns with the comment in previous learnings that angles above 90° would bypass safety logic, and now the coordinate system has been adjusted accordingly.
244-250: Verify visualization offset of PI/2.Line 247 adds
Math.PI / 2(90°) to the arm angle for visualization. Confirm this correctly orients the arm in the 3D visualization given the new coordinate system where -90° is the minimum angle.If the arm's zero position is now horizontal and you're adding 90° for visualization, the visual representation should point upward at zero. Verify this matches your robot's actual orientation.
80-82: Inconsistent offset application in mechanism update.Line 80 adds
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETtogetCurrentArmAngle()(which already includes the offset per line 150), while line 81 adds it toCLOSED_LOOP_REFERENCE. This double-applies the offset to the current angle for visualization.Apply this diff to remove the duplicate offset:
ArmElevatorConstants.ARM_MECHANISM.update( - Rotation2d.fromRotations(getCurrentArmAngle().getRotations()), + getCurrentArmAngle(), Rotation2d.fromRotations(armMasterMotor.getSignal(TalonFXSignal.CLOSED_LOOP_REFERENCE) + ArmElevatorConstants.ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET) );Likely an incorrect or invalid review comment.
64-70: Verify ROTOR_VELOCITY conversion
Confirm thatTalonFXSignal.ROTOR_VELOCITYreturns raw sensor units (ticks/100 ms) and isn’t already in rotor rotations/sec. If it is native ticks/100 ms, adjust your conversion to rotations/sec (e.g.,raw * 10 / (ticksPerRev * ELEVATOR_GEAR_RATIO)) before converting to meters/sec.
205-206: Remove offset warning: compensation is correctly applied. The code subtracts ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET (degreesToRotations(-23.56) – ANGLE_ENCODER_GRAVITY_OFFSET) from the setpoint and adds it back when reading CLOSED_LOOP_REFERENCE and POSITION, matching the TalonFX’s MagnetOffset configuration. No off-by-offset error present.Likely an incorrect or invalid review comment.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (8)
34-34: Document the reason for limit sensor channel change.
REVERSE_LIMIT_SENSOR_CHANNELchanged from 0 to 1. Ensure this matches your robot's actual wiring to avoid limit switch failures that could damage the elevator mechanism.
85-86: Verify angle range change is intentional.Angle range changed from (0°, 360°) to (-90°, 270°). This shifts the coordinate system by -90°. Confirm:
- All state angles in
ArmElevatorStatehave been updated consistently- The simulation limits match the physical hard stops
- Safety logic in
isArmAboveSafeAngle()is updated (it compares toMAXIMUM_ARM_SAFE_ANGLE = 0°)Based on learnings, angles above 90° bypass safety logic, but now the coordinate system is shifted. With the new range:
- Old 0° (horizontal forward) is now -90°
- Old 90° (straight up) is now 0°
- Old 180° (horizontal backward) is now 90°
Verify this is the intended behavior.
166-166: MAXIMUM_ARM_SAFE_ANGLE change affects safety logic.Changed from 90° to 0°. Combined with the angle range shift (-90° to 270°), this moves the safety boundary from "straight up" to "horizontal" in the new coordinate system. Verify:
isArmAboveSafeAngle()at line 116-118 in ArmElevator.java now correctly prevents interference- Safety calculations in
calculateMinimumArmSafeAngle()andcalculateMinimumSafeElevatorHeightRotations()are consistent with this changeThe safety logic should prevent the arm from moving into the elevator's travel zone. With the new angle:
- Arm angles ≥ 0° (horizontal and above) are "safe" and bypass elevator height constraints
- Arm angles < 0° (below horizontal) trigger minimum elevator height requirements
Confirm this matches your robot's mechanical constraints.
198-204: Verify PID tuning after gear ratio change.Real-robot PID gains are set with the new 42:1 gear ratio (changed from 40:1). The gains may need retuning since the gear ratio affects the relationship between motor output and arm movement.
Current gains:
- kP = 70 (increased from unknown previous value)
- kS = 0.02
- kG = 0.39 (gravity compensation)
Test the arm's response to verify:
- No oscillation at setpoints
- Adequate settling time
- Proper gravity compensation at all angles
232-233: ROTOR_VELOCITY and ROTOR_POSITION signals added.These signals provide raw motor shaft data. Confirm these are used correctly in ArmElevator.java line 73 where rotor velocity is divided by gear ratio for SysID logging.
337-356: Extensive state enum changes - verify all angles.All
ArmElevatorStateenum values have been redefined with new target angles and elevator positions. Given the coordinate system changes (angle range shift, gear ratio change, etc.), verify each state:Critical states to test:
- REST states (-90° or 90°) - ensure arm doesn't collide with frame
- SCORE_L4 (10°, 1.2m) - at maximum elevator extension
- COLLECT_ALGAE_FLOOR (-40°, 0.2m) - arm below horizontal, low elevator
- SCORE_NET (70°, 1.382m) - maximum elevator height
For each state, confirm:
- Arm angle is achievable within (-90° to 270°) range
- Elevator height is within (0 to 1.382m) range
- No collisions between arm and elevator/frame
- Safety logic allows the configuration
Consider creating a visualization tool or running simulation tests for all states before deploying to hardware.
320-322: Align sensor config with SwerveModuleConstants and validate arm behaviorThese settings mirror those in SwerveModuleConstants (SensorDirection = CounterClockwise_Positive, AbsoluteSensorDiscontinuityPoint = 0.5). Ensure:
- All arm-elevator position calculations account for the new range (–0.25 to 0.75 rotations) and wrap at ±0.5
- Positive commands move the arm in the expected physical direction without unintended wrapping
Test by commanding small positive angle changes and observing actual arm movement.
50-52: Verify gear ratio change and update dependent calculations
- Confirm 42:1 matches your physical gearbox swap.
- Update all motion profiles and hard-coded arm setpoints to account for the new 5% difference.
- Adjust PID gains (Slot0 kP/kV/kA in ArmElevatorConstants.java lines 198–204) for the new ratio.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
Outdated
Show resolved
Hide resolved
| // config.Feedback.VelocityFilterTimeConstant = 0.2; | ||
|
|
||
| config.MotionMagic.MotionMagicCruiseVelocity = ARM_DEFAULT_MAXIMUM_VELOCITY; | ||
| config.MotionMagic.MotionMagicAcceleration = ARM_DEFAULT_MAXIMUM_ACCELERATION; | ||
| config.MotionMagic.MotionMagicJerk = config.MotionMagic.MotionMagicAcceleration * 10; | ||
|
|
||
| config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; | ||
| config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270); | ||
| // config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; | ||
| // config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270); | ||
|
|
||
| // config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; | ||
| // config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = Conversions.degreesToRotations(-270); |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Commented-out velocity filter and limit switches.
Lines 209, 215-219 are commented out:
- Velocity filter (line 209)
- Forward/reverse software limit switches (lines 215-219)
Document why these are disabled. If this is temporary for testing, add TODO comments. If permanent, remove the dead code.
-// config.Feedback.VelocityFilterTimeConstant = 0.2;
-
config.MotionMagic.MotionMagicCruiseVelocity = ARM_DEFAULT_MAXIMUM_VELOCITY;
config.MotionMagic.MotionMagicAcceleration = ARM_DEFAULT_MAXIMUM_ACCELERATION;
config.MotionMagic.MotionMagicJerk = config.MotionMagic.MotionMagicAcceleration * 10;
-// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true;
-// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270);
-
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true;
-// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = Conversions.degreesToRotations(-270);Without software limits, the arm could exceed mechanical bounds if commanded beyond the angle range. Consider re-enabling with the updated angle range:
config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true;
config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(270) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;
config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true;
config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(-90) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;🤖 Prompt for AI Agents
In
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
around lines 209 to 219 the velocity filter and forward/reverse software limit
switch configurations are commented out with no explanation; either re-enable
these safety controls or mark them explicitly as temporary. Restore the velocity
filter line (or add a TODO explaining why it’s disabled and when to re-enable)
and re-enable the Forward/Reverse software limits using the updated angle range
and ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET via
edu.wpi.first.math.util.Units.degreesToRotations(...) for thresholds; if you
truly intend to keep them disabled, remove the dead code or add clear TODOs with
justification and a ticket/owner for follow-up.
| // config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; | ||
| // config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; | ||
| // | ||
| // config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; | ||
| // config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; |
There was a problem hiding this comment.
Elevator software limits commented out.
Similar to the arm, elevator software limits are disabled. This is more concerning for the elevator as it could crash into physical stops, potentially damaging the mechanism or causing safety hazards.
Strongly recommend re-enabling elevator limits:
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true;
-// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS;
-//
-// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true;
-// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8;
+ config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true;
+ config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS;
+
+ config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true;
+ config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = metersToRotations(MAXIMUM_ELEVATOR_HEIGHT_METERS);If the limits are disabled for debugging, add a TODO comment and re-enable before competition.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; | |
| // config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; | |
| // | |
| // config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; | |
| // config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; | |
| config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; | |
| config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; | |
| config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; | |
| config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = metersToRotations(MAXIMUM_ELEVATOR_HEIGHT_METERS); |
| // rightServo.setTargetSpeed(power); | ||
| // leftServo.setTargetSpeed(-power); |
There was a problem hiding this comment.
Servo control disabled without explanation.
The servo power commands have been commented out, effectively disabling servo control in the climber subsystem. If this is temporary for testing or due to missing hardware, add a TODO comment explaining when/why this will be re-enabled. If permanent, consider removing the dead code.
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/climber/Climber.java around lines
104 to 105 the servo control calls have been commented out, leaving dead code
and no explanation; either re-enable the calls if they were temporarily disabled
for testing or hardware reasons, or remove them if they’re permanently unused —
if keeping them commented, add a concise TODO comment on the same lines
explaining why they’re disabled, when they should be re-enabled, and who is
responsible (e.g., "TODO: disabled for bench testing until servo hardware
arrives; re-enable when hardware ID XYZ installed"), so future readers know the
intent.
src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java
Outdated
Show resolved
Hide resolved
| // config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; | ||
| // config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = MINIMUM_ANGLE.getRotations(); | ||
| // | ||
| // config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; | ||
| // config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = MAXIMUM_ANGLE.getRotations(); |
There was a problem hiding this comment.
Soft limits disabled without explanation.
The forward and reverse soft limits have been commented out, removing a safety boundary that prevents the intake from exceeding mechanical limits. Verify this is intentional and that the mechanism has alternative protection (e.g., hard limit switches).
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java around
lines 191-195 the forward and reverse software soft limits are commented out,
removing a safety boundary; either re-enable them by setting
config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true with threshold =
MINIMUM_ANGLE.getRotations() and
config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true with threshold =
MAXIMUM_ANGLE.getRotations(), or if this was intentional, add a clear comment
above these lines explaining why they are disabled and ensure and document
alternative protections (e.g., configured hardware limit switches, motor current
limiting, and/or mechanical stops) and where those protections are implemented
so reviewers know the safety is preserved.
| ANGLE_MOTOR.registerSignal(TalonFXSignal.ROTOR_VELOCITY, 100); | ||
| ANGLE_MOTOR.registerSignal(TalonFXSignal.CLOSED_LOOP_REFERENCE, 100); | ||
|
|
||
| OperatorConstants.DEBUGGING_TRIGGER.onTrue(new InstantCommand(() -> ANGLE_MOTOR.setPosition(0)).ignoringDisable(true)); |
There was a problem hiding this comment.
Debug trigger directly resets motor position.
This trigger allows resetting the angle motor position to 0 at runtime via DEBUGGING_TRIGGER. If triggered accidentally during operation, it could cause the control system to believe the intake is at a different position than reality, leading to unsafe movements.
Consider adding safeguards: require the robot to be disabled, add a confirmation step, or log a warning when this is triggered.
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java around
line 210, the DEBUGGING_TRIGGER currently calls ANGLE_MOTOR.setPosition(0)
immediately, which is unsafe; change the handler so it only performs the reset
when the robot is disabled (e.g., check DriverStation.isDisabled() or
Robot.isDisabled() first), add a simple confirmation requirement (for example
require a separate confirmation flag/button or a long-press) and emit a
warning/log entry when the reset is executed or when an attempt is blocked;
implement this by replacing the raw InstantCommand with a conditional command
that checks the disabled state and confirmation, logs the action with context,
and otherwise no-ops and logs the blocked attempt.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
72-79: Restore the SWERVE (and other critical) default commands.With these lines commented out the drivetrain never receives a default drive command, so the robot will sit idle (and other subsystems stay in their last state). That’s a blocking regression for teleop safety.
-// SWERVE.setDefaultCommand(GeneralCommands.getFieldRelativeDriveCommand()); -// ARM_ELEVATOR.setDefaultCommand(ArmElevatorCommands.getDefaultCommand()); -// CLIMBER.setDefaultCommand(ClimberCommands.getSetTargetStateCommand(ClimberConstants.ClimberState.REST)); -// END_EFFECTOR.setDefaultCommand(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.REST)); + SWERVE.setDefaultCommand(GeneralCommands.getFieldRelativeDriveCommand()); + ARM_ELEVATOR.setDefaultCommand(ArmElevatorCommands.getDefaultCommand()); + CLIMBER.setDefaultCommand(ClimberCommands.getSetTargetStateCommand(ClimberConstants.ClimberState.REST)); + END_EFFECTOR.setDefaultCommand(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.REST)); @@ -// configureSysIDBindings(ARM_ELEVATOR); -// OperatorConstants.DEBUGGING_TRIGGER.whileTrue(ArmElevatorCommands.getDebuggingCommand(true)); +// configureSysIDBindings(ARM_ELEVATOR); +// OperatorConstants.DEBUGGING_TRIGGER.whileTrue(ArmElevatorCommands.getDebuggingCommand(true));
🧹 Nitpick comments (1)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (1)
103-121: Prefer structured telemetry over rawSystem.out.
System.out.printlnruns on the main loop thread and will flood the console when states toggle, hurting timing and making logs noisy. Use the AdvantageKit logger you already depend on so the data is timestamped and filterable.- System.out.println("Setting intake state to " + targetState.name()); + Logger.recordOutput("Intake/TargetState", targetState.name()); @@ - System.out.println("Setting intake voltage to " + voltage); + Logger.recordOutput("Intake/TargetVoltageVolts", voltage); @@ - System.out.println("Setting intake angle to " + targetAngle.getDegrees() + " degrees"); + Logger.recordOutput("Intake/TargetAngleDegrees", targetAngle.getDegrees());
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
src/main/java/frc/trigon/robot/RobotContainer.java(3 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/intake/Intake.java(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java
🧬 Code graph analysis (3)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (2)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(27-372)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(36-119)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (7)
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (1)
IntakeAssistCommand(22-190)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(36-119)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(10-67)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(15-78)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(10-27)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(11-37)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)
src/main/java/frc/trigon/robot/RobotContainer.java (5)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(19-50)src/main/java/frc/trigon/robot/commands/commandfactories/CoralEjectionCommands.java (1)
CoralEjectionCommands(17-39)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(15-65)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(10-67)
| if (SHOULD_CALIBRATE_ELEVATOR) { | ||
| log.motor("Elevator") | ||
| .linearPosition(Units.Meters.of(getElevatorPositionRotations())) | ||
| .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) | ||
| .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); | ||
| return; |
There was a problem hiding this comment.
Fix SysId elevator logging units.
linearPosition/linearVelocity must be in meters, but you’re passing raw rotations (and rotor RPS). That will produce bogus SysId fits for the elevator.
- log.motor("Elevator")
- .linearPosition(Units.Meters.of(getElevatorPositionRotations()))
- .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO))
+ final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations());
+ final double elevatorVelocityMetersPerSecond = rotationsToMeters(
+ elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO
+ );
+ log.motor("Elevator")
+ .linearPosition(Units.Meters.of(elevatorPositionMeters))
+ .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond))📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (SHOULD_CALIBRATE_ELEVATOR) { | |
| log.motor("Elevator") | |
| .linearPosition(Units.Meters.of(getElevatorPositionRotations())) | |
| .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) | |
| .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); | |
| return; | |
| if (SHOULD_CALIBRATE_ELEVATOR) { | |
| final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations()); | |
| final double elevatorVelocityMetersPerSecond = rotationsToMeters( | |
| elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) | |
| / ArmElevatorConstants.ELEVATOR_GEAR_RATIO | |
| ); | |
| log.motor("Elevator") | |
| - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) | |
| - .linearVelocity(Units.MetersPerSecond.of( | |
| - elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) | |
| - / ArmElevatorConstants.ELEVATOR_GEAR_RATIO | |
| .linearPosition(Units.Meters.of(elevatorPositionMeters)) | |
| .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond)) | |
| .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); | |
| return; | |
| } |
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java around
lines 66 to 71, the SysId logging is passing raw rotations and rotor velocity
into linearPosition/linearVelocity (which expect meters and m/s). Convert
rotations to linear meters and rotor velocity to meters/second before calling
Units.Meters.of and Units.MetersPerSecond.of: compute positionMeters =
(rotations / ArmElevatorConstants.ELEVATOR_GEAR_RATIO) * (2 * Math.PI *
ArmElevatorConstants.DRUM_RADIUS) (or use a spool circumference constant) and
velocityMps = (rotorVelocityRPS / ArmElevatorConstants.ELEVATOR_GEAR_RATIO) * (2
* Math.PI * ArmElevatorConstants.DRUM_RADIUS); then pass those values to the
logging calls and keep the voltage log as-is.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (7)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
209-209: Commented-out velocity filter.The velocity filter is disabled without explanation. If this is temporary for testing, add a TODO comment. If permanent, remove the dead code.
Either restore the velocity filter:
-// config.Feedback.VelocityFilterTimeConstant = 0.2; + config.Feedback.VelocityFilterTimeConstant = 0.2;Or remove it entirely if no longer needed:
-// config.Feedback.VelocityFilterTimeConstant = 0.2; -Or document why it's disabled:
-// config.Feedback.VelocityFilterTimeConstant = 0.2; + // TODO: Re-enable velocity filter after tuning (disabled for SysID characterization) + // config.Feedback.VelocityFilterTimeConstant = 0.2;
57-58: Document the encoder offset values.
ANGLE_ENCODER_GRAVITY_OFFSET = -0.059326171875(approximately -21.36° when converted) and theARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETcalculation involve magic numbers. Add comments explaining:
- How
ANGLE_ENCODER_GRAVITY_OFFSETwas measured (encoder reading at gravity-down position?)- Why
-23.56°is subtracted inARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET- The intended zero position of the arm (horizontal? vertical?)
Apply this diff to add documentation:
+ // Encoder reading when arm is pointing straight down (gravity-down position) private static final double ANGLE_ENCODER_GRAVITY_OFFSET = -0.059326171875; + // Offset to make arm zero position horizontal (measured offset from gravity-down to horizontal) + private static final double ARM_HORIZONTAL_OFFSET_DEGREES = -23.56; + // Combined offset for arm position (simulation uses ideal zero, real robot applies physical offset) - static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() ? 0 : edu.wpi.first.math.util.Units.degreesToRotations(-23.56) - ANGLE_ENCODER_GRAVITY_OFFSET; + static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() + ? 0 + : edu.wpi.first.math.util.Units.degreesToRotations(ARM_HORIZONTAL_OFFSET_DEGREES) - ANGLE_ENCODER_GRAVITY_OFFSET;
215-219: Arm software limit switches commented out.Software limits for the arm are disabled. Without these limits, the arm could exceed mechanical bounds if commanded beyond the angle range.
Consider re-enabling with the updated angle range:
-// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270); - -// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = Conversions.degreesToRotations(-270); + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(270) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET; + + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(-90) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;If these are disabled for debugging, add a TODO comment and re-enable before competition.
275-279: Elevator software limit switches commented out.Similar to the arm, elevator software limits are disabled. This is more concerning for the elevator as it could crash into physical stops, potentially damaging the mechanism or causing safety hazards.
Strongly recommend re-enabling elevator limits:
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; -// -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; + + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = metersToRotations(MAXIMUM_ELEVATOR_HEIGHT_METERS);If the limits are disabled for debugging, add a TODO comment and re-enable before competition.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (1)
68-74: Fix SysId elevator logging units.
linearPosition/linearVelocitymust be in meters, but you're passing raw rotations (and rotor RPS). That will produce bogus SysId fits for the elevator.Apply this diff to convert units properly:
if (SHOULD_CALIBRATE_ELEVATOR) { + final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations()); + final double elevatorVelocityMetersPerSecond = rotationsToMeters( + elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO + ); log.motor("Elevator") - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) - .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) + .linearPosition(Units.Meters.of(elevatorPositionMeters)) + .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond)) .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); return; }src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (2)
191-195: Soft limits remain disabled (previously flagged).The software soft limits are still commented out, as noted in the previous review. This removes a safety boundary that prevents the intake from exceeding mechanical limits.
If this is intentional (e.g., relying on hardware limit switches or mechanical hard stops), please document the rationale and alternative protections in a comment above these lines. Otherwise, re-enable the soft limits.
210-210: Debug trigger still lacks safeguards (previously flagged).The debug trigger that resets the angle motor position to 0 is now active but still lacks safeguards, as noted in the previous review. While
ignoringDisable(true)allows this to work when the robot is disabled, accidental triggering during operation could cause the control system to believe the intake is at a different position than reality, leading to unsafe movements.Consider the recommendations from the previous review: add a confirmation step, require the robot to be disabled (check via
DriverStation.isDisabled()), or at minimum log a warning when this is triggered.
🧹 Nitpick comments (2)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (1)
22-22: Hardcoded calibration flag should be configurable.
SHOULD_CALIBRATE_ELEVATOR = trueis a hardcoded constant that determines which subsystem to calibrate. This requires a code change and redeployment to switch between calibrating the elevator and the arm.Consider making this configurable via:
- A dashboard boolean input (SmartDashboard/Shuffleboard)
- A command-line parameter
- A configuration file
Example using SmartDashboard:
- private static final boolean SHOULD_CALIBRATE_ELEVATOR = true; + private final boolean shouldCalibrateElevator; + + public ArmElevator() { + setName("ArmElevator"); + shouldCalibrateElevator = SmartDashboard.getBoolean("ArmElevator/CalibrateElevator", true); + }Then update all references from
SHOULD_CALIBRATE_ELEVATORtoshouldCalibrateElevator.src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
33-38: Consider simplifying the redundant end condition.The command uses both
.until(RobotContainer.END_EFFECTOR::hasGamePiece)and.unless(RobotContainer.END_EFFECTOR::hasGamePiece). This is redundant—both prevent execution when the end effector already has a game piece. Theunlesscheck prevents the command from starting, whileuntilwould end it immediately.Since the outcome is functionally identical, you can simplify to just the
unlessguard:public static Command getLoadCoralCommand() { return new ParallelCommandGroup( ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.LOAD_CORAL), EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.LOAD_CORAL) - ).until(RobotContainer.END_EFFECTOR::hasGamePiece).unless(RobotContainer.END_EFFECTOR::hasGamePiece); + ).unless(RobotContainer.END_EFFECTOR::hasGamePiece); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
src/main/java/frc/trigon/robot/RobotContainer.java(1 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(11 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/intake/Intake.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java(7 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/main/java/frc/trigon/robot/RobotContainer.java
- src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.javasrc/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (4)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (2)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(27-372)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(36-164)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (5)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(36-164)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(11-45)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (1)
IntakeConstants(32-238)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (1)
TransporterConstants(21-120)
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (2)
src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(12-99)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
🔇 Additional comments (26)
src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (3)
64-65: Verify pulse timing adjustments through testing.The pulse timing constants have been reduced:
- Applied time: 0.1s → 0.08s (20% reduction)
- Wait time: 0.05s → 0.03s (40% reduction)
These changes suggest performance tuning, but ensure that the shorter durations still provide reliable coral manipulation without mechanical issues.
25-25: Confirm beam break sensor wiring and documentation
No in-code references to DIO channel 3 remain. Manually verify that the beam break sensor is physically wired to channel 6 and update any external documentation or diagrams accordingly.
106-109: Verify transporter motor direction changes for coral-handling states.
- COLLECT: right motor voltage changed 5→ –4 (reversed & reduced)
- HOLD_CORAL: right motor changed 1→ –1 (reversed)
- EJECT: right motor changed –5→ 5 (reversed)
Confirm these inversions match the intended mechanical behavior and have been validated with physical testing.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (5)
337-356: Extensive ArmElevatorState enum rewrite.All state target angles and positions have been changed. This is a major behavioral change affecting the entire robot.
The new state definitions appear consistent with the updated angle range [-90°, 270°] and the new safe angle threshold (0°). However, verify:
- All target positions have been tested on the physical robot
- The
prepareStatereferences are correct (e.g., SCORE_L2 → PREPARE_SCORE_L2)- The
ignoreConstraintsflags are set appropriately for states that need to bypass safety checks- The
speedScalarvalues provide acceptable performance for each stateNotable changes:
- REST is now at -90° (was previously a different angle)
- Multiple new states added: PREPARE_SCORE_L1-L4, REST variants, COLLECT_ALGAE variants
- Elevator positions range from 0.2m to 1.382m
Consider adding integration tests to verify all state transitions work as expected.
34-34: No leftover channel 0 references—only ArmElevatorConstants.java:34 defines REVERSE_LIMIT_SENSOR_CHANNEL = 1. Ensure your physical wiring matches this update.
52-53: Verify new gear ratio impacts
- Confirm the physical gear ratio is 4:1
- Recompute each
ArmElevatorStateelevatorPositionRotationsfor ratio = 4- Test the elevator to ensure it reaches the intended heights
320-322: Confirm encoder direction and wrap settings
Ensure the new SensorDirectionValue.CounterClockwise_Positive matches the physical mounting, AbsoluteSensorDiscontinuityPoint = 0.5 aligns with your intended [–90°, 270°] range, and all angle calculations handle wrapping at ±180°. Test key positions (–90°, 0°, 180°, 270°) to verify smooth transitions.
85-86: All arm angle targets and safety calculations conform to the new [-90°, 270°] range
- Every ArmElevatorState targetAngle lies within –90°…270°
- calculateMinimumArmSafeAngle() returns between –90° and 0° as expected
- Simulation is bounded by ARM_MINIMUM_ANGLE = –90° and ARM_MAXIMUM_ANGLE = 270°
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (10)
55-57: LGTM: Brake now includes follower motors.Good addition. Applying brake to both master and follower motors ensures consistent behavior and prevents any potential drift from the followers.
76-78: Arm SysId logging now uses rotor velocity.The arm logging now uses
ROTOR_VELOCITYdirectly and divides byARM_GEAR_RATIO. This provides the angular velocity of the arm mechanism, which is correct for SysId characterization.
109-113: LGTM: Conditional SysId drive based on calibration flag.The
sysIDDrivemethod now correctly routes voltage to either the elevator or arm motor based onSHOULD_CALIBRATE_ELEVATOR. This ensures only one mechanism is being characterized at a time.
136-137: Updated to use subtractFrom180Degrees for reversed states.This change aligns with the encoder's new discontinuity point at 0.5 rotations (180°) instead of 1.0 rotation (360°).
The logic is consistent with:
- Line 245-247: The renamed
subtractFrom180Degreesmethod- Line 322 in ArmElevatorConstants.java:
AbsoluteSensorDiscontinuityPoint = 0.5
155-156: getCurrentArmAngle now includes position offset.The arm angle calculation now adds
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETto the encoder reading. This is consistent with the encoder configuration changes in ArmElevatorConstants.java (lines 57-58, 321).Verify that:
- The offset is applied in the correct direction (addition, not subtraction)
- Reported angles match the physical arm position
- The offset behaves correctly in simulation (where it's set to 0)
Test the arm at known physical positions (e.g., horizontal, vertical, gravity-down) and confirm the reported angles are correct.
210-211: setTargetArmAngle subtracts offset before commanding motor.The method calculates the target position, then subtracts
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETbefore sending it to the motor. This is the inverse ofgetCurrentArmAngle()(line 155), which adds the offset.This ensures:
getCurrentArmAngle()returns the arm angle in the robot's coordinate frame- The motor is commanded in the encoder's raw coordinate frame
- The offset is consistently applied/removed at the boundary
227-228: calculateMinimumArmSafeAngle updated for new angle range.The method now returns -90° when NaN (instead of 0°) and uses
kCCW_90degin the calculation. This aligns with the new angle range of [-90°, 270°] defined in ArmElevatorConstants.java (lines 85-86).The NaN case occurs when
acos()is undefined (e.g., when the elevator is fully retracted), and returning -90° is appropriate as it's the minimum angle in the new range.
232-233: calculateMinimumSafeElevatorHeightRotations adds 90° offset.The elevator safety calculation now adds
Rotation2d.kCCW_90degto the current arm angle before taking the cosine. This accounts for the new coordinate system where 0° is horizontal instead of vertical.Verify the safety logic:
- When the arm is at -90° (REST), the elevator should have minimal constraints
- When the arm is at 0° (horizontal), the elevator constraint should be at the safe zone threshold
- When the arm is above 0°, the
isArmAboveSafeAngle()check should disable elevator constraintsTest the elevator at various arm angles to ensure it doesn't hit the frame or base.
245-247: subtractFrom360Degrees renamed to subtractFrom180Degrees.The method name and implementation now reflect the encoder's new discontinuity point at 180° (0.5 rotations) instead of 360° (1.0 rotation).
This change is consistent with:
- Line 322 in ArmElevatorConstants.java:
AbsoluteSensorDiscontinuityPoint = 0.5- The new angle range of [-90°, 270°] which spans 360° but is centered differently
252-253: calculateVisualizationPose adds 90° offset to arm rotation.The visualization now adds
Math.PI / 2(90°) to the arm angle. This adjusts the 3D visualization to account for the new coordinate system where 0° is horizontal.This ensures the 3D visualization in Advantage Scope or other tools displays the arm in the correct orientation relative to the robot.
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (2)
20-31: LGTM! Improved collection flow with driver assist.The refactored collection command now has a clearer structure:
- Intake coral until the transporter detects it
- Provide collection confirmation feedback
- Schedule load command if not holding algae
The addition of
IntakeAssistCommandimproves driver feedback during collection. Theunlessguard correctly prevents the command from running when coral is already collected.
41-46: Verify transporter continuous vs. pulsed behavior for coral intake.
TransporterCommands#getSetTargetStateWithPulsesCommandis defined but not used elsewhere;getIntakeCoralCommandnow applies continuous voltage. Confirm that continuous operation still reliably collects coral—if pulsed cycles are required to prevent jams or improve grip, switch back togetSetTargetStateWithPulsesCommandhere or remove the unused pulses method.src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (6)
36-38: Verify hardware wiring matches updated channels.The sensor channels have been updated from 0/1/2 to 3/4/5. Ensure that the physical wiring on the robot matches these new channel assignments to prevent sensor malfunctions.
69-70: Verify angle limits match the physical mechanism.The intake angle limits have been significantly modified:
MINIMUM_ANGLE: -12° → 0°MAXIMUM_ANGLE: 110° → -127°This represents both a sign inversion and a range change. Ensure these new limits correctly reflect the physical mechanism's range of motion and that the angle measurement direction is consistent with the motor configuration and simulation.
Test the intake at both limits to confirm:
- The angle readings match expected positions
- The mechanism doesn't hit hard stops unexpectedly
- The simulation behavior matches reality
92-93: More aggressive SysID configuration.The SysID voltages have been increased (ramp: 0.2 → 1.2 V/s, step: 0.6 → 1.5 V), which will provide better characterization data. This is appropriate for a Kraken-powered mechanism but ensure the physical mechanism can safely handle these voltages during characterization.
154-154: Improved motor tuning and API update.The feedback ratio field has been updated to match the current CTRE Phoenix 6 API (
SensorToMechanismRatio). The PID gains have been retuned:
- Added derivative gain (kD = 0.5) on the real robot for better damping
- Increased cruise velocity (2 → 3 rps) for faster intake movements
These changes should improve control response and performance.
Also applies to: 174-182, 187-187
216-216: Limit sensor auto-reset and distance sensor simulation disabled.The automatic position reset on limit sensor triggers (line 216) and the distance sensor simulation supplier (line 220) have been disabled. This suggests a shift away from automatic calibration.
Ensure there's a manual calibration workflow in place and that simulation testing accounts for the lack of distance sensor feedback.
Also applies to: 220-220
227-228: IntakeState voltages updated to match mechanism changes.The
COLLECTandEJECTstates have been updated:
COLLECT: voltage 5 → -8 (reversed and increased magnitude)EJECT: voltage -5 → 5 (reversed)This aligns with the angle limit sign changes and suggests either motor inversion or a mechanism redesign. Verify that collection and ejection work as expected with these new voltage values.
| * The highest point of the arms angular zone where the safety logic applies. | ||
| */ | ||
| static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(90); | ||
| static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0); |
There was a problem hiding this comment.
🧩 Analysis chain
MAXIMUM_ARM_SAFE_ANGLE changed from 90° to 0°.
This moves the safe angle threshold significantly lower, which will affect when safety constraints are applied. The isArmAboveSafeAngle() check now triggers at 0° instead of 90°.
This change impacts safety logic throughout the codebase. Verify:
- The new threshold aligns with the physical constraints of the robot
- States like REST (-90°), LOAD_CORAL (-90°), and EJECT (-30°) are intentionally below the safe angle
- The elevator safety calculations in
calculateMinimumSafeElevatorHeightRotations()(ArmElevator.java:231-239) work correctly with the new threshold
Run the following script to find all usages of this constant:
🏁 Script executed:
#!/bin/bash
# Find all references to MAXIMUM_ARM_SAFE_ANGLE
rg -n -C3 'MAXIMUM_ARM_SAFE_ANGLE|isArmAboveSafeAngle' --type=javaLength of output: 2821
Arm safe angle threshold set to 0° disables dynamic elevator‐height safety for most arm positions
MAXIMUM_ARM_SAFE_ANGLE was lowered from 90° to 0° (ArmElevatorConstants.java:166), so isArmAboveSafeAngle() now returns true for any angle ≥ 0°. As a result, calculateMinimumSafeElevatorHeightRotations() (ArmElevator.java:231–239) applies only the static minimum elevator safe zone for nearly all forward arm angles, bypassing the intended dynamic height calculation. Revert MAXIMUM_ARM_SAFE_ANGLE to 90° or confirm this change won’t compromise safety.
🤖 Prompt for AI Agents
In
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
around line 166, MAXIMUM_ARM_SAFE_ANGLE was changed to 0° which causes
isArmAboveSafeAngle() to be true for virtually all arm positions and disables
the dynamic elevator-height safety; restore the original safe threshold by
setting MAXIMUM_ARM_SAFE_ANGLE back to 90° (Rotation2d.fromDegrees(90)) or, if
there was an intentional behavior change, add a safety check and tests proving
no safety regression before keeping 0°.
|
|
||
| void setTargetState(IntakeConstants.IntakeState targetState) { | ||
| this.targetState = targetState; | ||
| System.out.println("Setting intake state to " + targetState.name()); |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Replace System.out.println with structured logging.
The three System.out.println calls added for debugging (lines 112, 123, 129) should be replaced with proper structured logging using the existing Logger.recordOutput infrastructure already in use throughout this file. System.out is blocking I/O, cannot be filtered by log level, and isn't captured by your telemetry system.
Apply this diff to replace the debug prints:
void setTargetState(IntakeConstants.IntakeState targetState) {
this.targetState = targetState;
- System.out.println("Setting intake state to " + targetState.name());
+ Logger.recordOutput("Intake/TargetState", targetState.name());
setTargetState(targetState.targetAngle, targetState.targetVoltage);
}
private void setTargetVoltage(double voltage) {
IntakeConstants.INTAKE_MECHANISM.setTargetVelocity(voltage);
- System.out.println("Setting intake voltage to " + voltage);
+ Logger.recordOutput("Intake/TargetVoltage", voltage);
intakeMotor.setControl(voltageRequest.withOutput(voltage));
}
private void setTargetAngle(Rotation2d targetAngle) {
- System.out.println("Setting intake angle to " + targetAngle.getDegrees() + " degrees");
+ Logger.recordOutput("Intake/TargetAngleDegrees", targetAngle.getDegrees());
angleMotor.setControl(positionRequest.withPosition(targetAngle.getRotations()));
}Also applies to: 123-123, 129-129
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/intake/Intake.java around lines
112, 123, and 129, replace the three System.out.println debug prints with
structured logging via the existing Logger.recordOutput calls used elsewhere in
this class; specifically, remove System.out usage and call Logger.recordOutput
with a clear key (e.g., "intake/state" or similar), include the message "Setting
intake state to <state>" (or the corresponding messages at the other two sites)
substituting targetState.name() (or the relevant variable) as a formatted
argument, and ensure the messages follow the file's established logging pattern
so they are non-blocking, filterable by level, and captured by telemetry.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (4)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
57-58: Document the encoder offset values.These offset constants use unexplained magic numbers. This concern was previously raised and remains unresolved.
Based on past review comments.
166-166: Arm safe angle threshold set to 0° disables dynamic elevator‐height safety.This change was previously flagged as a critical issue. Setting
MAXIMUM_ARM_SAFE_ANGLEto 0° causesisArmAboveSafeAngle()to return true for most arm positions, bypassing dynamic elevator-height safety calculations.Based on past review comments.
209-219: Commented-out velocity filter and limit switches.These safety features remain disabled. This concern was previously raised and remains unresolved.
Based on past review comments.
275-279: Elevator software limits commented out.These safety limits remain disabled. This concern was previously raised as a major issue and remains unresolved.
Based on past review comments.
🧹 Nitpick comments (1)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
37-37: Consider simplifying the redundant guard.Both
.until()and.unless()use the same condition (RobotContainer.END_EFFECTOR::hasGamePiece). While safe, the.unless()guard alone would prevent unnecessary execution. The.until()guard is useful if the game piece arrives mid-execution, but the duplication is redundant for the common case.If you prefer to remove the redundancy:
- ).until(RobotContainer.END_EFFECTOR::hasGamePiece).unless(RobotContainer.END_EFFECTOR::hasGamePiece); + ).unless(RobotContainer.END_EFFECTOR::hasGamePiece);However, keeping both guards is safe and defensive, so this is optional.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/main/java/frc/trigon/robot/RobotContainer.java(0 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java(1 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(11 hunks)
💤 Files with no reviewable changes (1)
- src/main/java/frc/trigon/robot/RobotContainer.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (3)
src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (1)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(19-62)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (5)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(45-171)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(11-45)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (1)
IntakeConstants(32-238)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (1)
TransporterConstants(21-120)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
🔇 Additional comments (12)
src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (1)
93-93: LGTM!The switch from
getIntakeSequenceCommand()togetIntakeCoralCommand()simplifies the intake flow. The new public command is correctly integrated here.src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (2)
22-23: LGTM!The simplified intake flow using
getIntakeCoralCommand().until(RobotContainer.TRANSPORTER::hasCoral)followed by confirmation is clear and direct.
47-51: LGTM!Exposing
getIntakeCoralCommand()as public is correct and enables reuse in autonomous commands. The parallel intake and transporter activation logic is sound.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (9)
34-34: Verify the sensor channel change.The reverse limit sensor channel was changed from 0 to 1. Ensure this matches the physical wiring of the sensor on the robot.
52-52: Verify the elevator gear ratio change.The gear ratio changed from 3 to 4, which will affect all position and velocity conversions for the elevator. Ensure this matches the physical gearbox configuration and that all dependent calculations remain correct.
63-67: Approve motion parameter updates; verify tuning.The arm default velocity and acceleration were updated from 0 to actual values (2.5 and 7), which fixes a critical issue that would have prevented arm motion. The elevator acceleration was reduced from 80 to 50, which may improve stability but could reduce responsiveness.
Verify that these tuning parameters meet performance requirements during physical testing.
85-86: LGTM! Arm angle range adjusted to support new states.The angle range was shifted from [0°, 360°] to [-90°, 270°] to accommodate new states like REST (-90°) and EJECT (-30°). The total range remains 360°.
198-204: Verify updated PID gains.The arm PID gains were updated significantly (kP to 70, kG to 0.39 for the real robot). Verify these gains provide stable, responsive control during physical testing.
232-233: LGTM! Enhanced telemetry.Additional rotor velocity and position signals improve observability for debugging and tuning.
264-270: Verify updated elevator PID gains.The elevator PID gains were updated (kP to 12, kD to 1, and feedforward terms adjusted). Verify these gains provide stable elevator control during physical testing, especially given the gear ratio change.
320-322: Verify encoder direction and discontinuity point changes.The encoder direction was changed to
CounterClockwise_Positiveand the discontinuity point was changed from 1.0 to 0.5. The discontinuity point of 0.5 means the encoder wraps around at 180° instead of 360°, which may cause unexpected behavior if the arm crosses this boundary.Verify:
- The direction change matches the physical encoder mounting
- The arm never crosses the 180° boundary during normal operation, or handle the wraparound correctly
336-374: Verify the new state machine definitions.The entire
ArmElevatorStateenum was replaced with a new set of states. This is a major change that affects all arm-elevator behaviors.Key concerns to verify:
- Physical safety: Ensure all angle/position combinations are mechanically safe and don't cause collisions
- Prepare states: Verify that states with prepare states (e.g.,
SCORE_L2→PREPARE_SCORE_L2) sequence correctly- Safety bypass: States with
ignoreConstraints = true(e.g.,LOAD_CORAL,COLLECT_ALGAE_FLOOR) bypass safety checks. Confirm this is intentional and document why- Coordinate validity: Several states have extreme angles (e.g.,
SCORE_NETat 70°,COLLECT_ALGAE_LOLLIPOPat 70°). Verify these are achievable and safe- Speed scalars: The
speedScalarvalues range from 0.3 to 1. Verify these provide appropriate motion speeds for each operationConsider adding unit tests that verify state transitions and safety constraints.
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (2)
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (2)
191-195: Soft limits remain disabled.This concern was previously flagged. The forward and reverse software soft limits are still commented out, removing safety boundaries. Please address the previous review comment regarding this issue.
210-210: Debug trigger safety concern remains unaddressed and worsened.This concern was previously flagged. The debug trigger still allows runtime position reset, and now includes
.ignoringDisable(true), which permits the reset even when the robot is disabled. This increases the risk of unsafe position resets.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/main/deploy/pathplanner/settings.json(1 hunks)src/main/java/frc/trigon/robot/subsystems/MotorSubsystem.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/intake/Intake.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java(8 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/main/deploy/pathplanner/settings.json
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/frc/trigon/robot/subsystems/intake/Intake.java
🧰 Additional context used
🧬 Code graph analysis (1)
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (2)
src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(12-99)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
🔇 Additional comments (6)
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (6)
69-70: Verify angle coordinate system change is mechanically safe.The angle bounds have been fundamentally redesigned: MINIMUM_ANGLE went from -12° to -127° and MAXIMUM_ANGLE from 110° to 0°. This appears to flip the coordinate system and significantly extends the range.
With soft limits disabled (lines 191-195), ensure:
- The new range is mechanically safe and won't cause collisions
- Hardware limit switches are properly configured and tested
- The IntakeState enum values (lines 224-228) correspond to correct physical positions
92-93: LGTM: More aggressive SysID parameters.The characterization parameters are now more aggressive (6× ramp rate, 2.5× step voltage), which should provide better system identification data. Ensure characterization is performed in a controlled environment.
176-183: LGTM: Updated control gains.The PID and feedforward gains have been revised with separate simulation and real-world values. The cruise velocity calculation in simulation now uses a kV-based formula. These tuning changes should improve control performance.
Also applies to: 187-187
224-228: LGTM: IntakeState enum updated consistently.The state definitions have been updated to use the new angle coordinate system. The voltage and angle pairings appear logically consistent:
- COLLECT: negative voltage at minimum angle (extended)
- EJECT: positive voltage at maximum angle (retracted)
- REST states: zero voltage at appropriate angles
This aligns with the angle bound changes at lines 69-70.
36-38: Verify intake sensor wiringSensor channels were remapped from 0/1/2 to 3/4/5; ensure the robot’s physical DIO wiring matches these new assignments to prevent sensor misreads.
154-154: SensorToMechanismRatio usage is correct: SensorToMechanismRatio expects sensor rotations per mechanism output; INTAKE_MOTOR_GEAR_RATIO (4) and ANGLE_MOTOR_GEAR_RATIO (40) are appropriate values.
| configureIntakeMotor(); | ||
| configureAngleMotor(); | ||
| configureLimitSensor(REVERSE_LIMIT_SENSOR, REVERSE_LIMIT_SENSOR_SIMULATION_SUPPLIER, REVERSE_LIMIT_SENSOR_BOOLEAN_EVENT, MINIMUM_ANGLE); | ||
| configureLimitSensor(REVERSE_LIMIT_SENSOR, REVERSE_LIMIT_SENSOR_SIMULATION_SUPPLIER, REVERSE_LIMIT_SENSOR_BOOLEAN_EVENT, MAXIMUM_ANGLE); |
There was a problem hiding this comment.
Limit switch auto-zeroing disabled.
The automatic position reset when limit switches are triggered has been commented out (line 216). Combined with disabled soft limits (lines 191-195), this removes multiple layers of position safety:
- No automatic re-zeroing when hitting physical limits
- No software boundaries to prevent overtravel
- Manual reset via debug trigger (line 210) is now the only way to correct position drift
This increases the risk of accumulating position errors and the intake mechanism believing it's at an incorrect angle.
Consider re-enabling at least one safety layer: either restore soft limits with the new angle range or re-enable automatic position resets at limit switches.
Also applies to: 216-216
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java around
lines 140 and referencing the surrounding lines 191-195, 210, and 216, the
limit-switch auto-zero and soft limits have been disabled which removes position
safety; restore at least one safety layer by either re-enabling soft limits with
the correct angle range or re-enabling the automatic position reset in the limit
switch handler: if choosing soft limits, call the motor controller soft limit
configuration with MINIMUM_ANGLE and MAXIMUM_ANGLE and enable the soft limits
where they were commented out (lines ~191-195); if choosing auto-zero, uncomment
or re-add the limit switch event handler at line ~216 so that when the
reverse/forward limit BooleanEvent fires it sets the encoder position to the
known physical angle (use setSelectedSensorPosition or the equivalent API with
the correct offset), and keep the debug manual reset (line ~210) as a fallback;
ensure the simulation supplier and BooleanEvent used in configureLimitSensor at
line 140 are still wired to the handler and add brief comments documenting which
safety layer is active.
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java
Outdated
Show resolved
Hide resolved
| private static final Trigger DISABLED_TRIGGER = new Trigger(DriverStation::isDisabled); | ||
| private static final Executor BRAKE_MODE_EXECUTOR = Executors.newFixedThreadPool(8); | ||
| private static final LoggedNetworkBoolean ENABLE_EXTENSIVE_LOGGING = new LoggedNetworkBoolean("/SmartDashboard/EnableExtensiveLogging", RobotHardwareStats.isSimulation()); | ||
| private static final LoggedNetworkBoolean ENABLE_EXTENSIVE_LOGGING = new LoggedNetworkBoolean("/SmartDashboard/EnableExtensiveLogging", true);//TODO: AHAHAHAHAHHA |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
❓ Verification inconclusive
Verify this is intentional and track for reversion.
Changing the default from RobotHardwareStats.isSimulation() to true enables extensive logging unconditionally on real hardware, which increases resource consumption (CPU, network bandwidth, storage). The TODO comment suggests this is temporary.
If this is for debugging, consider reverting before competition or making it configurable via NetworkTables at runtime.
Based on learnings
Revert or disable extensive logging default before deployment.
The default for ENABLE_EXTENSIVE_LOGGING was changed to true, enabling costly logging on real hardware (CPU, network, storage). Since it’s already exposed via SmartDashboard, disable it at runtime or revert the default to false before competition.
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/MotorSubsystem.java around line 30,
the LoggedNetworkBoolean ENABLE_EXTENSIVE_LOGGING is defaulted to true which
enables heavy logging on real hardware; change its default back to false (or
programmatically force it off at startup) so extensive logging is disabled by
default while leaving the SmartDashboard key available for debugging. Update the
constructor or static initializer to use false as the default value (or call
ENABLE_EXTENSIVE_LOGGING.set(false) during robot init) and add a brief comment
reminding to enable it only for debugging.
Co-Authored-By: Nummun14 <[email protected]>
Co-Authored-By: Nummun14 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (18)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (1)
110-110: Replace System.out.println with structured logging.These debug print statements should use
Logger.recordOutputinstead ofSystem.out.printlnfor consistency with the existing logging infrastructure in this file.Also applies to: 121-121, 127-127
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (2)
168-172: Soft limits disabled without explanation.The forward and reverse soft limits have been commented out, removing a critical safety boundary. Combined with the removal of limit switch sensors and auto-zeroing, this creates significant position safety risks.
191-191: Distance sensor simulation disabled.The simulation supplier has been commented out, preventing coral collection detection from working in simulation.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (3)
67-72: Fix SysId elevator logging units.
linearPosition/linearVelocitymust be in meters and meters/second, but you're passing raw rotations and rotor RPS. This will produce invalid SysId characterization data for the elevator.Apply this diff to convert to proper units:
- log.motor("Elevator") - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) - .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) - .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); + final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations()); + final double elevatorVelocityMetersPerSecond = rotationsToMeters( + elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO + ); + log.motor("Elevator") + .linearPosition(Units.Meters.of(elevatorPositionMeters)) + .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond)) + .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE)));
67-72: Fix SysId elevator logging units.The elevator logging still passes raw rotations/rotor velocity to
Units.Meters.of()andUnits.MetersPerSecond.of(), which expect meters and m/s. This will produce bogus SysId fits.Convert to meters before logging:
if (SHOULD_CALIBRATE_ELEVATOR) { + final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations()); + final double elevatorVelocityMetersPerSecond = rotationsToMeters( + elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO + ); log.motor("Elevator") - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) - .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) + .linearPosition(Units.Meters.of(elevatorPositionMeters)) + .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond)) .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); return; }
67-73: Fix SysId elevator logging units.The elevator's
linearPositionandlinearVelocityare still logging raw rotations and rotor RPS instead of converting to meters and meters/second. This will produce incorrect SysId characterization. This issue was previously flagged.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (12)
48-49: Document the encoder offset values.
ANGLE_ENCODER_GRAVITY_OFFSET = -0.059326171875and theARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETcalculation involve unexplained magic numbers. Add inline comments explaining:
- How
ANGLE_ENCODER_GRAVITY_OFFSETwas measured (encoder reading at what physical position?)- Why
-23.56°is used in the offset calculation- What the arm's zero/reference position is (horizontal? vertical?)
Apply this diff:
- private static final double ANGLE_ENCODER_GRAVITY_OFFSET = -0.059326171875; - static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() ? 0 : edu.wpi.first.math.util.Units.degreesToRotations(-23.56) - ANGLE_ENCODER_GRAVITY_OFFSET; + // Encoder reading when arm is pointing straight down (gravity-down position, measured in rotations) + private static final double ANGLE_ENCODER_GRAVITY_OFFSET = -0.059326171875; + // Offset to align arm zero position: -23.56° converts from gravity-down to desired zero reference + // Simulation uses ideal zero (no physical offset needed) + static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() + ? 0 + : edu.wpi.first.math.util.Units.degreesToRotations(-23.56) - ANGLE_ENCODER_GRAVITY_OFFSET;
152-152: Arm safe angle threshold set to 0° disables dynamic elevator height safety.
MAXIMUM_ARM_SAFE_ANGLEchanged from 90° to 0°, soisArmAboveSafeAngle()returns true for virtually all forward arm positions. This causescalculateMinimumSafeElevatorHeightRotations()(ArmElevator.java:231-239) to bypass the dynamic height calculation and apply only the static minimum for most arm angles.Revert to 90° or confirm this change is intentional and won't compromise safety:
- static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0); + static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(90);Based on learnings: angles above 90° bypass the safety logic per previous team feedback, but lowering the threshold to 0° extends the bypass zone significantly.
192-202: Commented-out velocity filter and soft limits pose safety risks.The velocity filter (line 192) and forward/reverse software limit switches (lines 198-202) are disabled. Without software limits, the arm could exceed mechanical bounds if commanded beyond the valid angle range.
Either:
- Re-enable with updated thresholds accounting for the new offset:
config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(270) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET; config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(-90) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;
- Remove the dead code if permanently disabled, or add TODO comments explaining temporary disablement and tracking re-enablement.
258-262: Elevator software limits commented out—safety hazard.Elevator soft limits are disabled, allowing the elevator to potentially crash into physical stops and damage the mechanism or cause safety issues.
Strongly recommend re-enabling with appropriate thresholds:
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; -// -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = 0; // Minimum position + + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = metersToRotations(MAXIMUM_ELEVATOR_HEIGHT_METERS);If disabled for debugging, add a TODO comment and re-enable before deployment.
48-49: Document encoder offset values.The offset constants remain undocumented magic numbers. Add comments explaining:
- How
ANGLE_ENCODER_GRAVITY_OFFSETwas measured- What
-23.56°represents inARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET- The arm's intended zero position
As per coding guidelines from previous review.
152-152: Arm safe angle threshold disables elevator safety logic.
MAXIMUM_ARM_SAFE_ANGLE = 0°meansisArmAboveSafeAngle()returns true for nearly all arm positions, bypassing dynamic elevator height calculations incalculateMinimumSafeElevatorHeightRotations(). This could allow unsafe elevator/arm combinations.Restore the safe threshold:
- static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0); + static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(90);Or provide analysis proving 0° is safe for all intended operations.
192-202: Re-enable arm software limit switches.Commented-out soft limits leave the arm vulnerable to exceeding mechanical bounds. Re-enable with the updated angle range or document why they're disabled.
-// config.Feedback.VelocityFilterTimeConstant = 0.2; - -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270); - -// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = Conversions.degreesToRotations(-270); + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(270) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET; + + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(-90) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;
258-262: Re-enable elevator software limit switches.Disabled elevator limits risk crashing into hard stops, potentially damaging the mechanism. Re-enable before competition.
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; -// -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = 0; + + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.metersToRotations(MAXIMUM_ELEVATOR_HEIGHT_METERS) / ELEVATOR_GEAR_RATIO;
48-49: Document the encoder offset values.The magic numbers
ANGLE_ENCODER_GRAVITY_OFFSET = -0.059326171875and-23.56°inARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETneed inline comments explaining:
- How the gravity offset was measured
- What the -23.56° offset represents physically
- The arm's intended zero position
This issue was previously flagged.
152-152: Arm safe angle threshold disables dynamic elevator safety.
MAXIMUM_ARM_SAFE_ANGLEchanged from 90° to 0°. As previously flagged, this causesisArmAboveSafeAngle()to return true for virtually all forward arm positions, which bypasses the dynamic elevator-height safety calculation incalculateMinimumSafeElevatorHeightRotations(). This is a critical safety regression. Revert to 90° or provide justification and additional safety verification.Based on learnings: The team's design has angles above 90° bypassing safety logic, but changing the threshold to 0° extends this bypass to nearly all positions.
192-202: Commented-out velocity filter and limit switches.The velocity filter (line 192) and forward/reverse software limit switches (lines 198-202) remain commented out. Without these safety controls, the arm could exceed mechanical bounds. Either re-enable with proper thresholds accounting for
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET, or document why they're disabled and when they'll be restored. This issue was previously flagged.
258-262: Elevator software limits disabled.Elevator software limits remain commented out. This is particularly dangerous for the elevator, as it could crash into physical stops and cause mechanism damage or safety hazards. Strongly recommend re-enabling these limits before any testing. This critical issue was previously flagged.
🧹 Nitpick comments (5)
src/main/java/frc/trigon/robot/subsystems/swerve/Swerve.java (2)
5-5: Remove unused import of SwerveSetpoint inSwerve.java:5.
4-5: Remove unused SwerveSetpoint import
The importcom.pathplanner.lib.util.swerve.SwerveSetpointisn’t referenced in Swerve.java; remove it.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (3)
21-21: Document the calibration flag and consider a more robust approach.The
SHOULD_CALIBRATE_ELEVATORflag manually switches between arm and elevator calibration. This approach risks deployment errors if the flag isn't toggled correctly before running SysId.Consider one of these approaches:
- Add a clear inline comment explaining this is a manual toggle for SysId runs
- Use a dashboard-selectable option to choose the calibration target at runtime
- Create separate SysId command factories for arm vs. elevator
If keeping the flag, add:
- private static final boolean SHOULD_CALIBRATE_ELEVATOR = true; + /** + * Manual toggle: set to true for elevator SysId, false for arm SysId. + * IMPORTANT: Verify this matches your intended calibration target before running SysId. + */ + private static final boolean SHOULD_CALIBRATE_ELEVATOR = true;
21-21: Make calibration flag configurable or remove after testing.Hardcoding
SHOULD_CALIBRATE_ELEVATOR = truemeans the arm won't be calibrated when this code is deployed. Consider making this a dashboard-configurable boolean or removing it entirely after calibration is complete.Apply this diff to make it configurable:
- private static final boolean SHOULD_CALIBRATE_ELEVATOR = true; + private static final boolean SHOULD_CALIBRATE_ELEVATOR = SmartDashboard.getBoolean("ArmElevator/CalibrateElevator", false);Or add a TODO if this is temporary:
- private static final boolean SHOULD_CALIBRATE_ELEVATOR = true; + // TODO: Remove after elevator calibration is complete + private static final boolean SHOULD_CALIBRATE_ELEVATOR = true;
21-21: Make calibration target configurable.The
SHOULD_CALIBRATE_ELEVATORflag is hardcoded. Consider making this a dashboard-configurable value or a command-line argument so you can switch calibration targets without recompiling.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
src/main/java/frc/trigon/robot/RobotContainer.java(2 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(5 hunks)src/main/java/frc/trigon/robot/subsystems/intake/Intake.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java(7 hunks)src/main/java/frc/trigon/robot/subsystems/swerve/Swerve.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/swerve/SwerveConstants.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/swerve/swervemodule/SwerveModule.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/swerve/swervemodule/SwerveModuleConstants.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java(3 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/main/java/frc/trigon/robot/subsystems/swerve/swervemodule/SwerveModule.java
👮 Files not reviewed due to content moderation or server errors (3)
- src/main/java/frc/trigon/robot/subsystems/swerve/swervemodule/SwerveModuleConstants.java
- src/main/java/frc/trigon/robot/subsystems/swerve/Swerve.java
- src/main/java/frc/trigon/robot/subsystems/swerve/SwerveConstants.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.javasrc/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (9)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (2)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(18-108)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-170)
src/main/java/frc/trigon/robot/subsystems/swerve/swervemodule/SwerveModuleConstants.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java (1)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(18-108)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (2)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(22-354)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-170)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(12-99)
src/main/java/frc/trigon/robot/RobotContainer.java (2)
src/main/java/lib/commands/WheelRadiusCharacterizationCommand.java (1)
WheelRadiusCharacterizationCommand(25-197)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(11-36)
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
src/main/java/lib/hardware/misc/simplesensor/SimpleSensor.java (1)
SimpleSensor(16-139)
🔇 Additional comments (95)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (2)
21-21: Verify disabling autonomous scoring is intentional.
SHOULD_SCORE_AUTONOMOUSLYhas been changed fromtruetofalse, which disables autonomous scoring behavior by default. Ensure this aligns with current robot requirements and competition strategy.
47-47: Simplified manual scoring preparation.The manual scoring path now uses
getPrepareArmElevatorIfWontHitReefinstead ofgetAutonomouslyPrepareScoreCommand, removing autonomous driving logic from the manual workflow. This simplifies the operator-controlled scoring sequence by focusing solely on arm/elevator preparation without robot movement.src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java (1)
34-34: LGTM!The new distance sensor logging provides useful telemetry for monitoring game piece detection. The scaled value uses the calibration constants defined in
EndEffectorConstants.src/main/java/frc/trigon/robot/RobotContainer.java (1)
87-87: Improved end effector default behavior.The end effector now uses a dynamic default command that automatically switches between
HOLD_CORAL(when holding a game piece) andREST(when empty). This provides better default behavior compared to the previous staticRESTstate.src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
29-35: Smart default command implementation.The new
getDefaultCommand()provides intelligent default behavior by holding coral when detected and resting when empty. This prevents accidental game piece loss while maintaining safe idle behavior.src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (5)
21-21: Verify distance sensor wiring matches new channel.The distance sensor channel changed from 4 to 0. Ensure the physical wiring on the robot matches this new channel assignment to prevent detection failures.
26-26: Verify DutyCycle sensor hardware is installed.The sensor type changed from
createDigitalSensortocreateDutyCycleSensor, which requires different hardware. Confirm that a DutyCycle-compatible distance sensor (e.g., analog sensor with PWM output) is physically installed at channel 0.
49-52: Distance sensor calibration constants added.New scaling constants convert raw DutyCycle sensor readings to centimeters. The formula is:
distance_cm = (raw_value * 0.0002) - 200. Ensure these constants match your sensor's datasheet specifications.
69-70: Verify motor configuration changes align with mechanism behavior.Two critical motor configuration changes:
- NeutralMode: Changed from
BraketoCoast, allowing the end effector to backdrive when unpowered- Inverted: Changed from
Clockwise_PositivetoCounterClockwise_Positive, reversing the positive voltage directionVerify that:
- Coast mode is appropriate for your mechanism (won't drop game pieces when idle)
- The inversion change produces correct rotation direction for intake/ejection
99-99: HOLD_CORAL state provides gentle retention.The new
HOLD_CORAL(-0.5)state applies a low holding voltage to maintain coral grip without excessive motor current. This complements the new smart default command that switches between holding and resting.src/main/java/frc/trigon/robot/subsystems/swerve/swervemodule/SwerveModuleConstants.java (6)
80-85: Verify the drive motor PID/FF tuning values.The drive motor control gains have changed significantly:
- kP reduced from 50 to 2 (25× reduction)
- kS reduced from 5.25 to 0.24025 (~22× reduction)
- kV added: 0.91963 (new feedforward term)
- kA added: 0.069151 (new feedforward term)
These changes suggest either:
- New characterization data from sysid
- Hardware modifications (gearing, wheel diameter, motor type)
- Correction of previously incorrect values
The addition of kV and kA feedforward terms is good practice for velocity control. However, ensure these values were obtained from proper sysid characterization and have been tested under load.
Consider verifying:
- These values match the latest sysid characterization results
- The robot drives smoothly with these gains under various loads
- The step voltage reduction to 2V (line 34) didn't compromise characterization quality
34-34: Verify sysid step voltage reduction
Sysid step voltage for DRIVE_MOTOR_SYSID_CONFIG dropped from 8 V to 2 V, lower than battery voltage (~12 V) and other subsystems’ configs (e.g., climber at 5 V). Ensure this change is intentional and still provides adequate signal-to-noise ratio for friction (kS) and acceleration (kA) identification.
32-36: LGTM! Lower SysID voltage improves safety.Reducing the step voltage from 8V to 2V during system identification improves safety and can yield more accurate characterization at lower speeds, reducing the risk of wheel slip.
80-85: LGTM! PID/FF gains updated from characterization.The updated gains reflect typical post-characterization tuning:
- kP reduced from 50 to 2 (less aggressive response)
- kS, kV, kA now populated with non-zero values from system identification
Simulation values correctly preserved with their separate tuning.
34-34: Verify the reduced SysId voltage is intentional.The SysId voltage has been reduced from 8V to 2V. This lower voltage is safer for initial characterization but may provide less accurate results due to lower signal-to-noise ratio and potential issues with overcoming static friction. Ensure this change was intentional and that the characterization at 2V provides sufficient data quality.
80-85: Confirm and document new drive motor control gainsNo evidence found of SysId characterization or tuning documentation for the updated kP, kS, kV, and kA values. Please:
- Attach or reference the SysId tuning report used to derive these gains
- Validate on the robot: ensure smooth drive behavior and accurate setpoint tracking under both normal and aggressive maneuvers
src/main/java/frc/trigon/robot/subsystems/swerve/SwerveConstants.java (8)
31-34: LGTM: Encoder offsets calibrated.The encoder offsets have been updated from placeholder zeros to calibrated values. This is expected after physical alignment or initial hardware setup.
36-39: Verify wheel diameter impact
- Confirm the 0.076 m wheel diameter matches the actual hardware
- Validate odometry and velocity calculations using the new diameter
- Recalculate and update drive feedforward gains (kS=0.24025, kV=0.91963, kA=0.069151) in SwerveModuleConstants.java to reflect the diameter change
31-34: LGTM! Encoder offsets calibrated.The steer encoder offsets have been updated from placeholder zeros to measured calibration values. This is standard practice after aligning each module's encoder zero position with its mechanical zero.
102-104: LGTM! Gyro mount pose calibrated.The gyro mount pose configuration has been updated to reflect the actual physical mounting orientation of the IMU on the robot:
- Yaw offset of ~52° indicates the gyro is mounted at an angle relative to the robot frame
- Small pitch/roll corrections account for minor mounting imperfections
These corrections will improve odometry accuracy by properly transforming gyro readings into the robot's coordinate frame.
36-39: Verify downstream impacts of wheel diameter changeThe wheel diameter was reduced from 0.1 m to 0.076 m; ensure any max‐speed limits, odometry conversions, feedforward/feedback gains, or autonomous path parameters referencing wheel diameter have been updated or retuned.
31-34: LGTM! Steer encoder offsets calibrated.The steer encoder offsets have been updated from placeholder zeros to specific measured values. This is expected when physically calibrating the robot's swerve modules.
102-104: LGTM! Gyro mount pose configured.The gyro mount pose has been updated with specific orientation values. This calibration ensures the gyro readings are correctly transformed to match the robot's coordinate frame.
36-39: Validate wheel diameter reduction
The wheel diameter was changed from 100 mm to 76 mm (24% smaller), which directly affects your encoder-to-distance conversions and drive kinematics. Confirm:
- The 76 mm value was measured on the actual wheels
- Odometry/pose estimation has been recalibrated and validated with the new diameter
- Autonomous paths, speed limits, and distance-based routines have been tested for accuracy with this change
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (2)
51-55: Limit sensor updates removed consistently with constant changes.The removal of
FORWARD_LIMIT_SENSORandREVERSE_LIMIT_SENSORupdate calls is consistent with their removal fromIntakeConstants.java. However, this eliminates runtime feedback from physical limit switches, which compounds the safety concerns created by disabling soft limits in the constants file.Verify that the intake mechanism has alternative physical protections (hard stops, current limiting) since both software limits and limit switch feedback have been removed.
134-134: Visualization rotation direction corrected.Negating the Y-axis rotation adjusts the visualization to properly represent the intake's physical orientation.
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (6)
82-83: SysId parameters made more aggressive.The voltage ramp rate increased 6x (0.2→1.2 V/s) and maximum voltage increased 2.5x (0.6→1.5 V). This will produce faster characterization runs and potentially better data, but monitor the mechanism during SysId to ensure it handles the increased aggressiveness safely.
131-131: API naming updated to match Phoenix 6 conventions.The rename from
RotorToSensorRatiotoSensorToMechanismRatioaligns with updated Phoenix 6 API naming.
153-165: Control gains updated for new angle range.The PID, feedforward, and motion magic parameters have been retuned. Key changes:
- Real hardware: kP=30, kD=0.5, kS=0.61, kV=4, kG=0.3
- Motion magic cruise velocity reduced to 3 rot/s (more conservative)
These values appear reasonable but should be validated through testing across the full angle range.
Test the intake motion across the full angle range (-127° to 0°) to verify:
- Smooth motion without oscillation
- Adequate speed at cruise velocity
- Proper gravity compensation at all angles
187-187: Debug trigger removed - safety improvement.Commenting out the debug position reset trigger removes the previously flagged safety risk of accidentally resetting the motor position during operation.
34-34: Verify distance sensor wiring on DIO channel 5
Code now references channel 5 only; ensure the physical sensor is connected to DIO 5.
195-199: Verify all IntakeState usages with new voltage/angle mappings.
Confirm default commands and runtime checks now produce correct behavior in:
- RobotContainer.setDefaultCommand(IntakeConstants.IntakeState.REST)
- SimulationFieldHandler.atState checks for COLLECT and EJECT
- IntakeCommands.getSetTargetStateCommand in all CommandFactories (CoralCollection, CoralEjection, Climb, AlgaeManipulation)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (34)
48-49: LGTM!The conditional SysId configuration selection correctly delegates to the calibration flag.
52-57: LGTM!Good catch—follower motors now correctly match the brake state of their masters, ensuring consistent mechanical behavior across the entire mechanism.
82-85: LGTM!The mechanism visualization correctly applies the position offset to align the reference display with the actual arm position.
107-113: LGTM!The conditional voltage routing correctly implements the calibration flag behavior.
153-155: LGTM!Centralizing the offset application ensures all arm angle readings are consistently adjusted.
196-196: LGTM!Speed scaling is correctly applied before setting the target arm state.
209-212: LGTM!The offset is correctly removed when commanding the motor (since the encoder feedback includes the offset), maintaining consistency in the control loop.
219-219: LGTM!Correctly uses the dedicated
elevatorPositionRequestfor elevator positioning.
222-239: LGTM!The safety angle calculations correctly account for the new coordinate system (−90° to 270°). The ±90° adjustments in the trigonometric calculations align with the shifted reference frame.
249-255: LGTM!The visualization orientation correctly adds a 90° offset to align with the physical arm orientation in the new coordinate system.
257-267: LGTM!The speed scaling helper methods eliminate code duplication and correctly scale motion parameters proportionally while maintaining the jerk relationship (10× acceleration).
135-137: Verify reversed arm angle calculation.The code now uses
subtractFrom180Degrees(180°−angle) instead of mirroring around 180° (360°−angle). Confirm this new reversal axis matches your intended behavior for allisStateReversedstates.
52-57: LGTM!Correctly applying brake mode to follower motors ensures consistent behavior across the mechanism.
107-113: LGTM!The conditional SysId drive logic correctly routes voltage to the subsystem being calibrated.
153-155: LGTM!The offset correctly adjusts the encoder reading to match the intended arm coordinate system.
82-89: LGTM!Mechanism visualization correctly incorporates the arm position offset for both current and target positions.
249-255: LGTM!The 90-degree visualization offset aligns the 3D representation with the updated arm coordinate system.
222-229: LGTM!The updated safe angle calculation correctly handles the new coordinate system, returning -90° as a conservative lower bound when the elevator is too high for the arm to reach safely.
231-239: Verify elevator safety calculation with new angle system.Adding 90° to the arm angle before computing
getCos()fundamentally changes the elevator height constraint calculation. Ensure this produces correct minimum safe heights across the full arm range (-90° to 270°).Consider adding unit tests for edge cases:
- Arm at -90° (should allow low elevator positions)
- Arm at 0° (transition point for safety logic)
- Arm at 90° (vertical, critical for safety)
- Arm at 270° (maximum angle)
187-207: LGTM!Extracting speed scaling to helper methods improves code clarity and maintainability.
209-212: LGTM!The offset handling is correct: added when reading encoder position and subtracted when commanding motor position, ensuring consistent coordinate systems.
218-220: LGTM!Using separate motion magic requests for arm and elevator allows independent speed scaling and prevents interference between the two subsystems.
257-261: LGTM!Speed scaling helper maintains the correct relationship between velocity, acceleration, and jerk (10x).
263-267: LGTM!Elevator speed scaling correctly maintains motion profile relationships.
47-49: LGTM!SysId config selection correctly matches the calibration flag.
33-38: LGTM!Separate elevator motion magic request enables independent tuning and speed scaling.
132-137: Verify reversed angle math in atStateSubtraction from 180° (instead of 360°) changes reversed targets. Confirm for all calls with isStateReversed=true (SimulationFieldHandler.java:129–135; AutonomousCommands.java:133) that the resulting arm angles fall within the new –90° to 270° range and match the expected physical positions.
48-48: LGTM!The config selection logic correctly routes to the appropriate SysId configuration based on the calibration flag.
52-57: LGTM!Applying brake mode to both master and follower motors ensures consistent behavior across the motor groups.
107-113: LGTM!The voltage routing correctly targets the subsystem being calibrated.
153-155: LGTM!The arm position offset correctly applies the new gravity-based calibration reference.
209-212: LGTM!The offset is correctly subtracted when commanding the motor, maintaining consistency with the offset addition in
getCurrentArmAngle().
257-267: LGTM!The speed scaling helpers correctly apply the scalar to all motion parameters while maintaining the 10x jerk-to-acceleration ratio.
135-135: Confirm reversed angle calculation semanticsThe code now uses
subtractFrom180Degrees(180° − θ) instead of the previous 360° mirror, yielding very different results (e.g. 90°→90° vs. 90°→270°). Verify that mirroring around 180° matches your mechanical and control requirements.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (29)
44-44: Verify elevator PID gains were retuned for the new gear ratio.
ELEVATOR_GEAR_RATIOchanged from 3 to 4 (33% increase), which significantly affects the relationship between motor output and elevator motion. Confirm that the elevator PID gains (lines 247-253) were re-characterized for this new mechanical configuration.The velocity and acceleration limits may also need adjustment—verify through testing that motion profiles remain smooth and don't exceed mechanical limits.
54-58: LGTM—significant motion profile tuning applied.The updated velocity and acceleration limits represent major performance tuning:
- Arm real-robot acceleration increased from 0 to 7
- Elevator real-robot acceleration increased from 20 to 50
These changes should improve responsiveness but verify through testing that the mechanism remains mechanically sound under the new profiles.
76-77: LGTM—coordinate system updated to match physical constraints.The angle bounds shifted from [0°, 360°] to [−90°, 270°], representing the same 360° range with a new reference frame that better aligns with the physical mechanism orientation.
100-110: LGTM—more conservative SysId voltage limits.Reducing the step voltage targets (arm: 3V → 1.5V, elevator: 3V → 2V) makes characterization safer, reducing the risk of mechanism damage during SysId runs.
181-187: LGTM—substantial arm control tuning applied.The PID gains were significantly updated:
- kP doubled (34 → 70) for more aggressive position control
- kG increased 3.5× (0.1117 → 0.39) for better gravity compensation
These changes should be validated through testing to ensure stability and smooth motion.
215-216: LGTM!The additional rotor velocity and position signals support the SysId characterization logging implemented in ArmElevator.java.
247-253: LGTM—elevator control substantially retuned.The PID gains were significantly updated with the gear ratio change (3 → 4):
- kP increased 3.4× (3.5 → 12)
- kD increased 2.5× (0.4 → 1)
- kA disabled (feedforward removed)
These changes must be validated through testing to ensure stability with the new mechanical configuration.
279-280: LGTM!The rotor velocity signal supports SysId characterization, and the position reset provides consistent initialization on startup.
304-306: LGTM—encoder configuration aligns with new coordinate system.The sensor direction change and discontinuity point adjustment (1.0 → 0.5) align with the shifted angle reference frame and ensure continuous readings across the working range [−90°, 270°].
316-338: Verify the reworked state machine.
- Constraint-bypassing states: LOAD_CORAL (line 324), COLLECT_ALGAE_FLOOR (line 336)
- Manually confirm:
- All target angles/positions are mechanically achievable
- Prepare→execute state chains run in the intended order
- Speed scalars (especially 0.02) yield safe, smooth motion
- Ignoring constraints on these states won’t cause collisions
28-28: Verify elevator follower motor CAN ID.CAN ID changed from 18 to 17. Ensure the physical motor is connected to ID 17 and update any hardware documentation.
44-44: Verify elevator gear ratio change.Gear ratio changed from 3 to 4, which affects all elevator kinematics. Confirm this matches the actual gearbox installed on the robot. If this corrects a previous error, consider re-characterizing the elevator with SysId.
54-58: LGTM!Replacing zero acceleration/velocity values with realistic limits enables proper arm motion on the real robot. The simulation values remain higher for faster testing.
76-77: LGTM!The updated angle range (-90° to 270°) aligns with the new coordinate system and state definitions.
100-110: LGTM!Lower SysId voltage limits provide more conservative characterization, reducing risk of mechanism damage during testing.
181-187: LGTM!Non-zero PID gains for the real robot enable proper arm control. Previous zero values would have prevented motion.
215-216: LGTM!Registering rotor velocity and position signals enables more comprehensive debugging and system identification.
247-253: LGTM!Updated elevator PID and feedforward gains reflect characterization results and should improve control performance.
279-280: LGTM!Registering rotor velocity and zeroing position on initialization are correct practices for elevator control.
304-306: LGTM!Encoder configuration changes align with the updated coordinate system and 180-degree reversal logic.
316-337: Confirm speedScalar for REST_WITH_CORAL/REST_WITH_ALGAE
These states use a 0.02 speedScalar (2% of default arm speed), which may produce under 0.1 RPS movement. Ensure this extremely low speed is intentional for safe handling—otherwise consider increasing it (e.g., to 0.1–0.2) for practical responsiveness.
28-28: LGTM!Elevator follower motor ID updated to 17, consistent with hardware remapping.
44-44: LGTM - verify elevator behavior.The elevator gear ratio changed from 3 to 4, which affects all position/velocity calculations. Ensure the new ratio has been tested and all elevator position constants in the state machine (lines 316-337) are calibrated for this gearbox.
54-58: LGTM!Motion profile parameters updated based on physical testing. The arm acceleration increase from 0 to 7 on the real robot will improve responsiveness.
76-77: LGTM - verify mechanical limits.The arm angle range shifted from [0°, 360°] to [-90°, 270°]. This aligns with the new offset logic and the
subtractFrom180Degreesimplementation. Confirm these bounds match your physical hard stops.
100-110: LGTM!Reduced SysId voltage limits (arm: 1.5V, elevator: 2V) are a safer approach for characterization testing.
181-187: LGTM!Updated PID and feedforward gains from characterization. The significant kG increase (0.11 → 0.39) suggests the arm has more mass or different center of gravity than initially modeled.
247-253: LGTM!Elevator PID and feedforward gains updated from characterization. The increased kP (3.5 → 12) and kD (0.4 → 1) will provide more aggressive position tracking.
304-306: LGTM - encoder discontinuity matches new range.The encoder discontinuity point moved to 0.5 (180°), which aligns with the new [-90°, 270°] angle range and the
subtractFrom180Degreesimplementation. The sensor direction change likely reflects physical mounting orientation.
| MINIMUM_ANGLE = Rotation2d.fromDegrees(-127), | ||
| MAXIMUM_ANGLE = Rotation2d.fromDegrees(0); |
There was a problem hiding this comment.
🧩 Analysis chain
Verify mechanical clearances for dramatically expanded angle range.
The angle bounds have changed drastically:
MINIMUM_ANGLE: -12° → -127° (expanded by 115°)MAXIMUM_ANGLE: 110° → 0° (reduced by 110°)
This represents a fundamental change to the intake's operational envelope. At -127°, the intake may collide with the robot frame, strain cables, or interfere with other mechanisms.
Physically test the intake mechanism across the full new range (-127° to 0°) to verify:
- No collisions with robot frame or other subsystems
- No cable strain or connector stress
- Adequate structural support at extreme angles
- Intended functionality at all positions
🏁 Script executed:
#!/bin/bash
# Description: Check if there are test files or comments documenting the angle range change
rg -n -A 3 -B 3 "(MINIMUM_ANGLE|MAXIMUM_ANGLE|127|angle.*range)" --type java -g '*Test*.java' -g '*Constants*.java'Length of output: 6185
Enable software angle limits and validate mechanical range
- Uncomment and configure
config.SoftwareLimitSwitch.ReverseSoftLimitEnable = trueandForwardSoftLimitEnable = truewith thresholdsMINIMUM_ANGLE.getRotations()/MAXIMUM_ANGLE.getRotations()inIntakeConstants.java(lines 169–172) - Physically test the intake across its full new range (−127° to 0°) to confirm no collisions, cable strain, or structural interference
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java around
lines 61–62 and update at lines 169–172, enable and set the motor controller
software limits: uncomment and set
config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true and
config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true, and assign the
thresholds to MINIMUM_ANGLE.getRotations() and MAXIMUM_ANGLE.getRotations()
respectively; after making the changes, build and deploy, then physically
exercise the intake through the full range (−127° to 0°) and verify there are no
collisions, cable strain, or structural interference.
| config.MountPose.MountPoseYaw = Units.degreesToRotations(-52.198792); | ||
| config.MountPose.MountPosePitch = Units.degreesToRadians(-0.087891); | ||
| config.MountPose.MountPoseRoll = Units.degreesToRadians(-0.659180); |
There was a problem hiding this comment.
Fix inconsistent units for gyro mount pose configuration.
There's a units inconsistency in the gyro mount pose configuration:
- Line 102:
MountPoseYawusesUnits.degreesToRotations()(converts to rotations/revolutions) - Lines 103-104:
MountPosePitchandMountPoseRolluseUnits.degreesToRadians()(converts to radians)
According to CTRE Phoenix 6 documentation, the MountPose configuration expects all three values in the same units (typically rotations for the API). This inconsistency will cause incorrect gyro orientation compensation.
Apply this diff to use consistent units:
- config.MountPose.MountPoseYaw = Units.degreesToRotations(-52.198792);
- config.MountPose.MountPosePitch = Units.degreesToRadians(-0.087891);
- config.MountPose.MountPoseRoll = Units.degreesToRadians(-0.659180);
+ config.MountPose.MountPoseYaw = Units.degreesToRotations(-52.198792);
+ config.MountPose.MountPosePitch = Units.degreesToRotations(-0.087891);
+ config.MountPose.MountPoseRoll = Units.degreesToRotations(-0.659180);Or if radians are preferred:
- config.MountPose.MountPoseYaw = Units.degreesToRotations(-52.198792);
- config.MountPose.MountPosePitch = Units.degreesToRadians(-0.087891);
- config.MountPose.MountPoseRoll = Units.degreesToRadians(-0.659180);
+ config.MountPose.MountPoseYaw = Units.degreesToRadians(-52.198792);
+ config.MountPose.MountPosePitch = Units.degreesToRadians(-0.087891);
+ config.MountPose.MountPoseRoll = Units.degreesToRadians(-0.659180);Verify which unit system the CTRE API expects:
#!/bin/bash
# Search for CTRE Pigeon2 MountPose documentation or examples
rg -i "MountPose" --type java -C 5Co-Authored-By: Nummun14 <[email protected]>
Co-Authored-By: Nummun14 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
42-42: Simulation bug: collection detection always true.In simulation, getScaledValue() returns sensorInputs.value (0 or 1), and both are < 6 cm, so COLLECTION_DETECTION_BOOLEAN_EVENT is always true. Return realistic distances in cm in sim.
- private static final DoubleSupplier DISTANCE_SENSOR_SIMULATION_SUPPLIER = () -> (SimulationFieldHandler.isHoldingCoral() && SimulationFieldHandler.isCoralInEndEffector()) || SimulationFieldHandler.isHoldingAlgae() ? 1 : 0; + private static final DoubleSupplier DISTANCE_SENSOR_SIMULATION_SUPPLIER = () -> { + // Near object ~3 cm, otherwise far ~100 cm + final boolean hasObject = (SimulationFieldHandler.isHoldingCoral() && SimulationFieldHandler.isCoralInEndEffector()) + || SimulationFieldHandler.isHoldingAlgae(); + return hasObject ? 3.0 : 100.0; + };Also applies to: 55-57
♻️ Duplicate comments (4)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (1)
67-73: Fix SysId elevator logging units.The previous critical issue remains unresolved:
linearPosition/linearVelocitymust be in meters and m/s, but you're passing raw rotations (line 69) and rotor RPS (line 70). This will produce invalid SysId characterization fits for the elevator.Apply this diff to convert to proper units:
- if (SHOULD_CALIBRATE_ELEVATOR) { - log.motor("Elevator") - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) - .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) - .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); - return; - } + if (SHOULD_CALIBRATE_ELEVATOR) { + final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations()); + final double elevatorVelocityMetersPerSecond = rotationsToMeters( + elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO + ); + log.motor("Elevator") + .linearPosition(Units.Meters.of(elevatorPositionMeters)) + .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond)) + .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); + return; + }src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (3)
153-153: Arm safe-angle at 0° likely disables dynamic elevator safety.Setting MAXIMUM_ARM_SAFE_ANGLE to 0° makes isArmAboveSafeAngle() true for nearly all forward poses, bypassing dynamic elevator-height safety. Revert to 90° or add equivalent protections/tests before keeping 0°.
Based on learnings
193-204: Arm software limits are disabled — restore or justify.Forward/reverse soft limits are commented out. Re-enable with thresholds that account for ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET, or add a clear TODO with owner/ticket and rationale. Running without these invites hard-stop crashes.
259-264: Elevator software limits disabled — high risk.Forward/reverse soft limits are commented out. Strongly recommend re-enabling using MAXIMUM_ELEVATOR_HEIGHT_METERS (converted to sensor units) and your reverse reset position. If temporarily disabled, add TODOs and re-enable before field use.
🧹 Nitpick comments (4)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (2)
29-35: Default should react to hasGamePiece changes continuously.ConditionalCommand samples once at init; it won’t switch when hasGamePiece flips. Prefer a Run command that sets the target each cycle.
-import edu.wpi.first.wpilibj2.command.ConditionalCommand; +import edu.wpi.first.wpilibj2.command.Commands; ... - public static Command getDefaultCommand() { - return new ConditionalCommand( - getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.HOLD_CORAL), - getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.REST), - RobotContainer.END_EFFECTOR::hasGamePiece - ); - } + public static Command getDefaultCommand() { + return Commands.run( + () -> RobotContainer.END_EFFECTOR.setTargetState( + RobotContainer.END_EFFECTOR.hasGamePiece() + ? EndEffectorConstants.EndEffectorState.HOLD_CORAL + : EndEffectorConstants.EndEffectorState.REST + ), + RobotContainer.END_EFFECTOR + ); + }
21-27: End action is empty — confirm desired behavior.StartEndCommand does not stop the motor on end. If you want a defined safe state between commands, use END_EFFECTOR::stop.
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
20-31: Prefer composing the load step rather than scheduling inside an InstantCommand.Scheduling from inside a command makes cancellation and tracing harder. Consider returning a composed sequence:
- Intake until transporter has coral
- Rumble
- If not holding algae, then run getLoadCoralCommand()
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
49-57: Calibrate and document distance-sensor scaling.Slope 0.0002 and intercept −200 imply specific units from the duty-cycle IO. Briefly document the measurement procedure, units, and sample readings, and verify the threshold of 6 cm matches reality.
Also applies to: 88-89
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
src/main/java/frc/trigon/robot/RobotContainer.java(3 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java(1 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(6 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/main/java/frc/trigon/robot/RobotContainer.java
- src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.javasrc/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java
🧬 Code graph analysis (6)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (2)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-172)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(19-109)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (4)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-172)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(15-78)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(11-45)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)src/main/java/lib/hardware/phoenix6/cancoder/CANcoderEncoder.java (1)
CANcoderEncoder(20-193)src/main/java/lib/hardware/phoenix6/talonfx/TalonFXMotor.java (1)
TalonFXMotor(20-209)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (2)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(23-355)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-172)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (2)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/misc/simplesensor/SimpleSensor.java (1)
SimpleSensor(16-139)
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (1)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-172)
🔇 Additional comments (20)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (14)
21-21: LGTM! Calibration flag is clear.The calibration flag provides a clean way to switch between arm and elevator SysId characterization.
47-49: LGTM! Config selection logic is correct.The method correctly returns the appropriate SysId configuration based on the calibration flag.
52-57: Good fix! Follower motors now have synchronized brake mode.Previously, follower motors were not having their brake mode set, which could lead to inconsistent mechanical behavior. This ensures both master and follower motors have synchronized brake modes.
74-78: LGTM! Arm SysId logging units are correct.The arm logging correctly uses angular units (rotations and RPS) for the rotational arm mechanism, with proper gear ratio compensation for velocity.
82-89: LGTM! Mechanism visualization uses consistent offsets.The arm mechanism visualization correctly applies offsets to both current and target positions for consistency.
107-113: LGTM! SysId voltage routing is correct.The voltage routing correctly directs test voltages to the mechanism being characterized based on the calibration flag.
153-155: LGTM! Arm angle offset applied correctly.The arm position offset compensates for mechanical mounting and encoder reference point differences, aligning the encoder reading with the actual arm angle.
195-202: LGTM! Arm state setting applies speed scaling correctly.The method properly scales motion profile parameters before setting the target angle, maintaining consistent behavior with the reversed state logic.
209-212: LGTM! Arm angle offset compensation is bidirectional.The offset is correctly subtracted when commanding motor position (inverse of the addition in
getCurrentArmAngle), ensuring the motor control works in encoder reference frame.
218-220: LGTM! Elevator position request correctly uses renamed variable.The rename from
positionRequesttoelevatorPositionRequestimproves code clarity.
222-229: LGTM! Safe angle calculation handles edge cases and adjusts reference frame.The NaN check provides a safe fallback (-90° = arm down), and the 90-degree reference frame adjustment aligns with the corresponding elevator safety calculation.
231-239: LGTM! Elevator safety calculation uses consistent angle offset.The +90° offset (line 232) is the complement of the -90° offset in
calculateMinimumArmSafeAngle(line 228), maintaining mathematical consistency between arm and elevator safety constraints.
257-267: LGTM! Speed scaling implementation is clean.The speed scaling methods properly scale all motion profile parameters (velocity, acceleration, jerk) by the same factor, maintaining profile shape while allowing variable-speed states.
132-137: Validate the revised reversed-angle formula (180° − angle)
The mirroring logic was changed from360° − angleto180° − angle(subtractFrom180Degrees), which alters outputs (e.g., REST –90°→270° instead of 90°). Confirm that all reversed states (COLLECT_ALGAE_*, SCORE_L4.prepareState, etc.) still map to the intended physical arm positions.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (3)
37-42: CANivore bus usage consistency looks good.All arm/elevator motors and the angle encoder are on the same CANivore bus via RobotConstants.CANIVORE_NAME. Good for consistent remote sensor routing.
55-56: Double-check Motion Magic units and realism for accel values.ARM_DEFAULT_MAXIMUM_ACCELERATION is 67.2344 (sim) vs 4 (real). Ensure these are in the expected Phoenix6 units for your selected sensor (rotations/s² after ratios) and are realistic for both environments to avoid overshoot or sluggish response.
Also applies to: 59-59
305-308: Verify CANcoder direction, offset, and discontinuity interplay.With CounterClockwise_Positive, MagnetOffset = −0.0625 rotations, and discontinuity at 0.5, confirm:
- Increasing arm angle corresponds to increasing encoder rotations.
- The wrap point does not cross frequently-used poses.
- Offsets align with ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET assumptions.
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (2)
49-53: New public getIntakeCoralCommand() is clear and cohesive.Encapsulating Intake+Transporter collection improves reuse across teleop/auto.
37-39: Load flow end condition looks sound.Ending on hasGamePiece, then returning arm to REST until at-state, with final unless(hasGamePiece) prevents redundant actions.
Confirm default EndEffector behavior after this sequence returns (e.g., HOLD_CORAL via default command).
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
70-75: Confirm motor inversion/neutral mode vs state voltages.With CounterClockwise_Positive and NeutralMode.Coast, ensure:
- Negative HOLD_CORAL voltage aids retention, not ejection.
- Coasting at REST won’t let the piece slip unintentionally when default command toggles to REST.
Also applies to: 92-101
| PREPARE_SCORE_L4(Rotation2d.fromDegrees(50), 1.41, null, false, 1), | ||
| REST(Rotation2d.fromDegrees(-90), 0.603, null, false, 0.7), |
There was a problem hiding this comment.
SCORE_L4 targets exceed maximum elevator height (1.41 m > 1.382 m).
Both PREPARE_SCORE_L4 and SCORE_L4 command 1.41 m, above MAXIMUM_ELEVATOR_HEIGHT_METERS. This can overdrive the mechanism without soft limits.
Apply this diff to clamp within limits:
- PREPARE_SCORE_L4(Rotation2d.fromDegrees(50), 1.41, null, false, 1),
+ PREPARE_SCORE_L4(Rotation2d.fromDegrees(50), 1.382, null, false, 1),
...
- SCORE_L4(Rotation2d.fromDegrees(25), 1.41, PREPARE_SCORE_L4, false, 1),
+ SCORE_L4(Rotation2d.fromDegrees(25), 1.382, PREPARE_SCORE_L4, false, 1),Also applies to: 331-331, 62-68
🤖 Prompt for AI Agents
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
lines 320-321 (also check lines 331 and 62-68): PREPARE_SCORE_L4 and SCORE_L4
use 1.41 m which exceeds MAXIMUM_ELEVATOR_HEIGHT_METERS (1.382 m); update those
entries to clamp the elevator target to the defined maximum (e.g., replace
literal 1.41 with a value computed as Math.min(1.41,
MAXIMUM_ELEVATOR_HEIGHT_METERS) or directly set to
MAXIMUM_ELEVATOR_HEIGHT_METERS when the literal is greater) and apply the same
clamp to the other occurrences at the noted lines so no constant exceeds the
maximum allowed height.
Co-Authored-By: Nummun14 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (2)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (1)
68-72: Fix SysId elevator units.
linearPosition/linearVelocitystill log raw rotations, so any elevator SysId run will produce nonsense fits. Convert to meters before publishing.Apply this diff:
- log.motor("Elevator") - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) - .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) + final double elevatorPositionMeters = getCurrentElevatorPositionMeters(); + final double elevatorVelocityMetersPerSecond = rotationsToMeters( + elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO + ); + log.motor("Elevator") + .linearPosition(Units.Meters.of(elevatorPositionMeters)) + .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond)) .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE)));src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
320-333: Clamp L4 elevator setpoints to the defined maximum.Both PREPARE_SCORE_L4 and SCORE_L4 command 1.5 m while
MAXIMUM_ELEVATOR_HEIGHT_METERSis 1.382 m, and the software limits are still disabled. This will drive the elevator past its mechanical range.Apply this diff:
- PREPARE_SCORE_L4(Rotation2d.fromDegrees(50), 1.5, null, false, 1), + PREPARE_SCORE_L4(Rotation2d.fromDegrees(50), MAXIMUM_ELEVATOR_HEIGHT_METERS, null, false, 1), ... - SCORE_L4(Rotation2d.fromDegrees(20), 1.5, PREPARE_SCORE_L4, false, 1), + SCORE_L4(Rotation2d.fromDegrees(20), MAXIMUM_ELEVATOR_HEIGHT_METERS, PREPARE_SCORE_L4, false, 1),
🧹 Nitpick comments (1)
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (1)
113-125: Consider usingParallelCommandGroupinstead ofParallelRaceGroupfor semantic clarity.Both
getScoreInNetCommand()(lines 113-117) andgetAtonomouslyScoreInNetCommand()(lines 119-125) useParallelRaceGroupto coordinate multiple commands. However, examining the child commands:
getFlippableOverridableArmCommand()returns aStartEndCommand(infinite duration)runWhen(EndEffectorCommands.getSetTargetStateCommand(...))wraps anotherStartEndCommand(infinite duration)getDriveToNetCommand()ends with a closed-loop drive command (infinite duration)Since all child commands are infinite and never complete naturally, the race condition will never resolve on its own. Termination is handled by outer
untilclauses (line 59 and line 102). While functionally equivalent toParallelCommandGroupin this context,ParallelRaceGroupimplies that one command completing should terminate the group, which is misleading here.Apply this diff to improve semantic clarity in
getScoreInNetCommand():private static Command getScoreInNetCommand() { - return new ParallelRaceGroup( + return new ParallelCommandGroup( GeneralCommands.getFlippableOverridableArmCommand(ArmElevatorConstants.ArmElevatorState.SCORE_NET, false, AlgaeManipulationCommands::shouldReverseNetScore), GeneralCommands.runWhen(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.SCORE_ALGAE), OperatorConstants.CONTINUE_TRIGGER) ); }And similarly for
getAtonomouslyScoreInNetCommand():private static Command getAtonomouslyScoreInNetCommand() { - return new ParallelRaceGroup( + return new ParallelCommandGroup( GeneralCommands.getFlippableOverridableArmCommand(ArmElevatorConstants.ArmElevatorState.SCORE_NET, false, AlgaeManipulationCommands::shouldReverseNetScore), GeneralCommands.runWhen(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.SCORE_ALGAE), OperatorConstants.CONTINUE_TRIGGER), getDriveToNetCommand() ); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java(3 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java(2 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralEjectionCommands.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java(11 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(6 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java(4 hunks)
👮 Files not reviewed due to content moderation or server errors (2)
- src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java
- src/main/java/frc/trigon/robot/commands/commandfactories/CoralEjectionCommands.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.javasrc/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (7)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (3)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-172)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-96)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(19-109)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (9)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-172)src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (1)
AlgaeManipulationCommands(31-267)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(12-99)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(16-79)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(19-109)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(11-45)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (1)
TransporterConstants(21-120)
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (4)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-172)src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
CoralPlacingCommands(20-251)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-96)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(12-99)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-96)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (3)
src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-96)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(23-356)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(44-172)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (3)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/misc/simplesensor/SimpleSensor.java (1)
SimpleSensor(16-139)src/main/java/frc/trigon/robot/misc/simulatedfield/SimulationFieldHandler.java (1)
SimulationFieldHandler(18-213)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)src/main/java/lib/hardware/phoenix6/cancoder/CANcoderEncoder.java (1)
CANcoderEncoder(20-193)src/main/java/lib/hardware/phoenix6/talonfx/TalonFXMotor.java (1)
TalonFXMotor(20-209)
🔇 Additional comments (16)
src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (4)
64-65: Verify pulse timing adjustments are tested.The pulse timing has been reduced significantly (voltage application time by 20%, wait time by 40%). Ensure these faster pulse cycles have been tested with actual coral handling to confirm they don't cause slippage or degraded performance.
35-38: Encapsulation approved—no external references detected. MakingGEAR_RATIO,MOTOR_AMOUNT, andGEARBOXprivate is safe given there are no usages outsideTransporterConstants.
25-25: Confirm beam break channel change is propagatedNo hardcoded references to channel 3 remain in the code; ensure the physical wiring has been updated to use channel 1.
106-109: Major behavioral changes to transporter states—verify thoroughly.The target voltages for all non-REST states now reverse the right motor’s direction and, in one case, alter its magnitude:
- COLLECT: right 5 → –4 V, left 5 V
- ALIGN_CORAL: right 5 → –5 V, left 6 V
- HOLD_CORAL: right 1 → –1 V, left 1 V
- EJECT: right –5 → 5 V, left –5 V
These reversals fundamentally change coral intake, alignment, and ejection behavior. Ensure they align with the updated state-machine and have been validated with real-world testing.
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (7)
22-23: LGTM! Simplified intake flow.The intake sequence now clearly separates collection (until coral detected) from confirmation, making the flow easier to follow.
30-30: LGTM! Appropriate parallel command composition.Running the intake assist command alongside the main sequence is the correct approach for concurrent behavior.
52-57: LGTM! Clean public API.The simplified public
getIntakeCoralCommand()provides a clear entry point for intake operations, replacing the previous private helper logic. The parallel execution of intake and transporter is appropriate.
52-57: LGTM on the public API exposure!The visibility change from private to public for
getIntakeCoralCommand()and the simplified logic (replacing multiple private helpers) makes the intake flow more maintainable and testable. The parallel execution of intake and transporter COLLECT states is clear and straightforward.
37-42: Correct.unless()guard coverage: The.unless(RobotContainer.END_EFFECTOR::hasGamePiece)at the end applies to the entire load-and-rest sequence—if a piece is already held, neither phase runs—and no conflicting patterns were found.
52-57: Confirm continuous vs pulsed transporter behaviorTransporterCommands.getSetTargetStateCommand now drives continuously rather than the previous pulsed cycle (getSetTargetStateWithPulsesCommand: apply voltage for PULSE_VOLTAGE_APPLIED_TIME_SECONDS, wait for PULSE_WAIT_TIME_SECONDS, repeated). Verify this change has been tested to ensure reliable coral collection.
22-30: Incorrect guard removal –.until(RobotContainer.TRANSPORTER::hasCoral)remains ongetIntakeCoralCommand.Likely an incorrect or invalid review comment.
src/main/java/frc/trigon/robot/commands/commandfactories/CoralEjectionCommands.java (3)
18-24: Confirm simulation guard removal for Coral ejection commandRemoving the
onlyIf(SimulationFieldHandler::isHoldingCoral)guard allows the ejection command to run regardless of simulation state—isHoldingCoral()is still used in multiple simulation suppliers—potentially desyncing simulation behavior. Verify this change is intentional and safe.
18-24: Removal of the simulation-only guard is safe: ejection is now gated byRobotContainer.TRANSPORTER.hasCoral()orRobotContainer.INTAKE.hasCoral().
18-24: Verify removal of simulation-only guard is intentional.The
.onlyIf(SimulationFieldHandler::isHoldingCoral)guard was removed fromgetCoralEjectionCommand(). This guard previously restricted coral ejection to simulation environments only. Removing it enables ejection on the real robot.Confirm that this change is intentional and that the ejection command is safe to execute on physical hardware without the simulation guard.
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (2)
98-98: Clean separation of autonomous and manual scoring paths.The conditional selection between
getAtonomouslyScoreInNetCommand()andgetScoreInNetCommand()based onCoralPlacingCommands.SHOULD_SCORE_AUTONOMOUSLYprovides a clear separation between autonomous and operator-controlled scoring modes. This approach maintains code clarity and makes the scoring behavior explicit.
52-52: Verify and document the 0.5 s settling delay
This floor-algae command adds a 0.5 s post-detection wait via.raceWith(…WaitUntil…andThen(WaitCommand(0.5))), whereas other collection commands simply use.until(…). Confirm the END_EFFECTOR sensor bounce requires this delay, document the rationale, and ensure it doesn’t degrade cycle time.
| new InstantCommand( | ||
| () -> { | ||
| if (!AlgaeManipulationCommands.isHoldingAlgae()) | ||
| getLoadCoralCommand().schedule(); | ||
| } | ||
| ) |
There was a problem hiding this comment.
Avoid manual .schedule() inside commands.
Calling .schedule() on a command inside an InstantCommand bypasses the normal command composition patterns and can lead to issues with command lifecycle management, cancellation, and resource tracking.
Apply this diff to use proper command composition:
- new InstantCommand(
- () -> {
- if (!AlgaeManipulationCommands.isHoldingAlgae())
- getLoadCoralCommand().schedule();
- }
- )
+ Commands.either(
+ getLoadCoralCommand(),
+ Commands.none(),
+ () -> !AlgaeManipulationCommands.isHoldingAlgae()
+ )🤖 Prompt for AI Agents
In the file
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java
around lines 24 to 29, the code manually schedules the getLoadCoralCommand()
inside an InstantCommand. This is not the recommended approach as it bypasses
the normal command composition patterns and can lead to issues with command
lifecycle management, cancellation, and resource tracking. Instead, refactor the
code to use proper command composition by removing the manual .schedule() call
and allowing the command framework to handle the scheduling and execution of the
getLoadCoralCommand().
| ).until(RobotContainer.END_EFFECTOR::hasGamePiece).andThen( | ||
| new ParallelCommandGroup( | ||
| ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING), | ||
| EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.HOLD_CORAL) | ||
| ).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING)) | ||
| ).unless(RobotContainer.END_EFFECTOR::hasGamePiece); |
There was a problem hiding this comment.
Add timeout to prevent indefinite blocking.
The .until(RobotContainer.END_EFFECTOR::hasGamePiece) at line 37 could block indefinitely if the sensor fails to detect the coral or the game piece is not properly loaded. This would hang the command sequence and impact user experience.
Apply this diff to add a timeout:
- ).until(RobotContainer.END_EFFECTOR::hasGamePiece).andThen(
+ ).until(RobotContainer.END_EFFECTOR::hasGamePiece).withTimeout(2.0).andThen(Consider defining the timeout constant in CoralCollectionCommands or an appropriate constants file for maintainability.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ).until(RobotContainer.END_EFFECTOR::hasGamePiece).andThen( | |
| new ParallelCommandGroup( | |
| ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING), | |
| EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.HOLD_CORAL) | |
| ).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING)) | |
| ).unless(RobotContainer.END_EFFECTOR::hasGamePiece); | |
| ).until(RobotContainer.END_EFFECTOR::hasGamePiece).withTimeout(2.0).andThen( | |
| new ParallelCommandGroup( | |
| ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING), | |
| EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.HOLD_CORAL) | |
| ).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING)) | |
| ).unless(RobotContainer.END_EFFECTOR::hasGamePiece); |
🤖 Prompt for AI Agents
In
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java
around lines 37 to 42, the .until(RobotContainer.END_EFFECTOR::hasGamePiece) can
block indefinitely; add a timeout to the waiting predicates (e.g.,
.withTimeout(??, TimeUnit.SECONDS) or use .raceWith(new
WaitCommand(timeoutSeconds))) so the command chain fails or continues after a
bounded period, and likewise add a timeout to the
ParallelCommandGroup.until(...) that waits for the ARM_ELEVATOR state; define a
timeout constant (e.g., CORAL_COLLECTION_TIMEOUT_SECONDS) either as a private
static final in CoralCollectionCommands or in an existing constants file and use
that constant for both timeouts to keep maintainability.
Logic error: unless guard contradicts until condition.
The until(RobotContainer.END_EFFECTOR::hasGamePiece) on line 37 waits for the end effector to detect a game piece. Once this condition is true, execution proceeds to the andThen chain. However, the unless(RobotContainer.END_EFFECTOR::hasGamePiece) guard on line 42 prevents the entire andThen sequence from running when hasGamePiece() is true.
Since we can only reach the andThen after hasGamePiece() becomes true, the unless guard will always prevent the rest-after-loading sequence from executing. This means the arm elevator will never reach REST_AFTER_LOADING and the end effector will never hold the coral.
Remove the unless guard to fix the logic:
).until(RobotContainer.END_EFFECTOR::hasGamePiece).andThen(
new ParallelCommandGroup(
ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING),
EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.HOLD_CORAL)
).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING))
- ).unless(RobotContainer.END_EFFECTOR::hasGamePiece);
+ );📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ).until(RobotContainer.END_EFFECTOR::hasGamePiece).andThen( | |
| new ParallelCommandGroup( | |
| ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING), | |
| EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.HOLD_CORAL) | |
| ).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING)) | |
| ).unless(RobotContainer.END_EFFECTOR::hasGamePiece); | |
| ).until(RobotContainer.END_EFFECTOR::hasGamePiece).andThen( | |
| new ParallelCommandGroup( | |
| ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING), | |
| EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.HOLD_CORAL) | |
| ).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING)) | |
| ); |
🤖 Prompt for AI Agents
In
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java
around lines 37 to 42, the command chain uses
until(RobotContainer.END_EFFECTOR::hasGamePiece) followed by an andThen(...)
that is then wrapped with unless(RobotContainer.END_EFFECTOR::hasGamePiece),
which contradicts the until condition and prevents the sequence from ever
running; remove the trailing unless(RobotContainer.END_EFFECTOR::hasGamePiece)
so the andThen sequence executes after the until condition becomes true,
allowing the arm to move to REST_AFTER_LOADING and the end effector to enter
HOLD_CORAL as intended.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
155-156: Revert the arm safe-angle threshold to keep elevator safety working.Dropping
MAXIMUM_ARM_SAFE_ANGLEto 0° makesisArmAboveSafeAngle()true for almost every forward pose, so the dynamic elevator-height safety never kicks in. Restore the 90° limit (or provide an equivalent safeguard) before shipping.- static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0); + static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(90);
🧹 Nitpick comments (2)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (2)
109-111: Document usage and consider safety guards for position reset.The new
resetIntakePosition()method provides useful calibration functionality, but lacks documentation and safety considerations.Consider:
- Add JavaDoc explaining when this should be called (e.g., during initialization, when intake is at known zero position)
- Consider adding a safety check to prevent resetting during active motion
- Verify the intake is physically at the zero position before resetting
Example documentation:
+/** + * Resets the intake angle position to zero. + * Should only be called when the intake is physically at the zero position (fully retracted). + * Calling this method during active motion may cause control instability. + */ public void resetIntakePosition() { angleMotor.setPosition(0); }
123-125: Document direct voltage control insetAngleMotorVoltage.Add JavaDoc in
Intake.javaonsetAngleMotorVoltageclarifying:
- Used only in
IntakeCommands.resetIntakePositionCommandfor manual angle adjustment via joystick- Bypasses MotionMagic position control and soft limits
- Accepts voltages in a safe range (±12 V); consider clamping input
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/intake/Intake.java(6 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (3)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (4)
src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-130)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/swerve/SwerveCommands.java (1)
SwerveCommands(15-163)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(43-178)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (6)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)src/main/java/lib/hardware/phoenix6/cancoder/CANcoderEncoder.java (1)
CANcoderEncoder(20-193)src/main/java/lib/hardware/phoenix6/talonfx/TalonFXMotor.java (1)
TalonFXMotor(20-209)src/main/java/lib/hardware/simulation/ElevatorSimulation.java (1)
ElevatorSimulation(11-84)src/main/java/lib/hardware/simulation/SingleJointedArmSimulation.java (1)
SingleJointedArmSimulation(12-81)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (1)
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (1)
IntakeConstants(30-212)
🪛 Gitleaks (8.28.0)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java
[high] 86-86: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (4)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (4)
55-55: LGTM! Distance sensor logging added.The addition of distance sensor logging with a clear key name ("Intake/distanceSensorCM") is useful for debugging and telemetry monitoring.
80-80: LGTM! Log key refactoring aligns with naming standards.The updates to
@AutoLogOutputkeys from "CoralIntake/..." to "Intake/..." standardize the naming convention and improve consistency across the logging framework.Also applies to: 86-86
136-142: Verify visualization rotation aligns with physical mounting.The negation of the angle in the visualization pose calculation changes the rotation convention. This appears consistent with broader rotation convention changes mentioned across the codebase.
Please confirm:
- The negated rotation correctly represents the intake's physical orientation
- This change is consistent with visualization updates in other subsystems (e.g., ArmElevator)
- The visualization renders correctly in the simulation/dashboard
If needed, visually verify the intake orientation in the simulation to ensure it matches the physical robot.
70-74: Confirm intake motor stop() behavior
Intake.stop() sets target velocity to 0 but comments out intakeMotor.stopMotor(), unlike other subsystems (e.g., SwerveModule). Confirm whether setTargetVelocity(0) suffices to disable/brake the motor or if you should restore stopMotor() for safety.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
38-52: Still need bounded waits on the load sequenceAs noted in the earlier review, each
.until(...)in this block can stall forever if a sensor never reports ready (e.g., transporter beam break, end-effector detector, or elevator state). That will hang the entire coral load workflow mid-match. Add explicit timeouts (or race with aWaitCommand) for each stage so the command fails gracefully instead of freezing. For example:- ).until(RobotContainer.TRANSPORTER::hasCoral).unless((RobotContainer.TRANSPORTER::hasCoral)).unless(RobotContainer.END_EFFECTOR::hasGamePiece), + ).until(RobotContainer.TRANSPORTER::hasCoral) + .withTimeout(CoralCollectionConstants.TRANSPORTER_ACQUIRE_TIMEOUT_SECONDS) + .unless((RobotContainer.TRANSPORTER::hasCoral)).unless(RobotContainer.END_EFFECTOR::hasGamePiece), ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST).unless(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST)).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST)), new ParallelCommandGroup( ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.LOAD_CORAL), EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.LOAD_CORAL) - ).until(RobotContainer.END_EFFECTOR::hasGamePiece), + ).until(RobotContainer.END_EFFECTOR::hasGamePiece) + .withTimeout(CoralCollectionConstants.END_EFFECTOR_ACQUIRE_TIMEOUT_SECONDS), new ParallelCommandGroup( ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING), EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.HOLD_CORAL) - ).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING)) + ).until(() -> RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING)) + .withTimeout(CoralCollectionConstants.ARM_SETTLE_TIMEOUT_SECONDS)Define the timeout constants (tuned values) alongside the other statics in this class or an appropriate constants file.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/frc/trigon/robot/RobotContainer.java(5 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-21T17:39:27.460Z
Learnt from: Nummun14
PR: Programming-TRIGON/RobotCodeOffSeason2025#11
File: src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java:23-28
Timestamp: 2025-09-21T17:39:27.460Z
Learning: In FRC command-based programming, using InstantCommand with schedule() inside a command group is acceptable when you want to decouple command lifecycles - allowing part of a sequence to be interrupted while ensuring another part runs to completion independently. This creates "fire-and-forget" behavior where scheduled commands continue regardless of the parent command's cancellation.
Applied to files:
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java
🧬 Code graph analysis (2)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (6)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (1)
AlgaeManipulationCommands(31-274)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(16-58)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (1)
TransporterConstants(21-120)
src/main/java/frc/trigon/robot/RobotContainer.java (8)
src/main/java/frc/trigon/robot/constants/CameraConstants.java (1)
CameraConstants(12-60)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-130)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(17-92)src/main/java/frc/trigon/robot/subsystems/climber/ClimberCommands.java (1)
ClimberCommands(14-66)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(16-58)src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (1)
AutonomousCommands(32-257)
| ).alongWith(new IntakeAssistCommand(OperatorConstants.DEFAULT_INTAKE_ASSIST_MODE).until(RobotContainer.INTAKE::hasCoral).asProxy().onlyIf(() -> CoralCollectionCommands.SHOULD_USE_INTAKE_ASSIST) | ||
| ).finallyDo(() -> SHOULD_LOAD_CORAL = true); |
There was a problem hiding this comment.
Do not reset the operator toggle automatically
The new finallyDo forces SHOULD_LOAD_CORAL back to true every time the collection sequence ends. That completely negates the operator’s toggle—you flip it off once, the command finishes, and the flag is silently re-enabled. Please drop the unconditional reset (or persist the operator’s choice some other way) so the toggle actually behaves like a toggle.
- ).finallyDo(() -> SHOULD_LOAD_CORAL = true);
+ );🤖 Prompt for AI Agents
In
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java
around lines 33-34, the command sequence unconditionally resets
SHOULD_LOAD_CORAL to true in finallyDo which overrides the operator toggle;
remove the unconditional finallyDo that sets SHOULD_LOAD_CORAL = true (or
replace it with logic that only sets the flag when explicitly requested or
persists the operator choice via a setting/Preferences entry) so the operator
toggle remains respected.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/main/java/frc/trigon/robot/subsystems/swerve/Swerve.java (1)
305-310: Verify the prediction time and consider extracting it as a constant.The switch to using a predicted future pose (0.13 seconds ahead) is a good latency compensation technique. The atSetpoint() clamping prevents oscillation at the target position.
However, the hardcoded 0.13 second value should be extracted to a named constant for better maintainability and documentation.
Consider this refactor to extract the magic number:
In
SwerveConstants.java:+ static final double POSE_PREDICTION_TIME_SECONDS = 0.13;In
Swerve.java:- final Pose2d currentPose = RobotContainer.ROBOT_POSE_ESTIMATOR.getPredictedRobotFuturePose(0.13); + final Pose2d currentPose = RobotContainer.ROBOT_POSE_ESTIMATOR.getPredictedRobotFuturePose(SwerveConstants.POSE_PREDICTION_TIME_SECONDS);Alternatively, if you prefer to keep variables final while still applying the atSetpoint() logic:
- double xSpeed = SwerveConstants.X_TRANSLATION_PID_CONTROLLER.calculate(currentPose.getX(), flippedTargetPose.getX()); - xSpeed = SwerveConstants.X_TRANSLATION_PID_CONTROLLER.atSetpoint() ? 0 : xSpeed; - double ySpeed = SwerveConstants.Y_TRANSLATION_PID_CONTROLLER.calculate(currentPose.getY(), flippedTargetPose.getY()); - ySpeed = SwerveConstants.Y_TRANSLATION_PID_CONTROLLER.atSetpoint() ? 0 : ySpeed; + final double xSpeed = SwerveConstants.X_TRANSLATION_PID_CONTROLLER.atSetpoint() ? 0 : + SwerveConstants.X_TRANSLATION_PID_CONTROLLER.calculate(currentPose.getX(), flippedTargetPose.getX()); + final double ySpeed = SwerveConstants.Y_TRANSLATION_PID_CONTROLLER.atSetpoint() ? 0 : + SwerveConstants.Y_TRANSLATION_PID_CONTROLLER.calculate(currentPose.getY(), flippedTargetPose.getY());Note: The second refactor changes the order of operations—
atSetpoint()is checked beforecalculate(). This would use the previous calculation's setpoint status rather than the current one. Only apply this if you want the behavior to use the previous cycle's setpoint determination.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/main/java/frc/trigon/robot/subsystems/swerve/Swerve.java(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/main/java/frc/trigon/robot/subsystems/swerve/Swerve.java (2)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/subsystems/swerve/SwerveConstants.java (1)
SwerveConstants(19-112)
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (6)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (2)
68-73: Fix SysId elevator logging units.The elevator SysId logging still passes raw rotations and rotor velocity into
linearPosition/linearVelocity, which expect meters and m/s. This will produce incorrect SysId fits.Apply this diff to convert to proper units:
+ final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations()); + final double elevatorVelocityMetersPerSecond = rotationsToMeters( + elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO + ); log.motor("Elevator") - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) - .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) + .linearPosition(Units.Meters.of(elevatorPositionMeters)) + .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond))
76-77: Use primary sensor velocity, not rotor velocity division.The arm angular velocity calculation still divides rotor velocity by the gear ratio, but since the arm uses
RemoteCANcoderwithRotorToSensorRatio = ARM_GEAR_RATIO, theVELOCITYsignal already returns arm rotations per second.Replace with:
log.motor("Arm") .angularPosition(Units.Rotations.of(armMasterMotor.getSignal(TalonFXSignal.POSITION))) - .angularVelocity(Units.RotationsPerSecond.of(armMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ARM_GEAR_RATIO)) + .angularVelocity(Units.RotationsPerSecond.of(armMasterMotor.getSignal(TalonFXSignal.VELOCITY)))src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (4)
27-27: Contradictory until/unless logic prevents command execution.The command waits
.until(RobotContainer.TRANSPORTER::hasCoral)but immediately cancels with.unless(RobotContainer.TRANSPORTER::hasCoral). Once theuntilcompletes (coral present), theunlesswill always prevent the rest of the sequence from running.Apply this diff:
- getIntakeCoralCommand().until(RobotContainer.TRANSPORTER::hasCoral).unless((RobotContainer.TRANSPORTER::hasCoral)), + getIntakeCoralCommand().until(RobotContainer.TRANSPORTER::hasCoral),
36-36: Do not reset the operator toggle automatically.The
finallyDounconditionally resetsSHOULD_LOAD_CORALtotrueevery time the collection sequence ends, negating the operator's toggle. When the operator disables it, it gets silently re-enabled after one command execution.Remove the unconditional reset:
- ).finallyDo(() -> SHOULD_LOAD_CORAL = true); + );
44-44: Critical: Contradictory conditions prevent stage 1 from executing.Stage 1 has
.until(RobotContainer.TRANSPORTER::hasCoral).unless(RobotContainer.TRANSPORTER::hasCoral)— the same contradictory pattern. The stage will never complete because once theuntilis satisfied (coral present), theunlessimmediately cancels it.Apply this diff:
new ParallelCommandGroup( getIntakeCoralCommand(), ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST) - ).until(RobotContainer.TRANSPORTER::hasCoral).unless((RobotContainer.TRANSPORTER::hasCoral)).unless(RobotContainer.END_EFFECTOR::hasGamePiece), + ).until(RobotContainer.TRANSPORTER::hasCoral).unless(RobotContainer.END_EFFECTOR::hasGamePiece),
54-57: Refine unless guard to allow REST_AFTER_LOADING transition.The guard skips the entire sequence if the end effector has a game piece AND the arm is in
LOAD_CORAL,REST, orPREPARE_REST. However, if we've just completed stage 3 (arm inLOAD_CORALwith coral), this guard will prevent stage 4 (moving toREST_AFTER_LOADING) from executing.Consider excluding
LOAD_CORALfrom the guard:).unless(() -> RobotContainer.END_EFFECTOR.hasGamePiece() - && !(RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.LOAD_CORAL) - || RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST) + && !(RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST) + || RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.REST_AFTER_LOADING) || RobotContainer.ARM_ELEVATOR.atState(ArmElevatorConstants.ArmElevatorState.PREPARE_REST)));
🧹 Nitpick comments (1)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (1)
58-58: Consider logging flag value locally.Directly logging
CoralCollectionCommands.SHOULD_USE_INTAKE_ASSISTcreates tight coupling between subsystems. If this flag needs to be observable, consider passing it as a parameter or logging it from the command factory instead.Alternatively, if the intake needs to know this state for its own logic, consider making it part of the intake's internal state rather than reaching across subsystems.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
src/main/java/frc/trigon/robot/RobotContainer.java(5 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java(2 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java(3 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/climber/Climber.java(5 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/intake/Intake.java(7 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/Transporter.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java
- src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java
- src/main/java/frc/trigon/robot/subsystems/climber/Climber.java
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java
📚 Learning: 2025-09-21T17:39:27.460Z
Learnt from: Nummun14
PR: Programming-TRIGON/RobotCodeOffSeason2025#11
File: src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java:23-28
Timestamp: 2025-09-21T17:39:27.460Z
Learning: In FRC command-based programming, using InstantCommand with schedule() inside a command group is acceptable when you want to decouple command lifecycles - allowing part of a sequence to be interrupted while ensuring another part runs to completion independently. This creates "fire-and-forget" behavior where scheduled commands continue regardless of the parent command's cancellation.
Applied to files:
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java
🧬 Code graph analysis (5)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (2)
src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)
src/main/java/frc/trigon/robot/RobotContainer.java (9)
src/main/java/frc/trigon/robot/constants/CameraConstants.java (1)
CameraConstants(12-60)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(17-92)src/main/java/frc/trigon/robot/subsystems/climber/ClimberCommands.java (1)
ClimberCommands(14-66)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(16-58)src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (1)
AutonomousCommands(32-257)src/main/java/frc/trigon/robot/constants/FieldConstants.java (1)
FieldConstants(18-121)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (4)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(25-364)src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
CoralPlacingCommands(21-252)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (10)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (1)
AlgaeManipulationCommands(31-274)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(17-92)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(19-109)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(16-58)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (1)
IntakeConstants(30-212)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (1)
TransporterConstants(21-120)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (2)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (1)
IntakeConstants(30-212)
🪛 Gitleaks (8.28.0)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java
[high] 89-89: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (3)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (2)
142-142: Verify reversed angle calculation change.The reversed angle calculation changed from
subtractFrom360DegreestosubtractFrom180Degrees(180° - angle instead of 360° - angle). This fundamentally changes how reversed arm states are calculated.Please confirm this change is correct for your arm geometry when scoring from the opposite side. Test that reversed scoring positions (e.g., from the coral intake side) place the arm at the correct angles.
219-222: Verify manual voltage override safety.The code sends a fixed
-0.25voltage when the elevator is below REST height and the arm is below -80°. This bypasses motion magic control and could be unsafe if the condition is incorrectly triggered.Please verify:
- This condition correctly identifies a stuck/unsafe state
- The -0.25V value safely moves the arm out of the problematic position
- This doesn't cause unexpected behavior during normal operation
Consider adding a log statement when this override activates to aid debugging.
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (1)
75-75: Verify commented-out intake motor stop is intentional.The intake motor's
stopMotor()call is commented out, meaning the intake will coast rather than stop whenstop()is called. This could cause the intake to continue spinning and potentially interfere with game piece handling.If this is intentional (e.g., to allow coral to continue moving), please document why in a comment. Otherwise, uncomment the line to ensure proper stop behavior.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (11)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (4)
22-23: Consider encapsulating mutable static state.Public static mutable fields bypass encapsulation and lack thread-safety. For better maintainability and safety, consider using private fields with synchronized accessor methods.
27-27: Contradictory until/unless logic prevents command execution.The
.until(RobotContainer.TRANSPORTER::hasCoral)waits for coral, but.unless(RobotContainer.TRANSPORTER::hasCoral)cancels immediately when coral is present. Sinceuntilonly completes when the condition is true, theunlesswill always prevent subsequent commands from running.
36-36: Do not reset the operator toggle automatically.The
finallyDoforcesSHOULD_LOAD_CORALback totrueevery time the collection sequence ends, negating the operator's toggle. Remove this reset to respect the operator's choice.
40-57: Multiple issues with getLoadCoralCommand sequence.This command has several critical issues previously flagged:
- Line 44: Contradictory
until/unlesslogic (same as line 27)- Lines 44, 49, 53: Missing timeouts could cause indefinite blocking on sensor failures
- Line 54-57: The
unlessguard may prevent REST_AFTER_LOADING from executingThese issues prevent reliable command execution and should be addressed.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
206-210: Arm software limits commented out.Commented-out forward/reverse software limit switches remove protection against commanding the arm beyond mechanical bounds. Without these limits, the arm could exceed the safe angle range (-90° to 270°) if commanded improperly.
266-270: Elevator software limits commented out.Elevator software limits are disabled, removing protection against crashing into physical hard stops. This is a safety concern.
155-155: MAXIMUM_ARM_SAFE_ANGLE set to 0° disables dynamic safety.Changing from 90° to 0° means
isArmAboveSafeAngle()returns true for nearly all forward arm positions, bypassing dynamic elevator-height safety calculations incalculateMinimumSafeElevatorHeightRotations().
343-343: SCORE_NET at maximum height leaves no safety margin.
SCORE_NETtargets exactly 1.644m, which equalsMAXIMUM_ELEVATOR_HEIGHT_METERS. With software limits disabled, there's no protection if this value is exceeded. Consider reducing slightly to 1.64m to leave a margin.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
40-52: Reset sequence now bounded; prior stall resolved.The first ExecuteEndCommand is gated by until(atState(ZERO_ELEVATOR)), allowing progression. The hold‑while‑pressed second step + finallyDo(reset) matches intent.
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (2)
61-62: Re‑enable soft limits for the new −127°..0° range (safety).Angle range expanded drastically and both soft limits are commented out. Restore soft limits to protect the mechanism and validate end‑to‑end clearances.
Apply:
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = MINIMUM_ANGLE.getRotations(); -// -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = MAXIMUM_ANGLE.getRotations(); + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = MINIMUM_ANGLE.getRotations(); + + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = MAXIMUM_ANGLE.getRotations();Also applies to: 170-174
105-111: Distance scaling likely incorrect → “always present” detection risk.The slope/intercept (0.0002, −200) will keep scaled values near −200 for realistic raw duty‑cycle readings, making “< 35 cm” effectively always true on real hardware. Calibrate with two measured points and derive slope/intercept, then set a realistic threshold.
Quick approach:
- Measure raw at two known distances (d1, r1), (d2, r2) in cm.
- slope = (d2 − d1) / (r2 − r1), intercept = d1 − slope*r1.
- Update DISTANCE_SENSOR_SCALING_* and COLLECTION_DETECTION_DISTANCE_CENTIMETRES accordingly.
🧹 Nitpick comments (8)
src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
42-52: Consider separate toggles for independent control.The conditional logic couples
SHOULD_USE_INTAKE_ASSISTandSHOULD_SCORE_AUTONOMOUSLYtogether—both are enabled or both are disabled. This prevents operators from toggling collection autonomy independently from scoring autonomy. If that coupling is intentional, consider adding a comment explaining the rationale. Otherwise, provide separate toggle commands for finer control.src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
18-19: Remove unused imports.The imports for
AutoLogandAutoLogOutputare not used in this file. Remove them to keep the code clean.Apply this diff:
-import org.littletonrobotics.junction.AutoLog; -import org.littletonrobotics.junction.AutoLogOutput;src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (1)
75-75: Clarify intake stop logic
setTargetVelocity(0) on IntakeConstants.INTAKE_MECHANISM replaces the direct intakeMotor.stopMotor() call—remove the redundant commented‐out line or add a brief comment explaining why it’s omitted.src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java (2)
40-45: Remove commented code or document the intent.The PWM boundary constants are commented out but remain in the codebase. If servo boundary configuration is no longer needed, remove these lines. If this is temporary or intentional (e.g., using default boundaries), add a comment explaining why.
Apply this diff to remove the dead code:
-// private static final int -// SERVO_PULSE_WIDTH_MICROSECONDS = 20000, -// SERVO_MAXIMUM_DEADBAND_RANGE_MICROSECONDS = 0, -// SERVO_CENTER_PULSE_WIDTH_MICROSECONDS = 1500, -// SERVO_MINIMUM_DEADBAND_RANGE_MICROSECONDS = 1000, -// SERVO_MAXIMUM_PULSE_WIDTH_MICROSECONDS = 2000;Alternatively, if this is intentional, add a comment:
+ // Servo PWM boundaries are not configured - using default values // private static final int // SERVO_PULSE_WIDTH_MICROSECONDS = 20000,
124-137: Remove empty configureServos method or its commented code.The
configureServos()method is still invoked in the static initializer (line 80) but does nothing. Either remove the commented code and leave the empty method (if servos use defaults), or remove both the method and its invocation if servo configuration is unnecessary.If servo configuration is no longer needed:
static { configureMotor(); - configureServos(); }And remove the empty method:
-private static void configureServos() { -// RIGHT_SERVO.setPWMBoundaries( -// SERVO_PULSE_WIDTH_MICROSECONDS, -// SERVO_MAXIMUM_DEADBAND_RANGE_MICROSECONDS, -// SERVO_CENTER_PULSE_WIDTH_MICROSECONDS, -// SERVO_MINIMUM_DEADBAND_RANGE_MICROSECONDS, -// SERVO_MAXIMUM_PULSE_WIDTH_MICROSECONDS -// ); -// LEFT_SERVO.setPWMBoundaries( -// SERVO_PULSE_WIDTH_MICROSECONDS, -// SERVO_MAXIMUM_DEADBAND_RANGE_MICROSECONDS, -// SERVO_CENTER_PULSE_WIDTH_MICROSECONDS, -// SERVO_MINIMUM_DEADBAND_RANGE_MICROSECONDS, -// SERVO_MAXIMUM_PULSE_WIDTH_MICROSECONDS -// ); -}src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (2)
112-117: Race ends immediately on “continue” press — confirm intent.ParallelRaceGroup will finish as soon as runWhen(...) completes (which is immediate after scheduling the end‑effector command). This cancels the arm move early. If you want the arm to keep running until it finishes while still gating ejection on “continue”, prefer a ParallelCommandGroup or a deadline group with an explicit WaitUntil as the deadline.
134-140: Typo: “Atonomously” → “Autonomously”.Rename for clarity.
- private static Command getAtonomouslyScoreInProcessorCommand() { + private static Command getAutonomouslyScoreInProcessorCommand() { return new ParallelCommandGroup( ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.SCORE_PROCESSOR), GeneralCommands.runWhen(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.SCORE_ALGAE), OperatorConstants.CONTINUE_TRIGGER), getDriveToProcessorCommand() ).finallyDo(GeneralCommands.getFieldRelativeDriveCommand()::schedule); }src/main/java/frc/trigon/robot/RobotContainer.java (1)
122-124: Gate position reset commands to disabled (safety).Avoid accidental encoder resets while enabled. Gate triggers with DriverStation.isDisabled().
- OperatorConstants.RESET_CLIMBER_POSITION_TRIGGER.whileTrue(ClimberCommands.resetClimberPositionCommand().ignoringDisable(true)); - OperatorConstants.RESET_INTAKE_POSITION_TRIGGER.whileTrue(IntakeCommands.resetIntakePositionCommand().ignoringDisable(true)); - OperatorConstants.RESET_ELEVATOR_POSITION_TRIGGER.whileTrue(ArmElevatorCommands.resetElevatorPositionCommand().ignoringDisable(true)); + OperatorConstants.RESET_CLIMBER_POSITION_TRIGGER.and(DriverStation::isDisabled) + .whileTrue(ClimberCommands.resetClimberPositionCommand().ignoringDisable(true)); + OperatorConstants.RESET_INTAKE_POSITION_TRIGGER.and(DriverStation::isDisabled) + .whileTrue(IntakeCommands.resetIntakePositionCommand().ignoringDisable(true)); + OperatorConstants.RESET_ELEVATOR_POSITION_TRIGGER.and(DriverStation::isDisabled) + .whileTrue(ArmElevatorCommands.resetElevatorPositionCommand().ignoringDisable(true));
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
src/main/java/frc/trigon/robot/RobotContainer.java(5 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java(4 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/ClimbCommands.java(2 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java(2 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java(5 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(6 hunks)src/main/java/frc/trigon/robot/subsystems/intake/Intake.java(7 hunks)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java(7 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/Transporter.java(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
📚 Learning: 2025-09-21T17:39:27.460Z
Learnt from: Nummun14
PR: Programming-TRIGON/RobotCodeOffSeason2025#11
File: src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java:23-28
Timestamp: 2025-09-21T17:39:27.460Z
Learning: In FRC command-based programming, using InstantCommand with schedule() inside a command group is acceptable when you want to decouple command lifecycles - allowing part of a sequence to be interrupted while ensuring another part runs to completion independently. This creates "fire-and-forget" behavior where scheduled commands continue regardless of the parent command's cancellation.
Applied to files:
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java
🧬 Code graph analysis (12)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (4)
src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/swerve/SwerveCommands.java (1)
SwerveCommands(15-163)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (5)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(17-94)
src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (4)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
CoralPlacingCommands(21-252)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(17-94)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (3)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/misc/simplesensor/SimpleSensor.java (1)
SimpleSensor(16-139)src/main/java/frc/trigon/robot/misc/simulatedfield/SimulationFieldHandler.java (1)
SimulationFieldHandler(18-213)
src/main/java/frc/trigon/robot/subsystems/transporter/Transporter.java (1)
src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (1)
TransporterConstants(21-120)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)src/main/java/lib/hardware/phoenix6/cancoder/CANcoderEncoder.java (1)
CANcoderEncoder(20-193)src/main/java/lib/hardware/phoenix6/talonfx/TalonFXMotor.java (1)
TalonFXMotor(20-209)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (2)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (1)
IntakeConstants(30-211)
src/main/java/frc/trigon/robot/RobotContainer.java (9)
src/main/java/frc/trigon/robot/constants/CameraConstants.java (1)
CameraConstants(12-60)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(17-94)src/main/java/frc/trigon/robot/subsystems/climber/ClimberCommands.java (1)
ClimberCommands(14-66)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(16-58)src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (1)
AutonomousCommands(32-257)src/main/java/frc/trigon/robot/constants/FieldConstants.java (1)
FieldConstants(18-121)
src/main/java/frc/trigon/robot/commands/commandfactories/ClimbCommands.java (6)
src/main/java/frc/trigon/robot/subsystems/climber/ClimberCommands.java (1)
ClimberCommands(14-66)src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java (1)
ClimberConstants(22-156)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/swerve/SwerveCommands.java (1)
SwerveCommands(15-163)src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (1)
IntakeConstants(30-211)
src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (3)
src/main/java/lib/hardware/misc/simplesensor/SimpleSensor.java (1)
SimpleSensor(16-139)src/main/java/frc/trigon/robot/misc/simulatedfield/SimulationFieldHandler.java (1)
SimulationFieldHandler(18-213)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (5)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(17-94)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java (1)
IntakeCommands(16-58)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterCommands.java (1)
TransporterCommands(12-45)
🪛 Gitleaks (8.28.0)
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java
[high] 89-89: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (39)
src/main/java/frc/trigon/robot/commands/commandfactories/ClimbCommands.java (6)
18-18: LGTM!The static IS_CLIMBING flag is a straightforward approach to track the climbing state across the command lifecycle.
23-24: LGTM!The BREAK_ZIP_TIE state transition is correctly implemented and appropriately sequenced before PREPARE_FOR_CLIMB. The until condition properly waits for the climber to reach the target state.
26-26: Verify removal of hasCage() safety check.The wait condition for PREPARE_FOR_CLIMB has been simplified to only check CONTINUE_TRIGGER. Ensure that removing the hasCage() check (if it existed previously) doesn't introduce safety concerns during the climb sequence. Verify that cage presence validation is either unnecessary at this stage or handled elsewhere in the climb logic.
41-41: Verify the 3× manual climb speed multiplier for safety.The manual climb adjustment speed has been increased by a factor of 3. Confirm that this multiplier is safe and intentional, particularly during the sensitive final climb adjustment phase. Consider whether this speed is appropriate given the mechanical constraints and safety requirements of the climber mechanism.
46-46: Verify that asProxy() is necessary.The addition of asProxy() changes the command's lifecycle by scheduling it as a separate command rather than as part of the parent group. This prevents the parent group's cancellation from immediately affecting this command. Verify that this proxy behavior is necessary to address a specific scheduling issue and doesn't introduce unintended side effects during the climb sequence.
53-53: Verify OPEN_REST is the correct intake state for climbing.The intake rest state during climb has been changed from REST_FOR_CLIMB to OPEN_REST. Confirm that OPEN_REST (with minimum angle) is the appropriate and safe state for the intake subsystem during the entire climb sequence, and that this change doesn't conflict with any mechanical constraints or safety requirements.
src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (3)
35-40: LGTM!The toggle command correctly flips the
SHOULD_LOAD_CORALflag usingInstantCommand. The.ignoringDisable(true)ensures the toggle works even when the robot is disabled, which is appropriate for operator controls.
54-66: LGTM!Both toggle commands correctly flip their respective flags using
InstantCommandand.ignoringDisable(true), matching the pattern established by the other toggle commands.
72-73: LGTM!The signature formatting changes improve readability by breaking long parameter lists across multiple lines. No behavior changes.
Also applies to: 113-114, 120-122, 128-129
src/main/java/frc/trigon/robot/subsystems/intake/Intake.java (4)
56-58: LGTM!The logging updates replace removed limit sensor logs with distance sensor readings, angle measurements, and autonomous intake flag status. These provide useful telemetry for debugging and monitoring coral collection behavior.
112-114: LGTM!The
resetIntakePosition()method provides a clean API for resetting the angle motor encoder position to zero, which is useful for calibration and manual positioning workflows.
126-128: LGTM!The
setAngleMotorVoltage()method with package-private visibility provides controlled access to set the angle motor voltage, useful for manual control sequences like the reset position command.
142-142: LGTM!Negating the angle in
calculateVisualizationPose()aligns with the updated rotation convention for visualization, ensuring the intake pose is rendered correctly in the 3D view.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (3)
163-173: LGTM!The
IS_BREAKING_ARM_EVENTtrigger detects excessive current (70A) in the arm motor and automatically stops it after 0.1s debounce. This provides a safety mechanism to prevent damage. The trigger is registered in the static initializer, ensuring it's active throughout the robot's operation.
327-327: Verify SCORE_L4 heights against maximum.
PREPARE_SCORE_L4andSCORE_L4both target 1.5m, which is withinMAXIMUM_ELEVATOR_HEIGHT_METERS(1.644m) ✓- However, past reviews flagged earlier versions exceeding the limit. Confirm these values are safe and tested.
Also applies to: 342-342
324-349: LGTM!The
ArmElevatorStateenum has been comprehensively rewritten with new scoring levels, rest positions, and collection states. The targets appear mechanically feasible (except for the noted SCORE_NET concern), and the state machine structure withprepareStatereferences andignoreConstraintsflags provides good control flow.src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (5)
70-71: Verify motor configuration changes align with physical setup.The neutral mode changed from Brake to Coast, which will allow the end effector to spin freely when unpowered instead of resisting motion. The motor direction is also inverted. These changes will significantly affect how the end effector holds and releases game pieces.
Ensure that:
- Coast mode is appropriate for game piece retention during unpowered states
- The inversion matches the physical motor mounting
- Any commands relying on the motor self-braking have been updated accordingly
88-88: LGTM!The scaling constants are correctly applied to the distance sensor.
97-101: Verify voltage increases for motor safety and performance.The voltage values for several states have changed significantly:
COLLECT_ALGAE: -4V → -11V (2.75× increase)SCORE_ALGAE: 4V → 10V (2.5× increase)HOLD_ALGAE: -4V → -7.5V (1.875× increase)These are substantial increases that bring the motor operation to 83-92% of the maximum 12V. While the 80A stator current limit provides protection, please verify:
- These voltages were empirically tested and produce the desired performance
- The motor and gearbox can handle these loads without overheating during extended operation
- The mechanical stress on the gear train (12.82:1 ratio) is within acceptable limits
- The new
HOLD_CORALandHOLD_ALGAEholding voltages adequately secure game pieces
22-22: Verify hardware configuration changes
ConfirmedCANIVORE_NAMEis defined inRobotConstants. Manually validate that the duty-cycle distance sensor is wired to DIO port 0 and the motor is connected to the CANivore bus.
42-42: Verify distance sensor scaling and simulation behavior
- Scaling constants (0.0002, –200) are consistent across IntakeConstants and EndEffectorConstants – validate against the sensor’s datasheet and real-world measurements.
- Ensure the simulation supplier’s 1 cm/10 cm outputs accurately reflect expected end-effector positions.
- Confirm the debounce reduction to 0.16 s remains stable without excessive false positives.
src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java (5)
76-76: Verify the doubled tolerance is acceptable for climber operation.The tolerance has been doubled from 0.01 to 0.02 rotations. Ensure this looser tolerance is acceptable for the climber's positioning requirements, particularly for critical operations like aligning for climbing.
89-97: PID tuning with gravity compensation looks appropriate.The addition of gravity feedforward (kG) and setting GravityType to Elevator_Static is correct for an elevator-style climber mechanism. The tuned values appear reasonable, particularly the precise kG value which suggests empirical tuning.
99-106: Different gravity compensation for on-cage operation is appropriate.Slot1 (on-cage PID) uses a different kG value (-1) compared to Slot0 (-0.2001953125), which correctly accounts for the different loading conditions when the robot is on the cage versus grounded.
108-109: Conservative MotionMagic settings for real robot are appropriate.The reduced cruise velocity and acceleration for the real robot compared to simulation values are sensible for safe operation.
142-144: Verify the significant climber position changes are tested and safe.The climber state positions have changed substantially:
- New BREAK_ZIP_TIE state at -0.35 rotations
- PREPARE_FOR_CLIMB changed from 3 to 0 rotations
- CLIMB changed from 0 to -1.3 rotations
These changes represent significant alterations to the climber's mechanical behavior. Ensure these positions have been tested for:
- Correct direction of motion
- Safe limits (no collisions with robot frame or other mechanisms)
- Proper sequencing with the new BREAK_ZIP_TIE state
src/main/java/frc/trigon/robot/subsystems/intake/IntakeConstants.java (3)
78-78: Sim supplier logic LGTM.1 cm when holding coral at intake and 1000 otherwise matches the 35 cm threshold semantics in sim.
192-195: Good: sensor sim + scaling wired.Simulation supplier enabled and scaling constants set; simulation path respects unscaled values per SimpleSensor.
198-201: Verify IntakeState -> angle remap.REST/EJECT now at MAXIMUM_ANGLE (0°), OPEN_REST/COLLECT at MINIMUM_ANGLE (−127°). Confirm direction conventions and that downstream atState() logic (e.g., SimulationFieldHandler) matches the new mapping.
src/main/java/frc/trigon/robot/subsystems/transporter/Transporter.java (2)
45-48: Updated log key is fine.AutoLogOutput path change to Transporter/TransporterHasCoral is non‑breaking.
50-53: Public setTargetState is reasonable.Exposing the enum‑based setter aligns with new command flows.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
88-92: Default command refactor LGTM.ContinuousConditionalCommand keeps REST_WITH_CORAL vs REST behavior concise.
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (3)
52-53: Cleaner floor flow.Racing initiation with WaitUntil(hasGamePiece).andThen(0.1s) is a neat simplification.
127-132: Processor scoring path LGTM.Arm set‑state + gated ejection + drive resume in finallyDo works.
188-199: Good: lollipop toggle resets.finallyDo clears SHOULD_COLLECT_FROM_LOLLIPOP to avoid sticky state.
src/main/java/frc/trigon/robot/RobotContainer.java (4)
42-45: Camera swap: verify extrinsics and pipeline.Switching to FRONT_REEF_TAG_CAMERA changes transform and view; re‑validate pose estimator covariances and tag visibility.
83-85: Restored safe defaults LGTM.Using getDefaultCommand() for climber and end effector brings back predictable idle behavior.
116-119: New coral toggles look fine.Side‑effects in GeneralCommands are simple and idempotent.
165-172: Auto chooser additions LGTM.New floor auto variants by clock positions are well‑formed.
| RIGHT_SERVO_CHANNEL = 0, | ||
| LEFT_SERVO_CHANNEL = 1; |
There was a problem hiding this comment.
🧩 Analysis chain
Verify servo channels don't conflict with other hardware.
The servo channels have been reassigned (RIGHT: 1→0, LEFT: 2→1). Ensure channels 0 and 1 are not used by other PWM devices in the robot to avoid hardware conflicts.
🏁 Script executed:
#!/bin/bash
# Description: Search for other PWM channel assignments that might conflict with channels 0 and 1.
# Search for PWM/Servo channel assignments
rg -n --type=java -C3 'CHANNEL\s*=\s*[01]\b' -g '!**/ClimberConstants.java'Length of output: 148
🏁 Script executed:
#!/bin/bash
# Search for any other *_CHANNEL constants assigned to 0 or 1, excluding ClimberConstants.java
rg -nP '\b[A-Z0-9_]+_CHANNEL\s*=\s*[01]\b' -C3 -g '!src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java'Length of output: 148
🏁 Script executed:
#!/bin/bash
# Broad search for any other channel constants assigned to 0 or 1 in Java files
rg -nP '\b[A-Z0-9_]+_CHANNEL\s*=\s*[01]\b' -C3 --type javaLength of output: 2625
Fix conflicting PWM channels
The servo channels (RIGHT_SERVO_CHANNEL = 0, LEFT_SERVO_CHANNEL = 1) conflict with DISTANCE_SENSOR_CHANNEL (0) in EndEffectorConstants.java and BEAM_BREAK_CHANNEL (1) in TransporterConstants.java. Reassign servos to unused PWM ports.
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/climber/ClimberConstants.java
around lines 25-26, the RIGHT_SERVO_CHANNEL and LEFT_SERVO_CHANNEL are set to 0
and 1 which conflict with EndEffectorConstants.DISTANCE_SENSOR_CHANNEL (0) and
TransporterConstants.BEAM_BREAK_CHANNEL (1); change the servo channel
assignments to unused PWM ports (e.g., RIGHT_SERVO_CHANNEL = 2 and
LEFT_SERVO_CHANNEL = 3) so they no longer overlap with those sensors.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (7)
src/main/java/frc/trigon/robot/subsystems/swerve/SwerveConstants.java (1)
104-106: This issue was previously flagged: Fix inconsistent units for gyro mount pose configuration.The inconsistency in the gyro mount pose configuration (Line 104 uses
degreesToRotations()while Lines 105-106 usedegreesToRadians()) was already identified in a previous review. This critical issue must be addressed to ensure correct gyro orientation compensation.src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (2)
99-100: Refactor approved in previous review.This change has already been reviewed and approved. The use of
assistMode.isAlternateinstead of direct enum comparison is a good refactor that centralizes alternate mode logic.
145-146: Refactor approved in previous review.This change has already been reviewed and approved. The use of
assistMode.isAlternatefor theta power calculation is consistent with the translation power refactor.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (4)
68-73: Fix SysId elevator logging units.The elevator SysId logging still passes raw rotations and rotor velocity to
linearPositionandlinearVelocity, which expect meters and meters/second. This will produce incorrect characterization data.Apply this diff to convert units properly:
if (SHOULD_CALIBRATE_ELEVATOR) { + final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations()); + final double elevatorVelocityMetersPerSecond = rotationsToMeters( + elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO + ); log.motor("Elevator") - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) - .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) + .linearPosition(Units.Meters.of(elevatorPositionMeters)) + .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond)) .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); return; }
75-78: Use primary sensor velocity, not rotor velocity division.Since the arm motor uses
FeedbackSensorSource = RemoteCANcoderwithRotorToSensorRatio = ARM_GEAR_RATIO, theVELOCITYsignal already returns arm rotations per second. DividingROTOR_VELOCITYby the gear ratio is incorrect.Apply this diff:
log.motor("Arm") - .angularPosition(Units.Rotations.of(armMasterMotor.getSignal(TalonFXSignal.POSITION))) - .angularVelocity(Units.RotationsPerSecond.of(armMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ARM_GEAR_RATIO)) + .angularPosition(Units.Rotations.of(getCurrentArmAngle().getRotations())) + .angularVelocity(Units.RotationsPerSecond.of(armMasterMotor.getSignal(TalonFXSignal.VELOCITY))) .voltage(Units.Volts.of(armMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE)));
68-73: Elevator SysId logging units still incorrect.The elevator SysId logging still passes raw rotations to
linearPosition(line 70) and unconverted rotor velocity tolinearVelocity(line 71), but these methods expect meters and meters/second respectively. This will produce incorrect SysId characterization data.Convert to proper units before logging:
if (SHOULD_CALIBRATE_ELEVATOR) { + final double elevatorPositionMeters = rotationsToMeters(getElevatorPositionRotations()); + final double elevatorVelocityMetersPerSecond = rotationsToMeters( + elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO + ); log.motor("Elevator") - .linearPosition(Units.Meters.of(getElevatorPositionRotations())) - .linearVelocity(Units.MetersPerSecond.of(elevatorMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ELEVATOR_GEAR_RATIO)) + .linearPosition(Units.Meters.of(elevatorPositionMeters)) + .linearVelocity(Units.MetersPerSecond.of(elevatorVelocityMetersPerSecond)) .voltage(Units.Volts.of(elevatorMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE))); return; }
76-77: Use primary sensor velocity instead of rotor velocity.Since the arm motor is configured with
FeedbackSensorSource = RemoteCANcoderandRotorToSensorRatio = ARM_GEAR_RATIO, theVELOCITYsignal already returns arm rotations per second. UsingROTOR_VELOCITY / ARM_GEAR_RATIOis redundant and potentially incorrect.Apply this diff:
log.motor("Arm") .angularPosition(Units.Rotations.of(armMasterMotor.getSignal(TalonFXSignal.POSITION))) - .angularVelocity(Units.RotationsPerSecond.of(armMasterMotor.getSignal(TalonFXSignal.ROTOR_VELOCITY) / ArmElevatorConstants.ARM_GEAR_RATIO)) + .angularVelocity(Units.RotationsPerSecond.of(armMasterMotor.getSignal(TalonFXSignal.VELOCITY))) .voltage(Units.Volts.of(armMasterMotor.getSignal(TalonFXSignal.MOTOR_VOLTAGE)));Based on learnings.
🧹 Nitpick comments (8)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
40-52: Consider using a method reference for consistency.The command structure is correct and the
.until()termination condition properly addresses the previous review concern. However, line 49 uses an empty lambda() -> {}whereRobotContainer.ARM_ELEVATOR::stopwould be more consistent with the codebase style (see line 44).Apply this diff for consistency:
new ExecuteEndCommand( () -> RobotContainer.ARM_ELEVATOR.setElevatorVoltage(-OperatorConstants.DRIVER_CONTROLLER.getRightY() * 2), - () -> {}, + RobotContainer.ARM_ELEVATOR::stop, RobotContainer.ARM_ELEVATORsrc/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (2)
19-19: Remove unused AutoLogOutput import.Delete the
import org.littletonrobotics.junction.AutoLogOutput;from CoralPlacingCommands.java since it’s not used.
19-19: Remove unused import.The
AutoLogOutputimport is not used in this file.Apply this diff:
-import org.littletonrobotics.junction.AutoLogOutput;src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java (2)
76-78: Consider more descriptive naming.The method and parameter names could be more explicit to improve readability.
Apply this diff to improve naming:
- private void setCur(double cur) { - endEffectorMotor.setControl(new TorqueCurrentFOC(cur).withMaxAbsDutyCycle(0.6)); + private void setTargetCurrent(double targetCurrentAmps) { + endEffectorMotor.setControl(new TorqueCurrentFOC(targetCurrentAmps).withMaxAbsDutyCycle(0.6)); }Then update the call site on line 66:
- setCur(targetState.targetVoltage); + setTargetCurrent(targetState.targetVoltage);
64-70: Clarify the naming: targetVoltage used for current value.The conditional logic correctly routes
HOLD_ALGAEto current control. However, theEndEffectorState.targetVoltagefield is confusing sinceHOLD_ALGAE(-50)now represents -50 amps of current, not voltage.Consider one of these approaches:
Option 1: Rename the field to reflect dual usage:
public enum EndEffectorState { // ... states - public final double targetVoltage; + public final double targetValue; // Voltage for most states, current for HOLD_ALGAE - EndEffectorState(double targetVoltage) { - this.targetVoltage = targetVoltage; + EndEffectorState(double targetValue) { + this.targetValue = targetValue; } }Option 2: Add explicit documentation:
public final double targetVoltage; // Voltage in V, except HOLD_ALGAE uses this as current in Asrc/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (1)
119-125: Fix typo in method names.Both new autonomous scoring methods have a typo: "Atonomously" should be "Autonomously".
Apply this diff:
- private static Command getAutonomouslyScoreInNetCommand() { + private static Command getAutonomouslyScoreInNetCommand() { - private static Command getAtonomouslyScoreInProcessorCommand() { + private static Command getAutonomouslyScoreInProcessorCommand() {Also applies to: 134-140
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (1)
228-241: Clarify and parameterize low‐arm recovery logic
- Extract the hard-coded
-80°threshold and-0.25output into well-named constants (e.g.LOW_ARM_ANGLE_THRESHOLD,RECOVERY_OUTPUT) with Javadoc explaining the choice.- If using percent-output, ensure voltage-compensation is enabled or consider closed-loop control for consistent behavior across battery states.
- Document how this branch interacts with the default command to avoid command conflicts.
[src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java:231–234]src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
50-53: Document the sensor model for maintainability.The scaling constants (slope=0.0002, intercept=-200) are sensor-specific. Consider adding a comment documenting the sensor model/part number for future reference and maintenance.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java(5 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java(5 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java(4 hunks)src/main/java/frc/trigon/robot/constants/AutonomousConstants.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java(11 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/climber/ClimberCommands.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(6 hunks)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java(2 hunks)src/main/java/frc/trigon/robot/subsystems/swerve/SwerveConstants.java(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java
- src/main/java/frc/trigon/robot/subsystems/climber/ClimberCommands.java
- src/main/java/frc/trigon/robot/constants/AutonomousConstants.java
👮 Files not reviewed due to content moderation or server errors (2)
- src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java
- src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java
🧬 Code graph analysis (8)
src/main/java/frc/trigon/robot/subsystems/swerve/SwerveConstants.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (5)
src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/swerve/SwerveCommands.java (1)
SwerveCommands(15-163)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(25-366)
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java (1)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(19-109)
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (6)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(19-109)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(17-94)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (4)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(25-366)src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
CoralPlacingCommands(21-252)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (3)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/misc/simplesensor/SimpleSensor.java (1)
SimpleSensor(16-139)src/main/java/frc/trigon/robot/misc/simulatedfield/SimulationFieldHandler.java (1)
SimulationFieldHandler(18-213)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (3)
src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)
🪛 Gitleaks (8.28.0)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java
[high] 38-38: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (94)
src/main/java/frc/trigon/robot/subsystems/swerve/SwerveConstants.java (5)
31-34: LGTM!The steer encoder offsets have been updated with calibrated values. These calibration constants are essential for proper module alignment.
36-39: LGTM!The wheel diameter has been refined from 0.1 to 0.1016 meters (approximately 4 inches), which is a typical size for swerve modules. This precision adjustment will improve odometry accuracy.
64-64: LGTM!The translation kP has been increased from 5 to 6.3 for the physical robot, which is a reasonable tuning adjustment to improve position tracking performance.
67-67: LGTM!The rotation PID constants have been retuned (kP: 13→10, kD: 0.25→0.1), likely to improve stability and reduce overshoot in rotational control.
98-99: LGTM!Adding translation PID tolerances of 0.02 meters (20mm) for both X and Y axes is a good practice. This helps the controller determine when it has reached the target position within acceptable bounds.
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (5)
118-124: LGTM!The method signature correctly accepts
AssistModeand uses per-axis enablement flags (shouldAssistX,shouldAssistY) to conditionally apply alternate power calculations. This aligns with the centralized alternate mode approach.
154-155: Verify removal of scalar is intentional.The signature changed from
(pidOutput, pidScalar, joystickPower)to(pidOutput, joystickPower), removing the scalar parameter. The calculation now uses:pidOutput * (1 - Math.abs(joystickPower)) + joystickPowerThis means alternate assist modes no longer scale the PID output by
intakeAssistScalar, while normal assist modes still do (line 159). This behavior difference should be intentional—alternate modes now provide full PID correction that scales down only with joystick input, not with the configurable scalar.Please confirm this is the intended behavior. If so, consider documenting this difference in the
AssistModeenum Javadoc to clarify that alternate modes ignore the intake assist scalar.
175-191: Good addition of ALTERNATE_ALIGN mode.The new
ALTERNATE_ALIGNmode is well-structured and provides an alternate alignment option that assists Y and theta but not X, which is useful for partial assist scenarios. The consistent use of theisAlternateparameter (true for both ALTERNATE_ASSIST and ALTERNATE_ALIGN) properly routes to the alternate calculation path.
193-204: LGTM!The AssistMode enum expansion is clean and maintainable. The addition of the
isAlternatefield with updated constructor properly supports the new routing logic. All existing constants have been updated with the new parameter, maintaining backward compatibility.
26-32: Verify PID tuning validated
No tests or comments were found confirming these new PID parameters. Ensure they’ve been validated in simulation and on hardware before merging.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (4)
7-9: LGTM!The new imports are necessary for the updated command implementations.
88-88: LGTM!The refactoring to use
GeneralCommands.getContinuousConditionalCommandmaintains the same behavior while improving code consistency.
40-52: LGTM! Manual elevator reset sequence is well-structured.The two-step sequence properly handles the calibration workflow:
- Automatically moves to ZERO_ELEVATOR state (terminates via
.until())- Allows manual voltage control via joystick until operator releases the trigger
- Resets elevator position on completion via
finallyDoThis implementation correctly addresses the previous concern about command termination.
88-88: LGTM! Refactored to use helper method.Extracting the continuous conditional command logic into
GeneralCommands.getContinuousConditionalCommandimproves code reuse and maintainability.src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (10)
25-30: LGTM!The
hasCoral()guard properly prevents scoring attempts when no coral is present, and the conditional logic correctly routes between autonomous and manual scoring based on the configuration and level selection.
33-41: LGTM!The addition of
CONTINUE_TRIGGERto the wait condition provides a useful manual override for autonomous scoring, improving operator control.
43-52: LGTM!Loading coral before the manual scoring sequence ensures the robot is in the correct state, and the
CONTINUE_TRIGGERwait gives the operator control over timing.
54-65: LGTM!The sequential loading of coral before preparing the arm is consistent with the manual scoring flow and ensures proper state management.
151-157: Confirm Logic Change in isPrepareArmAngleAboveCurrentArmAngle
The removal of thearmAtAngle(...)check now only gatesgetPrepareArmElevatorIfWontHitReef, potentially allowing the prepare command to run before the arm reaches its target angle and risking reef collisions. Verify this change is intentional and safe.
26-30: LGTM! Improved scoring flow with proper guard.The refactored structure now:
- Properly guards against scoring without coral via
hasCoral()check- Cleanly separates autonomous vs. manual scoring paths
- The
hasCoral()guard already excludes the algae edge case (verified in CoralCollectionCommands.java:64)
35-35: LGTM! Operator override improves safety.Adding
OperatorConstants.CONTINUE_TRIGGER.getAsBoolean()allows the operator to manually override and continue scoring even when autonomous logic indicates the robot isn't ready. This is a good safety feature.
45-46: LGTM! Coral loading now happens before arm preparation.Loading coral before preparing the arm ensures the game piece is secured before moving to scoring position. This is consistent across both manual (lines 45-46) and autonomous (lines 56-58) scoring paths.
Also applies to: 56-58
156-156: LGTM! Simplified logic removes confusing condition.Removing the
armAtAngle(targetAngle)check makes the method behavior match its name. Previously checking both "above angle" AND "at angle" was contradictory—the arm can't be simultaneously above and at a specific angle.
160-160: LGTM! Custom tolerance allows looser ready check.Passing tolerance value
4(degrees) toatState()makes the autonomous scoring readiness check less strict, allowing the robot to proceed when close enough to the target state rather than requiring exact positioning.src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (9)
48-61: LGTM!The
raceWithpattern with a 0.15-second delay after game piece detection ensures the collection mechanism has time to fully secure the algae before proceeding, improving reliability.
63-75: LGTM!The reef algae collection follows the same improved pattern as floor collection, with a slightly shorter 0.1-second delay that's appropriate for reef collection timing.
112-125: LGTM!The separation of manual and autonomous net scoring commands is clear and well-structured. The manual version provides operator control via
CONTINUE_TRIGGER, while the autonomous version appropriately includes the drive command.
127-140: LGTM!The processor scoring commands follow the same pattern as net scoring, maintaining consistency. The
finallyDohook that schedules the field-relative drive command ensures the robot returns to manual control after scoring completes.
188-199: LGTM!The
finallyDocleanup properly resets theSHOULD_COLLECT_FROM_LOLLIPOPflag, ensuring consistent state management regardless of how the command terminates.
52-52: LGTM! Debounce delays prevent premature continuation.Adding short delays (0.15s for floor, 0.1s for reef) after game piece detection ensures the sensor reading is stable before proceeding with the collection sequence.
Also applies to: 67-67
113-117: LGTM! Manual net scoring now uses race pattern.The refactored
ParallelRaceGroupcleanly separates manual scoring (without autonomous drive) from the autonomous variant. The race pattern allows the operator to control when to release the algae via the CONTINUE_TRIGGER.
128-132: LGTM! Processor scoring simplified and consistent.Using
ArmElevatorCommands.getSetTargetStateCommandfor SCORE_PROCESSOR state provides a cleaner implementation, and scheduling field-relative drive infinallyDoensures proper cleanup.
198-198: LGTM! Proper cleanup of collection mode flag.Adding
finallyDoto resetSHOULD_COLLECT_FROM_LOLLIPOPensures the flag is cleared when the command ends, preventing state from leaking across command invocations.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevator.java (25)
22-22: LGTM!The
SHOULD_CALIBRATE_ELEVATORflag provides a clean way to switch between arm and elevator SysId characterization modes.
34-39: LGTM!Renaming to
elevatorPositionRequestimproves code clarity by distinguishing it fromarmPositionRequest.
53-58: LGTM!Applying brake mode to the follower motors ensures all motors in the arm/elevator subsystem maintain a consistent brake state, improving overall system behavior.
82-95: LGTM!The mechanism updates properly incorporate the
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETfor both the current position and closed-loop reference, ensuring accurate visualization.
110-116: LGTM!The conditional routing of SysId voltage correctly targets either the elevator or arm based on the calibration mode.
118-120: LGTM!The
resetElevatorPosition()method provides a clean public API for resetting the elevator encoder, as used by the reset command inArmElevatorCommands.
139-151: LGTM with note on semantic change.The new
atStateoverload with a tolerance parameter provides useful flexibility. The switch fromsubtractFrom360DegreestosubtractFrom180Degrees(line 142) changes the flipping behavior from vertical (around 0°) to horizontal (around 180°), which aligns with the physical arm geometry.
158-161: LGTM!The tolerance parameter overload provides flexibility for different precision requirements in various command contexts.
163-165: LGTM!Making the 4-degree tolerance explicit improves code clarity and makes the threshold easier to tune if needed.
172-174: LGTM!Applying
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETto the encoder reading ensures the arm angle is correctly referenced to the gravity-aligned coordinate system.
214-245: LGTM!The refactored arm control logic properly handles:
- Speed scaling based on state
- Reversed state angle calculations using
subtractFrom180Degrees- Collision prevention when elevator is low and arm is below -80°
- Safe angle constraints with proper offset handling
The new
sendControlToArmhelper correctly subtracts the offset when sending position commands to the motor.
255-272: LGTM!The safe angle and height calculations properly account for the arm's coordinate system with 90-degree offsets. Based on learnings, the system design intentionally bypasses
isArmAboveSafeAngle()logic for angles above 90 degrees.
278-280: LGTM!The
subtractFrom180Degreeshelper correctly implements horizontal flipping (around 180°) for reversed arm states, replacing the previous vertical flip logic.
282-288: LGTM!The visualization pose correctly adds π/2 to the arm angle to align with the coordinate system used for 3D visualization.
290-304: LGTM!The speed scaling helpers and voltage control method provide clean abstractions for dynamic motion parameter adjustment based on target state requirements.
22-22: LGTM! SysId calibration mode toggle.The
SHOULD_CALIBRATE_ELEVATORflag cleanly separates elevator vs. arm characterization, allowing you to switch between calibrating each mechanism independently by changing a single constant.Also applies to: 49-49, 68-74, 111-116
55-57: LGTM! Brake mode now applied to follower motors.Ensuring follower motors match the master brake mode prevents inconsistent behavior during braking.
118-120: LGTM! Elevator position reset method.This public method allows the reset command to zero the elevator encoder position after manual calibration, completing the reset workflow.
142-143: LGTM! Changed angle flip from 360° to 180° reflection.Switching from
subtractFrom360DegreestosubtractFrom180Degreesimplements a mirror reflection around 180° rather than a full rotation complement. For example:
- 45° → 135° (instead of 315°)
- 90° → 90° (instead of 270°)
This keeps reversed angles in the [0°, 180°] range, which better matches the physical arm constraints.
Also applies to: 215-217, 278-280
146-151: LGTM! Tolerance parameter overloads improve flexibility.The new
atStateandarmAtAngleoverloads with custom tolerance parameters allow autonomous scoring commands to use looser checks (e.g., 4° tolerance) while maintaining strict tolerances elsewhere.Also applies to: 158-161
164-164: LGTM! Arm angle check now includes 4° tolerance.Changing from
< 0to< 4makes the "above angle" check more lenient, allowing the arm to be considered "above" the target when within 4 degrees. This prevents tight coupling issues in autonomous sequences.
173-173: LGTM! Consistent offset handling throughout.Adding
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETconsistently across:
- Encoder reading (line 173)
- Mechanism visualization (lines 84-85)
- Control output (line 244, subtracted to cancel offset)
ensures the offset is properly accounted for in all arm angle calculations.
Also applies to: 84-85, 244-244
260-261: LGTM! Coordinate system adjustments for 90° offset.The 90° offsets in:
- Safe angle calculation (line 261:
minus(Rotation2d.kCCW_90deg))- Elevator height calculation (line 265:
plus(Rotation2d.kCCW_90deg))- Visualization pose (line 285:
+ Math.PI / 2)indicate a coordinate system change where the arm's zero position has shifted relative to the previous implementation. These adjustments appear consistent across calculations.
Also applies to: 265-265, 285-285
290-294: LGTM! Speed scaling enables state-specific motion profiles.Extracting speed scaling into separate methods allows different arm/elevator states to move at different speeds by adjusting velocity, acceleration, and jerk proportionally via the
speedScalarfield in eachArmElevatorState.Also applies to: 296-300
302-304: LGTM! Direct voltage control for manual reset.This method provides direct voltage control of the elevator motor, used by the reset command to allow operators to manually drive the elevator to the mechanical bottom before zeroing the encoder.
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java (13)
61-61: Verify the ejecting threshold through testing.The voltage threshold for determining ejection state was lowered from >2 to >1. This makes the detection more sensitive and should be validated to ensure it correctly identifies ejecting behavior without false positives during other operations.
64-70: Current control for HOLD_ALGAE is appropriate.The switch to current control (TorqueCurrentFOC) specifically for HOLD_ALGAE provides better grip control compared to voltage control. The conditional logic is clear and correct.
38-38: Confirm external dashboards after rename
No references toEndEffector/HasCoralwere found in this repo—ensure any external dashboards, telemetry tools, or log‐analysis scripts still pointing to the old key are updated.
3-3: LGTM!The import is necessary for the new current control functionality in
setCur().
35-35: LGTM!Logging the distance sensor value in centimeters provides useful telemetry.
38-38: LGTM!The renamed logging key provides better clarity and consistency with other log entries.
Note: The static analysis warning about a "Generic API Key" is a false positive—this is just a logging key string.
61-61: Verify the ejecting threshold change.The threshold was lowered from >2 to >1 volts, making ejection detection more sensitive. Ensure this tuning change doesn't cause false positives during normal operation.
76-78: Current control implementation is sound, but verify the value.The
TorqueCurrentFOCimplementation withmaxAbsDutyCycle(0.6)is correct. However, ensure the current value passed to this method is safe (see concern raised in lines 64-70 about HOLD_ALGAE using -50 amps).
3-3: LGTM! TorqueCurrentFOC import and implementation.The addition of
TorqueCurrentFOCcontrol for theHOLD_ALGAEstate is appropriate for maintaining consistent holding force. ThemaxAbsDutyCycleof 0.6 provides a reasonable safety margin.Also applies to: 76-78
35-35: LGTM! Distance sensor logging.Logging the scaled sensor value in centimeters will be helpful for debugging game piece detection.
38-38: Ignore the false positive from static analysis.The static analysis tool flagged this line as containing a "Generic API Key", but this is a false positive. The string
"EndEffector/EndEffectorHasCoral"is simply a logging key for AdvantageKit, not a security credential.
61-61: Verify the ejecting threshold reduction is intentional.The ejecting voltage threshold was reduced from
> 2to> 1volts. Ensure this change has been tested and doesn't cause false positives in ejection detection during normal operation.
76-78: Verify HOLD_ALGAE current draw The HOLD_ALGAE state applies –50 A (62.5 % of the 80 A stator limit); ensure this value is necessary and has been validated under expected loads without overheating or damaging the motor.src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (23)
42-42: Simulation supplier correctly updated for duty cycle sensor.The simulation now returns 1 (game piece detected) or 10 (no game piece) instead of 1 or 0, which aligns with the duty cycle sensor's analog output behavior and the scaling/threshold logic.
22-22: Verify distance sensor wiring: DISTANCE_SENSOR_CHANNEL was changed from 4 to 0 (EndEffectorConstants.java:22); confirm the sensor is physically wired to channel 0.
26-27: Validate distance sensor change
- Ensure the digital sensor has been replaced with a duty-cycle sensor.
- Verify scaling constants produce correct distance readings.
- Test game-piece detection across the sensor’s operational range.
- Motor constructor’s addition of
RobotConstants.CANIVORE_NAMEis correct.
97-101: Validate retuned EndEffectorState values
- SCORE_CORAL: 4 V → 1.5 V (−62.5%)
- COLLECT_ALGAE: −4 V → −11 V (+175%)
- SCORE_ALGAE: 4 V → 10 V (+150%)
- HOLD_CORAL: 0 V → −0.5 V
- HOLD_ALGAE: −4 V → −50 A (current control)
Verify via testing that scoring, collection, and holding operate reliably and safely at these new levels.
70-71: Verify end effector motor configuration. No diff shown—confirm that switching NeutralMode to Coast and inverting to CounterClockwise_Positive in EndEffectorConstants was intentional, won’t cause game pieces to slip, and that rotation direction remains correct.
50-53: Verify and correct distance sensor scaling and threshold
- Confirm raw sensor output range from your duty-cycle sensor and recalculate the slope/intercept to map to centimetres.
- Validate the 5 cm detection threshold in EndEffectorConstants against real readings (IntakeConstants uses the same scaling with a 35 cm threshold).
9-9: LGTM!The import is necessary for referencing
RobotConstants.CANIVORE_NAMEin the motor initialization.
22-22: Verify sensor wiring matches the channel change.The distance sensor channel changed from 4 to 0. Ensure the physical sensor is wired to DIO channel 0, or this change won't function correctly.
26-26: LGTM!Adding the CANivore bus name improves clarity and ensures the motor is on the correct CAN bus.
27-27: Verify the sensor hardware matches the type change.The sensor initialization changed from digital to duty cycle. This is a fundamental change that requires:
- Different sensor hardware (duty cycle encoder/sensor instead of a digital proximity sensor)
- Physical replacement/rewiring if the hardware was previously digital
Ensure the correct sensor type is installed at channel 0.
42-42: LGTM!The simulation supplier now returns values (1 or 10) that align with the duty cycle sensor and scaling constants, where values <5 cm indicate game piece detection.
49-49: LGTM!The debounce time reduction from 0.2 to 0.16 seconds is a minor tuning adjustment that slightly speeds up detection response.
56-56: LGTM!The predicate correctly uses
getScaledValue()with the 5 cm threshold, which aligns with the duty cycle sensor type and scaling constants.
70-70: Verify the NeutralMode change doesn't affect game piece retention.Changing from
BraketoCoastmeans the motor will free-spin when unpowered rather than resist motion. Ensure this doesn't cause:
- Unintended game piece dropping
- Difficulty maintaining positions
- Unexpected back-driving during collisions
Test the behavior with actual game pieces to confirm it meets requirements.
88-88: LGTM!The scaling constants are correctly applied to the duty cycle sensor for distance calculation.
97-101: Verify EndEffectorState values with the inverted motor.Multiple state values were updated:
SCORE_CORAL: 4 → 1.5COLLECT_ALGAE: -4 → -11SCORE_ALGAE: 4 → 10HOLD_CORAL: -0.5HOLD_ALGAE: -50Given the motor inversion on line 71, verify that:
- The signs of these values are correct for the intended direction.
- The magnitudes produce the desired speeds/forces.
HOLD_ALGAE= -50 is safe when used as current (already flagged as critical in EndEffector.java).Test each state with actual hardware to confirm proper operation.
71-71: Confirm motor inversion aligns with EndEffectorState voltages.Inversion changed to CounterClockwise_Positive; verify that each
targetVoltageinEndEffectorStatestill drives the mechanism correctly (e.g., positive ejects/scores, negative loads/holds). Test on hardware to ensure intended behavior.
9-9: LGTM! CANivore name addition.The addition of
RobotConstants.CANIVORE_NAMEto the motor constructor properly specifies the CAN bus.Also applies to: 26-26
22-22: Verify sensor hardware migration from digital to duty cycle.The distance sensor changed from a digital sensor (binary) on channel 4 to a duty cycle sensor (analog) on channel 0. Ensure:
- The physical sensor is connected to DIO channel 0
- The sensor supports duty cycle output
- The wiring and hardware have been updated accordingly
Also applies to: 27-27
42-42: LGTM! Distance sensor scaling implementation.The duty cycle sensor scaling converts the raw sensor output to centimeters. The simulation supplier returns realistic distance values (1 cm when holding a game piece, 10 cm when empty), and the 5 cm detection threshold is reasonable.
Also applies to: 50-53, 56-56, 88-88
49-49: LGTM! Debounce time reduction.Reducing the debounce time from 0.2s to 0.16s (20% faster) will improve responsiveness of game piece detection.
70-71: Verify motor configuration changes are intentional.Two significant motor configuration changes:
- Neutral mode:
Brake→Coast- The motor will no longer actively brake when stopped, which could affect game piece holding stability.- Inversion:
Clockwise_Positive→CounterClockwise_Positive- This reverses the motor direction.Ensure these changes match the physical robot configuration and have been tested, especially the coast mode's impact on game piece control.
97-101: Verify tuned voltage/current values, especially HOLD_ALGAE.Multiple
EndEffectorStatevalues were updated:
SCORE_CORAL: 4V → 1.5V (reduced ejection speed)COLLECT_ALGAE: -4V → -11V (increased intake power)SCORE_ALGAE: 4V → 10V (increased ejection speed)HOLD_CORAL: implicitly 0V → -0.5V (light holding force)HOLD_ALGAE: -4V → -50A (now interpreted as current, not voltage)The
HOLD_ALGAEvalue of -50A is particularly concerning:
- It's 62.5% of the 80A stator current limit
- Such high sustained current could cause motor overheating
- The naming
targetVoltageis misleading since this is now currentConfirm these tuning values have been tested and validated, especially the high current for
HOLD_ALGAE.
| void setTargetState(EndEffectorConstants.EndEffectorState targetState) { | ||
| setEndEffectorTargetVoltage(targetState.targetVoltage); | ||
| if (targetState == EndEffectorConstants.EndEffectorState.HOLD_ALGAE) { | ||
| setCur(targetState.targetVoltage); | ||
| } else { | ||
| setEndEffectorTargetVoltage(targetState.targetVoltage); | ||
| } | ||
| } |
There was a problem hiding this comment.
Critical: Verify current value safety for HOLD_ALGAE.
The code routes HOLD_ALGAE to setCur(), which interprets targetVoltage as current. From EndEffectorConstants, HOLD_ALGAE.targetVoltage is -50, meaning this would command -50 amps. Even with maxAbsDutyCycle limited to 0.6, this could be unsafe or exceed motor/controller ratings.
Additionally, the naming is misleading: targetVoltage is being used as a current value in this path.
Recommendations:
- Verify that -50 amps is safe for the motor and controller.
- Consider separating voltage and current values in the enum, or use a lower current value specifically for HOLD_ALGAE.
- Consider renaming the field or adding documentation to clarify when it represents current vs. voltage.
🤖 Prompt for AI Agents
In src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java around
lines 64-70, the HOLD_ALGAE branch calls setCur() with
EndEffectorConstants.EndEffectorState.targetVoltage (currently -50), which
treats a voltage field as a current and would command -50A — change this so
HOLD_ALGAE uses an explicit current value: update the enum to provide separate
fields (e.g., targetVoltage and targetCurrent) or add a getter for holdCurrent,
set a safe hold current constant (or clamp the value to a verified safe range)
and call setCur(holdCurrent) instead; also rename or document the enum fields to
avoid mixing voltage/current semantics and ensure any chosen current is
validated against motor/controller specs.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (7)
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (1)
99-101: Nice centralization using isAlternateRouting alternate vs normal translation through a single branch improves maintainability as more modes arrive.
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
92-101: Large negative values for HOLD_ALGAE/HOLD_CORAL combined with EndEffector#setCur(-50) are unsafe.HOLD_ALGAE = -50 is used as current (A) in EndEffector#setCur. This risks commanding −50 A. Separate current from voltage and clamp to a verified safe range.
Suggested minimal change in EndEffector.java (see that file’s comment) and add an explicit constant here:
// Add in EndEffectorConstants (outside this hunk) public static final double HOLD_ALGAE_CURRENT_AMPS = -5; // example, set to verified safe valueThen use HOLD_ALGAE_CURRENT_AMPS in EndEffector#setCur.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (3)
163-166: Extract 70A magic number for arm break detection.Name the threshold constant for clarity and central tuning.
+ private static final double ARM_BREAKING_CURRENT_THRESHOLD_AMPS = 70; static final Trigger IS_BREAKING_ARM_EVENT = new Trigger( - () -> Math.abs(ARM_MASTER_MOTOR.getSignal(TalonFXSignal.STATOR_CURRENT)) > 70 + () -> Math.abs(ARM_MASTER_MOTOR.getSignal(TalonFXSignal.STATOR_CURRENT)) > ARM_BREAKING_CURRENT_THRESHOLD_AMPS ).debounce(0.1);
155-156: MAXIMUM_ARM_SAFE_ANGLE = 0° likely disables dynamic elevator safety.Setting to 0° causes isArmAboveSafeAngle() to trip at almost all forward poses, bypassing dynamic min-elevator calc. Revert to 90° or provide justification/tests.
- static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0); + static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(90);Based on learnings
206-211: Software limit switches are commented out.Without soft limits, a bug can hard‑stop the arm/elevator. Re‑enable with proper thresholds.
-// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270); -// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = Conversions.degreesToRotations(-270); + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(270) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET; + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(-90) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; -// -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = metersToRotations(MAXIMUM_ELEVATOR_HEIGHT_METERS);If intentionally disabled for bring‑up, add TODOs with owner/ticket and re‑enable before field use.
Also applies to: 266-271
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java (1)
64-79: Critical: HOLD_ALGAE uses enum targetVoltage as current (−50A).This calls setCur(targetVoltage) where HOLD_ALGAE.targetVoltage is −50, commanding −50 A. Unsafe and semantically confusing.
Apply this fix:
- if (targetState == EndEffectorConstants.EndEffectorState.HOLD_ALGAE) { - setCur(targetState.targetVoltage); - } else { + if (targetState == EndEffectorConstants.EndEffectorState.HOLD_ALGAE) { + setCur(EndEffectorConstants.HOLD_ALGAE_CURRENT_AMPS); // explicit, safe current + } else { setEndEffectorTargetVoltage(targetState.targetVoltage); }And add in EndEffectorConstants:
public static final double HOLD_ALGAE_CURRENT_AMPS = -5; // tune to safe valueOptionally clamp current in setCur:
- private void setCur(double cur) { - endEffectorMotor.setControl(new TorqueCurrentFOC(cur).withMaxAbsDutyCycle(0.6)); + private void setCur(double cur) { + double clamped = Math.max(-10, Math.min(10, cur)); // example clamp; tune based on specs + endEffectorMotor.setControl(new TorqueCurrentFOC(clamped).withMaxAbsDutyCycle(0.6)); }src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (1)
37-38: Empty reefClockPositions causes null scoring pose.The varargs parameter allows calling without positions (as confirmed in RobotContainer.java:169-170), resulting in:
- Command name ending in "0Branches" (line 38)
- Empty loop in
calculateClosestOpenScoringPose(line 161)- Null return on line 177, causing NullPointerException in downstream code
🧹 Nitpick comments (13)
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (5)
24-33: PID retune: add tolerances/telemetry and consider constants for constraintsGood real-robot retune. To ease future tuning:
- Set tolerances (position/velocity) on the ProfiledPIDControllers for atGoal checks and logging.
- Extract constraints and gains to named constants (per axis) for clarity and single-source tuning.
- Log setpoint, measurement, error, and output per controller.
118-126: Alternate per-axis blending looks good; consider deadband and final clamp
- Optional: apply a small deadband to joystickPower before blending to avoid tiny inputs suppressing PID help (e.g., MathUtil.applyDeadband).
- Optional: clamp xPower/yPower to [-1, 1] after blending to guard against rounding/accumulation.
154-156: Document the 1 − |joystick| blending rationaleThe math is sound and preserves joystick authority at high inputs. Add a brief comment to explain the absolute value choice for future readers.
162-167: Magic number for X setGoal; verify sign and extract to constant
- Verify that goal = -0.15 aligns with the sign of distanceFromTrackedGamePiece.getX() (given robot minus target earlier). If forward intake bias is intended, confirm the negative sign.
- Extract to a named constant (e.g., DEFAULT_X_OFFSET_GOAL_METERS) for clarity.
- X_PID_CONTROLLER.setGoal(-0.15); + // Slight standoff to nose-in while intaking; negative matches +X error sign convention + final double DEFAULT_X_OFFSET_GOAL_METERS = -0.15; + X_PID_CONTROLLER.setGoal(DEFAULT_X_OFFSET_GOAL_METERS);
176-193: AssistMode expansion: clarify docs and encapsulate fields
- ALTERNATE_ASSIST vs ALTERNATE_ALIGN have identical docstrings; clarify intended behavioral difference (X assist disabled for ALIGN).
- Consider exposing getters (isAlternate(), shouldAssistX/Y/Theta()) instead of public fields for future compatibility.
Also applies to: 197-205
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (4)
52-53: Race exit looks good; consider a small timeout guard.The race exits 0.1s after hasGamePiece. Add a short overall timeout (e.g., 3–5s) to prevent an indefinite wait on sensor failure.
- getInitiateFloorAlgaeCollectionCommand().raceWith(new WaitUntilCommand(RobotContainer.END_EFFECTOR::hasGamePiece).andThen(new WaitCommand(0.1))), + getInitiateFloorAlgaeCollectionCommand() + .withTimeout(5) + .raceWith(new WaitUntilCommand(RobotContainer.END_EFFECTOR::hasGamePiece).andThen(new WaitCommand(0.1))),
67-68: Mirror the same timeout guard for reef collection.Prevents hanging if the sensor never trips.
- getInitiateReefAlgaeCollectionCommand().raceWith(new WaitUntilCommand(RobotContainer.END_EFFECTOR::hasGamePiece).andThen(new WaitCommand(0.1))), + getInitiateReefAlgaeCollectionCommand() + .withTimeout(5) + .raceWith(new WaitUntilCommand(RobotContainer.END_EFFECTOR::hasGamePiece).andThen(new WaitCommand(0.1))),
127-132: Processor scoring: same termination concern and drive resume race.The ParallelCommandGroup won’t finish by itself; finallyDo will fire only on cancel. Add a “piece left” completion to improve flow determinism.
- return new ParallelCommandGroup( + return new ParallelCommandGroup( ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.SCORE_PROCESSOR), GeneralCommands.runWhen(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.SCORE_ALGAE), OperatorConstants.CONTINUE_TRIGGER) - ).finallyDo(GeneralCommands.getFieldRelativeDriveCommand()::schedule); + ) + .raceWith(new WaitUntilCommand(() -> !RobotContainer.END_EFFECTOR.hasGamePiece()).andThen(new WaitCommand(0.2))) + .finallyDo(GeneralCommands.getFieldRelativeDriveCommand()::schedule);
134-140: Typo in method name (“Atonomously”).Rename to getAutonomouslyScoreInProcessorCommand for consistency and discoverability.
- private static Command getAtonomouslyScoreInProcessorCommand() { + private static Command getAutonomouslyScoreInProcessorCommand() {Also update any call sites.
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
42-57: Collection detection now uses scaled distance; verify real‑world units.Threshold is 4 cm with slope 0.0002 and intercept −200. Please confirm calibration on‑robot so getScaledValue() reflects centimetres and the threshold is correct across tolerances.
Would you like a small calibration routine to sweep and log raw vs. scaled values for quick tuning?
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
43-57: Reset command relies on trigger hold to cancel; OK. Add joystick deadband/clamp.Parallel group won’t finish by itself (intended for whileTrue). Clamp elevator voltage and add a small deadband to avoid unintended motion.
- new ExecuteEndCommand( - () -> RobotContainer.ARM_ELEVATOR.setElevatorVoltage(OperatorConstants.DRIVER_CONTROLLER.getRightY() * 2), + new ExecuteEndCommand( + () -> { + double v = OperatorConstants.DRIVER_CONTROLLER.getRightY(); + v = Math.abs(v) < 0.08 ? 0 : v; // deadband + RobotContainer.ARM_ELEVATOR.setElevatorVoltage(Math.max(-2, Math.min(2, v * 2))); + }, () -> {}, RobotContainer.ARM_ELEVATOR ),src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (2)
102-110: LGTM with optional simplification.The parallel command structure correctly coordinates driving, intake, and arm movement. The until/unless conditions properly handle coral detection.
Optionally simplify the lambda on line 105:
- ArmElevatorCommands.getSetTargetStateCommand(() -> ArmElevatorConstants.ArmElevatorState.REST), + ArmElevatorCommands.getSetTargetStateCommand(ArmElevatorConstants.ArmElevatorState.REST),If
getSetTargetStateCommandaccepts a constant, remove the unnecessary supplier wrapper.
180-186: LGTM with optional retry limit.The conditional logic correctly switches between assisted driving and coral searching based on vision tracking. The 10-second timeout and
repeatedly()wrapper enable persistent collection attempts.If infinite retries are undesired, consider adding a max attempt limit:
).repeatedly().withTimeout(30) // or .until(() -> attemptCount > MAX_ATTEMPTS)This prevents indefinite loops if coral collection consistently fails.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java(6 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java(5 hunks)src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java(5 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/climber/ClimberCommands.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java(3 hunks)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java(6 hunks)src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/main/java/frc/trigon/robot/subsystems/intake/IntakeCommands.java
- src/main/java/frc/trigon/robot/subsystems/climber/ClimberCommands.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (7)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (5)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/subsystems/swerve/SwerveCommands.java (1)
SwerveCommands(15-163)
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (1)
src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java (1)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
EndEffectorConstants(19-109)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)src/main/java/lib/hardware/phoenix6/cancoder/CANcoderEncoder.java (1)
CANcoderEncoder(20-193)src/main/java/lib/hardware/phoenix6/talonfx/TalonFXMotor.java (1)
TalonFXMotor(20-209)
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (6)
src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (1)
ArmElevatorConstants(25-366)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(20-99)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (3)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/misc/simplesensor/SimpleSensor.java (1)
SimpleSensor(16-139)src/main/java/frc/trigon/robot/misc/simulatedfield/SimulationFieldHandler.java (1)
SimulationFieldHandler(18-213)
src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (5)
src/main/java/frc/trigon/robot/subsystems/swerve/SwerveCommands.java (1)
SwerveCommands(15-163)src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
CoralPlacingCommands(21-252)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/RobotContainer.java (1)
RobotContainer(40-179)src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (1)
IntakeAssistCommand(22-207)
🪛 Gitleaks (8.28.0)
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java
[high] 38-38: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (12)
src/main/java/frc/trigon/robot/commands/commandclasses/IntakeAssistCommand.java (1)
145-147: Theta path parity with isAlternateConsistent alternate/normal routing for theta. LGTM.
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java (1)
188-199: finallyDo resets SHOULD_COLLECT_FROM_LOLLIPOP.Good safeguard to exit lollipop mode post-collection.
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorConstants.java (1)
26-28: Switch to CANivore and duty‑cycle sensor looks consistent.CAN bus and sensor type updates align with project patterns; no issues.
src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffector.java (2)
59-62: Lowered ejecting threshold to >1V.Seems fine; confirm this still filters out hold voltages to avoid false positives.
34-36: New distance log key.Good observability addition.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
92-98: Default command switch to continuous conditional looks good.Cleaner than manual ConditionalCommand loop.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (2)
51-53: ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET simplifies to zero; verify intent.With ANGLE_ENCODER_GRAVITY_OFFSET = 0.347412109375 − 0.25, the computed offset becomes 0 on real robot. If that’s accidental, restore the measured/calibrated offset.
Suggested pattern:
// Example: document and compute from a named angle // private static final double ARM_HORIZONTAL_OFFSET_DEGREES = -23.56; // static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() ? 0 // : edu.wpi.first.math.util.Units.degreesToRotations(ARM_HORIZONTAL_OFFSET_DEGREES) - ANGLE_ENCODER_GRAVITY_OFFSET;As per past guidance. Based on learnings
323-349: State heights appear within limits now.SCORE_NET at 1.61 and SCORE_L4 at 1.5 are below MAXIMUM_ELEVATOR_HEIGHT_METERS (1.644). Good.
src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java (4)
5-6: LGTM!The new imports are required for the algae-avoidance transform logic added in lines 169-170.
41-46: LGTM!The signature change enables position-specific autonomous behavior. The method correctly forwards the reefClockPositions array to downstream commands.
48-57: Verify zero rotation power is intentional.Line 54 now uses a hardcoded
0for theta power instead of a constant. Ensure this change is intentional and that removing rotation during coral finding doesn't negatively impact the command's effectiveness.
86-100: LGTM!The two-phase driving approach is sound:
- Drive toward the "behind algae" pose (line 97) until the arm angle is ready
- Switch to the final scoring pose (line 98)
This ensures the robot avoids obstacles while preparing the mechanism.
| private static Command getScoreInNetCommand() { | ||
| return new ParallelRaceGroup( | ||
| GeneralCommands.getFlippableOverridableArmCommand(ArmElevatorConstants.ArmElevatorState.SCORE_NET, false, AlgaeManipulationCommands::shouldReverseNetScore), | ||
| GeneralCommands.runWhen(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.SCORE_ALGAE), OperatorConstants.CONTINUE_TRIGGER) | ||
| ); | ||
| } |
There was a problem hiding this comment.
Scoring race may never finish; add an ejection-complete condition.
Both subcommands are effectively non-terminating. Race will only end if externally canceled. Add a “piece left” condition to auto-finish.
- return new ParallelRaceGroup(
+ return new ParallelRaceGroup(
GeneralCommands.getFlippableOverridableArmCommand(ArmElevatorConstants.ArmElevatorState.SCORE_NET, false, AlgaeManipulationCommands::shouldReverseNetScore),
GeneralCommands.runWhen(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.SCORE_ALGAE), OperatorConstants.CONTINUE_TRIGGER)
- );
+ )
+ .raceWith(new WaitUntilCommand(() -> !RobotContainer.END_EFFECTOR.hasGamePiece()).andThen(new WaitCommand(0.2)));📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| private static Command getScoreInNetCommand() { | |
| return new ParallelRaceGroup( | |
| GeneralCommands.getFlippableOverridableArmCommand(ArmElevatorConstants.ArmElevatorState.SCORE_NET, false, AlgaeManipulationCommands::shouldReverseNetScore), | |
| GeneralCommands.runWhen(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.SCORE_ALGAE), OperatorConstants.CONTINUE_TRIGGER) | |
| ); | |
| } | |
| private static Command getScoreInNetCommand() { | |
| return new ParallelRaceGroup( | |
| GeneralCommands.getFlippableOverridableArmCommand(ArmElevatorConstants.ArmElevatorState.SCORE_NET, false, AlgaeManipulationCommands::shouldReverseNetScore), | |
| GeneralCommands.runWhen(EndEffectorCommands.getSetTargetStateCommand(EndEffectorConstants.EndEffectorState.SCORE_ALGAE), OperatorConstants.CONTINUE_TRIGGER) | |
| ) | |
| .raceWith( | |
| new WaitUntilCommand(() -> !RobotContainer.END_EFFECTOR.hasGamePiece()) | |
| .andThen(new WaitCommand(0.2)) | |
| ); | |
| } |
🤖 Prompt for AI Agents
In
src/main/java/frc/trigon/robot/commands/commandfactories/AlgaeManipulationCommands.java
around lines 112 to 117, the ParallelRaceGroup created for getScoreInNetCommand
currently contains two long-running/non-terminating commands so the race can
never finish on its own; add a third terminating condition that completes the
race when the piece has been ejected (a “piece left” / ejection-complete check).
Implement this by adding a short-lived command or a
GeneralCommands.runWhen-style wrapper that watches the end-effector sensor/state
(e.g., a BooleanSupplier that returns false when no piece is present or a new
EndEffectorCommands.getWaitForPieceRemovedCommand()) and include it as another
entry in the ParallelRaceGroup so the group ends automatically when the piece is
detected as removed.
| public static FlippablePose2d calculateClosestOpenScoringPose(FieldConstants.ReefClockPosition[] reefClockPositions, boolean shouldStayBehindAlgae) { | ||
| final boolean[] scoredBranchesAtL4 = getScoredBranchesAtL4(); | ||
| final Pose2d currentRobotPose = RobotContainer.ROBOT_POSE_ESTIMATOR.getEstimatedRobotPose(); | ||
|
|
||
| double closestDistance = Double.POSITIVE_INFINITY; | ||
| Pose2d closestScoringPose = null; | ||
| for (FieldConstants.ReefClockPosition currentClockPosition : FieldConstants.ReefClockPosition.values()) { | ||
| for (FieldConstants.ReefClockPosition currentClockPosition : reefClockPositions) { | ||
| for (FieldConstants.ReefSide currentSide : FieldConstants.ReefSide.values()) { | ||
| if (scoredBranchesAtL4[currentClockPosition.ordinal() * 2 + currentSide.ordinal()]) | ||
| continue; | ||
| final Pose2d reefSideScoringPose = CoralPlacingCommands.ScoringLevel.L4.calculateTargetPlacingPosition(currentClockPosition, currentSide).get(); | ||
| final double distance = currentRobotPose.getTranslation().getDistance(reefSideScoringPose.getTranslation()); | ||
| if (distance < closestDistance) { | ||
| closestDistance = distance; | ||
| closestScoringPose = reefSideScoringPose; | ||
| if (shouldStayBehindAlgae) | ||
| closestScoringPose = reefSideScoringPose.transformBy(new Transform2d(new Translation2d(FieldConstants.REEF_CENTER_TO_TARGET_NO_HIT_REEF_POSITION_X_TRANSFORM_METERS - FieldConstants.REEF_CENTER_TO_TARGET_SCORING_POSITION_X_TRANSFORM_METERS, 0), new Rotation2d())); | ||
| else | ||
| closestScoringPose = reefSideScoringPose; | ||
| } | ||
| } | ||
| } | ||
|
|
||
| return closestScoringPose == null ? null : new FlippablePose2d(closestScoringPose, false); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Null return when reefClockPositions is empty.
If reefClockPositions is empty, the loop at line 161 doesn't execute, closestScoringPose remains null, and line 177 returns null. This causes NullPointerExceptions in calling code (lines 96, 97, 151).
Additionally, verify the transform calculation on line 170 produces the correct "behind algae" offset:
new Transform2d(new Translation2d(FieldConstants.REEF_CENTER_TO_TARGET_NO_HIT_REEF_POSITION_X_TRANSFORM_METERS - FieldConstants.REEF_CENTER_TO_TARGET_SCORING_POSITION_X_TRANSFORM_METERS, 0), new Rotation2d())Ensure this moves the robot back by the appropriate distance to avoid algae collision.
🏁 Script executed:
#!/bin/bash
echo "=== Callers of calculateClosestOpenScoringPose ==="
rg -n 'calculateClosestOpenScoringPose' -g '*.java' -C2
echo "=== Definitions of REEF constants ==="
rg -n 'REEF_CENTER_TO_TARGET_NO_HIT_REEF_POSITION_X_TRANSFORM_METERS' -g '*.java' -C3
rg -n 'REEF_CENTER_TO_TARGET_SCORING_POSITION_X_TRANSFORM_METERS' -g '*.java' -C3Length of output: 10499
Guard against empty reefClockPositions in calculateClosestOpenScoringPose.
If the input array is empty, the method returns null, causing the WaitUntilCommand to hang indefinitely and downstream SwerveCommands.getDriveToPoseCommand calls to NPE. Add a check at the top of the method (e.g., throw IllegalArgumentException or return a valid fallback) to ensure a non-null pose is always returned.
🤖 Prompt for AI Agents
In
src/main/java/frc/trigon/robot/commands/commandfactories/AutonomousCommands.java
around lines 155 to 178, the method calculateClosestOpenScoringPose does not
guard against an empty or null reefClockPositions array and can return null; add
an explicit check at the top that reefClockPositions is not null and has length
> 0 and if it is invalid throw an IllegalArgumentException with a clear message
(e.g., "reefClockPositions must be non-null and non-empty"), so the method never
returns null and callers cannot hit a silent NPE or cause WaitUntilCommand to
hang.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
19-19: Remove unused import.The
AutoLogOutputimport is not used anywhere in this file.-import org.littletonrobotics.junction.AutoLogOutput;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java(4 hunks)src/main/java/frc/trigon/robot/constants/FieldConstants.java(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (3)
src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)
🔇 Additional comments (8)
src/main/java/frc/trigon/robot/constants/FieldConstants.java (2)
31-34: LGTM! Field geometry tuning adjustments.The X-transform constants have been adjusted to fine-tune reef positioning:
- Scoring position moved 5 cm farther from reef center (1.3→1.35m)
- No-hit-reef offset reduced by 10 cm (0.3→0.2m relative offset)
These tuning changes align with the PR's broader geometry retuning objectives.
35-35: Verify the reduced safety distance doesn't cause collisions.The safety distance has been reduced by 32% (0.25m → 0.17m). Ensure this tighter clearance doesn't cause the robot to collide with the reef structure during scoring operations, especially under varying field conditions or tolerance stack-ups.
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (6)
26-30: LGTM! ConditionalCommand cleanly separates scoring modes.The refactor from
SequentialCommandGrouptoConditionalCommandproperly gates autonomous vs manual scoring based on the flag and level. The guard usingCoralCollectionCommands.hasCoral()now correctly excludes algae, addressing the previous review concern.
33-41: LGTM! Manual override improves operator control.The addition of
CONTINUE_TRIGGER.getAsBoolean()as an OR condition allows the operator to manually proceed when needed, improving flexibility during autonomous scoring.
43-52: LGTM! Coral loading sequenced before arm movement.Prepending
getLoadCoralCommand()ensures the end effector has coral before the arm moves to the scoring position, improving safety and consistency with the autonomous flow.
54-65: LGTM! Consistent coral loading sequence.Wrapping
getLoadCoralCommand()andgetPrepareArmElevatorIfWontHitReefin aSequentialCommandGroupmaintains the same safety guarantee as the manual scoring path—coral must be loaded before arm preparation begins.
151-157: Verify relaxed arm angle check is safe.Removing the
armAtAnglecheck means the condition now passes as soon as the arm is above the target angle, even if still moving toward it. This allows earlier transition to reef driving but could be unsafe if the arm hasn't stabilized.Confirm this change is intentional and that removing the "at angle" stability check doesn't create collision risks during the autonomous scoring sequence. The method is called from
getAutonomousDriveToNoHitReefPose(line 60) to gate when driving can begin.
159-162: LGTM! Tolerance parameter added.The additional parameter
4passed toatStatelikely specifies a tolerance value for the state check, making the readiness condition more explicit and tunable.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (5)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
25-31: Persistent edge case: hasCoral() guard still allows algae scoring.The past review identified that
hasCoral()could returntruewhen the transporter contains coral while the end effector holds algae. While the implementation in CoralCollectionCommands.java (line 64) was partially updated, the parentheses placement still allows this edge case:// Current implementation: (!AlgaeManipulationCommands.isHoldingAlgae() && RobotContainer.END_EFFECTOR.hasGamePiece()) || RobotContainer.TRANSPORTER.hasCoral(); // Should be: !AlgaeManipulationCommands.isHoldingAlgae() && (RobotContainer.END_EFFECTOR.hasGamePiece() || RobotContainer.TRANSPORTER.hasCoral());The current logic allows
TRANSPORTER.hasCoral()to bypass the algae check, potentially causing algae to be scored through the coral scoring sequence.As noted in the previous review, update CoralCollectionCommands.java line 64 to wrap both sensor checks in the algae condition.
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
155-155: Arm safe angle threshold at 0° still disables dynamic elevator safety.
MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0)causesisArmAboveSafeAngle()to return true for any angle ≥ 0°, bypassing the intended dynamic elevator-height safety calculation incalculateMinimumSafeElevatorHeightRotations(). This critical safety issue was flagged in previous reviews but remains unresolved.Restore the safe angle threshold:
- static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0); + static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(90);
163-166: Extract hardcoded current threshold as a named constant.The 70A stator current threshold is a magic number. Extract it as a named constant for clarity and maintainability.
+ private static final double ARM_BREAKING_CURRENT_THRESHOLD_AMPS = 70; + static final Trigger IS_BREAKING_ARM_EVENT = new Trigger( - () -> Math.abs(ARM_MASTER_MOTOR.getSignal(TalonFXSignal.STATOR_CURRENT)) > 70 + () -> Math.abs(ARM_MASTER_MOTOR.getSignal(TalonFXSignal.STATOR_CURRENT)) > ARM_BREAKING_CURRENT_THRESHOLD_AMPS ).debounce(0.1);
200-210: Commented-out velocity filter and software limits remain unaddressed.The velocity filter (line 200) and forward/reverse software limit switches (lines 206-210) are still commented out without explanation. This was flagged in previous reviews but remains unresolved. Without software limits, the arm could exceed mechanical bounds.
Either:
- Re-enable these safety controls with appropriate thresholds
- Add TODO comments explaining why they're disabled and when to re-enable them
- Remove the dead code if they're permanently disabled
Re-enabling example:
-// config.Feedback.VelocityFilterTimeConstant = 0.2; + config.Feedback.VelocityFilterTimeConstant = 0.2; -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270); -// -// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = Conversions.degreesToRotations(-270); + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(270) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET; + + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(-90) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;
266-270: Elevator software limits still disabled - safety hazard.The elevator software limits remain commented out despite being flagged in previous reviews. This is more critical than the arm limits as the elevator could crash into physical stops, potentially damaging the mechanism or causing safety hazards.
Strongly recommend re-enabling elevator limits:
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; -// -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = 0; + + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = metersToRotations(MAXIMUM_ELEVATOR_HEIGHT_METERS);If disabled for debugging, add a TODO comment and re-enable before competition.
🧹 Nitpick comments (4)
src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (1)
35-38: Consider addingfinaltoFOC_ENABLEDfor consistency.Lines 35, 37, and 38 now correctly use
private final staticfor immutable constants. However,FOC_ENABLEDon line 36 is declared asstatic finalwithout thefinalmodifier following the same pattern. For consistency and to clearly indicate immutability, consider updating line 36 to:- static final boolean FOC_ENABLED = true; + private static final boolean FOC_ENABLED = true;src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
160-163: Replace magic number with named constant.The hardcoded
4passed toatState()at line 161 appears to be a tolerance value but lacks documentation. This reduces code clarity and maintainability.Add a constant to clarify the tolerance value's purpose:
+private static final int SCORING_READINESS_TOLERANCE = 4; + private static boolean isReadyToScore(boolean shouldScoreRight) { - return RobotContainer.ARM_ELEVATOR.atState(REEF_CHOOSER.getArmElevatorState().prepareState, shouldReverseScore(), 4) + return RobotContainer.ARM_ELEVATOR.atState(REEF_CHOOSER.getArmElevatorState().prepareState, shouldReverseScore(), SCORING_READINESS_TOLERANCE) && RobotContainer.SWERVE.atPose(calculateClosestScoringPose(shouldScoreRight)); }src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (2)
51-52: Document the encoder offset calculation.The encoder offset uses unexplained magic numbers:
0.347412109375 - 0.25. Add inline comments explaining:
- What 0.347412109375 represents (encoder reading at what position?)
- Why 0.25 is subtracted
- The arm's intended zero position
This was marked as addressed in previous reviews but the code still lacks clear documentation.
- private static final double ANGLE_ENCODER_GRAVITY_OFFSET = 0.347412109375 - 0.25; - static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() ? 0 : 0.347412109375 - 0.25 - ANGLE_ENCODER_GRAVITY_OFFSET; + // Raw encoder reading at calibration position (rotations) + private static final double RAW_ENCODER_READING = 0.347412109375; + // Offset to align encoder zero to desired reference (rotations) + private static final double ENCODER_ALIGNMENT_OFFSET = 0.25; + // Encoder reading when arm is at gravity-down position + private static final double ANGLE_ENCODER_GRAVITY_OFFSET = RAW_ENCODER_READING - ENCODER_ALIGNMENT_OFFSET; + // Combined offset for arm position (simulation uses ideal zero, real robot applies physical offset) + static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() ? 0 : 0;
287-288: Consider removing commented setPosition call.Line 288 has a commented-out
setPosition(0)call. If this is no longer needed, remove it. If it should be enabled, uncomment it with justification.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java(5 hunks)src/main/java/frc/trigon/robot/constants/FieldConstants.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/frc/trigon/robot/constants/FieldConstants.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (2)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (5)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(20-115)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)src/main/java/frc/trigon/robot/subsystems/endeffector/EndEffectorCommands.java (1)
EndEffectorCommands(12-37)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (6)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)src/main/java/lib/hardware/phoenix6/cancoder/CANcoderEncoder.java (1)
CANcoderEncoder(20-193)src/main/java/lib/hardware/phoenix6/talonfx/TalonFXMotor.java (1)
TalonFXMotor(20-209)src/main/java/lib/hardware/simulation/ElevatorSimulation.java (1)
ElevatorSimulation(11-84)src/main/java/lib/hardware/simulation/SingleJointedArmSimulation.java (1)
SingleJointedArmSimulation(12-81)
🔇 Additional comments (19)
src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (3)
25-25: Verify the beam break sensor is connected to DIO channel 1.The beam break channel has been changed from 3 to 1. Ensure that the physical sensor wiring matches this new channel number to prevent runtime failures.
64-65: Verify the reduced pulse timing values.The pulse voltage application time has been reduced from 0.1s to 0.08s, and the pulse wait time from 0.05s to 0.03s. These shorter durations will result in faster pulsing, which could affect coral handling reliability. Ensure these timing values have been tested to confirm they provide consistent and reliable coral transportation.
106-109: Verify the motor direction reversals are intentional and tested.The right motor voltage directions have been reversed for
COLLECT,HOLD_CORAL, andEJECTstates:
COLLECT: right motor changed from 5V to -3.5V (reversed + magnitude reduced)HOLD_CORAL: right motor changed from 1V to -1V (reversed)EJECT: right motor changed from -5V to 5V (reversed)These direction reversals are critical as they fundamentally change the transporter's behavior. For example, if the motors were intended to spin in opposite directions before, they may now spin in the same direction, or vice versa. This could cause coral to be ejected when it should be collected, or held incorrectly.
Ensure that:
- These changes align with any hardware modifications (e.g., motor wiring changes)
- All transporter states have been tested to confirm coral is correctly collected, aligned, held, and ejected
- The behavior matches the intended design for each state
You can verify the motor behavior by running integration tests or manually testing each state on the robot.
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (6)
13-13: LGTM!The import is necessary for the
getStayInPlaceCommand()usage at line 84.
33-41: LGTM!The added
CONTINUE_TRIGGERcondition at line 35 provides a sensible manual override for operators to proceed with scoring even if not fully ready. This enhances operator control during autonomous scoring sequences.
43-52: LGTM!The refactored sequence properly ensures coral is loaded before attempting to score (line 45), preventing empty scoring attempts. The
CONTINUE_TRIGGERat line 46 gives operators manual control over timing.
54-65: LGTM!The sequential loading of coral before arm preparation (lines 56-58) ensures proper state progression during autonomous scoring. This mirrors the manual scoring flow and prevents arm preparation without coral.
81-87: LGTM!The switch to
getContinuousConditionalCommandwithgetStayInPlaceCommand()provides intelligent collision avoidance. The arm stays in place when below target angle and near the reef, preventing potential collisions while still allowing preparation when safe.
152-158: LGTM!Removing the
atStatecheck simplifies the logic to a pure position comparison. The method now correctly reflects its name by checking whether the arm is above the target angle, regardless of tolerance.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (10)
11-14: LGTM!The new imports support the breaking arm event trigger and centralized CANivore configuration.
39-43: LGTM!Centralizing the CANivore name through
RobotConstants.CANIVORE_NAMEimproves maintainability.
45-47: Verify gear ratios match physical hardware.The gear ratios have been updated (
ARM_GEAR_RATIO = 55.273,ELEVATOR_GEAR_RATIO = 4). Confirm these values match the actual mechanical configuration of the robot to ensure accurate motion control.
57-61: LGTM!The separation of simulation and real hardware motion profile values allows for accurate simulation tuning without affecting real robot behavior.
173-173: LGTM!The breaking arm event handler provides a safety mechanism to stop the motor when excessive current is detected, preventing potential damage.
189-196: LGTM!The PID tuning parameters are appropriately separated for simulation and real hardware, allowing for accurate control in both environments.
223-224: LGTM!Registering additional rotor signals provides useful telemetry for monitoring and debugging.
255-261: LGTM!The elevator PID tuning parameters are appropriately separated for simulation and real hardware.
312-314: Verify encoder configuration matches hardware.The sensor direction changed to
CounterClockwise_Positiveand discontinuity point is set to 0.5 rotations. Confirm these settings match the physical encoder mounting and desired behavior.
324-349: LGTM! State definitions are within limits.The completely rewritten
ArmElevatorStateenum defines comprehensive state transitions. All elevator heights are withinMAXIMUM_ELEVATOR_HEIGHT_METERS(1.644m), and all arm angles are within the defined range (-90° to 270°). The previous issues with SCORE_L4 exceeding limits have been resolved.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (11)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (10)
51-52: Document the encoder offset values.The encoder offset constants use magic values without explanation. Based on past review feedback, add concise inline comments documenting:
- How
ANGLE_ENCODER_GRAVITY_OFFSETwas measured (e.g., encoder reading at a specific arm position)- The purpose of
ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSETand why simulation uses zero- The intended zero/reference position for the arm
Apply this diff to add clarifying comments:
- private static final double ANGLE_ENCODER_GRAVITY_OFFSET = 0.347412109375 - 0.25; - static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() ? 0 : 0.347412109375 - 0.25 - ANGLE_ENCODER_GRAVITY_OFFSET; + // Encoder reading when arm is at a known reference position (gravity-down or horizontal) + private static final double ANGLE_ENCODER_GRAVITY_OFFSET = 0.347412109375 - 0.25; + // Offset applied on real robot to align arm zero position; simulation uses ideal zero + static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() ? 0 : 0.347412109375 - 0.25 - ANGLE_ENCODER_GRAVITY_OFFSET;
155-155: MAXIMUM_ARM_SAFE_ANGLE set to 0° disables dynamic elevator safety.
MAXIMUM_ARM_SAFE_ANGLEchanged from 90° to 0°, causingisArmAboveSafeAngle()to return true for nearly all forward arm positions. This bypasses the intended dynamic elevator-height safety calculation incalculateMinimumSafeElevatorHeightRotations()(ArmElevator.java:231–239), applying only the static minimum safe zone. Based on learnings, angles above 90° bypass this logic anyway, so setting it to 0° eliminates safety for the 0°-90° range.Revert to the original threshold:
- static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0); + static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(90);If 0° is intentional, add tests proving no safety regression and document the rationale.
163-165: Extract hardcoded current threshold as a named constant.The 70A stator current threshold for detecting arm damage is a magic number that should be extracted for clarity and maintainability.
Apply this diff:
+ private static final double ARM_BREAKING_CURRENT_THRESHOLD_AMPS = 70; + static final Trigger IS_BREAKING_ARM_EVENT = new Trigger( - () -> Math.abs(ARM_MASTER_MOTOR.getSignal(TalonFXSignal.STATOR_CURRENT)) > 70 + () -> Math.abs(ARM_MASTER_MOTOR.getSignal(TalonFXSignal.STATOR_CURRENT)) > ARM_BREAKING_CURRENT_THRESHOLD_AMPS ).debounce(0.1);
200-210: Commented-out velocity filter and arm software limits.Lines 200, 206-210 have disabled velocity filtering and forward/reverse software limits with no explanation. Without software limits, the arm could exceed mechanical bounds if commanded beyond the safe angle range.
Either:
- Re-enable these safety controls with appropriate thresholds
- Add TODO comments explaining why they're disabled and when to re-enable
- Remove the dead code if permanently disabled
If re-enabling, apply this diff:
-// config.Feedback.VelocityFilterTimeConstant = 0.2; + config.Feedback.VelocityFilterTimeConstant = 0.2; config.MotionMagic.MotionMagicCruiseVelocity = ARM_DEFAULT_MAXIMUM_VELOCITY; config.MotionMagic.MotionMagicAcceleration = ARM_DEFAULT_MAXIMUM_ACCELERATION; config.MotionMagic.MotionMagicJerk = config.MotionMagic.MotionMagicAcceleration * 10; -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270); - -// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = Conversions.degreesToRotations(-270); + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(270) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET; + + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(-90) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;
266-270: Elevator software limits disabled without explanation.Similar to the arm, elevator software limits are commented out. This is more concerning as the elevator could crash into physical stops, potentially damaging the mechanism or causing safety hazards.
Strongly recommend re-enabling elevator limits:
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; -// -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; + + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = metersToRotations(MAXIMUM_ELEVATOR_HEIGHT_METERS);If disabled for debugging, add a TODO comment and re-enable before competition.
51-52: Encoder offset values updated but remain undocumented.While the offset values have been updated, they still lack explanatory comments about how they were measured and what physical alignment they represent. This was previously flagged.
Add inline documentation:
+ // Encoder reading when arm is at gravity-down position (measured with arm hanging straight down) private static final double ANGLE_ENCODER_GRAVITY_OFFSET = 0.347412109375 - 0.25; + // Combined offset: accounts for difference between encoder zero and desired arm zero position + // Simulation uses ideal zero; real robot applies physical calibration offset static final double ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET = RobotHardwareStats.isSimulation() ? 0 : 0.347412109375 - 0.25 - ANGLE_ENCODER_GRAVITY_OFFSET;
163-165: Extract hardcoded 70A threshold as a named constant.The stator current threshold remains a magic number. This was previously flagged but not yet addressed.
Apply this diff:
+ private static final double ARM_BREAKING_CURRENT_THRESHOLD_AMPS = 70; + static final Trigger IS_BREAKING_ARM_EVENT = new Trigger( - () -> Math.abs(ARM_MASTER_MOTOR.getSignal(TalonFXSignal.STATOR_CURRENT)) > 70 + () -> Math.abs(ARM_MASTER_MOTOR.getSignal(TalonFXSignal.STATOR_CURRENT)) > ARM_BREAKING_CURRENT_THRESHOLD_AMPS ).debounce(0.1);
155-155: Critical: MAXIMUM_ARM_SAFE_ANGLE=0° disables dynamic elevator safety.This change was previously flagged as critical and remains unresolved. Setting
MAXIMUM_ARM_SAFE_ANGLEto 0° causesisArmAboveSafeAngle()to return true for virtually all forward arm angles, bypassing the intended dynamic elevator-height safety calculation incalculateMinimumSafeElevatorHeightRotations().Revert to 90°:
- static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(0); + static final Rotation2d MAXIMUM_ARM_SAFE_ANGLE = Rotation2d.fromDegrees(90);
200-200: Re-enable arm software limits or document why disabled.Velocity filter (line 200) and forward/reverse software limits (lines 206-210) remain commented out without explanation. This was previously flagged as a major issue.
Either re-enable these safety controls or add TODO comments with justification:
-// config.Feedback.VelocityFilterTimeConstant = 0.2; + config.Feedback.VelocityFilterTimeConstant = 0.2; -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = Conversions.degreesToRotations(270); - -// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = Conversions.degreesToRotations(-270); + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(270) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET; + + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = edu.wpi.first.math.util.Units.degreesToRotations(-90) - ARM_POSITION_OFFSET_FROM_GRAVITY_OFFSET;Also applies to: 206-210
266-270: Re-enable elevator software limits.Elevator software limits remain disabled. This is more concerning than the arm limits, as the elevator could crash into physical hard stops, causing mechanism damage.
Strongly recommend re-enabling:
-// config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = ELEVATOR_REVERSE_LIMIT_RESET_POSITION_ROTATIONS; -// -// config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; -// config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = 6.8; + config.SoftwareLimitSwitch.ReverseSoftLimitEnable = true; + config.SoftwareLimitSwitch.ReverseSoftLimitThreshold = 0; + + config.SoftwareLimitSwitch.ForwardSoftLimitEnable = true; + config.SoftwareLimitSwitch.ForwardSoftLimitThreshold = edu.wpi.first.math.util.Units.metersToInches(MAXIMUM_ELEVATOR_HEIGHT_METERS) / (Math.PI * DRUM_DIAMETER_METERS) * ELEVATOR_GEAR_RATIO;src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
26-30: hasCoral() guard may allow scoring algae instead of coral.The
hasCoral()check at line 30 could returntruewhen holding algae if the transporter contains coral. In this scenario, the scoring sequence proceeds but attempts to score algae instead of coral. While teleop triggers filter by!isHoldingAlgae(), this edge case could occur in autonomous routines.Update
hasCoral()inCoralCollectionCommands.java(line ~64) to exclude algae:static boolean hasCoral() { return !AlgaeManipulationCommands.isHoldingAlgae() && (RobotContainer.END_EFFECTOR.hasGamePiece() || RobotContainer.TRANSPORTER.hasCoral()); }
🧹 Nitpick comments (1)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (1)
161-161: Extract tolerance magic number into named constant
The third parameter inatState(…, 4)is the arm‐angle tolerance (in degrees). Replace4with aprivate static final double ARM_ANGLE_TOLERANCE_DEGREES = 4.0constant for clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java(5 hunks)src/main/java/frc/trigon/robot/constants/FieldConstants.java(1 hunks)src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java(10 hunks)src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/frc/trigon/robot/constants/FieldConstants.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-18T22:46:49.269Z
Learnt from: ShmayaR
PR: Programming-TRIGON/RobotCodeOffSeason2025#16
File: src/main/java/frc/trigon/robot/subsystems/arm/Arm.java:86-88
Timestamp: 2025-09-18T22:46:49.269Z
Learning: In the arm subsystem for this robot, angles above 90 degrees bypass the isArmAboveSafeAngle() logic, making the Rotation2d wrap-around issue less critical in practice according to the team's current system design.
Applied to files:
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java
🧬 Code graph analysis (2)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (6)
src/main/java/frc/trigon/robot/constants/RobotConstants.java (1)
RobotConstants(7-17)src/main/java/lib/hardware/RobotHardwareStats.java (1)
RobotHardwareStats(6-78)src/main/java/lib/hardware/phoenix6/cancoder/CANcoderEncoder.java (1)
CANcoderEncoder(20-193)src/main/java/lib/hardware/phoenix6/talonfx/TalonFXMotor.java (1)
TalonFXMotor(20-209)src/main/java/lib/hardware/simulation/ElevatorSimulation.java (1)
ElevatorSimulation(11-84)src/main/java/lib/hardware/simulation/SingleJointedArmSimulation.java (1)
SingleJointedArmSimulation(12-81)
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (4)
src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorCommands.java (1)
ArmElevatorCommands(20-115)src/main/java/frc/trigon/robot/commands/commandfactories/CoralCollectionCommands.java (1)
CoralCollectionCommands(21-82)src/main/java/frc/trigon/robot/constants/OperatorConstants.java (1)
OperatorConstants(13-109)src/main/java/frc/trigon/robot/commands/commandfactories/GeneralCommands.java (1)
GeneralCommands(19-134)
🔇 Additional comments (15)
src/main/java/frc/trigon/robot/subsystems/transporter/TransporterConstants.java (6)
25-25: Verify BEAM_BREAK_CHANNEL hardware wiring change.
BEAM_BREAK_CHANNELchanged from 3 to 1. Ensure the physical beam break sensor is wired to DIO channel 1 on the robot before deploying this code, or the coral detection will not function.Confirm the wiring matches the new channel assignment in robot documentation or by physical inspection.
64-65: Pulse timing reduced; verify coral handling behavior.
PULSE_VOLTAGE_APPLIED_TIME_SECONDSreduced from 0.1s to 0.08s andPULSE_WAIT_TIME_SECONDSfrom 0.05s to 0.03s. These shorter intervals may affect coral alignment reliability, especially if the transporter needs more time to settle between pulses.Test the coral collection and alignment sequences with the new timing to ensure reliable operation. If alignment issues occur, consider reverting to the original timing or adding a configurable parameter.
106-109: Transporter state voltage values updated.
COLLECTandHOLD_CORALstate voltages changed significantly:
COLLECT: right motor voltage changed from 5V to -3.5V (reversed direction)HOLD_CORAL: right motor voltage changed from 1V to -1V (reversed direction)These direction changes may be intentional to correct motor polarity or improve coral handling, but verify that:
- The physical motor direction matches the intended coral movement
- The new voltages provide adequate holding force without excessive current draw
Test the coral collection and holding behavior with the new voltage values to confirm correct motor direction and adequate performance.
35-38: LGTM: Constants properly declared as final static.The gear ratio, motor amount, and gearbox are now correctly declared as
private final static, improving immutability and clarity.
64-65: Verify pulse timing adjustments.
PULSE_VOLTAGE_APPLIED_TIME_SECONDSreduced from 0.1 to 0.08 andPULSE_WAIT_TIME_SECONDSreduced from 0.05 to 0.03. These shorter timings may affect coral manipulation reliability.Confirm these timing changes were tested and don't cause premature pulse termination or insufficient wait periods between pulses during coral handling sequences.
106-109: Verify transporter voltage changes align with coral handling.
COLLECTright motor voltage changed from 5 to -3.5, andHOLD_CORALright motor voltage changed from 1 to -1. The sign reversal for COLLECT suggests a change in collection direction.Confirm these voltage adjustments (especially the direction reversal for COLLECT) align with the intended coral collection and holding behavior, and have been tested with the hardware.
src/main/java/frc/trigon/robot/commands/commandfactories/CoralPlacingCommands.java (5)
82-86: Improved command flow with getContinuousConditionalCommand.The refactor to use
GeneralCommands.getContinuousConditionalCommandwithgetStayInPlaceCommandprovides cleaner conditional logic compared to the previous implementation. This ensures the arm stays in place when the prepare condition is not met, preventing unintended movement.
26-30: LGTM: Conditional scoring logic with coral presence check.The new
ConditionalCommandstructure properly gates scoring onhasCoral()returning true, preventing attempts to score when no coral is present. Based on learnings,hasCoral()in CoralCollectionCommands.java now correctly excludes algae.Based on learnings
82-86: LGTM: Stay-in-place command prevents unintended arm movement.Using
getContinuousConditionalCommandwithgetStayInPlaceCommand()as the false branch ensures the arm maintains its position when the prepare condition isn't met, avoiding unwanted drift.
157-157: Simplified angle check is clearer.Removing the
armAtAnglecheck and keeping onlyarmAboveAngle(targetAngle)simplifies the logic and makes the intent more explicit.
161-161: Clarify the angular tolerance parameter
The third argument (4) inatState(…, shouldReverseScore(), 4)sets the angular tolerance (in degrees) passed toarmAtAngle. Confirm that a 4° tolerance is appropriate for accurate coral scoring.src/main/java/frc/trigon/robot/subsystems/armelevator/ArmElevatorConstants.java (4)
324-349: Limits verified—no out-of-bounds states. All arm angles fall within –90° to 270° and all elevator target heights ≤ 1.644 m.
39-43: LGTM: Motors and encoder properly configured for CANivore.The addition of
RobotConstants.CANIVORE_NAMEto motor and encoder constructors correctly configures them for remote CAN bus communication.
173-173: LGTM: Breaking arm event wired to stop motor.The trigger properly stops the master motor when excessive current is detected (after debounce), providing a safety mechanism against arm damage.
324-349: All elevator state heights are within the 1.644 m limit
No defined target exceeds the 1.644 m maximum (highest is 1.61 m).
3 participants
Summary by CodeRabbit
New Features
Improvements
Chores