Package com.crossbotics.ftchelper.core
Interface Subsystem
- All Known Subinterfaces:
AngleDevice,Feeder,PathFollower,TargetSource
- All Known Implementing Classes:
Arm,Camera,Claw,DeadWheelOdometry,Flywheel,Hood,Indexer,Intake,Launcher,Launcher,Lift,Lights,LimelightTags,Module,MotorFeeder,MotorPositions,OtosOdometry,Pieces,PieceSensor,PinpointOdometry,PoseTracker,Positioner,PositionMotor,PositionServo,ServoFeeder,ServoPositions,SpinMotor,SpinServo,Subsystems,Turret,Turret,WebcamTags,Wrist
public interface Subsystem
One part of the robot (a lift, a claw, an intake, a launcher) that needs a little work every loop.
Every mechanism helper in this library is a Subsystem, and your own classes can be one too.
Put them in a Subsystems group and call update() once per loop: every part is
updated, in TeleOp and in autonomous.
Java note: an "interface" is a promise, a list of methods a class says it has. Any class that
writes implements Subsystem promises to have update(), so a Subsystems
group can call it without knowing what the part is. Methods marked "default" come with a ready-made
version (here: do nothing), so you only write them if your part needs them.
public class Bucket implements Subsystem {
public void update() { ... } // talk to the hardware here
public void stop() { motor.setPower(0); } // optional
public void addTelemetry(RobotTelemetry t) { ... } // optional
}
Making your own: docs/guides/extending.md. Why update() must never wait: docs/guides/non-blocking.md. Docs: docs/modules/core.md
-
Method Details
-
update
void update()Called once every loop. Do the hardware work here. Must be quick: no sleep, no waiting. While update() waits, the whole robot is frozen (no driving, no limits, no STOP). -
stop
default void stop()Stops all motion. Called at the end of every OpMode. -
addTelemetry
Adds this part's lines to the telemetry. Uset.linefor drivers,t.debugfor programmers. -
name
The name shown in telemetry and in the hardware check.
-