Custom Mechanism Actions

Write actions that cooperate with drive paths.

Road Runner 1.0 Actions and AutonomousRoad Runner

In this lesson, you will:

Write an action that returns quickly while work continues.
End on target or timeout and publish the stop reason.
Guarantee zero mechanism power when the action or OpMode exits.

Concept narrative

Custom actions let mechanisms participate in autonomous without threads or sleeps. They run in small repeated steps and finish by returning false.

Robot mental model

A good mechanism action is polite: it does a little work, reports useful packet telemetry, and gives other actions time to run.

Implementation walkthrough

Write an action that initializes once, commands a target, checks sensor or encoder error, and returns false when finished.

CustomAction.javaJava

public Action liftTo(int target) {
    return new Action() {
        private boolean initialized;
        private final ElapsedTime timer = new ElapsedTime();

        @Override
        public boolean run(@NonNull TelemetryPacket packet) {
            boolean stopRequested = !opModeIsActive();
            if (stopRequested) {
                lift.setPower(0.0);
                packet.put("liftStopRequested", true);
                packet.put("liftExit", "stop");
                return false;
            }

            if (!initialized) {
                lift.setTargetPosition(target);
                lift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
                lift.setPower(0.4);
                timer.reset();
                initialized = true;
            }

            int error = target - lift.getCurrentPosition();
            boolean timedOut = timer.seconds() >= 2.0;
            boolean running = Math.abs(error) > 25 && !timedOut;

            packet.put("liftError", error);
            packet.put("liftTimedOut", timedOut);
            packet.put("liftStopRequested", stopRequested);

            if (!running) {
                lift.setPower(0.0);
                packet.put("liftExit", timedOut ? "timeout" : "target");
            }
            return running;
        }
    };
}

try {
    Actions.runBlocking(liftTo(targetTicks));
} finally {
    lift.setPower(0.0); // Also stop the mechanism when the OpMode is interrupted.
}

Common mistakes and debugging

Actions that sleep or loop internally starve parallel actions. Actions with bad finish conditions stall or skip steps.

Practice

Create a lift action and run it in parallel with a short drive action.

Checkpoint

Each run call returns promptly so parallel actions can continue.
The action ends on target or a documented timeout.
Telemetry identifies target, error, timeout, and completion reason.
Mechanism power returns to zero after completion and OpMode interruption.
The test record includes the setup, prediction, and observed result.
A teammate can repeat the check from the saved evidence without guessing.

Reflection check

Check your understanding before moving on.

Why should a custom lift action initialize target, mode, power, and timer only once?

Road Runner requires a new motor object every call.

It makes the action return false immediately.

Repeated run calls should monitor progress without restarting the mechanism action.

What should a lift action do when it reaches target or its documented timeout?

Set mechanism power to zero and report the completion reason.

Keep applying the last power until another action overwrites it.

Switch the robot to TeleOp automatically.

0 of 2 answered

References

Road Runner 1.0 ActionsAction composition, custom actions, and autonomous structure.FTC DashboardLive telemetry, graphs, config variables, and camera streaming.