OpModes in FTC Eric Golde

What is an opmode? The brain of your robot. Takes input from sensors, controllers, or both. Controls motors, servos to play the game. You can have as many opmodes as you want, but only one opmode runs at one time. Each opmode should be independent. Each opmode is a Java class, in its own Java file.

AUTONOMOUS VS TELEOP Autonomous and Teleop periods always use different opmodes. You might want to chose from different autonomous opmodes for different game strategies (depending on alliance partner plans, blue/red side of arena, etc.) Teleop may want different opmodes for different chassis/sensor/motor configurations.

Parts of an opmode @TeleOp() / @Autonomous() / @Disabled Registers your opmode so it shows up. Don’t forget it or you opmode will be invisible! You don’t need to explicitly register it like last year. See details @Override public void init() Gets called ONCE, when you the start button once. Use this for registering motors, servos, buttons, joysticks, …. @Override public void start() Get called ONCE, right before loop gets called. Use this to set the position of servos/turn on sensors. @Override public void loop() Gets called over and over and over again, until the stop button. This the main part of your opmode. You typically check joysticks, buttons, sensors, and then change motors/servos. @Override public void stop() Called when the opmode stops. Usually not needed, but there if you do.

Creating a basic Drive TELEOP opmode @TeleOp(name="TankDrive", group="Drive") public class TankDrive extends OpMode { DcMotor left; DcMotor right; @Override public void init() { left = hardwareMap.dcMotor.get("left"); right = hardwareMap.dcMotor.get("right"); right.setDirection(DcMotorSimple.Direction.REVERSE); } public void loop() { float leftValue = -gamepad1.left_stick_y; float rightValue = -gamepad1.right_stick_y; leftValue = Range.clip(leftValue, -1, 1); rightValue = Range.clip(rightValue, -1, 1); left.setPower(leftValue); right.setPower(rightValue);

CONTROLLERS Push Start and A button at the same time to tell driver station that joystick 1 is connected (Start and B for joystick 2). For joysticks, down is Y direction is positive. Use a negative sign to flip it to up being positive. In FTC, there is no way to detect a single button press. You can only sense if a button is up or down. But there is an easy way… boolean lastStateA = false; // Last state of A button @Override public void loop() { if (gamepad1.a && !lastStateA) { // A was pressed once. Put your code to react to this here. } lastStateA = gamepad1.a; }

SENSORS Sensors are just like motors with the hardware. Sensors can be fairly complicated, but very useful. ColorSensor can be used to sense lines on the playing field. Not sensitive enough to detect beacon color (in my experience…) You can use the phone camera as a sensor. There is a special class to use to turn the camera into a sensor (complex!). Feel free to ask us for more information. Viewphoria is very limiting

MOTORS AND SERVOS Motors: use DCMotor. Servos: use Servo. For DC Motors, use .setDirection to set the direction of motors. Don’t just switch wires around. Continuous servos and non-continuous servos use different ways to control them. Use Range.clip to prevent crashes; if you try to set too large a value.

TELEMETRY Telemetry allows you to send information from the robot controller to the driver station, in the form of text. Very useful to debug your code. Things have changed quite a bit from last year. To print a line of text to telemetry: public void writeLine (String line) { telemetry.addLine(line); updateTelemetry(telemetry); } You can also have a value that updates without printing a new line: public void updateValue (String name, Object value) { telemetry.addData(name, String.valueOf(obj)); updateTelemetry(telemetry);

autonomous opmodeS Two basic kinds: Drive pre-programmed dead reckoning. Doesn’t use any sensors. Relatively easier. Dead reckoning, but also use sensors to adjust and react to the robots surrounding. Harder. Lots of options on how much to use sensors vs. dead reckoning. For dead reckoning, you need to test on your exact robot or a very close replica. Gear ratios, wheel size, etc. will affect your code significantly. Autonomous is hard. You need to test a LOT.

Sharing code BETWEEN OPMODES Opmodes should never call other opmodes directly. Opmodes should not have static functions. You can share code by creating a “utility class” with static functions that is used by multiple opmodes. Example: telemetry. You can also share code by creating a base class that multiple opmodes extend. This is more advanced, but helps share common initialization code.

TIPS Never get frustrated Ask on the FTC forum about your question Take time to go through the FTC tutorials Test code on a replica of your robot as similar as possible. Use telemetry to report the values of variables or to figure out where you are in your code. A variable might not be what you think. The more telemetry the easier it is to debug. You can also use sound (but disable it before competition!) TEST. TEST. TEST. TEST. TEST. TEST.

QUESTIONS?