Conversation
|
This PR was automatically closed because it adds new files. If this is intentional, comment |
|
Reopening since this is a false close /not-a-mistake |
|
This PR was automatically closed because it adds new files. If this is intentional, comment |
There was a problem hiding this comment.
Pull request overview
Adds a new FTC autonomous OpMode (AutoTest2) implementing a multi-stage path-following routine with flywheel spin-up and timed multi-ball firing controlled by a state machine.
Changes:
- Introduces
AutoTest2OpMode with multiplePathChains (line/Bezier) for shooting → pickup → gate → shooting cycles. - Adds flywheel velocity control with “ready” detection and timeouts, plus timed launcher firing steps.
- Adds telemetry for path state/timing and flywheel velocities.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| .build(); | ||
| shootToPickup = follower.pathBuilder() | ||
| .addPath(new BezierLine(shootPose, ballPickup1)) | ||
| .setLinearHeadingInterpolation(ballPickup1.getHeading(), ballPickup1.getHeading()) |
| flywheel2 = hardwareMap.get(DcMotorEx.class, "flywheel2"); | ||
| launcher = hardwareMap.get(DcMotorEx.class, "Launcher"); | ||
| launcher.setDirection(DcMotorSimple.Direction.REVERSE); | ||
| flywheel1.setDirection(DcMotorSimple.Direction.REVERSE); |
| public void start() { | ||
| pathTimer.resetTimer(); | ||
| opModeTimer.resetTimer(); | ||
| pathState = 0; | ||
| stopFlywheels(); | ||
| launcher.setPower(0.0); | ||
| } | ||
| @Override | ||
| public void stop() { | ||
| stopFlywheels(); | ||
| launcher.setPower(0.0); | ||
| } |
| import com.pedropathing.paths.Path; | ||
| import com.pedropathing.paths.PathChain; | ||
| import com.qualcomm.robotcore.eventloop.opmode.Autonomous; | ||
| import com.qualcomm.robotcore.eventloop.opmode.OpMode; | ||
| import com.pedropathing.util.Timer; | ||
| import com.qualcomm.robotcore.hardware.DcMotor; | ||
| import com.qualcomm.robotcore.hardware.DcMotorEx; | ||
| import com.qualcomm.robotcore.hardware.DcMotorSimple; | ||
| import com.qualcomm.robotcore.hardware.HardwareMap; | ||
|
|
| pathTimer = new Timer(); | ||
| opModeTimer = new Timer(); | ||
| follower = Constants.createFollower(hardwareMap); | ||
| pathBuilder(); | ||
| follower.setPose(startPose); | ||
| flywheel1 = hardwareMap.get(DcMotorEx.class, "flywheel1"); | ||
| flywheel2 = hardwareMap.get(DcMotorEx.class, "flywheel2"); | ||
| launcher = hardwareMap.get(DcMotorEx.class, "Launcher"); | ||
| launcher.setDirection(DcMotorSimple.Direction.REVERSE); | ||
| flywheel1.setDirection(DcMotorSimple.Direction.REVERSE); | ||
| flywheel1.setMode(DcMotor.RunMode.RUN_USING_ENCODER); | ||
| flywheel2.setMode(DcMotor.RunMode.RUN_USING_ENCODER); | ||
| intake = hardwareMap.get(DcMotorEx.class, "Intake"); | ||
| stopFlywheels(); | ||
| } | ||
| public void start() { | ||
| pathTimer.resetTimer(); | ||
| opModeTimer.resetTimer(); | ||
| pathState = 0; |
There was a problem hiding this comment.
Pull request overview
Adds a new FTC autonomous OpMode (AutoTest2) implementing a multi-stage routine that combines Pedro Pathing trajectories with a flywheel/launcher/intake state machine, plus adds (currently disabled) GitHub Actions workflows for “mistake PR” auto-close/reopen handling.
Changes:
- Added
AutoTest2autonomous OpMode with path chains, timers, mechanism control, and telemetry. - Implemented a timed multi-shot firing sequence integrated into the autonomous state machine.
- Added three disabled GitHub Actions workflow definitions related to auto-closing and re-opening “mistake” PRs.
Reviewed changes
Copilot reviewed 1 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
TeamCode/src/main/java/org/firstinspires/ftc/teamcode/OpModes/Autos/AutoTest2.java |
New autonomous OpMode with Pedro Pathing trajectories and a timed state machine for shooting/intake. |
.github/workflows/reopen-once.yml.disabled |
Disabled workflow to allow PR author to reopen a “mistake-pr” once via a comment command. |
.github/workflows/mistake-pr.yml.disabled |
Disabled workflow to auto-label/close PRs that add new files. |
.github/workflows/disable-auto-reopen-after-second-close.yml.disabled |
Disabled workflow to permanently disable auto-reopen after a second close. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } | ||
| break; | ||
| case 2: | ||
| if (flywheelsAtSpeed() || pathTimer.getElapsedTimeSeconds() >= FLYWHEEL_READY_TIMEOUT) { |
There was a problem hiding this comment.
In this transition, the code proceeds to the shooting state even when the robot hasn't reached shootPose (it can advance solely on the 5s timeout). That can result in firing while off-position. Consider requiring atPose(shootPose, ...) before entering the firing states, and handling timeouts by aborting/replanning (or explicitly gating firing on being at pose).
| if (flywheelsAtSpeed() || pathTimer.getElapsedTimeSeconds() >= FLYWHEEL_READY_TIMEOUT) { | |
| if (follower.atPose(shootPose, 2, 2) | |
| && (flywheelsAtSpeed() || pathTimer.getElapsedTimeSeconds() >= FLYWHEEL_READY_TIMEOUT)) { |
| if (!follower.isBusy() || follower.atPose(shootPose, 2, 2) || pathTimer.getElapsedTimeSeconds() > 5) { | ||
| pathTimer.resetTimer(); | ||
| pathState = 11; |
There was a problem hiding this comment.
This condition advances to the second firing sequence if the follower is no longer busy OR on timeout, even if the robot isn't actually within tolerance of shootPose. That can cause shots to be taken from an unintended position. Consider only entering the firing states once atPose(shootPose, ...) is true, and treat !isBusy()/timeouts as error handling paths rather than green-lighting shooting.
| if (!follower.isBusy() || follower.atPose(shootPose, 2, 2) || pathTimer.getElapsedTimeSeconds() > 5) { | |
| pathTimer.resetTimer(); | |
| pathState = 11; | |
| if (follower.atPose(shootPose, 2, 2)) { | |
| // Reached the desired shooting pose: proceed to firing sequence | |
| pathTimer.resetTimer(); | |
| pathState = 11; | |
| } else if (!follower.isBusy() || pathTimer.getElapsedTimeSeconds() > 5) { | |
| // Error/timeout: follower stopped or timed out without reaching shootPose. | |
| // Abort firing to avoid shooting from an unintended position. | |
| stopFlywheels(); | |
| launcher.setPower(0); |
| pathState = 17; | ||
| } | ||
| break; | ||
| case 17: |
There was a problem hiding this comment.
After the final shot, the state machine stops the flywheels but never stops the intake motor. Since intake is set to -1 earlier and not changed afterward, it will keep running indefinitely in state 17 until the OpMode ends. If the routine is complete here, stop the intake (and optionally the follower) when entering the terminal state.
| case 17: | |
| case 17: | |
| intake.setPower(0.0); |
| case 2: | ||
| if (flywheelsAtSpeed() || pathTimer.getElapsedTimeSeconds() >= FLYWHEEL_READY_TIMEOUT) { | ||
| launcher.setPower(LAUNCHER_POWER); | ||
| pathTimer.resetTimer(); | ||
| pathState = 3; | ||
| } | ||
| break; | ||
| case 3: | ||
| if (pathTimer.getElapsedTimeSeconds() >= FIRE_DURATION) { | ||
| launcher.setPower(0); | ||
| pathTimer.resetTimer(); | ||
| pathState = 4; | ||
| } | ||
| break; | ||
| case 4: | ||
| if (pathTimer.getElapsedTimeSeconds() >= PAUSE_DURATION) { | ||
| launcher.setPower(LAUNCHER_POWER); | ||
| pathTimer.resetTimer(); | ||
| pathState = 5; | ||
| } | ||
| break; | ||
| case 5: | ||
| if (pathTimer.getElapsedTimeSeconds() >= FIRE_DURATION) { | ||
| launcher.setPower(0); | ||
| pathTimer.resetTimer(); | ||
| pathState = 6; | ||
| } | ||
| break; |
There was a problem hiding this comment.
The firing sequence is implemented by a long run of nearly identical states (2–7 and again 11–16). This duplication makes tuning risky (power/timing changes must be kept in sync in multiple places) and increases the chance of inconsistent behavior. Consider refactoring into a helper that steps through N shots using a counter (or an array of shot/ pause durations) to reduce duplicated state logic.
This pull request introduces a new autonomous operation mode called
AutoTest2for the robot, implementing a multi-This pull request introduces a new autonomous operation mode for the robot by adding the
AutoTest2class. The new op mode implements a multi-stage autonomous routine that leverages path following, flywheel launching, and intake mechanisms for ball handling. The code includes state management, hardware initialization, and telemetry updates to support the autonomous sequence.New autonomous routine implementation:
AutoTest2class inorg.firstinspires.ftc.teamcode.OpModes.Autos, which defines a multi-stage autonomous sequence using path following and ball launching mechanisms.updatePathState()method, controlling robot actions like path following, flywheel spinning, launcher firing, and intake operation based on the current state and timing.Path and hardware integration:
Follower,PathChain, and Bezier paths, with trajectory definitions for shooting, picking up balls, and gate operations.flywheel1,flywheel2,launcher,intake) in theinit()method, including motor directions and modes.Telemetry and control:
loop()method to monitor timers, state, flywheel velocities, and readiness, aiding debugging and performance tracking during autonomous operation. (F77f5771stage path-following and shooting routine. The code sets up complex path chains using Bezier curves and lines, manages flywheel and launcher control for shooting, and coordinates the robot's mechanisms through a state machine.Key additions and features:
Autonomous Path Following and State Machine:
updatePathState()to control the robot's movement, shooting, and ball pickup sequence, coordinating path transitions and timing for each action.FollowerandPathChainclasses for smooth trajectory following.Flywheel and Launcher Control:
Initialization and Telemetry: