Files
allwpilib/wpilibj/src/main/java/org/wpilib/opmode/OpMode.java

40 lines
1.3 KiB
Java
Raw Normal View History

// Copyright (c) FIRST and other WPILib contributors.
// Open Source Software; you can modify and/or share it under the terms of
// the WPILib BSD license file in the root directory of this project.
package org.wpilib.opmode;
/**
* Top-level interface for opmode classes. Users should generally extend one of the abstract
[wpilib] Remove LinearOpMode (#8638) Linear OpModes have several major downsides with no obvious solutions: - Some things stop working automatically--e.g. in a linear opmode, simulation will not work out-of-the-box; the user must explicitly call sim themselves.  there's a few other things we do periodically, but this is the big one (it also forces some decisions on other parts of the library—eg if we want Tunable to work in linear without the user manually calling refresh, we have to run it on a background thread, which means it must be thread safe throughout).  We can help in some areas (e.g. have sleep functions call background things), but if the user is writing a loop that waits to drive a certain distance with no sleep, it's an easy footgun - Writing code with no sleeps is easy to do, and can hog an entire processing core easily--yes, there's more than one core, but it could still easily impact e.g. vision processing - Many people I've talked to want robot-level periodic and periodic sim functions.  Given linear opmodes, we have two options, neither of which is great: (1) don't provide robot-level periodic functions, and the users who want those must set those up themselves and remember to call them explicitly from every periodic opmode, or (2) provide them, but only call them automatically from periodic opmodes, which could be confusing for linear opmode users (they'd have to call them manually if they wanted them).  Currently we do (1) but someone in the community already opened a change to do (2). - Restarting the robot program fixes the "stuck in auto for the rest of the match" problem but still feels like an ugly hack because the startup time is not unlikely to make the robot not immediately ready for teleop Removing LinearOpMode resolves these issues by moving to a periodic-only structure. We can address the few notable use cases of LinearOpMode (e.g. very basic autonomous sequences) in other ways such as Blocks generated code, better state machine tutorials/documentation, etc.
2026-02-27 14:26:27 -08:00
* implementations of this interface (e.g. {@link PeriodicOpMode}) rather than directly implementing
* this interface.
*/
public interface OpMode {
/**
* This function is called periodically while the opmode is selected on the DS (robot is
* disabled). Code that should only run once when the opmode is selected should go in the opmode
* constructor.
*/
default void disabledPeriodic() {}
/**
* This function is called when the opmode starts (robot is enabled).
*
* @param opModeId opmode unique ID
* @throws InterruptedException when interrupted
*/
void opModeRun(long opModeId) throws InterruptedException;
/**
* This function is called asynchronously when the robot is disabled, to request the opmode return
* from opModeRun().
*/
void opModeStop();
/**
* This function is called when the opmode is no longer selected on the DS or after opModeRun()
* returns. The object will not be reused after this is called.
*/
void opModeClose();
}