All pages
Powered by GitBook
1 of 10

Part 2: Robot Control

Thus far we've tackled a lot of the basics to get parts of our robot moving in response to our gamepad or sensors. So what comes next?

In Part 2 of Hello Robot we're going to look at working with a full, functional robot. By the end of this section your robot will be able controlled with the gamepad!

Before continuing it is recommended to complete, at minimum, a drivetrain. There are a few different options depending on the kit being used. We recommend looking at the C-Channel Drivetrain, such as what is used with our Starter Bot program, or the Class Bot V2!

For this guide the Class Bot V2 is used. Check out the build guide for full building instructions for the Class Bot V2!

Create a Basic Robot

The graphic below highlights the major hardware components of the Class Bot V2. These components are important to understand for the configuration process.

The Hello Robot - Configuration section focused on configuring the components in the Test Bed.

In order to continue forward with the Robot Control programming sections, additional motors must be added. It is your choice what variable names you would like to assign to your robot, but for reference this guide will use the following names for each hardware component.

Hardware Component

Hardware Type

Name

Right Drive Motor

REV Robotics UltraPlanetary HD Hex Motor

rightmotor

Left Drive Motor

REV Robotics UltraPlanetary HD Hex Motor

leftmotor

Arm Motor

REV Robotics Core Hex Motor

arm

Touch Sensor

REV Touch Sensor

test_touch

Drivetrain Basics

Before continuing it is important to understand the mechanical behavior of different drivetrains. The two most common drivetrain categories types are Differential and Omnidirectional.

Differential Drivetrains are the standard starting drivetrain. They are able to move in forward/reverse, as well as rotate either direction around a central point. There are different styles of directional drivetrains depending on the type of wheels, number of motors, and wheel positions. These include 4WD, 6WD, West Coast, and C-Channel drivetrains.

By comparison, omnidirectional drivetrains can move in any direction with each wheel typically being controlled separately. This allows for advanced forms of navigation, such as strafing, but requires a more complex program. Omnidirectional drivetrains include the use of omni wheels in Y or X configurations, mecanum wheel drivetrains, swerve drive, and other forms of holonomic drives.

The Class Bot V2 uses a directional drivetrain, which will be the drivetrain of focus for this tutorial!

Teleoperated Control Types

While driving our robot with teleop control, we will be giving the robot inputs from our gamepad connected to our Driver Hub. Its job is to translate those inputs to the robot to perform the specified actions. How your robot drives and what joystick does what can be largely dependent on what you or your team's driver is comfortable using. Let's take a look at two of the more common methods of control: Tank Drive and Arcade Drive.

Tank Drive

For tank drive, each side of the differential drivetrain is mapped to its own joystick so both will be used. Changing the position of each joystick allows the drivetrain to steer and change its heading. Sample code exists in the Robot Controller Application to control a differential drivetrain in this way.

Arcade Drive

For arcade drive, each side of the differential drivetrain is controlled by a single joystick. Changing position of the joystick changes the power applied to each side of the drivetrain allowing for a given command.

Arcade drives typically have left/right movement of the joystick set to spin the robot about its axis with forward/back moving the robot forward and reverse.

Arcade Drive may also be configured as a Split Arcade Drive where one joystick turns the robot while the other controls forward/back. An example of a Split Arcade Drive robot can be found as part of our 2023-24 Starter Bot.

Robot Control OnBot Java Directory

Quick Jump Back to a Section

Programming Drivetrain Motors

Arcade Style TeleOp - OnBot Java

Arm Control - OnBot Java

Programming Drivetrain Motors

In Part 1 we learned how to control a single motor by giving it power or input from a joystick. For controlling a drivetrain, we need to be able to control two motors simultaneously to help the robot move.

Programming Drivetrain Motors

Any code from Part 1: Tackling the Basics within our loop should be deleted before continuing this section. Alternatively, you may choose to create a new program.


Since the focus of this section is creating a functional drivetrain in code, lets started by adding rightmotor.setPower(1); and leftmotor.setPower(1); to the OpMode while loop.

while (opModeIsActive()) {
        rightmotor.setPower(1);
        leftmotor.setPower(1);
        }

Quick Check!

Before running your code for the first time, pause and think about the following:

  • What do you expect your robot to do once the program is activated?

Now save your OpMode using the button in the upper lefthand corner and give your program a go!

Did the robot move as you expected?

You may have expected your robot to move in a straight line forwards or backwards. Instead, your robot likely spun in a circle.

When motors run at different speeds they spin along their center pivot point. But the motors are both set to a power of 1 here so what else could be the cause?

Always keep the Driver Hub within reach in the case of the event that a robot does not perform as expected. When in doubt, disable your robot to keep you and it safe.

Mirroring Motors

DC Motors are capable of spinning in two different directions depending on the current flow provided. When a positive power value is applied the motors will spin in a clockwise direction. The opposite will happen when using a negative power value, meaning the motors will spin in a counter clockwise direction.

But how does that help with our current spinning robot? Let's take a closer look at our physical robot to find out:

Top down view of the Class Bot V2

Notice how the motors on your robot are currently mirrored from each other as part of the drivetrain. Now think about how we learned that when giving the motors a positive value they should turn clockwise. This is still how, however while they may both be rotating clockwise, the direction they know to be as clockwise is opposite.

Motors running the same direction, but facing opposite ways!

Try activating your robot's code again, but this time watching which direction the wheels turn. You may consider supporting the robot's frame so the wheels are suspended to make this easier to see.

Reversing a Motor:

There are a couple ways we could adjust our program to help our robot not to be a spinning top. For example, we could make sure the power is set to a negative value whenever one of our motors is called. Or we could simple reverse our motor's direction during initialization.

Before our waitForStart(); we will add the line rightmotor.setDirection(DcMotorSimple.Direction.REVERSE); . This sets our right motor to always be in reverse once it initializes.

    @Override
public void runOpMode() {
        control_Hub = hardwareMap.get(Blinker.class, "Control Hub");
        arm = hardwareMap.get(DcMotor.class, "arm");
        leftmotor = hardwareMap.get(DcMotor.class, "leftmotor");
        rightmotor = hardwareMap.get(DcMotor.class, "rightmotor");
        test_motor = hardwareMap.get(DcMotor.class, "test_motor");
        test_servo = hardwareMap.get(Servo.class, "test_servo");
        test_touch = hardwareMap.get(TouchSensor.class, "test_touch");
        

        telemetry.addData("Status", "Initialized");
        telemetry.update();
        
        //Reverse the rightmotor
        rightmotor.setDirection(DcMotorSimple.Direction.REVERSE);
        
        // Wait for the game to start (driver presses PLAY)
        waitForStart();

        // run until the end of the match (driver presses STOP)
        while (opModeIsActive()) {
        rightmotor.setPower(1);
        leftmotor.setPower(1);
            telemetry.addData("Status", "Running");
            telemetry.update();

        }
    }

Arcade Style TeleOp - OnBot Java

The time has come to program our robot to respond to our gamepad inputs so we can drive it around! To start we will be focusing on controlling our drivetrain.

Think back to the very start of Part 2 for a moment. We will be programming our robot using the Arcade Style of TeleOp. This means our forward and back movements will be controlled using the y-axis of the joystick while turning will be controlled by the x-axis.

This section will introduce the use of variables as we create our program. This will allow us to set up calculations in our program that will determine what power the motors should receive based on our gamepad's input. How much power each motor receives changes how the robot will move, so it is important to also review this relationship will establishing our code!

Below is a sneak peek at our final program:

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;
import com.qualcomm.robotcore.hardware.Blinker;
import com.qualcomm.robotcore.hardware.Servo;
import com.qualcomm.robotcore.hardware.TouchSensor;
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;
import com.qualcomm.robotcore.util.ElapsedTime;

@TeleOp

public class HelloRobot_TeleOp extends LinearOpMode {
    private Blinker control_Hub;
    private DcMotor arm;
    private DcMotor leftmotor;
    private DcMotor rightmotor;
    private DcMotor test_motor;
    private Servo test_servo;
    private TouchSensor test_touch;


    @Override
public void runOpMode() {
        control_Hub = hardwareMap.get(Blinker.class, "Control Hub");
        arm = hardwareMap.get(DcMotor.class, "arm");
        leftmotor = hardwareMap.get(DcMotor.class, "leftmotor");
        rightmotor = hardwareMap.get(DcMotor.class, "rightmotor");
        test_motor = hardwareMap.get(DcMotor.class, "test_motor");
        test_servo = hardwareMap.get(Servo.class, "test_servo");
        test_touch = hardwareMap.get(TouchSensor.class, "test_touch");
        
        rightmotor.setDirection(DcMotorSimple.Direction.REVERSE);
        double x;
        double y;
        
        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 Control
        x = gamepad1.right_stick_x;
        y = -gamepad1.right_stick_y;
        
        rightmotor.setPower(y-x);
        leftmotor.setPower(y+x);
 
        telemetry.addData("Status", "Running");
        telemetry.update();
        }
    }
}

Establishing Variables in OnBot Java

Creating X and Y Variables:

You may not expect it, but there is a little bit of math that needs to be done to get our robot moving smoothly. But before we dive too deeply into that let's start with the basics of movement we'll need.

To start, create two variablesxxxand yyy. In OnBot Java to establish a variable with a numerical value we will use the object double. Our variables are established during our initialization process.

public void runOpMode() {
        rightmotor = hardwareMap.get(DcMotor.class, "rightmotor");
        leftmotor = hardwareMap.get(DcMotor.class, "leftmotor");

        rightmotor.setDirection(DcMotorSimple.Direction.REVERSE);
        double x;
        double y;
        
        telemetry.addData("Status", "Initialized");
        telemetry.update();
        waitForStart();

Then within our loop assign yyy as y = -gamepad1.right_stick_y; and the xxx as the x = gamepad1.right_stick_x;.

Remember positive/negative values inputted by the gamepad's y-axis are inverse of the positive/negative values of the motor.

while (opModeIsActive()) {
        x = gamepad1.right_stick_x;
        y = -gamepad1.right_stick_y;
        
        rightmotor.setPower(1);
        leftmotor.setPower(1);
        }

Setting x = gamepad1.right_stick_x; and y = -gamepad1.right_stick_y; assigns values from the gamepad joystick to x and y. Depending on the orientation of the joystick, these valuables will receive some value between -1 and 1.

For a quick reference let's take a look at what number each variable would be assigned at their far ends:

Joystick Direction

xxx

yyy

0

1

0

-1

-1

0

1

0

What is a Variable?

Right now we have x and y assigned values based on our joystick's movement, but what does that mean? Why is that useful?

Maybe you have seen in a math class before something like this:

a+8=15a + 8 = 15a+8=15

In this case, a is our variable that has been assigned some value. For this example, we can determine that value is 7. But what does that mean in programming?

Variables used in programming follow this same principle. We can define a variable within our code to hold a set value or a value that changes, such as we are doing here. Then whenever that variable is referenced the robot will read it as that assigned value!

So using our example above if I had:

a+10=?a + 10 = ?a+10=?

My robot would know my variable of a is equal to 7 and therefore calculate the answer as 17 for me!

When or Why do we use Variables?

Consider for a moment, why should we use a variable when we could just use the number on its own?

We'll be using variables in greater detail in later sections, but even for our drive code you will be able to see the use of variables helps keep our program clean and easier to follow.

By using setting our y variable at the beginning of our code we can inverse it without needing to do so every time we may reference the joystick's y-axis. Within a longer program, having our variables defined at the start would allow us to quickly change a value without having to hunt down or double check that every possible instance in the code has been updated to reflect this change. Instead we are able to change it once and continue testing!

Motor Power vs. Robot Movement

At the moment, our motors are set to power on to a full forward at the start of our program. For reference, the image below shows the full scale of movement between forward and reverse:

Let's take this information and think back to when we first programmed a motor to move with our gamepad. During that section our motor was able to rotate at different power levels depending on how far and in which direction our joystick moved. However, do you recall the problem we had with this set up?

While using our previous code our motor only spun when the joystick was moved along the y-axis. Moving to the left or right did not ask the motor to power on, but it would begin to stutter some at the diagonals.

This is where adding some math to our code comes into play. Remember on an arcade drive both motors are being controlled by a single joystick. We need our robot to be able to calculate for both motors how much they should power on and in which direction. Thankfully, once we have it all set up our robot will be able to handle the calculations itself as the program runs!

By the end, we should be able to create situations like the following charts where the motors respond to create different forms of motion:

Quick Check!

How our robot moves is dependent on how much power each motor is receiving. Before continuing, we can explore with our current program how the robot reacts when changing the values assigned to our motors.

  • What happens when we set the power of the rightmotor to 0.3 and leftmotor to 1?

  • What happens when we set the power of the leftmotor to 0.5 and rightmotor to 1?

  • What happens when we set the power of the leftmotor to -0.4 and rightmotor to 0.4?

After testing different combinations, let's look at a quick breakdown of how power between the motors effects movement:

Power Comparison
Robot Movement

rightMotor power = leftMotor power

Straight Forward or Reverse

rightMotor power > leftMotor power

Left Turn

rightMotor power < leftMotor power

Right Turn

Determining Power with the Joysticks

Rather than setting a static numerical value for our motors, the variables we've set will help our robot to translate the motion of the joysticks into a power level.

For our arcade drive, the goal is for our joystick inputs to calculate to the following motor outputs:

Joystick Direction

( xxx , yyy )

rightmotor

leftmotor

Movement

(0,1)

1

1

Forward

(0,-1)

-1

-1

Reverse

(-1,0)

1

-1

Turn left

(1,0)

-1

1

Turn right

To get the outputs expressed in the table above, the gamepad values must be assigned to each motor in a meaningful way. To do so we are going to set up two equations in our code using the variables we have already established:

rightmotor=y−xleftmotor=y+xrightmotor = y-x \\ leftmotor = y+x rightmotor=y−xleftmotor=y+x

Programming Arcade Drive

Programming Arcade Drive

With our variables established and movement understood we just need to add our equations to each power!

@Override
public void runOpMode() {
        control_Hub = hardwareMap.get(Blinker.class, "Control Hub");
        arm = hardwareMap.get(DcMotor.class, "arm");
        leftmotor = hardwareMap.get(DcMotor.class, "leftmotor");
        rightmotor = hardwareMap.get(DcMotor.class, "rightmotor");
        test_motor = hardwareMap.get(DcMotor.class, "test_motor");
        test_servo = hardwareMap.get(Servo.class, "test_servo");
        test_touch = hardwareMap.get(TouchSensor.class, "test_touch");
        
        rightmotor.setDirection(DcMotorSimple.Direction.REVERSE);
        double x;
        double y;
        
        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()) {
        x = gamepad1.right_stick_x;
        y = -gamepad1.right_stick_y;
        
        rightmotor.setPower(y-x);
        leftmotor.setPower(y+x);
            telemetry.addData("Status", "Running");
            telemetry.update();

        }
    }

Arm Control - OnBot Java

Now that our robot is able to drive around let's get our arm up and moving!

Introduction to Arm Control

Controlling an arm requires a different thought process than the one you used to control the drivetrain. While the drivetrain uses the rotation motion of the motors to drive along a linear distance, an arm rotates along a central point, or joint.

Unlike our drivetrain, our arm has physical limitations for how far it can rotate. We don't want our robot to damage itself so we'll be making use of our touch sensor to act as a limit switch.

Basics of Programming an Arm

For this section, we will start by creating a new program called HelloRobot_ArmControl. We will be able to add this to our drivetrain OpMode later, but for now keeping it separate will help us to focus just on the arm.

To control our arm we will be using the Dpad on our gamepad. While our joystick provides a range of possible values or float data, our Dpad will only be read as 1 or 0. To us these numbers translate to true, the button has been pressed, or false, the button has not been pressed.

Click to Review Boolean vs. Float Data Types!

Boolean (Dpad, a/b/y/x buttons, bumpers)

Boolean data has two possible values: True and False. These two values can also be represented by On and Off or 1 and 0.

The buttons, bumpers, and triggers on the gamepad provide boolean data to our robot! For example, a button that is not pressed will return a value of False (or 0) and a button that is pressed will return the value True (or 1).

Float (Joysticks and triggers)

Float data is a number that can include decimal places and positive or negative values.

On the gamepad, the float data returned will be between 1 and -1 for the joystick's position on each axis. Some examples of possible values are 0.44, 0, -0.29, or -1.

To begin we can set up our If/else if statement for our Dpad Up and Dpad Down buttons inside our loop:

while (opModeIsActive()) {
   if(gamepad1.dpad_up){
                
                }
   else if (gamepad1.dpad_down){
            
                } 
     }            

Adding Motion

For now, our easiest path is to have our arm move up with DpadUp and down with DpadDown. You may decide later to change which buttons are being used, but the logic found here should be similar.

Let's add an arm.setPower(); to each "do" section of our statement. While testing our movement we will want to reduce the power to a more manageable range. For now, we will set our up to 0.2 and down to -0.2.

if(gamepad1.dpad_up){
       arm.setPower(0.2);         
            }
else if (gamepad1.dpad_down){
       arm.setPower(-0.2); 
            }   

Quick Check!

Save your OpMode and give it a go! Consider the following as test your program:

  • What happens if you press up on the Dpad?

  • What happens if you press down on the Dpad?

  • What happens when neither button is actively pressed?

Did the robot move as you expected?

What happened while testing your program?

Likely, you noticed even when no button is pressed the motor continues to try to move the last direction inputted. This is more obvious when pressing the DpadUp button, but if you listen closely you'll be able to hear the motor trying to move downward once DpadDown is pressed as well.

Stalled movement such as this is not healthy for our motors nor is it the easiest to control. We'll want to fix this before we continue testing!

Establishing an "Else"

The current if/else if statement tells the robot when the motor should move and in what direction, but nothing tells the motor to stop, thus the arm is continuing to run without limits. Ideally, we want our arm to move ONLY when a button is pressed.

To fix this we can make our statement longer by adding an "else" at the end. This "else" will be checked last and let the robot know what to do when niether Dpad button is pressed!

if(gamepad1.dpad_up){
       arm.setPower(0.2);         
            }
else if (gamepad1.dpad_down){
       arm.setPower(-0.2); 
            }   
else { 
       arm.setPower(0); 
            }    

With this change in place, save your program and give it another test!

Adding a Limit Switch

Something to consider is the physical limitations of your arm mechanism. Just like you have limitations in how far you can move your arms, our robot's arm can only move up or down so far. However, while you have nerves to help you know when you've hit your limit, we need to add something to help prevent the robot from damaging itself or things around it.

This is where the importance of using sensors comes into play. There are a few ways we could limit our mechanism. What do you think they could be?

In this section we're going to look at how to add a limit switch to stop our robot's arm from extending too far. You might recall in our "Programming Touch Sensors" section that we discussed the touch sensor can act like an on/off switch when programmed. Essentially we're going to have the arm of our robot turn its motor off once the limit is met!

This section is designed with the REV Touch Sensor or Magnetic Limit Switch in mind. There may be additional requirements for 3rd party touch sensors.

If you are using a Class Bot your robot should have a Touch Sensor mounted to the front of your robot chassis. You also have a Limit Switch Bumper installed.

Quick Check!

Think back to the "Programming Touch Sensors" section, where you learned how to create a basic limit switch program, similar to the one below:

Limit Switch if/else
 if (test_touch.isPressed()){
    //Touch Sensor is pressed  
     arm.setPower(0);
} else {
    //Touch Sensor is not pressed 
    arm.setPower(0.2);
                        }

We also learned how the touch sensor operates on a TRUE/FALSE binary. So what is our program above asking the robot to do?

What is our code doing?

Remember that when the touch sensor is pressed it reports as TRUE and while it is NOT pressed it is FALSE.

Right now our robot has been told the motor should be moving at 20% power when the button is not pressed. Once the button is pressed it'll set the power to 0!

Adding Controller Control

Let's take the next step for our program by adding the ability to control our arm with a controller. To do this we can nest the Gamepad if/else statement within the Limit Switch if/else statement as seen below:

if(test_touch.isPressed()){
     arm.setPower(0);
       }
  else {
      if(gamepad1.dpad_up){
       arm.setPower(0.2);         
            }
     else if (gamepad1.dpad_down){
       arm.setPower(-0.2); 
            }   
     else { 
       arm.setPower(0); 
            } 
       } 

While testing, double check the arm mechanism is aligned with the Touch Sensor.

For the Class Bot V2, you may need to adjust the Touch Sensor so that the Limit Switch Bumper is connecting with it more consistently.

Save the OpMode and give it a try!

Making Adjustments

When you tested the above code what happened? You may have encountered a problem where once the touch sensor was pressed the arm could no longer move. This is probably not ideal so why do you think this happened?

One of the advantages of a limit switch, like the touch sensor, is the ability to easily reset to its default state. All it takes is the pressure being released from the button, but right now all our robot knows is that if the switch is pressed it needs to turn off power!

So how do we fix that?

To remedy this, an action to move the arm in the opposite direction of the limit needs to be added to the else statement. Since the touch sensor serves as the lower limit for the arm, it will need to move up (or the motor in the forward direction) to back away from the touch sensor.

To do this we can create an if/else statement similar to our existing gamepad Gamepad if/else ifstatement. In this instance, when the touch sensor andDpadUpare pressed together the arm moves away from the touch sensor. Once the touch sensor no longer reports true, the normal gamepad operations will takeover again!

if(test_touch.isPressed()){
       if(gamepad1.dpad_up){
            arm.setPower(0.2);         
                 }
       else{
            arm.setPower(0);
                 }  
       }
  else {
   if(gamepad1.dpad_up){
            arm.setPower(0.2);         
                 }
      else if (gamepad1.dpad_down){
            arm.setPower(-0.2); 
                 }   
      else { 
            arm.setPower(0); 
                 } 
       } 

Robot Control Full Program

It's time to bring everything together so to have a fully mobile robot! Returning to our HelloRobot_TeleOp program we can add our arm control to our loop below the drivetrain code.

Full Program

This program uses the same configuration file created at the start of Hello Robot. Some hardware may not be used during this section.

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;
import com.qualcomm.robotcore.hardware.Blinker;
import com.qualcomm.robotcore.hardware.Servo;
import com.qualcomm.robotcore.hardware.TouchSensor;
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;
import com.qualcomm.robotcore.util.ElapsedTime;

@TeleOp

public class HelloRobot_TeleOp extends LinearOpMode {
    private Blinker control_Hub;
    private DcMotor arm;
    private DcMotor leftmotor;
    private DcMotor rightmotor;
    private DcMotor test_motor;
    private Servo test_servo;
    private TouchSensor test_touch;


    @Override
public void runOpMode() {
        control_Hub = hardwareMap.get(Blinker.class, "Control Hub");
        arm = hardwareMap.get(DcMotor.class, "arm");
        leftmotor = hardwareMap.get(DcMotor.class, "leftmotor");
        rightmotor = hardwareMap.get(DcMotor.class, "rightmotor");
        test_motor = hardwareMap.get(DcMotor.class, "test_motor");
        test_servo = hardwareMap.get(Servo.class, "test_servo");
        test_touch = hardwareMap.get(TouchSensor.class, "test_touch");
        
        rightmotor.setDirection(DcMotorSimple.Direction.REVERSE);
        double x;
        double y;
        
        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 Control
        x = gamepad1.right_stick_x;
        y = -gamepad1.right_stick_y;
        
        rightmotor.setPower(y-x);
        leftmotor.setPower(y+x);
        
        //Arm Control with Limit Switch
        if(test_touch.isPressed()){
              if(gamepad1.dpad_up){
                    arm.setPower(0.2);         
                         }
              else{
                    arm.setPower(0);
                         }  
               }
        else {
              if(gamepad1.dpad_up){
                    arm.setPower(0.2);         
                 }
              else if (gamepad1.dpad_down){
                    arm.setPower(-0.2); 
                 }   
              else { 
                    arm.setPower(0); 
                 } 
               } 
        telemetry.addData("Status", "Running");
        telemetry.update();
        }
    }
}

Right Stick vs. Left?

Which joystick is used for driving the robot is largely based on driver preference.

For Hello Robot, we will be referencing using the right stick due to the arm control using the Dpad. This can be changed at any time by changing from right to left in your x = gamepad1.right_stick_x; lines.

Downloads

These premade programs do not include control of the Class Bot V2's "claw" servo. To learn about programming a servo visit Programming Servos.

Class Bot V2 / Hello Robot Configuration File:

694B
HelloRobot.xml

Class Bot V2 / Hello Robot Full TeleOp:

4KB
HelloRobot_TeleOp.java

Class Bot V2 / Hello Robot Arm Control no Limit Switch:

3KB
HelloRobot_ArmControl.java

Class Bot V2 / Hello Robot Arm with Limit Switch:

4KB
HelloRobot_LimitSwitch.java