Requests and Actions
Custom pattern made specifically for sequencing in FRC
Actions
What are Actions? Actions are simple, sequential tasks that run one at a time. Think of them like a to-do list that the robot runs step-by-step in autonomous mode.
Where do we use Actions? Only in autonomous mode, where the robot needs to perform precise, ordered sequences of movements and operations without driver input.
How do Actions behave? When an Action starts, it runs until it finishes before moving on to the next one. This makes it easy to control exactly what the robot does and when, with clear start-to-finish steps.
Why Actions over Commands in Auto? Actions are simpler and easier to debug for autonomous routines. They provide clear, linear control flow without the extra complexity of a command scheduler.
// Note: must be in a class extending AutoBase
// Example Composite Action
Action action =
new ParallelAction(List.of(
new TrajectoryAction(t.next(),AutoConstants.scoreTimeout),
new LambdaAction(() -> {
s.setGoal(GoalState.L4);
})
))
// Example use
r(action)// Example action from scratch
package com.team5817.frc2025.autos.Actions;
/**
* An action that executes a lambda function.
*/
public class LambdaAction implements Action {
/**
* Functional interface for a void function.
*/
public interface VoidInterace {
void function();
}
private final VoidInterace mFunction;
/**
* Constructs a LambdaAction with the specified function.
*
* @param function the function to execute
*/
public LambdaAction(VoidInterace function) {
this.mFunction = function;
}
/**
* Called when the action starts and executes the function.
*/
@Override
public void start() {
mFunction.function();
}
/**
* Called periodically to update the action.
*/
@Override
public void update() {}
/**
* Checks if the action is finished.
*
* @return true since this action does nothing after the function is executed
*/
@Override
public boolean isFinished() {
return true;
}
/**
* Called when the action is done.
*/
@Override
public void done() {}
}Requests
What are Requests? Requests are like tasks you send to the robot’s subsystems that can be managed and queued flexibly. They can start, stop, or be replaced based on what’s happening.
Where do we use Requests? Requests run during teleop, autonomous, and superstructure control—anywhere the robot needs to react dynamically, manage multiple tasks, or handle interruptions.
How do Requests behave? They don’t block the robot’s main loop. Instead, they run alongside other activities, can be queued up, and the system manages switching between them smoothly.
Why Requests over Commands? Requests give us more control and flexibility with how tasks are scheduled and executed. They’re lighter weight and better tailored to our robot’s architecture, avoiding some complexity of the WPILib command system.
// Example Composite Request
Request idle =
new SequentialRequest(
new ParallelRequest(
new SequentialRequest(
mEndEffectorWrist.stateRequest(EndEffectorWrist.State.IDLE),
new WaitRequest(0.1),
mElevator.stateRequest(Elevator.State.ZERO)),
mEndEffectorRollers.stateRequest(EndEffectorRollers.State.HOLD),
mIntake.stateRequest(Intake.State.IDLE)),
mEndEffectorRollers.stateRequest(EndEffectorRollers.State.IDLE)
).addName("Idle");
// Example use
Superstructure.getInstance().request(idle) // Example Request From Scratch
/**
* Creates a request to change the state of the intake deployment.
*
* @param _wantedState The desired state.
* @return The request to change the state.
*/
public Request stateRequest(State _wantedState) {
return new Request() {
@Override
public void act() {
setState(_wantedState);
}
@Override
public boolean isFinished() {
return atState();
}
};
}WPILib Commands
Are likely a better solution
Very different than how we have coded forever
Don‘t make as much sense to me
If you have the time consider migration
Last updated