All pages
Powered by GitBook
1 of 2

Loading...

Loading...

Arm Control - Blocks

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 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 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.


Let's start by adding an block to our active loop. Use the settings dropdown to change the block to an block.

Now the skeleton of our if/else if statement is ready. We can add the and blocks next.

With this in place our robot will be checking if the Dpad Up or Dpad Down button are pressed before proceeding with the appropriate action. But what do we want our arm to do?

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 a block 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.

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?

The current 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 edit the block to have an extra at the end of the statement.

Then add a block to our new "else" section.

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

Adding Motion

Quick Check!

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"

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

Float (Joysticks and triggers)

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 installed.

For the moment, let's grab the statement made in the previous section to be set off to the side for later use.

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:

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

Add the block set back to the code in the else port of the block.

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 do 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!

Now we can snap this into our do statement to complete our code:

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

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 op mode and give it a try!

Making Adjustments

Limit Switch Bumper