Getting Started!

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

Configuration

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.

2024-25 REV DUO FTC Starter Bot Gamepad Layout:

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

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

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.

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:

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:

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!

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!

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

Documentation Links

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();
        }
    }
}

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.

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.

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!

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!

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!

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

Mecanum Drive

For Mecanum Drive each wheel has an individual motor!

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

The following additional parts are needed:

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

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

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

Programming Breakdown

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

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.

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.

Starter Bot Programming TeleOp without Initialization

The provided program template for the 2024-25 Starter Bot has the robot move to initialization at the start of the program. However, in some situations the arm and wrist motor may never hit the designated starting position leading to oscillating movements, or the Control Hub may have been powered on in the wrong positions, which determines these motors' zeroes, leading to unexpected movement.

Below is a version of the TeleOp program that changes this initialization so the robot no longer moves until receiving input from the gamepad. This version is only available for the basic Blocks template and not for any upgrades. Read through the short guide below to learn more about the changes!

Download of Starter Bot Program without Initialization

Robot Start Up Position

When the program begins, the robot will first STOP_AND_RESET_ENCODER for the arm's HD Hex Motor and wrist's Core Hex Motor. Whatever position the arm and wrist are in will become the "zero" the presets are based around.

Left Bumper Reset

When pressing the left bumper on the gamepad, the arm and wrist will return to their start up position. To prevent this from also resetting the encoder, a new variable called ZEROING has been added to our STATE_MACHINE as seen below:

The call for the left bumper now looks like below:

Adjusting the STATE_MACHINE

Due to variations in the robot's structure and how team's decide to position it for start up, you will likely need to make some adjustments to your arm and wrist values within the STATE_MACHINE to fit your team's needs for the presets.

Some changes to the targetArm position have already been included, but we recommend using the telemetry readout on your Driver Hub to refine your movements!

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!

Mecanum Drive

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

The following additional parts are needed:

Example Mecanum Drive Program

Adding Independent Wrist Movement

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

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:

Quick Links

• Substructures

Full Bill of Materials (BOM) - Excel Download

Full Robot

Substructures

Tower

Arm

Gripper

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.

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.

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.

1. Ground Junction: Plastic disc that is molded to hold Cones

2. Low Junction: 13in spring-mounted pole

3. Medium Junction: 23in spring-mounted pole

4. High Junction: 33in spring-mounted pole

Junction locations on field

Navigation Images

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

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:

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:

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.

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.

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.

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.

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.

POWERPLAY's rules limit robots to possessing a maximum of one corresponding Alliance Cone or one corresponding Alliance Beacon at a time, so, a major component of your points per second strategy should be the intake. Intakes come in many different forms, so we brainstormed some concepts and put them through the first stages of the engineering design process to help us decide if they met our gameplay requirements.

Requirements

• Touch it, Own It - Be able to quickly intake and control elements

• Pick Up One Only - reduce the chances of picking up more than one element by using the exterior rather than interior as a grip point

• Adaptability - ability to pick up a cone against a wall on a cone stack as well as in the open from a substation or on the field

• Release It - be able to release the element with ease whether by mechanical movement or by automation

First Round of Prototyping

Simple Gripper

We started with a simple gripper that has one pivot joint. The simple gripper has two stationary compliant wheels on the moving arm that grip the cone. This design is actuated by a servo and its low profile allows for cones to be picked up close to the wall.

Passive Intake

We also wanted to explore passive options for an intake. This passive intake works with free-spinning rollers at the end of two arms that are mounted with surgical tubing. The flexibility of the surgical tubing allows the arms to stretch around the cones as the rollers lock them in. Because this intake is passive and grabs a cone from the side, a bit of assistance from the field wall to keep the cone in place while grabbing is necessary. This may be an issue with intaking cones that are in the middle of the field.

Active Roller Intake

The active roller intake uses two sets of wheels powered by servo motors that roll the cones into a held position. The space needed to mount the servos and gear them correctly for the intake wheels causes this intake to be a bit bulkier than the others. Depending on what structural material you use, the frame can also be heavier which will need to be taken into consideration when building a lift.

Second Round of Prototyping

Compact Active Roller Intake

For our final intake design we took inspiration from the Active Roller Intake to create a version that could get closer to the wall and pick up cones from the cone stacks. This compact active roller intake features one servo motor driven roller paired with a free spinning roller. This provides the same amount of control as the two roller intake with about half the footprint. Because of the smaller size, this intake is also easier for your lift to move.

Bonus: Cone Flipper

A bonus mechanism we prototyped was a cone righting device. With cones getting dropped or knocked over, it might be a useful tool to have on your robot if your intake can only pick up an upright cone. Our idea was to mount compliant wheels on a rotating roller that is hinged to allow the cone to rotate into position.

Game Introduction

The 2021-2022 FTC game is Freight Frenzy. The Freight Frenzy challenge features game elements such as freight, shipping hubs, carousels, warehouses, barriers and ducks! Each robot starts against the Playing Field wall adjacent to the Alliance Station and must be in possession of of Box piece of freight. From there each team will progress through the thirty second autonomous period followed by the two minute long driver controlled period. The last thirty seconds of the match is the end game period. Each period has different scoring achievements. See the scoring summary excerpt from Game Manual Part 2 for more information on the game objectives.

Scoring Summary

If you are unfamiliar with the game the following field view can give insight to the field elements.

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 worlds 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. Typically, these are autonomous scoring achievements where a robot has moved to a particular portion of the field and parked there.

This year there are four potential navigation achievements.

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.

Carousel

Each alliance's carousel starts with a duck placed on it in the pre-match setup. This duck can be delivered to the field by rotating the carousel. We tested the carousel and took a look at the rules to factor in all considerations for this scoring achievement.

The first thing to take a look at is the rules constraining and defining carousel interaction and delivery. Deliver is a glossary term defined in section 4.4 Game Definitions of Game Manual Part 2. Information on the carousel can be found in Game Specific Rule 7 <GS7> and delivery restrictions are in Game Specific Rule 9 <GS9> of Game Manual Part 2. One of our main concerns with the constraints, particularly in the autonomous period is that the definition of delivered specifically states that in order for a duck to be considered delivered "the Sweeper Plate must knock the Duck or Teams Shipping Element off of the carousel onto the playing field floor." Which implies that a properly delivered duck must enter the playing field by making contact with the sweeper plate.

Paying attention to the rules for delivery is crucial for maximizing points per second. But why? After testing the carousel we quickly realized that the speed at which the carousel is rotated, affects whether the duck enters the playing field. Spin the carousel too fast and the duck flies off of the carousel before it can be knocked off by the sweeper plate. Finding the speed the carousel can be rotated that allows the duck to be properly delivered and maximize points per second is crucial for this scoring achievement.

The final consideration we'd like to make is for traditional events. There is only one duck that is deliverable in autonomous. When also considering that travel time to the carousel affects the points per second of the delivery score, we think that going for this scoring achievement is maximized if your robot starts on the side of the field closest to the carousel.

Autonomous Bonus

In Freight Frenzy the randomization factor includes being able to identify which Barcode position a duck (or Team Shipping Element) is in and using that information to correctly place the Pre-Loaded Box onto the correct level of the Alliance Shipping Hub.

The following table highlights some of the ways to analyze the Barcode:

While Vuforia will likely be easier to tune to the Duck game element over the Team Shipping Element, using the Team Shipping Element is worth more points.

Placing Freight

Each robot is required to start with a pre-loaded box. Even if you are unable to properly read the Barcode location at the start of the match, placing the pre-loaded box onto the same level every round, yields a 33% chance of getting the autonomous bonus. This is in addition to the points gained from placing a piece of freight on Alliance Shipping Hub, which is the same amount of points regardless of the level it is placed on.

Driver Controlled

Since the only scoring achievement in the Driver Controlled period is placing Freight in one of the designated areas the main strategy is efficiency and accuracy. As we said its always about maximizing points per second!

Freight

The main scoring opportunity in the Driver Controlled period is placing Freight. A robot can control one freight at a time, per game specific rule <GS8>. Score freight by placing freight completely in the Alliance Specific Storage Unit, on one of the levels of the Alliance Shipping Hub, or on the Shared Shipping Hub.

There are a few considerations to make when deciding on your strategy for placing Freight:

Balancing

At the end of the match additional points may be awarded depending on whether your Alliance Shipping Hub is balanced or the Shared Shipping Hub is unbalanced in your alliances favor. Understanding how to identify the weight difference, and decide how that may effect your strategy.

GS5 and Warehouse Operations

Rule GS5 defines the expectations for each robot in regards to Warehouse Operations. In order for a Freight to be consider legally removed from the Warehouse, each piece of Freight must follow the Warehouse Operations

1. Start Completely Out of the Warehouse, then

2. Drive Completely In the Warehouse, then

3. Collect one (1) piece of Freight, then

4. Drive Completely Out of the Warehouse with the collected Freight.

End Game

During End Game you can continue to gain points by placing Freight or do one of the End Game specific tasks.

Duck and Team Shipping Element Delivery

In end game, ducks and team shipping elements can be introduced to the field by rotating the carousel, similar to the autonomous task. Delivering a duck or team element is worth 6 points a piece. Removing the ducks from autonomous from the overall count, nine ducks (or team elements) can be scored in end game. That's a potential of 54 points in the end game period just for delivering ducks. Obviously this score is reliant on being able to score all nine in the end game period, which would require that the delivery process take around three seconds to complete per duck.

Capping

Capping involves taking the Team Shipping Element and attempting to score it on top of the center pole above level 3, or on another capped team shipping element. Accuracy is key with this scoring achievement.

Shipping Hub Status

Shipping Hub Status focuses on where the Shipping Hubs are at, at the conclusion of a match. If the Alliance Shipping Hub is balanced at the end of the match you receive 10 points. If the Shared Shipping Hub is Unbalance you receive 20 point.

After looking at Game Manual Part 2, we believe the best strategy for the Shared Hub is to try to maintain balance as you are placing objects. This way you do not have to scramble at the end of the match to try to balance it.

Parking

Parking is also considered where the robot is at the end of the match. Calculating how long it would take you to get from one side of the field to the Warehouse will help you decide if the potential points per seconds are worth the points you would have to give up to park.

General Drivetrain Options

Before diving into the specific obstacles in the Freight Frenzy game that may impact drivetrain design, lets first consider some of the game agnostic information on drivetrains.

Robot Size Restrictions

Robot rules, outside of the weight limit, have mainly stayed the same. The main constraint is the 18" x 18" x 18" sizing requirement.

Drivetrain Options

While there are many types of drivetrains teams can build, getting a drive train up and running as quickly as possible should be an overall goal. With this in mind there were two main drivetrains we considered utilizing for Freight Frenzy; Differential Drive or Mecanum Drive.

Differential Drivetrain

Mecanum Drivetrain

Either choice for a team will lead them to success this season. For our prototyping we went with the channel drivetrain to make modifications.

Field Obstacles and Challenges

Many FTC teams recycle drivetrains from season to season, whether for cost or ease of design reason. The requirements surrounding the warehouse, such as the barriers and the warehouse procedures, shakes up the standard design expectations for drivetrains in FTC.

There are two options for getting around the barriers: Going around or going over.

Going Around

Each barrier is roughly 13.7 inches from the playing field wall. To go around the barrier a drivetrain must be less than 13.7 inches wide. Creating a drivetrain that meets the size parameter creates constraints in the overall size of the robot. While this is a perfectly valid solution to the problem, we wanted to find a solution that could be made from a Starter Kit, and did not require structural components to be cut down.

Going Over

The poles of the barriers are roughly 1.26" from the floor with a roughly 3.5" gap between each pole. If we compare these dimensions against the standard FTC kit drivetrains, the drivetrains do not have the clearance to get over the barrier. Using our C Channel we were able to create a solution to this clearance issues.

Rather than seat the wheel shafts within the bearing holes on the Channel pattern, we used the extrusions slots and bearing pillow blocks to host the wheel shaft. By doing this we get approximately 2 inches of clearance, which gives us the clearance necessary to get over the barrier.

As we stated in the Game Breakdown, delivering ducks during the end game is a potential of 54 points. At 6 points per duck this is an equivalent action to scoring in the third level of the Shipping Hub. The Carousel itself is pretty similar to the Control Panel from the 2020 FIRST Robotics Competition game, Infinite Recharge, and is a good starting point for inspiration for a mechanism.

Requirements

• Reliable - consistently interfaces with the rim of the carousel to do a full delivery

• Balance of power - can rotate the carousel quickly without tossing the duck off

• Simple - achieves the task without needing to be overly complex

Grip Wheel Mechanism

We focused on creating one carousel mechanism, the grip wheel mechanism. The reason we focused so intently on this particular mechanism was that we wanted a mechanism that was easy to build. Powering a grip wheel with a servo we were able to produce the necessary traction to transmit motion to the carousel.

This mechanism met our needs and requirements for rotating the carousel. However, it does take the mechanism about six second to fully rotate the carousel, bringing our total points per second to about one. You may want to get a low speed motor, like the Core Hex Motor, to provide a bit more speed to the mechanism than the servo. Obviously be cautious of the speed, as we have mentioned in the previous sections.

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

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)

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

Drivetrains are one of the first mechanisms that teams typically build and start development on. There are few changes to the robot rules that are needed to consider when designing a drivetrain

Field Layout and Obstacles

Ultimate Goal provides a flat field with little in the way for a robot to maneuver through out the field of play. Rings are re-introduced into the field through a drop on the side of the goals by a human player. Rings will likely be rolling along the field and sitting flat when hitting a robot or another object like a field wall. While the rings themselves are compliant it doesn't seem like they are easily trapped inside of a drivetrain.

Robot Size Restrictions

Robot rules, outside of the weight limit, have mainly stayed the same. The main constraint is the 18" x 18" x 18" sizing requirement.

Drivetrain Options

While there are many types of drivetrains teams can build, getting a drive train up and running as quickly as possible should be an overall goal. With this in mind there were two main drivetrains we considered utilizing for Ultimate Goal; Differential Drive or Mecanum Drive.

Differential Drivetrain

Mecanum Drivetrain

Either choice for a team will lead them to success this season. For our prototyping of intakes we went with a Mecanum Drivetrain mainly so it would sit lower to the ground.

Manipulating the ring game piece during play is a key for success in this year's challenge. Intakes can take many forms but we would want to try a few concepts and see how the meet some of our requirements.

Requirements

• Touch it, own it - Be able to quickly touch the rings and have control of them

• Pick up multiple - Be able to handle multiple of the rings coming in at a time

• Ability to hand-off to a conveyor/shooter

Two concepts to try as 15 minute prototypes are a pinch intake and a roller intake.

Pinch Intake

Basic idea is to have a servo with a pivot to pick up the rings. Ability to lift up the intake and put it down on top of other rings in position to carry up to 3 is another requirement.

We took the intake that we made last season for SKYSTONE and tried it out with the rings. Surprisingly it didn't need much adjustment to pick up the rings. Holding multiple rings was possible however the grip on the pinch decreased with the more rings used. If using a pinch intake teams may want to consider picking up from the inside diameter of the ring and finding some ways to hold onto a compliant piece like the ring.

With the difficulty of picking up multiple rings for carrying we chose to look at another option for intakes as well.

Roller/wheel Intake

Another way is to have a roller or wheeled intake. With the size of the game piece relative to the size of the robot and the number of game pieces a robot could hold, we chose to go with a horizontal roller intake and to iterate on this concept.

The real quick test of this concept was stacking 90mm Traction wheels across a simple 15mm Extrusion frame. We direct drove the wheel roller with a Core Hex Motor as a proof of concept. This worked well as the traction wheels had enough grip to pick up the ring game pieces. Picking off of a stack of pieces could be challenging and something needed in future iterations.

This is the design we chose to iterate off of to find a better solution. Next steps were to mount this to a drivetrain to see how it performed.

Pasta Roller Intake

When we started the process of developing the intake we were thinking of styles used in the 2017 FIRST Robotics Competition game STEAMWORKS as inpsiration. In that game a gear, which was a flat game piece like the ring, was picked up individually and delivered to another location on the field. Curious to see if a "Pasta Roller" intake would work we started tinkering on a drivetrain to see what we could come up with.

Final Design

Utilizes one large roller to pull the ring in, one small roller to knock the front edge of the ring up, and one small roller to redirect the ring into the robot. This utilizes an open front of the robot to move the ring into a location where a conveyor or indexing system could live.

The large front roller is connected to an arm that is free to rotate, which introduces some compliance into the system. Since the rings have some compliance to them we could hard connect this to a specific location. Furthermore, a ridgid mounted intake didn't allow for the "kicking" of the ring up the back to rollers and into the drivetrain. Another option is to keep the "drop down" behavior and have the intake pushed further forward. This would allow for the outer large roller to store inside the start configuration and deploy once the match begins to give extra space. This option also could allow for more wheels and wider roller for better ability to pick up rings.

Design Considerations

The HD Hex Motor is running an UltraPlanetary with a 5:1 ratio. This is four times faster than the 20:1 ratio that the drive motors have. It is important for the intake speed to be faster than the driving surface speed so that the intake is able to pick up rings while the drivetrain is moving towards or away from the game piece.

Pieces of corrugated plastic were used as an easy way to direct rings from the wide front intake to the narrower rear rollers. The ring needs some way to be centered on the indexing mechanism, and corrugated plastic is an easy and effective way to create such a mechanism and comes in the FTC Starter Kit V3.

Other options

Rollers on the sides (i.e. parallel to the ground, on either side of the ring) could also be used, but it is more difficult to package:

• The rollers have to fit within the 18” footprint limit but still reach out enough to grab the wheels

• Adding compliance to the system is more difficult to achieve with side rollers, unless the rollers have some sort of compliant finger.

• Power the side rollers is also a packaging/power issue as with the current design all rollers are powered off of the same motor.

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:

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.

Freight Frenzy Starter Bot controller layout:

Programming Teleop - Blocks

Drive Code

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

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;
import com.qualcomm.robotcore.eventloop.opmode.TeleOp;
import com.qualcomm.robotcore.eventloop.opmode.Disabled;
import com.qualcomm.robotcore.hardware.DcMotor;
import com.qualcomm.robotcore.hardware.DcMotorSimple;


@TeleOp

public class StarterKitRobotTank extends LinearOpMode {
    private DcMotor LeftDrive;
    private DcMotor RightDrive;


    @Override
    public void runOpMode() {
        LeftDrive = hardwareMap.get(DcMotor.class, "LeftDrive");
        RightDrive = hardwareMap.get(DcMotor.class, "RightDrive");
 
        telemetry.addData("Status", "Initialized");
        telemetry.update();
        // Wait for the game to start (driver presses PLAY)
        waitForStart();
        
        // run until the end of the match (driver presses STOP)
        while (opModeIsActive()) {
            //DRIVETRAIN CODE
            double leftAxis = -gamepad1.left_stick_y;
            double rightAxis = -gamepad1.right_stick_y;
            
            double leftPower = -leftAxis;
            double rightPower = rightAxis;
            
            LeftDrive.setPower(leftPower);
            RightDrive.setPower(rightPower);
            
            telemetry.update();
            }
        }
    }

Freight Delivery Mechanism Control Code

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

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;
import com.qualcomm.robotcore.eventloop.opmode.TeleOp;
import com.qualcomm.robotcore.eventloop.opmode.Disabled;
import com.qualcomm.robotcore.hardware.DcMotor;
import com.qualcomm.robotcore.hardware.DcMotorSimple;


@TeleOp

public class StarterKitRobotTank extends LinearOpMode {
    private DcMotor ArmMotor;
    private DcMotor IntakeMotor;


    @Override
    public void runOpMode() {
        ArmMotor = hardwareMap.get(DcMotor.class, "Arm");
        ArmMotor.setTargetPosition(0);
        ArmMotor.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);
        
        ArmMotor.setMode(DcMotor.RunMode.RUN_TO_POSITION);
        
        int ArmTarget = 0;

        telemetry.addData("Status", "Initialized");
        telemetry.update();
        // Wait for the game to start (driver presses PLAY)
        waitForStart();
        
        // run until the end of the match (driver presses STOP)
        while (opModeIsActive()) {
            //MECHANISM CODE
            
            if (gamepad1.a) {
                ArmTarget = 0; //On the ground for starting and intaking
            }
            else if (gamepad1.x) {
                ArmTarget = 120; //Low level on the goal
            }
            else if (gamepad1.y) {
                ArmTarget = 260; //Mid level on the goal
            }
            else if (gamepad1.b) {
                ArmTarget = 410; //High level on the goal
            }
            else if (gamepad1.right_bumper) {
                ArmTarget = 1420; //High level on the goal scoring backwards
            }
            else if (gamepad1.left_bumper) {
                ArmTarget = 1570; //Mid level on the goal scoring backwards
            }
            
            //stuff for arm position control
            ArmMotor.setTargetPosition(ArmTarget);
            ArmMotor.setPower(1);
             
            telemetry.addData("Arm Position", ArmMotor.getCurrentPosition());
            telemetry.update();
            }
        }
    }

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.

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;
import com.qualcomm.robotcore.eventloop.opmode.TeleOp;
import com.qualcomm.robotcore.eventloop.opmode.Disabled;
import com.qualcomm.robotcore.hardware.DcMotor;
import com.qualcomm.robotcore.hardware.DcMotorSimple;


@TeleOp

public class StarterKitRobotTank extends LinearOpMode {
    private DcMotor IntakeMotor;


    @Override
    public void runOpMode() {
       IntakeMotor = hardwareMap.get(DcMotor.class, "Intake");
        
   
        telemetry.addData("Status", "Initialized");
        telemetry.update();
        // Wait for the game to start (driver presses PLAY)
        waitForStart();
        
        // run until the end of the match (driver presses STOP)
        while (opModeIsActive()) {
            //MECHANISM CODE
            
            double IntakePower = (gamepad1.right_trigger>0.5)?1:((gamepad1.left_trigger>0.5)?-1:0);
            
            IntakeMotor.setPower(IntakePower);
                         
            telemetry.update();
            }
        }
    }