1 of 47

FTC Kickoff Concepts

2024-25 REV DUO FTC Starter Bot

We are excited for the 2024-2025 FTC Game, INTO THE DEEP℠ presented by RTX and reveal our Starter Bot! Utilizing just the and the , this starter bot is the culmination of analyzing the game, prototyping, and technical documentation. The REV DUO FTC Starter Bot is designed to give teams a starting point for building their robot, while leaving room for iteration, revision, and adaptation to the game’s challenges.

We're looking forward to see what teams create this year!

Documentation Links

INTO THE DEEP 2024-25

Starter Bot - INTO THE DEEP

Introducing the 2024-25 REV DUO FTC Starter Bot!

This year's 2024-2025 REV DUO FTC Starter Bot is here to help as your team DIVEs into the season. Actively intake samples to deliver them to the low basket or observation zone, grab and hook specimens on the upper chamber, and ascend to the lower rung!

Refine the robot's movement with manual controls of the arm and wrist as you journey INTO THE DEEP℠.

2024-25 REV DUO FTC Starter Bot Walkthrough

The 2024-25 REV DUO Starter Bot is designed to be built using the FTC Starter Kit V3.1 (REV-45-3529) and DUO Control Bundle (REV-35-2709).

Documentation Links

Bill of Materials

The 2024-25 REV DUO Starter Bot is designed to be built using the FTC Starter Kit V3.1 (REV-45-3529) and DUO Control Bundle (REV-35-2709).

Full Bill of Materials (BOM) - Excel Download

Full Robot

Substructures

Intake

Forearm

Tower

Programming TeleOp

Getting Started!

This year's Starter Bot program offers a slightly more technical solution than previous years. If your team is new to FTC, or in need of a review, we strongly recommend checking out our updated before diving in!

To begin, let's take a look at the configuration and actuators used in this year's design.

Configuration

Before getting started with programming we needed to create a . Below is an overview of how the robot is configured for the TeleOp code to function as expected:

Port Type

Port Number

Device Type

Name

Configuration File Download

Right click the file below and select "save link as". To put this configuration file on your robot, drag this file into the "FIRST" folder of your Control Hub's file system.

Wiring Diagram

Gamepad Setup

In split arcade drive, the left joystick will control forward and reverse motion of the robot, and the right joystick will control turning. This is similar to how some RC cars are driven and video games are played.

Not all gamepads have buttons labeled the same way. Check the manufacturer's documentation for accurate button mapping.

2024-25 REV DUO FTC Starter Bot Gamepad Layout:

The REV USB PS4 Compatible Gamepad (REV-31-2983) has two remappable M-buttons on the back side of the controller. By default, these are mapped to circle and cross.

TeleOp Program Downloads

Blocks (v1.0.2):

Java (v1.0.1):

The following pages will be a deep dive into the Blocks code, grab your snorkel and let's get started!

Video Walkthrough

Programming - Initialization

Before the bulk of our program begins, we need to first establish our variables and tell our motors how we want them to run. This section of code will run once when the program is activated and before we hit "Play" on the Driver Hub.

Drivetrain Motor Settings

Since the motors on our drive train are a mirror of each other, one needs to be set to run in reverse. In this case we have the leftDrive motor set to run in reverse.

By default, our drivetrain motors will not be using encoder data so we can set them to RUN_WITHOUT_ENCODER. Your team may choose to change this later when working on autonomous programming!

Establishing Variables

To learn more about "What is a Variable?" check out our Hello Robot tutorial!

There are two parts to our variable set up in this year's Starter Bot program. Often times we use variables in place of a number or equation, but in this case we will be using them to help our robot move between functions in our code and determine preset arm/wrist positions.

Let's take a look at what all our variables do:

Variables: OnBot Java vs. Blocks

In the OnBot Java version of this code, we use something called "enum". This allows us to declare the variable name and have it treated as a unique value.

For example: the robot interprets the variable "MANUAL" as one of the states within our switch case in OnBot Java. We'll discuss more about the switch case down below!

However, "enum" is not available in Blocks meaning we have to be a little clever to mimic this process. We created strings using the "text" block to do a similar thing. This will have the robot understand MANUAL equals the word "manual", which allows it to move between cases.

currentState Variable

You'll notice the variable currentState appears throughout our program repeatedly. But what does it do?

This variable is what will allow our robot to switch between its various preset configurations based on what button is pressed on the gamepad. It's one variable that can be set to a number of different constant states. In comparison, our position variables will remain constant.

When we press one of the buttons on our gamepad it changes our currentState. In turn, this tells our arm and wrist on the robot to move to one of the predetermined positions seen below.

If we needed to update the position value for one of our presets, we can do so within this if/else statement and it will be reflected throughout the entire code without having the hunt down every instance it may be used.

Programming - Creating Functions

This year in our Starter Bot Blocks code we are using "functions" for the first time.

What is a Function?

Functions act similar to a variable in that we are using one thing to represent another. However, where a variable typically is used in place of something short, such as a number or equation, a function can take the place of several lines of code.

This can be incredibly useful if there is a section of code we know will be repeated or to break apart our code into chunks for easy editing.

Below is a breakdown of our functions:

How do Functions appear in Blocks?

When using functions, our Blocks program becomes divided into different sections containing separate series of code:

So let's say we wanted to change how quickly our robot's arm moves during manual control with the d-pad. With our functions organizing our code in chunks, it's easy to find the values we want to change:

Without the use of functions our code would end up a little long and clunky:

Creating a new Function in Blocks

Next we will replace "do something" with an appropriate name. Maybe in this case we are adding a new function for climbing:

Once our function is named it will appear in the "Functions" menu to be added to the main loop or wherever we need it within our code!

All that's left is to add whatever code we'd like to be within this function:

The Starter Bot is able to climb the lower rung using the existing example program!

Additional Function Example

By default, the Starter Bot's program only references each function once during our loop. The following is intended to be an additional example for reusing functions throughout a program and as an additional educational resource!

This program can be tested on the Starter Bot or another robot using the same configuration file! Create a new OpMode to begin. Ours is called FunctionsDemo.

If you are using the Starter Bot, make sure the arm is adjusted to not drag while the robot drives autonomously.

Let's say we are working on an autonomous code where we want our robot to drive roughly in a square. Remember that autonomous means this code will move the robot on its own when play is pressed:

Next, let's say we need the robot to do something between one of the turns, such as move its arm or open a servo's claw. There's a couple of ways we could approach this without functions:

Already our code is getting a little long so let's move our side motion and turn into a function:

Now our loop may look like this:

When we test our code we may notice our robot isn't exactly driving in a square shape. Thankfully with our function in place we only need to change the needed value in one place:

This change to the function will be reflected anywhere DRIVE_AND_TURN used.

Give it a try by changing the right motor's power or the timer to refine your square!

Programming - Controlling the Arm and Wrist

Setting up the Arm and Wrist Motors:

As part of our main loop, our arm and wrist motors are set to RUN_TO_POSITION mode with their TargetPosition set to the appropriate variable. Additionally, our arm and wrist motors are set to full power whenever they are moving.

Because our targetArm and targetWrist values change throughout our code, we include this as part of our loop rather than initialization.

Preset Movements

The GAMEPAD_INPUT_STATE function contains all our code for controlling the arm and wrist. Let's break it down by what each button does in our If/Else statement!

Pressing A/Cross

When the A/Cross button on the gamepad is pressed our currentState switches to INTAKE meaning our robot's arm will move down and wrist will unfold to be ready to pick up samples.

Pressing B/Circle

This section of code allows for a togglable state between two positions of our arm/wrist when B/Circle are pressed. Because we want this to be togglable and not require the button to be held, we want to have our robot check the state of the B/Circle button each loop.

The lastGrab variable will change between true or false based on the state of the button. If the driver holds down the B/Circle button its state will not update again until it is first released.

If B/Circle is pressed AND is not currently held then the robot will run a second if/then statement to determine which of the Wall positions the arm/wrist should move to.

With this statement the robot knows that if the arm is already at our WALL_GRAB preset it should move to unhook. The opposite is also true where if the arm/wrist is in the WALL_UNHOOK preset it will go back to grab.

Pressing Y/Triangle

This section functions similarly to B/Circle providing a togglable control for clipping a specimen!

In this case lastHook allows the robot to determine if the Y/Triangle button is being held before the robot moves between the two positions.

Pressing X/Square

When the X/Square button on the gamepad is pressed our currentState switches to LOW_BASKET meaning our robot's arm will move up and wrist will unfold to be ready to deposit samples in the low basket.

Pressing Left Bumper

It's always good to have a way to reset our robot if needed! By pressing left bumper, currentState will be set to INIT moving our robot back to its initilization configuration, like what might be used at the start of a match.

Manual Control

Beyond our preset movements, we want our robot to have refined control for the arm and wrist as we navigate the field.

Whenever we press a button on the d-pad our currentState will switch to MANUAL allowing the arm or wrist to move in increments until the button is released.

Because we have our motors set to "RUN_TO_POSITION" mode we can't just turn the power on for manual control. Instead we have the robot changing the position in the appropriate direction in chunks. Depending our your driver's preference, you may choose to adjust these values for quicker or more refined control!

By default, these position values are different in the OnBot Java and Blocks version of the provided code. This is due to a difference in how quickly OnBot Java loops through a program compared to Blocks.

Programming - Intake and Claw Toggle

Intake Control

When one of the triggers on the gamepad is pressed, it activates our GAMEPAD_INTAKE function. This simple if/then statement just checks which trigger is being pressed so our servo knows which way to rotate.

Because our servo is set to continuous mode in our configuration, we have the ability to tell our servo to set a power instead of moving by position increments!

Claw Toggle Control

When the right bumper is pressed on the gamepad, the claw on the robot either opens or closed. This prevents the driver from having to hold down the button to maintain control of a picked up specimen!

Because togglable control is not natively available in the FTC SDK, we have to make use of a couple of variables to help the robot check the state of the claw's servo and the right bumper.

Similar to what's used in our arm control's presets, lastBump checks if the right bumper is being held down and won't accept another input until its been released.

Meanwhile, clawOpen allows the servo to shift between the two set positions based on where it has last moved to. You can adjust these values based on your specific robot to have the claw open more or less.

Programming - Driving and Telemetry

Split Arcade Drive

This year's Starter Bot is designed for split arcade drive. This means the left joystick controls the forward and back motion while the right joystick allows for rotation.

By adding a "clip" block to our drive program, we determine the minimum and maximum number or equation can equal out to. This reduces the possibility of an error occurring in the scenario where the value equals something higher than 1 or lower than -1, the motor's max range, which may cause a missed input.

Telemetry

Telemetry helps our robot to communicate to use what it thinks it is doing.

As part of our telemetry function, we have our robot reading out the currentState variable letting us know if the arm/wrist are in manual mode or at one of our various preset positions.

Claw Position shows us if the claw is currently open or closed. The "test" block can be found under the logic menu!

Lastly, our robot provides the current position and power of the arm and wrist. This is helpful for if we need to change a preset or for adding new code using the encoders on the motors!

Programming - OnBot Java Overview

While most of our example program is the same between Blocks and OnBot Java there are a couple differences and some cool parts to the OnBot Java code we want to point out here!

Using "enum" for variables

In the OnBot Java version of this code, we use something called "enum". This allows us to declare the variable name and have it treated as a unique value.

    private enum RobotState {
        INIT,
        INTAKE,
        WALL_GRAB,
        WALL_UNHOOK,
        HOVER_HIGH,
        CLIP_HIGH,
        LOW_BASKET,
        MANUAL
    }

For example: the robot interprets the variable "MANUAL" as one of the states within our switch case in OnBot Java.

With these variables defined we can now have all of our preset positions stored and easily updatable in our state machine:

 // State machine logic
            switch (currentState) {
                case INIT:
                    targetArm = ARM_POSITION_INIT;
                    targetWrist = WRIST_POSITION_INIT;
                    telemetry.addData("State", "INIT");
                    break;
                case INTAKE:
                    targetArm = ARM_POSITION_INTAKE;
                    targetWrist = WRIST_POSITION_SAMPLE;
                    telemetry.addData("State", "INTAKE");
                    break;

                case WALL_GRAB:
                    targetArm = ARM_POSITION_WALL_GRAB;
                    targetWrist = WRIST_POSITION_SPEC;
                    telemetry.addData("State", "WALL_GRAB");
                    break;

                case WALL_UNHOOK:
                    targetArm = ARM_POSITION_WALL_UNHOOK;
                    targetWrist = WRIST_POSITION_SPEC;
                    telemetry.addData("State", "WALL_UNHOOK");
                    break;

                case HOVER_HIGH:
                    targetArm = ARM_POSITION_HOVER_HIGH;
                    targetWrist = WRIST_POSITION_SPEC;
                    telemetry.addData("State", "HOVER_HIGH");
                    break;
                    
                case CLIP_HIGH:
                    targetArm = ARM_POSITION_CLIP_HIGH;
                    targetWrist = WRIST_POSITION_SPEC;
                    telemetry.addData("State", "CLIP_HIGH");
                    break;
                case LOW_BASKET:
                    targetArm = ARM_POSITION_LOW_BASKET;
                    targetWrist = WRIST_POSITION_SAMPLE;
                    telemetry.addData("State", "LOW_BASKET");
                    break;
                case MANUAL:
                    telemetry.addData("State", "MANUAL");
                    break;
            }

Our robot will switch states depending on which button on the gamepad is pressed for the arm/wrist!

Creating a Togglable Button

Within our program there are a few buttons set up to work like a toggle. This means the button only needs to be pressed once rather than held for the code to run. In our Starter Bot code, we're taking advantage of this toggle to have one button be able to do multiple things. For example, our claw can switch between open and closed with just the right bumper.

            // Toggle claw position when right_bumper is pressed
            if (gamepad1.right_bumper && !lastBump) {
                clawOpen = !clawOpen;
                if (clawOpen) {
                    claw.setPosition(CLAW_OPEN_POSITION);
                } else {
                    claw.setPosition(CLAW_CLOSED_POSITION);
                }
            }
            lastBump = gamepad1.right_bumper;

In other programming languages, you might have an option such as "on button pressed", however that's not available to us here so we have to be a little clever to mimic this concept. Our claw is using two simple variables to make this possible.

The variable clawOpen allows the servo to move between its two set positions. At the start of our program this is set to false, but will switch each time the right bumper is pressed.

Meanwhile the variable lastBump checks if the right bumper is currently being held down. If it is set to true, the button is held down so the claw will not move again until it is released, changing the value back to false, then pressed again.

            // Toggle claw position when right_bumper is pressed
            if (gamepad1.right_bumper && !lastBump) {
            //checks if right bumper is pressed AND has been released since last pressed
                clawOpen = !clawOpen;
            //switches the state of clawOpen, this is defined originally during initilization
                if (clawOpen) { 
                //if clawOpen = clawOpen  then open claw, else clawOpen = not clawOpen then close claw
                    claw.setPosition(CLAW_OPEN_POSITION);
                } else {
                    claw.setPosition(CLAW_CLOSED_POSITION);
                }
            }
            lastBump = gamepad1.right_bumper;
            //when right bumper is pressed this will set lastBump to true

Along with the claw, our robot is using a togglable button for retrieving specimens and hooking them on the high rung!

Full Code

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;
import com.qualcomm.robotcore.robot.Robot;
import com.qualcomm.robotcore.hardware.Servo;
import com.qualcomm.robotcore.robot.RobotState;
import com.qualcomm.robotcore.hardware.DcMotor;
import com.qualcomm.robotcore.hardware.CRServo;
import com.qualcomm.robotcore.util.Range;

@com.qualcomm.robotcore.eventloop.opmode.TeleOp(name="StarterBot_V1_Java", group="Linear Opmode")
public class StarterBot2025TeleOpJava extends LinearOpMode {

    // Declare OpMode members.
    private DcMotor leftDrive = null;
    private DcMotor rightDrive = null;
    private DcMotor arm = null;
    private DcMotor wrist = null;
    private Servo claw = null;
    private CRServo intake = null;


    // Arm and Wrist target positions for each state
    private static final int ARM_POSITION_INIT = 300;
    private static final int ARM_POSITION_INTAKE = 450;
    private static final int ARM_POSITION_WALL_GRAB = 1100;
    private static final int ARM_POSITION_WALL_UNHOOK = 1700;
    private static final int ARM_POSITION_HOVER_HIGH = 2600;
    private static final int ARM_POSITION_CLIP_HIGH = 2100;
    private static final int ARM_POSITION_LOW_BASKET = 2500;

    
    private static final int WRIST_POSITION_INIT = 0;
    private static final int WRIST_POSITION_SAMPLE = 270;
    private static final int WRIST_POSITION_SPEC = 10;


    
    // Claw positions
    private static final double CLAW_OPEN_POSITION = 0.55;
    private static final double CLAW_CLOSED_POSITION = 0.7;

    // Enum for state machine
    private enum RobotState {
        INIT,
        INTAKE,
        WALL_GRAB,
        WALL_UNHOOK,
        HOVER_HIGH,
        CLIP_HIGH,
        LOW_BASKET,
        MANUAL
    }

    // Initial state
    private RobotState currentState = RobotState.INIT;

    // Claw toggle state
    private boolean clawOpen = true;
    private boolean lastBump = false;
    private boolean lastHook = false;
    private boolean lastGrab = false;
    
    //target position
    private int targetArm = 0;
    private int targetWrist = 0;

    @Override
    public void runOpMode() {
        // Initialize the hardware variables.
        leftDrive  = hardwareMap.get(DcMotor.class, "leftDrive");
        rightDrive = hardwareMap.get(DcMotor.class, "rightDrive");
        arm = hardwareMap.get(DcMotor.class, "arm");
        wrist = hardwareMap.get(DcMotor.class, "wrist");
        claw = hardwareMap.get(Servo.class, "claw");
        intake = hardwareMap.get(CRServo.class, "intake");

        // Stop and reset encoders
        leftDrive.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);
        rightDrive.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);
        arm.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);
        wrist.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);

        // Set motors to use encoders
        leftDrive.setMode(DcMotor.RunMode.RUN_WITHOUT_ENCODER);
        rightDrive.setMode(DcMotor.RunMode.RUN_WITHOUT_ENCODER);
        
        // Set motor direction
        leftDrive.setDirection(DcMotor.Direction.REVERSE);
        rightDrive.setDirection(DcMotor.Direction.FORWARD);
        //Set zero power behavior
        wrist.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE);
        arm.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE);
        leftDrive.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.FLOAT);
        rightDrive.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.FLOAT);

        // Wait for the game to start (driver presses PLAY)
        waitForStart();

        // Run until the end of the match (driver presses STOP)
        while (opModeIsActive()) {

            // State machine logic
            switch (currentState) {
                case INIT:
                    targetArm = ARM_POSITION_INIT;
                    targetWrist = WRIST_POSITION_INIT;
                    telemetry.addData("State", "INIT");
                    break;
                case INTAKE:
                    targetArm = ARM_POSITION_INTAKE;
                    targetWrist = WRIST_POSITION_SAMPLE;
                    telemetry.addData("State", "INTAKE");
                    break;

                case WALL_GRAB:
                    targetArm = ARM_POSITION_WALL_GRAB;
                    targetWrist = WRIST_POSITION_SPEC;
                    telemetry.addData("State", "WALL_GRAB");
                    break;

                case WALL_UNHOOK:
                    targetArm = ARM_POSITION_WALL_UNHOOK;
                    targetWrist = WRIST_POSITION_SPEC;
                    telemetry.addData("State", "WALL_UNHOOK");
                    break;

                case HOVER_HIGH:
                    targetArm = ARM_POSITION_HOVER_HIGH;
                    targetWrist = WRIST_POSITION_SPEC;
                    telemetry.addData("State", "HOVER_HIGH");
                    break;
                    
                case CLIP_HIGH:
                    targetArm = ARM_POSITION_CLIP_HIGH;
                    targetWrist = WRIST_POSITION_SPEC;
                    telemetry.addData("State", "CLIP_HIGH");
                    break;
                case LOW_BASKET:
                    targetArm = ARM_POSITION_LOW_BASKET;
                    targetWrist = WRIST_POSITION_SAMPLE;
                    telemetry.addData("State", "LOW_BASKET");
                    break;
                case MANUAL:
                    telemetry.addData("State", "MANUAL");
                    break;
            }
            

            // Handle state transitions based on gamepad input
            if (gamepad1.a) {
                currentState = RobotState.INTAKE;
            } else if (gamepad1.b && !lastGrab) {
                if(currentState == RobotState.WALL_GRAB){
                    currentState = RobotState.WALL_UNHOOK;
                }else{
                    currentState = RobotState.WALL_GRAB;
                }
            } else if (gamepad1.y && !lastHook) {
                if(currentState == RobotState.HOVER_HIGH){
                    currentState = RobotState.CLIP_HIGH;
                }else{
                    currentState = RobotState.HOVER_HIGH;
                }
            } else if (gamepad1.x) { 
                currentState = RobotState.LOW_BASKET;           
            } else if (gamepad1.left_bumper) {
                currentState = RobotState.INIT;
            } else if (gamepad1.dpad_up){ //manual control
                currentState = RobotState.MANUAL;
                targetArm += 10;
            } else if (gamepad1.dpad_down){
                currentState = RobotState.MANUAL;
                targetArm -= 10;
            } else if (gamepad1.dpad_left){
                currentState = RobotState.MANUAL;
                targetWrist += 1;
            } else if (gamepad1.dpad_right){
                currentState = RobotState.MANUAL;
                targetWrist -= 1;
            }
            
            lastGrab = gamepad1.b;
            lastHook = gamepad1.y;

            // Toggle claw position when right_bumper is pressed
            if (gamepad1.right_bumper && !lastBump) {
                clawOpen = !clawOpen;
                if (clawOpen) {
                    claw.setPosition(CLAW_OPEN_POSITION);
                } else {
                    claw.setPosition(CLAW_CLOSED_POSITION);
                }
            }
            lastBump = gamepad1.right_bumper;

            // Control intake servo with triggers
            if (gamepad1.right_trigger>0.1) {
                intake.setPower(1.0);
            } else if (gamepad1.left_trigger>0.1) {
                intake.setPower(-1.0);
            } else {
                intake.setPower(0);
            }
            
            //DRIVE Split Arcade
            double drive = -gamepad1.left_stick_y;
            double turn  =  -gamepad1.right_stick_x;
            double leftPower    = Range.clip(drive + turn, -1.0, 1.0) ;
            double rightPower   = Range.clip(drive - turn, -1.0, 1.0) ;
    
            leftDrive.setPower(leftPower);
            rightDrive.setPower(rightPower);
            
            arm.setTargetPosition(targetArm);
            arm.setMode(DcMotor.RunMode.RUN_TO_POSITION);
            wrist.setTargetPosition(targetWrist);
            wrist.setMode(DcMotor.RunMode.RUN_TO_POSITION);
            arm.setPower(1);
            wrist.setPower(1);

            // Send telemetry data to the driver station
            telemetry.addData("Claw Position", clawOpen ? "Open" : "Closed");
            telemetry.addData("Arm Position", arm.getCurrentPosition());
            telemetry.addData("Arm Power", arm.getPower());
            telemetry.addData("Wrist Position", wrist.getCurrentPosition());
            telemetry.addData("Wrist Power", wrist.getPower());
            telemetry.update();
        }
    }
}

Build Tips & Tricks

Compatibility with Starter Kit V3

The 2024-25 REV DUO Starter Bot is designed to be built with the FTC Starter Kit V3.1, however there are only a few parts missing from the Starter Kit V3. Below is the list of parts you will need to add to your Starter V3 to make it compatible with the 2024-25 REV DUO Starter Bot.

Pre-Loading Brackets

UltraPlanetary Overtightening

Making the Chain and Master Links

Squaring Your Assembly

When assembling your Starter Bot, it is important to square up your shafts and extrusion. This will ensure your robot operates smoothly and effectively. To check if your assembly is square you can use a Square tool or if that is not available you can use something with a known 90 degree angle such as a sheet of paper.

Initializing Your Robot

The preset positions, such as "Intake" and "Low Basket," in the default Starter Bot code work using the built-in encoders of the motors. To ensure the robot moves to the correct position for these presets, make sure the robot is powered on while in its initialization orientation.

This orientation is pictured below: arm down and the wrist folded up.

Programing Your Smart Robot Servo

Wire Management

One of the most important steps for a reliable and safe robot is wire management. Wire management involves bundling and routing wires along a defined path to the electrical parts, such as servos and motors. Wires can bundled with zip ties, wrapped in tape, tucked into extrusion, and routed away from moving parts of your robot.

Pinch Points

There are points on the robot that can catch an unconstrainted wire and pinch it causing it to be damaged or disconnected. This is most noticeable with the gears on the arm and the servo wires, however, the arm still needs to move we can not completely constrain the wires.

We recommend using a length of extra wire to form a "service loop", like the one shown above. This loop keeps wires bundled together, and provides a predictable path of movement as your arm pivots.

Strain Relief

Minimizing stress on a wire connection, which is often a two-part connector on FTC Robots, is a great method to avoid wiring getting pulled loose within your control system! Proper strain relief ensures that the wires are not causing unnecessary stress on the connectors and that the connection remains snug.

To add strain relief to your wiring, secure the wire about one or two inches from the connector and leave a bit of slack on the connector side. This helps avoid unintentional tension that could damage the connector and allows for easy disconnection when needed for testing or replacing modules.

Be careful to not leave too much or too little slack on either end of the connection

Too little slack can cause the wires to pull apart
Too much slack can become an entanglement risk

Smart Tug

A "Smart Tug" is a test where you test your wiring by tugging on a wire with a reasonable amount of force to see if it comes undone. The Smart Tug simulates many common scenarios, including a wire getting caught on a field element, actuator, or another robot. It is a good practice to do this test any time you connect a wire to ensure it is fully seated in the connector and secure.

If you perform a Smart Tug on your wire and it becomes disconnected, you can use one of the above methods to secure the wire!

Upgrades!

Dual Gamepads

There are many ways to split robot control across two gamepads. We recommend testing different combinations with your team to decide what feels the most comfortable to you!

This version of the program is intended to be just one example for using two gamepads. Arm and wrist control has been moved to a second gamepad while the main gamepad handles driving and the servos on the intake and claw.

The associated gamepad for a button input can be changed at any time by clicking on the block's dropdown:

Arcade Drive

In this example code, we changed our drive function to only be on the left stick!

You can learn about arcade style of driving in Hello Robot!

When changing a function name this will automatically change throughout the entire code to reflect the new name.

Mecanum Drive

Upgrading to a Mecanum Drivetrain (REV-45-2470) allows for new kinds of movement giving the robot the ability to strafe side-to-side across the field.

For Mecanum Drive each wheel has an individual motor!

The FTC Starter Kit V3.1 can be upgraded to the Mecanum Drivetrain V 1 following this guide.

Upgrading from the FTC Starter Kit V3.1 to Mecanum Drivetrain V2:

The following additional parts are needed:

UltraPlanetary Gearbox Kit & HD Hex Motor - QTY 2
Ultra 90 Degree Gearbox - QTY 4
75mm Mecanum Wheel Set - QTY 1 (set of 4)
M3 x 6mm HexCap Screws 50 Pack - QTY 1
Expansion Hub (QTY 1) OR SPARKmini Motor Controller (QTY 2)

Full build instructions can be found here!

Example Mecanum Drive Program

How a Mecanum Drivetrain is programmed largely depends on the driver's preference for how the controller is configured.

In our provided example, the left joystick controls forward/back and strafe then the right joystick controls turning. This code is based on the sample provided by FIRST in Blocks (BasicOmniOpMode).

Mecanum Demo Blocks Code:

Mecanum Configuration File:

Mecanum Configuration - Control Hub and Expansion Hub

Mecanum Code Breakdown

Before diving into mecanum, double check the direction your motors and wheels are turning. They may need to be reversed if you're experiencing jittering or inverted controls!

At the very beginning of our program the drivetrain motors are set to RUN_WITHOUT_ENCODER.

We need to create some new variables in order to use mecanum. Let's break those down first:

At the beginning of the MECANUM_DRIVE function, our variables for each movement direction are being set to the value generated by the movement of the matching joystick axis.

Since we now have four motors in play, our equation for setting the appropriate power to each motor gets a little more complicated.

Our robot first needs to determine the combined movement of the left stick then calculate with the right stick's value. This allows for movement when the left joystick is at an angle, such as strafing along a diagonal!

Next, similar to our original drivetrain code, there's a chance a value may fall outside the range of the motor's power (-1 to 1). Therefore, we want our robot to check and bring those values back into range so we don't miss any inputs.

For our last step, our robot sets the power of each pair of motors based on all our calculations!

Tips, Tricks, & Upgrades Video Walkthrough

Starter Bot Changelog 2024-25

Changes made to any of the 2024-25 REV DUO FTC Starter Bot Documentation will be listed below. Check back for updates as the season progresses!

Version

Release Date & Notes

CENTERSTAGE 2023-2024

Starter Bot - CENTERSTAGE

We are excited for teams to get started building the 2023-24 REV DUO FTC Starter Bot! Please keep this page bookmarked for future updates and more ideas for building a robot that can play the 2023-2024 FTC Game, CENTERSTAGE.

Documentation Links

Build Guide - PDF Download

Bill of Materials

Full Bill of Materials (BOM) - Excel Download

Full Robot

Substructures

Tower

Arm

Gripper

Programming Teleop

Configuration

Before getting started with programming we needed to create a configuration file. Below is an overview of how the robot is configured for the teleop code to function as expected:

Port Type

Port Number

Device Type

Name

Configuration file download

To put this configuration file on your robot, drag this file into the "FIRST" folder of your Control Hub's file system.

For more in-depth information on the configuration process check out !

Wiring Diagram

Gamepad Setup

Items to consider when mapping out your gamepad:

What kind of input does the mechanism need?
What drivetrain are you using and what driving style do you want to use?
- We decided our robot for CENTERSTAGE would be driven with Split Arcade Drive for advantages in precision while driving.
Which input makes the most sense?
- There are multiple buttons in play for this year's Starter Bot. Both bumpers control the gripper's ability to pick up Pixels. The wrist servo is bound to the "A/Cross" and "B/Circle" buttons for rotating between the intake and home position. Lastly, this year's arm is controlled by the triggers.

Not all gamepads have buttons labeled the same way. Check the manufacturer's documentation for accurate button mapping.

2023-24 REV DUO FTC Starter Bot Gamepad Layout:

Programming Teleop - Blocks

Let's break down the Blocks Code for CENTERSTAGE!

Establishing Variables:

This year's Starter Bot makes use of a lot of variables.

Setting Up Encoders:

This code runs AFTER the initialization is activated, but BEFORE the play button is clicked.

This section allows the encoder on the arm Core Hex Motors to be reset to zero on start up and establishes their default behavior. Additionally, this sets two of the motors to run in reverse, one on the drivetrain and one of the arm motors.

This code will run ONCE after the play button is activated.

This section acts as an additional check for resetting the arm's power and position as well as setting the Core Hex Motors to "RUN_TO_POSITION" mode as default when the play button is clicked.

Split Arcade Drive:

The following sections all run REPEATEDLY in the "while loop" once the play button is activated.

Let's begin with programming our Split Arcade Drive. This code will take input from the right and left joysticks to determine the robot's movement. The left joystick controls forward and back, while the right stick controls left and right turning movement.

Manual Arm Movement:

The triggers on the controller determine the direction of the arm's rotation. The arm's power is determined by how far down both triggers are pressed. Additionally, the if/then statement switches the arm between manual drive and being ready to run the preset positions.

Arm and Wrist Preset Positions:

There are three preset positions for the arm and wrist on the Starter Bot- intake, home, and scoring.

Re-zero Encoder:

When you re-zero the encoder the arm and wrist should be in the HOME position.

Watchdog to Shutdown Motor in Home Position:

This check prevents the Core Hex Motors from continuing to run while in home position to prevent potential overheating.

Let's take a closer look at all the parts of this if/then statement:

This if/then statement will only run if all the following are met:

The arm is not currently moving in manual mode from the triggers being pressed
The motors are actively on
The left Core Hex Motor's current and target position are less than or equal to the threshold (currently set to five)
- Home position's value is set to 0 while Intake is set to 10

Gripper Controls:

When either or both of the bumpers on the controller are held down the gripper will open fully. When released it will return to the closed position to secure the fingers around the pixel.

Programming Teleop - OnBot Java

Full Robot Code

To use this code with your Starter Bot, copy and paste it into a new OnBot Java OP Mode!

Building Tips & Tricks

Check out the following video for some Tips and Tricks when building the 2023-24 REV DUO FTC Starter Bot:

We strongly recommend checking that your wires are secure for the arm, gripper, and wrist and bound to a location where they cannot be sliced by extrusion or a pinch point.

Programming Breakdown

The following video provides a breakdown of the provided code example for the 2023-24 Starter Bot!

Upgrades

Mecanum Drive

Upgrading to a (REV-45-2470) allows for new kinds of movement giving the robot the ability to strafe side-to-side across the field.

For Mecanum Drive each wheel has an individual motor!

Upgrading from the FTC Starter Kit V3 to Mecanum Drivetrain V2:

The following additional parts are needed:

Example Mecanum Drive Program

This example code uses a different configuration than the Starter Bot's provided code! Please make sure to update both your program and the configuration file through the Driver Station.

Adding Independent Wrist Movement

Below are a couple examples for adding wrist movement using the existing variables:

These examples are meant to replace the use of presets in favor of manual control of the arm and wrist.

Blocks:

Example 1:

This option functions similar to the gripper using the two preset positions. If "Up" on the Dpad is held down then the wrist will move and stay in the up position. When released, it will return down.

Example 2:

This option breaks the movement apart to move up or down when the matching button is pressed once on the Dpad. The button does not need to be held for it to remain in the set position.

OnBot Java:

Example 1:

Example 2:

Starter Bot Changelog

Changes made to any of the 2023-24 REV DUO FTC Starter Bot Documentation will be listed below. Check back for updates as the season progresses!

Version

Release Date & Notes

POWERPLAY 2022-2023

Starter Bot - POWERPLAY

For the POWERPLAY season FIRST asked us at REV to help develop an introduction robot for newer teams, completely built out of the FTC Starter Kit V3 (), that is able to play the game to some level of success. To design this robot we went through a similar process as we did with kickoff concepts and that works with our teams.

We hope the above downloads help provide a launching off point for new teams and veterans to see some ways to build using REV DUO parts!

Alternative Control Hub Placement

If you are experiencing trouble wiring your Control Hub to the Core Hex Motors (REV-41-1300) driving the lift on your Starter Bot, try the following placement of your Hub.

Starter Bot - Programming Teleop

Basic Teleop Strategy

Our strategy for teleoperated mode was to make driving the robot as intuitive and precise as possible. Navigating carefully through the grid of Junctions is important for gameplay so we decided to use Split Arcade Drive this year.

Since the Junctions are mounted on springs and can move or change height freely, we found the best method to control the Lift mechanism was to not use preset levels. This allows us to easily raise cones to any height needed.

Configuration and Wiring

Before getting started with programming we needed to create a configuration file. Below is an overview of how the robot is configured for the teleop code to function as expected:

For more in depth information on the configuration process check out !

Wiring Diagram

Assigning Controls to a Gamepad/Controller

Items to consider when mapping out your gamepad:

What kind of input does the mechanism need?
What drivetrain are you using and what driving style do you want to use?
- We decided the POWERPLAY Starter Bot would be driven with Split Arcade Drive for advantages in precision while driving.
Which input makes the most sense? Would pressing up on the d-pad be more intuitive for moving your arm up or down?
- We chose to assign our D-Pad inputs to raising and lowering our lift and the right bumper to releasing Cones from the intake.

POWERPLAY Starter Bot controller layout:

Not all controllers have buttons labeled the same way. Check the manufacturer's documentation for accurate button mapping.

Programming Teleop - Blocks

Drive Code

We opted to use split arcade drive during the POWERPLAY season because it allows for forward and reverse movement without worrying about accidentally pushing the joystick in the X-Axis. The POWERPLAY field requires precise movements, and split arcade drive allows teams to have more control and precision.

Similar to the traditional arcade style driving tutorial, we will use the Dual Motor block to assign power values to our motors.

Remember to reverse one of the motors and negate the values on the Y-Axis of your joysticks.

Lift Code

For all of our button inputs we used an if/else statement. In the image below you can see the code for pressing the DPad. When DPadUp is pressed, both Core Hex Motors set power to -1, which moves the lift upwards. When DPadDown is pressed, the Core Hex Motors change their power to 0.8, which moves the lift downwards.

Remember that when it comes to coding your robot, the Y-Axis is -1 at its topmost point, and +1 at its bottommost point, unless you negate values.

Intake Code

The Starter Bot's compact active roller intake features one servo motor-driven roller paired with a free spinning roller. To make sure we keep a good grip on the Cone, the intake is always running inwards. This means we need to reverse the direction of the servo to release the Cone once the robot is in position to place it.

For the intake, we chose to use the RightBumper to control the direction and speed of the motor spinning the mechanism. In order to tell the intake to increase power when RightBumper is pressed, an if/else statement needs to be used.

As you can see, if you press the RightBumper, the intake sets its power to max. Otherwise, the intake power is set to 0.3.

Complete Blocks Program

Below is the complete Blocks Program for the POWERPLAY Starter Bot.

Game Breakdown

Game Introduction

The 2022-2023 FTC season game is POWERPLAY. The POWERPLAY challenge features game elements such as Cones, Junctions, Substations, and Terminals. At the start of the match, each robot begins against their alliance wall and is able to be pre-loaded with one cone. Once the match starts, teams race to score cones and create circuits during the thirty second autonomous period followed by the two minute driver controlled period. During the last thirty seconds of the match called the end game, teams continue to score cones and have the opportunity to cap a junction with a beacon and park in their alliance's terminal for extra points. See the scoring summary below for more information on the game objectives.

Scoring Summary

The following table shows the possible scoring achievements and their point values. The table is a quick reference guide and not a substitute for a thorough understanding of the game manual. All achievements are scored at rest.

Field Layout

If you are unfamiliar with the game field structure the following view can give insight to the different elements and their locations.

Game Breakdown

The first step to any good FTC Game strategy is a full, in-depth understanding of the game. Strong knowledge of scoring achievements, point values, and game rules help teams develop a game strategy that maximizes their scoring ability. Once the knowledge is built the game can be broken down into data points for analysis.

A commonly used metric in the competitive robotics world is points per second. Basing your game strategy based on the amount of points you can gain per second (or even per game period), will help your team make the mechanical choices best for you!

Remember to always strategize and build within your resources! Not all teams will have access to the same resources, whether it is parts or people. A strategy that seems to yield the most points per second on paper may not be as successful as a strategy that focuses on maximizing accuracy.

The following section will breakdown the major scoring achievements of the game as well as provide some of the strategic considerations, we at REV noticed. While this breakdown may provide you with a basic knowledge of this years game it is always advised to consult Game Manual Part 2 to better understand the rules.

Autonomous

Navigating

Most FTC games include some sort of navigation or parking task in the autonomous period and this years game is no different. Typically, these are autonomous scoring achievements where a robot has moved to a particular portion of the field and parked. Adding to the navigation challenge this year is the Signal Bonus. Robots will earn extra points when parked completely in the designated zone as indicated by their signal.

To understand the full break down of navigating, it helps to understand how Game Manual Part 2 defines In and Completely in. Once you have a grasp on how these concepts are defined you can make a decision about which navigation achievements will give you the most points per second, when compared against the rest of your autonomous strategy.

Cones

During the Autonomous period of POWERPLAY teams can also earn points by scoring cones. Cones scored in the autonomous period will earn additional points at the end of the Driver-Controlled Period if they remain in place.

Driver Controlled

Directly following the end of the Autonomous Period, Drive Teams have five (5) seconds plus a "3-2-1-go" countdown to prepare their Driver Stations for the start of the 2 minute Driver-Controlled Period. On the countdown word "go," the Driver-Controlled Period starts, and Drive Teams press their Driver Station start button to resume playing the Match.

Cones

During the Driver Controlled period teams strategically place cones on junctions to complete a circuit. All cones placed during the Driver-Controlled period are scored at rest after the match.

End Game

The last thirty seconds of the Driver-Controlled Period is called the End Game. Driver-Controlled Period Scoring can still take place during the End Game and this is when the Beacon (team scoring element) is introduced into the Playing Field.

Junction Ownership

Alliances can earn points for owning a junction by fulfilling one of two conditions:

If both conditions are met, a beacon will take precedence over the top scored cone and the alliance will receive 10 points

Circuit

A completed Circuit earns 20 points for the alliance. Only one circuit can be awarded per match.

See the example of a completed circuit (Red Alliance) and a partial or incomplete circuit (blue) below.

Navigating

Robots that end the match parked in either of the Alliance's terminals will earn 2 points.

Game Elements

Cones

Red and blue rigid plastic cones are game pieces for this years POWERPLAY game. There are 60 cones total on the playing field, 30 red and 30 blue. The average weight of the cones is approximately: 2.55oz

Signal

Similar in size, shape, and weight to the cones, a signal is a non-scorable game piece used to indicate the randomization state. Robots can read the images on a signal, or a team-designed signal sleeve, for additional information at the start of a match.

A Signal is NOT a Cone and cannot be scored!

Beacon

Also known as the Team Scoring Element, a Beacon is a team-designed and manufactured scoring element that is used in the endgame portion of POWERPLAY. Beacons are used to cap and claim ownership of Ground, Low, Middle, and High Junctions.

Junctions

Junctions are the main location for scoring Cones to create a Circuit. There are four types of Junctions on the POWERPLAY playing field.

Ground Junction: Plastic disc that is molded to hold Cones
Low Junction: 13in spring-mounted pole
Medium Junction: 23in spring-mounted pole
High Junction: 33in spring-mounted pole

Junction locations on field

The following images are displayed in different locations around the field perimeter and used for Navigation tasks.

Drivetrain

General Drivetrain Considerations

Field Obstacles and Challenges

The grid of Junctions on the POWERPLAY field is the largest field obstacle for this season. Ground, Low, Medium, and High Junctions spaced in a 2ft grid can limit the amount of space your robot has to navigate the field. There are floor obstacles as well- the Ground Junctions. The Ground Junctions are 0.56in tall with a recessed portion that drivetrains can get stuck on if they do not have the necessary clearance. However, once a Cone has been scored on a Ground Junction, you can no longer drive over the Junction.

Robot Size Restrictions

Robot rules have mainly stayed the same for this years game. The main constraint is the starting 18" x 18" x 18" sizing requirement.

Drivetrain Options

While there are many types of drivetrains teams can build, getting a drivetrain up and running as quickly as possible to begin testing should be a priority. This year the two main drivetrains we considered were Differential Drive and Mecanum Drive.

Differential Drivetrain

Mecanum Drivetrain

Other Options

In addition to changing the wheels, you can vary other parts of your drivetrain to change how effective it is for navigating the POWERPLAY field.

One way to do this is to change the size of your frame. If you shrink down your drivetrain, you will have more space to drive around the grid than if you built your robot to the full 18in X 18in dimensions. However, if you do this pay attention to the geometry of your other mechanisms as that will change too.

Starter Bot Drivetrain Update

Using either differential, mecanum, or another drivetrain for a robot will lead a team to success this season. For our prototyping and the final Starter Bot we used the channel drivetrain. In the video below we installed an optional mecanum upgrade to our Starter Bot to highlight it's maneuverability on this years field.

Lifts

The varying heights of the Junctions create a challenge for placing cones that can be solved with a vertical movement from your robot. When designing these lifts, we decided to try three popular categories of Lifts used commonly in FTC: Linear Lifts, Single Jointed arms, and a Four Bar Linkages.

Requirements

Simple, Reliable, Compact - we want something that fits within the 18"x18"x18" starting requirement, is easy to build and consistently scores at all levels
Bear a Light Load - The mechanism has to be able to handle the load of the intake and a single cone or Beacon.

Lift Prototypes

Elevator

We started exploring designs with our Linear Motion Kit. We made a few modifications to the two stage continuous lift to create the elevator below. While it is fairly easy to build and deploy, this lift is not capable of reaching the high junctions. However, you may be able to add on another stage to gain more height. Also, the Linear motion kit can be used for horizontal motion too, as seen in our Lift Prototypes video above.

Single Jointed Arms

A Single Jointed Arm is one of the simplest solutions for a lift. We knew from past experience that this arm would struggle to reach the high junctions and fit within the 18"x18"x18" size restraint. It is important to pay attention to your geometry calculations when building a Single Jointed Arm so you can maximize your reach. This version of the arm was also a little heavier than we wanted, which may cause balance issues with a more narrow or smaller drivetrain.

Four Bar Linkage

Four Bar Linkages are very similar to Single Jointed Arms because they both pivot around a single point. You will run into similar issues with what height they can reach so be sure to pay attention to your geometry calculations! However, Four Bar Linkages are unique because they maintain the orientation of the object they are lifting. This is very useful for POWERPLAY when lifting a standing cone. As the lift rises, the cone will remain parallel to the plane it started in, remaining upright.

Reverse Virtual Four Bar

A Reverse Virtual Four Bar Linkage is a two-stage lift where the second stage is actuated by a four bar arm. Because the lift folds back on itself, you can reach almost twice as high as a single jointed lift. The Virtual Four Bar is created by the chain and it helps keep the end of the lift traveling along one plane. This keeps whatever you are raising in an intake oriented correctly for the whole lift.

The Kickoff Concepts team really liked this lift so we mounted our Compact Active Roller Intake to the end for our Starter Bot testing. It is mounted on a hinge so that the lift will keep the cones upright, but we will still have the needed compliance for lining up to intake cones.

Freight Frenzy - 2021-2022

Starter Bot - Programming Teleop

Basic Teleop Strategy

Our strategy for teleoperated mode was to make driving the robot as intuitive as possible. Having certain actions pre-programmed and assigned to buttons, like moving the arm into position to score on level 2 of the Shipping Hubs, will make the robot easier to control.

We decided to have buttons assigned to all 3 levels of the Shipping Hubs while scoring from the front and levels 2 and 3 from the back of the robot. Another decision we made was to have the intake motor controlled by the triggers. We chose to control the intake this way so that we could drive and pick up Freight at the same time.

Configuration and Wiring

Before getting started with programming we needed to create a configuration file. Below is an overview of how the robot is configured for the teleop code to function as expected:

For more in depth information on the configuration process check out !

Wiring Diagram

Assigning Controls to a Gamepad/Controller

Items to consider when mapping out your gamepad:

What kind of input does the mechanism need?
What drivetrain are you using and what driving style do you want to use?
- We decided the Freight Frenzy Starter Bot would be driven tank style.
Which input makes the most sense? Would pressing up on the d-pad be more intuitive for moving your arm up or down?
- We chose to assign our backwards scoring presets to the bumpers because we liked the idea of backwards controls being on the back of the controller.

Not all controllers have buttons labeled the same way. Check the manufacturer's documentation for accurate button mapping.

Freight Frenzy Starter Bot controller layout:

Programming Teleop - Blocks

Drive Code

Remember to reverse one of the motors and set the correct direction for forward movement of your robot. In our code we needed to reverse both motors with the dual drive block.

Freight Delivery Mechanism Control Code

For all of our button inputs we used an if/else statement. In the image below you can see the first two sections, one for setting the position of the arm to the ground and one for setting it to the height of level 1 on the Shipping Hub.

Carousel and Intake Mechanisms Control Code

For the intake, we chose to use the triggers to control the speed of the motor spinning the mechanism. Since the triggers are easy to accidentally bump when holding the controller we decided we would only count the action as active if it was more than half way pressed. You can see this in the blocks intake mechanism code where the value of the right/left trigger is compared to 0.5.

Complete Blocks Program

Below is the complete Blocks Program for the Freight Frenzy Starter Bot.

Programming Teleoperated - OnBot Java

Drive Code

Be sure to reverse one of the motors and set the correct direction for forward movement of your robot. In our code we needed to reverse both motors with the dual drive block.

Freight Delivery Mechanism Control Code

For all of our button inputs we used the if/else statement shown below:

Carousel and Intake Mechanisms Control Code

For the intake, we chose to use the triggers to control the speed of the motor spinning the mechanism. Since the triggers are easy to accidentally bump when holding the controller we decided we would only count the action as active if it was more than half way pressed. This is what the statementgamepad1.right_trigger>0.5)?1:((gamepad1.left_trigger>0.5)?-1:0); is used to achieve.

Complete OnBot Java Program

Below is the complete OnBot Java Program for the Freight Frenzy Starter Bot.

Game Elements

Freight

This years game comes with a series of different game elements that fall into the Freight category: Cargo, Boxes, and Ducks. Each type of freight varies in size, shape, and material, which may effect mechanism design. An added challenge to calculate for is that boxes come in three different weight classes.

Cargo

Cargo is a standard Wiffle Ball, used in past seasons of FTC (such as Rover Ruckus). From past seasonwe know that the material for the cargo is going to be a rigid plastic.

Boxes

Boxes (also known as an FTC Blocks) are also making a reappearance this season along with the Wiffle Ball. Boxes are 2" x 2" x 2" cubes made of polypropylene, a rigid plastic material.

One of the key components of Boxes is that they come in different weight classes: Light, Medium, and Heavy. Pre-load Boxes fall in the same weight class as Light Boxes

Box weights can have a massive advantage in the balancing or unbalancing of the Shipping Hub. It will also affect mechanism design as you will have to account for any additional work your mechanism will have to perform to pick and place one of the heavier boxes.

Ducks

Ducks are somewhat of an outlier this season. From what we can tell they are a standard rubber duck, which makes the much more pliable than the other game elements. When designing for a mechanism you may need to do additional intake testing.

Shipping Hubs

In Freight Frenzy there are two Game Elements under the classification of Shipping Hub. Both the Alliance Shipping Hub and the Shared Shipping Hub, are 21" tall, structures, that balance on on a rounded base. On of the key objectives of gameplay is the status of the Shipping Hubs at the end of each match. To gain this scoring achievement the Alliance Shipping Hub must be balanced and the Shared Shipping Hub must be unbalanced in the favor of your alliance

Alliance Shipping Hub

The Alliance Shipping Hub has three scoring levels, for placing freight. The image above explains the diameter of each level as well as its distance from the playing field floor. This information is good to know for design of a Freight delivery mechanism. However, one other consideration to make is the difference in diameter between each level.

For instance, level 1 and level 2 have a 3 inch different in diameter. Which means that, since all levels are centered around a center pole, level 1 and level 2 have a difference of 1.5 inches all the way around the Shipping Hub. A robot will need to be able to account for the difference when attempting to reach another level.

Finally, the dimensions surrounding the top of the center pole of the Shipping Hub are need to calculate for capping a Team Shipping Element. After some analysis, we believe one of the best designs for a Team Shipping Element would be to create something that can be capped on the 1.3" diameter of the center pole, while also have roughly the same dimensions so that it can be easily capped on top of.

Shared Shipping Hub

Unlike the Alliance Shipping Hub, the Shared Hub only has one scoring level. The focus with this particular Shipping Hub is unbalancing it in your alliances favor.

Carousel

The Carousel is an alliance specific Game Element located in the corner of the Audience Side and Alliance Station Side of the field. To deliver ducks to the field, a robot must rotate the carousel until the sweeper plate knocks the duck onto the field. Robots can only interact with the rim of the carousel in order to rotate it.

Barriers

Another Challenge of Freight Frenzy are the Barriers. In order to access the Warehouses and the Shared Shipping Hub, robots must cross over the barriers or move through the 13.7" to 13,75" space between the edge of the barrier and the field wall.

Each Barrier is made up of two poles connected by the end pieces as shown above. Somethings to be aware of when deciding on your drivetrain design:

The Center to Center Distance between poles (4.5 inches)
The Distance from the playing field floor to the top of the poles (1.26 inches)
The distance from the playing field floor to the top of the end pieces (2.2 inches)

Intake

Since Freight Frenzy's possession and control rule limits robots to one piece of freight at a time, one of the keys for success is the intake mechanism. Intakes can take many forms, so we brainstormed some concepts and put them through the engineering design process to help us decide on an intake that met our gameplay requirements

Requirements

Touch it, own it - Be able to quickly intake and control freight
Adaptable - Be able to pick up all the different types of freight
Pick up one - reduces the chances of picking up more than one freight
Release it - be able to outtake the element with ease

Scoop Intake

Once we identified our requirements for an intake, one of things to come to mind as a potential mechanism was some sort of gripper. We started with a Class Bot claw to do initial testing. However we had some issues with grabbing cargo and ducks.

With the variance in size and shape of each of the different types of freight, we decided to take inspiration from claw machine claws. However, while claw machine claws are capable of picking up objects of different sizes and shapes, they aren't great at retaining objects. By playing with the idea of a claw machine we came up with the idea to create a scoop mechanism. The idea was to have a mechanism attached to a cage. The scooper extends out to direct freight into the cage and retain them in place while the robot moves to a shipping hub.

After designing and building the mechanism, we put it to the test to determine if it met our requirements. The scoop was great at directing and intaking the cargo, but struggled to intake the boxes and ducks. There are a few fixes to this design that would get it to work more efficiently, such as replacing the servo with a motor to get more power on the scoop. While, this alternative may elevate the design to more successfully grab the other freight, lets explore some of other options.

Roller Intakes

To evolve our intake into something that meets the requirements we set, we took a look at the prior FTC games that the cargo and boxes were used in, particularly the 2019 game Rover Ruckus. One of the most common and efficient intake types during those seasons were some sort of roller intake.

We used an intake prototype from last years kickoff concepts, and iterated three total designs: one with traction wheels, one with a corrugated plastic flapper, and one with surgical tubing. We tested each roller intake to determine over all compliance and effectiveness. From this we found that the flapper was the the relatively level of compliance we needed.

We used a sheet of corrugated plastic that leverages behind each type of freight to intake and outtake them. The benefit of using corrugated plastic as the intake is the ability to adjust compliance. In our case we cut our corrugated plastic piece so that the side that interfaces most with freight is parallel to the ridges of the plastic. We then folded along the ridges of the plastic. This made the corrugated plastic more compliant, which increased the intakes speed and accuracy.

We still wanted to evolve our designs and find a better more robust intake. So after this initial test we went back to the drawing board to further iterate.

Side Roller Intake

After trying out the Scoop Intake, we decided to explore roller intakes. One of the benefits of roller intakes over grip intakes, like the Scoop, are their ability to direct game elements. This time we took inspiration from car wash rollers. The side rollers on car washes not only clean the car, but help direct it along the track.

Using this idea we created the "Side Roller Intake". The Side Intake utilizes two rollers, both made using a combination of REV Sprockets and Polycord.

During the testing process the Side Roller Intake, grabbed and released boxes quickly and efficiently. However, in order to grab cargo, the cargo had to be pushed up against a wall; otherwise the intake knocked cargo out of the way rather than intaking it.

In the Ultimate Goal season we explored side rollers and had some concerns about how they packaged into the robot. Some of those same concerns came up with the intake.

Size - Side Roller was difficult to package within the limits of our drivetrain
Weight - The weight of the Side Roller, when attached to an arm, caused instability

There were some other issues with this design including: lack of mounting space to attach the intake to an arm and the fact that the arm picks up more than one game element. To address these issues, move standoffs to decrease the size of the storage for the intake or add other structural components to mount off of.

Building the Sprocket Wheel Assembly

Belt segments should be a bit longer than needed. It’s easier to cut down than replace the loop.

Add 20mm screws in the corners of the motion pattern on a 32 Tooth Metal sprocket
Create three polybelt loops using zipties. Place them on alternating screws.
Add a 26 Tooth Plastic Sprocket to the assembly. Then create and add the three more polybelt loops, on the opposite screws to where the bottom loops were places.
Add another 32 Tooth Metal Sprocket and nuts to the assembly
Cut the zipties and pull the belts so each loop rests against the screw and is equal distance from the others.
Tight screws until belts a significantly compressed and can not shift around at all.

Top Roller Intake

We decided to create a top roller intake as well. Choosing to do a top roller allowed us to gain the benefits of a roller intake while taking up less space than the side roller intake.

The top roller intake we created uses our compliant wheels with a 5mm Hex Insert. We also created a spring loaded jaw using M3 Standoffs and surgical tubing. The compliance and strength of this mechanism meets all of our requirements. It is able to intake and outtake all three freight quickly and and reduces the chance of picking up more than once piece of freight.

Ultimate Goal - 2020-2021

Programming Autonomous

Basic Autonomous Strategy

When we were planning for this years kickoff concept one thing we really wanted to address was the accessibility of autonomous scoring achievements. Certain barriers of entry to autonomous programming keep teams from scoring points during the autonomous period. What are these barriers? In our experience as FTC alumni and mentors, time and programming knowledge are the major reasons teams don't create autonomous programs. If a team feels like they don't have the time or skills, programming an autonomous can seem overwhelming. However, many autonomous scoring achievements, like navigation, are easily obtainable objectives that do not require a deep knowledge of programming.

After identifying this as a goal, analyzing the game, and laying out what a starter bot would look like; we decide to explore what a basic autonomous would be for the Freight Frenzy season. There are two major task we feel are achievable.

Placing the Pre-Load Box on level 1 of the Alliance Shipping Hub
Navigating to the Warehouse

As you may recall from the Game Breakdown, each robot must start with a pre-loaded box. For this season's randomization element, a robot determines what position the barcode is in and places the pre-loaded box on the corresponding level of the shipping hub. Using a vision component, like a webcam, to determine the position of the barcode is a more advanced programming concept. However, since placing freight on any level of the alliance shipping hub is worth 6 points (regardless of level), we think that placing the block on the 1st level of the shipping hub is an attainable task. This objective also comes with a 33% chance of getting the autonomous bonus.

Once we decided on placing the pre-loaded box the next decision to make was where to navigate: the warehouse or the storage unit. We chose the warehouse for a few different reasons. Parking in or completely in the warehouse is worth more points that parking in or completely in the storage unit. The warehouse also has a larger surface area than the storage unit, which means that less tuning is needed to get completely in.

We want to start with these two tasks for ease of access reasons. The important thing with programming is to work incrementally. Setting starting tasks allows us to focus on one section of the autonomous at a time, rather than get overwhelmed attempting to solve all the pieces. After tuning and working our autonomous to the point that we want, we can look at other tasks, like adding duck delivery to our lists of tasks.

Autonomous Path

Once we identified what objectives we wanted to achieve in autonomous we created a a basic path. We decided to have the robot start on the red alliance side of the field near the carousel. From there we identified the following basic elements of the path:

Go to shipping hub and drop off the pre-loaded box
Head towards Warehouse and straighten out
Drive into warehouse and park

This path design is for a red alliance autonomous. Adjustments will need to be made to create blue alliance autonomous.

We know from our mockups for the basic starter kit robot that we want a differential drivetrain, single jointed arm, and roller intake. A differential drivetrain combined with limited the amount of space between the shipping hub and the field wall, makes turning in that space difficult. There is also a risk of the arm knocking into the shipping hub. Taking into consideration what the basic robot design was we knew we needed to make some adjustments to our path.

Path 1
- Drive towards shipping hub
- Turn slightly
Path 2
- Lift arm to level 1 height
- Get closer to shipping hub while arm is still lifted
- Outtake pre-loaded box
Path 3
- Reverse towards towards storage unit
- Turn slight to angle towards warehouse
Path 4
- Drive into warehouse
- Park

Programming Autonomous - Blocks

This section makes the assumption that you have learned some of the FTC programming basics by going through the Hello Robot guide. If you have not gone through this guide please walk through it before proceeding.

In the Hello Robot - Encoder Navigation, we covered how to useRUN_TO_POSITION to create paths for the Class bot. We decided to use the same basic concepts to create the path for the Freight Frenzy autonomous. To start we created the code for the first path.

Like with the Encoder Navigation guide, we created several constant variables to convert from encoder ticks per rotation of the HD Hex Motors (drivetrain motors) to ticks per millimeter traveled. We further converted this value to ticks per inch traveled. TheDRIVE_GEAR_REDUCTION variable was created by following the same guidelines from the Total Gear Reduction formula; using our planned gear ratios for the motor gearboxes and for transmitting motion to the wheels.

Another change we made was to howrightTarget and leftTarget are calculated. To reduce the need to useSTOP_AND_RESET_ENCODER mode before each path, we instead take the current position of the motor encoders and add the calculate ticks needed to go to target to the current position.

Once we had a general idea of the first path down and tested, we knew we were going to have to repeat the following segment of code for each path that requires the robot to drive.

This is a rather large segment of code, while duplicating it would allow us to repeat it, we decided instead to move it into a function. Functions in programming, much like mathematical functions, are a set of instructions that are bundled together to reach a particular goal. Since we are using the same (or similar) set of instructions to create each drive path, we can reduce clutter by creating a function that allows us to repeat these actions over and over again.

Lets start by creating a function called drive.

Before creating our function we looked at what information in our instructions needs to be editable. Each path will have a different target distance and we may want to change the speed the robot is running. Knowing this we create three parameters:power, leftInches, andrightInches. By adding parameters we are requiring that each instance of the function must be given a value for power (or speed) and the number of inches we want each motor to move.

Now that we have the basics of our function we can add in the motor code.

The parameter that we pass through the function act similar to variables. We used the rightInches and leftInches parameters to help us calculate the target position. We also use power to set speed.

With the function created we removed the motor code from our main op mode and reference the function instead. To confirm the function worked as expected we passed the parameter we knew lined up with the first path.

The leftInches and rightInches parameters are set to different values. We did this so that the robot would move in a relatively straight line and then turn slightly. For more information on the part speed and direction play in how drivetrains move, check out our Robot Navigation guide.

From here we can work to create our other paths. We know the next action we need to make is to lift the arm and hold that position. We know that RUN_TO_POSITION alone will not hold the arm for the amount duration needed to move forward and outtake the pre-loaded box. So we used the elapsed time function to do path 2.

We did some testing with the elapsed time solution. While it was able to score consistently, there are some flaws with this solution. Since path two is included in a loop the reference to our function, repeats itself; meaning that the drivetrain moves forward twice before the condition of the loop is met. In general, a flaw of using elapsed time, is that basing movement on time isn't a guarantee for consistency. That being said, in testing and refining our code to our robot we were able to score the pre-loaded box about 80% of the time. This met our basic standard for our autonomous.

Once we had path two figured out, we were able to do some basic testing to create paths 3 and 4 using our function.

This basic code allowed us to achieve our basic autonomous strategy. Bare in mind that we generated the power, rightInches, leftInches, and elapsed time numbers doing basic testing with our Class Bot and then made some assumptions from the other mechanisms we made. You will need to make adjustments based on your own mechanisms and hardware components To fine tune this code for your robot, test the code and adjust the number accordingly for the best results. Good luck!

Programming Autonomous - OnBot Java

@Autonomous
public class FreightFenzy_REDAuton1 extends LinearOpMode {

  private DcMotor RightDrive;
  private DcMotor LeftDrive;
  private DcMotor Arm;
  private DcMotor Intake;
  
  //Convert from the counts per revolution of the encoder to counts per inch
  static final double HD_COUNTS_PER_REV = 28;
  static final double DRIVE_GEAR_REDUCTION = 20.15293;
  static final double WHEEL_CIRCUMFERENCE_MM = 90 * Math.PI;
  static final double DRIVE_COUNTS_PER_MM = (HD_COUNTS_PER_REV * DRIVE_GEAR_REDUCTION) / WHEEL_CIRCUMFERENCE_MM;
  static final double DRIVE_COUNTS_PER_IN = DRIVE_COUNTS_PER_MM * 25.4;
    
  @Override
  public void runOpMode() {

    RightDrive = hardwareMap.get(DcMotor.class, "RightDrive");
    LeftDrive = hardwareMap.get(DcMotor.class, "LeftDrive");
    Arm = hardwareMap.get(DcMotor.class, "Arm");
    Intake = hardwareMap.get(DcMotor.class, "Intake");

   // reverse left drive motor direciton
    LeftDrive.setDirection(DcMotorSimple.Direction.REVERSE);
    
    waitForStart();
    if (opModeIsActive()) {
      // Create target positions
      rightTarget = RightDrive.getCurrentPosition() + (int)(30 * DRIVE_COUNTS_PER_IN);
      leftTarget = LeftDrive.getCurrentPosition() + (int)(15 * DRIVE_COUNTS_PER_IN);
      
      // set target position
      LeftDrive.setTargetPosition(leftTarget);
      RightDrive.setTargetPosition(rightTarget);
      
      //switch to run to position mode
      LeftDrive.setMode(DcMotor.RunMode.RUN_TO_POSITION);
      RightDrive.setMode(DcMotor.RunMode.RUN_TO_POSITION);
      
      //run to position at the desiginated power
      LeftDrive.setPower(0.7);
      RightDrive.setPower(0.7);
      
      // wait until both motors are no longer busy running to position
      while (opModeIsActive() && (LeftDrive.isBusy() || RightDrive.isBusy())) {
      }
      
      // set motor power back to 0 
      LeftDrive.setPower(0);
      RightDrive.setPower(0);
        }
     }
 }

Another change we made was to howrightTarget and leftTarget are calculated. To reduce the need to useSTOP_AND_RESET_ENCODER mode before each path,; we instead take the current position of the motor encoders and add the calculate ticks needed to go to target to the current position.

Once we had a general idea of the first path down and tested, we knew we were going to have to repeat the following segment of code for each path that requires the robot to drive.

if (opModeIsActive()) {
      // Create target positions
      rightTarget = RightDrive.getCurrentPosition() + (int)(30 * DRIVE_COUNTS_PER_IN);
      leftTarget = LeftDrive.getCurrentPosition() + (int)(15 * DRIVE_COUNTS_PER_IN);
      
      // set target position
      LeftDrive.setTargetPosition(leftTarget);
      RightDrive.setTargetPosition(rightTarget);
      
      //switch to run to position mode
      LeftDrive.setMode(DcMotor.RunMode.RUN_TO_POSITION);
      RightDrive.setMode(DcMotor.RunMode.RUN_TO_POSITION);
      
      //run to position at the desiginated power
      LeftDrive.setPower(0.7);
      RightDrive.setPower(0.7);
      
      // wait until both motors are no longer busy running to position
      while (opModeIsActive() && (LeftDrive.isBusy() || RightDrive.isBusy())) {
      }
      
      // set motor power back to 0 
      LeftDrive.setPower(0);
      RightDrive.setPower(0);
  }

Lets start by creating a function called drive.

//drive function
private void drive() {

  }

// drive function intakes 3 parameters
private void drive(double power, double leftInches, double rightInches) {

  }

Now that we have the basics of our function we can add in the motor code.

private void drive(double power, double leftInches, double rightInches) {
    int rightTarget;
    int leftTarget;

    if (opModeIsActive()) {
     // Create target positions
      rightTarget = RightDrive.getCurrentPosition() + (int)(rightInches * DRIVE_COUNTS_PER_IN);
      leftTarget = LeftDrive.getCurrentPosition() + (int)(leftInches * DRIVE_COUNTS_PER_IN);
      
      // set target position
      LeftDrive.setTargetPosition(leftTarget);
      RightDrive.setTargetPosition(rightTarget);
      
      //switch to run to position mode
      LeftDrive.setMode(DcMotor.RunMode.RUN_TO_POSITION);
      RightDrive.setMode(DcMotor.RunMode.RUN_TO_POSITION);
      
      //run to position at the desiginated power
      LeftDrive.setPower(power);
      RightDrive.setPower(power);
      
      // wait until both motors are no longer busy running to position
      while (opModeIsActive() && (LeftDrive.isBusy() || RightDrive.isBusy())) {
      }
      
      // set motor power back to 0
      LeftDrive.setPower(0);
      RightDrive.setPower(0);
    }
  }

The parameter that we pass through the function act similar to variables. We used the rightInches and leftInchesparameters to help us calculate the target position. We also use power to set speed.

With the function created we can remove the motor code from our main op mode and reference the function instead. To confirm the function worked as expected we passed the parameter we knew lined up with the first segment.

  @Override
  public void runOpMode() {

    RightDrive = hardwareMap.get(DcMotor.class, "RightDrive");
    LeftDrive = hardwareMap.get(DcMotor.class, "LeftDrive");
    Arm = hardwareMap.get(DcMotor.class, "Arm");
    Intake = hardwareMap.get(DcMotor.class, "Intake");
   
   // reverse left drive motor direciton
    LeftDrive.setDirection(DcMotorSimple.Direction.REVERSE);
    
    waitForStart();
    if (opModeIsActive()) {
    
      // segment 1 
      drive(0.7, 30, 15);
    }
}

 static final double HD_COUNTS_PER_REV = 28;
 static final double DRIVE_GEAR_REDUCTION = 20.15293;
 static final double WHEEL_CIRCUMFERENCE_MM = 90 * Math.PI;
 static final double DRIVE_COUNTS_PER_MM = (HD_COUNTS_PER_REV * DRIVE_GEAR_REDUCTION) / WHEEL_CIRCUMFERENCE_MM;
 static final double DRIVE_COUNTS_PER_IN = DRIVE_COUNTS_PER_MM * 25.4;
 
 //Create elapsed time variable and an instance of elapsed time
 private ElapsedTime     runtime = new ElapsedTime();

waitForStart();
    if (opModeIsActive()) {
      
      //segment 1
      drive(0.7, 30, 15);
      
      runtime.reset(); // reset elapsed time timer
      
      //segment 2 - lift arm, drive to shipping hub, outtake freight
      while (opModeIsActive() && runtime.seconds() <= 7) {
        
        //lift arm and hold
        Arm.setTargetPosition(120);
        Arm.setMode(DcMotor.RunMode.RUN_TO_POSITION);
        Arm.setPower(0.3);
        
        //drive forward for 1 second
        while (runtime.seconds() > 2 && runtime.seconds() <= 3) {
          drive(0.4, 4, 4);
        }
        
        //run intake
        while (runtime.seconds() > 4 && runtime.seconds() <= 7) {
          Intake.setPower(-0.6);
        }
      
      // turn off arm and intake
      Arm.setPower(0);
      Intake.setPower(0);
    
      }

Once we had path two figured out, we were able to do some basic testing to create segments 3 and 4 using our function.

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.Autonomous;
import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;
import com.qualcomm.robotcore.hardware.DcMotor;
import com.qualcomm.robotcore.hardware.DcMotorSimple;
import com.qualcomm.robotcore.util.ElapsedTime;

@Autonomous(name = "FreightFenzy_REDAuton1 (Java)")
public class FreightFenzy_REDAuton1 extends LinearOpMode {

  private DcMotor RightDrive;
  private DcMotor LeftDrive;
  private DcMotor Arm;
  private DcMotor Intake;
  
  //Convert from the counts per revolution of the encoder to counts per inch
  static final double HD_COUNTS_PER_REV = 28;
  static final double DRIVE_GEAR_REDUCTION = 20.15293;
  static final double WHEEL_CIRCUMFERENCE_MM = 90 * Math.PI;
  static final double DRIVE_COUNTS_PER_MM = (HD_COUNTS_PER_REV * DRIVE_GEAR_REDUCTION) / WHEEL_CIRCUMFERENCE_MM;
  static final double DRIVE_COUNTS_PER_IN = DRIVE_COUNTS_PER_MM * 25.4;
  
  //Create elapsed time variable and an instance of elapsed time
  private ElapsedTime     runtime = new ElapsedTime();
  
  // Drive function with 3 parameters
  private void drive(double power, double leftInches, double rightInches) {
    int rightTarget;
    int leftTarget;

    if (opModeIsActive()) {
     // Create target positions
      rightTarget = RightDrive.getCurrentPosition() + (int)(rightInches * DRIVE_COUNTS_PER_IN);
      leftTarget = LeftDrive.getCurrentPosition() + (int)(leftInches * DRIVE_COUNTS_PER_IN);
      
      // set target position
      LeftDrive.setTargetPosition(leftTarget);
      RightDrive.setTargetPosition(rightTarget);
      
      //switch to run to position mode
      LeftDrive.setMode(DcMotor.RunMode.RUN_TO_POSITION);
      RightDrive.setMode(DcMotor.RunMode.RUN_TO_POSITION);
      
      //run to position at the desiginated power
      LeftDrive.setPower(power);
      RightDrive.setPower(power);
      
      // wait until both motors are no longer busy running to position
      while (opModeIsActive() && (LeftDrive.isBusy() || RightDrive.isBusy())) {
      }
      
      // set motor power back to 0
      LeftDrive.setPower(0);
      RightDrive.setPower(0);
    }
  }


  @Override
  public void runOpMode() {

    RightDrive = hardwareMap.get(DcMotor.class, "RightDrive");
    LeftDrive = hardwareMap.get(DcMotor.class, "LeftDrive");
    Arm = hardwareMap.get(DcMotor.class, "Arm");
    Intake = hardwareMap.get(DcMotor.class, "Intake");

 
    LeftDrive.setDirection(DcMotorSimple.Direction.REVERSE);
    
    waitForStart();
    if (opModeIsActive()) {
      
       //segment 1
      drive(0.7, 30, 15);
      
      runtime.reset(); // reset elapsed time timer
      
      //segment 2 - lift arm, drive to shipping hub, outtake freight
      while (opModeIsActive() && runtime.seconds() <= 7) {
        
        //lift arm and hold
        Arm.setTargetPosition(120);
        Arm.setMode(DcMotor.RunMode.RUN_TO_POSITION);
        Arm.setPower(0.3);
        
        //drive forward for 1 second
        while (runtime.seconds() > 2 && runtime.seconds() <= 3) {
          drive(0.4, 4, 4);
        }
        
        //run intake
        while (runtime.seconds() > 4 && runtime.seconds() <= 7) {
          Intake.setPower(-0.6);
        }
      
      // turn off arm and intake
      Arm.setPower(0);
      Intake.setPower(0);
      
      //segment 3 - reverse to get better angle 
      drive(0.7, -15, -30);
      
      //segment 4 - drive into warehouse
      drive(1, 90, 90);
    }
  }
}

This basic code allowed us to achieve our basic autonomous strategy. Bare in mind that we generated the power, rightInches, leftInches, and elapsed time numbers doing basic testing with our Class Bot and then made some assumptions from the other mechanisms we made. You will need to make adjustments based on your own mechanisms and hardware components. To fine tune this code for your robot, test the code and adjust the number accordingly for the best results.

Autonomous Wrap Up

The above walkthrough should give you the basic information to get started with programming your own autonomous. We recommend testing and tuning your code to make sure everything works consistently. Once you have a functioning code, explore different ways you can add on this code to elevate it. The starting position for the path puts you in a great place to deliver the duck, which can easily be reworked into your path. Also it is worth considering what your alliance partner may do in a match to better optimize the code.

If you are new to FTC programming check out our Hello Robot programming guide to learn the basics of programming within the FTC SDK.