Middle School

Overview: 
Explore the components of the FRC robot control system.
Objectives: 

Understand the purpose of the robot control system and its various components.

Content: 

A robot consists of motors, actuators, sensors and other components that provide it's functionality. Your program gets input from and sends commands to those components to operate the robot. Sitting between your code and the hardware components is the Robot Control System

The Robot Control System consists of the hardware and software components that host your Java program and provide the interfaces to the hardware components. The most important piece of the control system is the RoboRio controller, but there is much more to the control system. As a robot programmer you will need to know what these components are and what they do so you can design a program that uses the WpiLib classes that represent the control system components to communicate with those control components and thereby control the hardware systems of your robot. Whew, that is a mouthful!

Typically, the robot programmer participates in the design of the control system and may also participate in locating and attaching control system components and wiring them together as well. To that end it is important to review the documentation for the control system and become familiar with the components, what they do and how they are connected to the RoboRio.

Here is the top level of the RoboRio based control system documentation. You can start here to find information about most any topic.

Here is a discussion of the RoboRio based control system hardware components.

Here is a discussion of the control system software compoments.

Here is a single PDF containing the same information for you to study.

Another great resource is Chief Delphi, an online forum for the FRC platform.

 

Navigation:

Overview: 
Explore more information about the RoboRio hardware and software environment. Install the tools need to write Java programs for the RoboRio.
Objectives: 

Understand the RoboRio hardware and software enviroment in more detail. Download and install the software tools needed to develop Java programs for the RoboRo.

Content: 

Before we get into installation of the software tools, we will go over some basics.

The documentation for the RoboRio based robot control system is located on-line at the ScreenStepsLive web site. This site contains fairly complete documentation of the RoboRio based FRC Control System. Here is a discussion on how to use the ScreenStepsLive site. In addition to the on-line documentation, there various other web sites and PDF based manuals that provide valuable information. Note that the links to ScreenStepsLive topics in our lessons point to the 2016 version of the documentation. When looking at topics in ScreenStepsLive, be aware that there is a complete set of the documentation for each year of FRC competition. So you may want to navigate to the current year version of the topic linked to. The yearly update is released near the end of each year for the upcoming competition season.

The software development SDK you will use for RoboRio programs is provided by Worcester Polytechnic Institute and is called the WPILib. Here is an overview of the WPILib.

In our lessons we are only going to be covering the development of Java programs for the RoboRio and the tools you need to do that development. Be aware that  the complete robot control system involves many more software tools that need to be installed and configured. This is typically done by senior team members is not something every Java developer will need to do...but it is important to have an understanding of these other components and how they fit into the complete control system. We are not going to discuss these other components in detail but you should study the ScreenSteps documentation about these other components for best results.

The RoboRio control system can be programmed in Java, C++ or LabView. Follow these instructions to install the Java SDK, Eclipse and the WPILib plugins. Note that when installing Eclipse, you want Eclipse for Java developers. Ignore all discussion of mixing Java and C++. You will not need C++.

The section that follows the Eclipse install instructions titled "Installing the FRC 201x Update Suite" is not needed for most developers. This section is for lead or master FRC programmers and relates to installing software for the driver station, LabView and some other tools used in FRC. Most developers will not need to deal with this and this area is beyond the scope of this curriculum at this time.

However, if you do not install the Update Suite, there is one software tool you need that is part of that suite. This is the mDNS service. A lesson on mDNS will be added, but for now just know that it is a needed component for communication with the RoboRio. mDNS is installed as part of the Update Suite or is already present on your PC if you have iTunes installed. If you do not have iTunes, you can install the Apple BonJour service (which is mDNS by another name) manually from here.

When you have completed the Java SDK, Eclipse and WPILib plugins and mDNS installations you are ready to ready to take a closer look at using Java to program the RoboRio control system.

 

Navigation:

Overview: 
Introduce the main concepts, hardware and software components of the RoboRio control system.
Objectives: 

Understand the main concepts and the hardware and software components of the RoboRio robot control system.

Content: 

This lesson is the first in the "off ramp" Unit for RoboRio programmers. This Unit contains a detailed exploration of writing Java programs for the RoboRio. Don't forget to complete the rest of the Java curriculum starting with Unit 12.

We have been learning a lot about the Java programming language. Now its time to explore how we actually write, compile and deploy Java programs for the RoboRio (FRC) robotics control system.

RoboRio based robots use a far more complex control system than the EV3 (FLL) based robots but is similar to Tetrix (FTC) robots. At the FRC level robots engage in autonomous activity, that is, not under the control of a human, just like EV3/Tetrix robots do. However, autonomous activity is a relatively small part of the match that is played in competition. The larger portion of match time is teleoperated activity, that is, the robot is under remote control by human players. As such, the control system consists of three hardware devices, a robot controller device, a robot attached wireless router (also called the radio) and a driver station PC. The controller and driver station PC are connected over a WiFi network created by the wireless router. Your code development PC may be the same PC as the driver station or a different PC. A different PC is recommended.

The robot controller is the RoboRio device which is a Linux based computer with hardware interfaces (ports) that connect to external devices. The RoboRio hosts the Java JVM that will execute your program. The RoboRio connects to the router (via cable) which functions as a wireless access point, creating a wireless network that the driver station and development PCs can connect to. The RoboRio is manufactured by National Instruments and is also called an NI-roboRIO. The RoboRio manual can be found here. A simpler overview of the RoboRio by FRC team 2168 is found here.

The driver station (DS) PC is a Windows PC running the driver station application provided by FIRST. This application communicates with the RoboRio over the network created by the router. You attach joysticks and other control devices to the DS PC and the DS app sends input information from these devices to the RoboRio and then to your program. The driver station also has a software component called the Dashboard which is a customizable program that you can use to display information from your program or send control information to your program.

The software tools needed to write RoboRio robot control programs are:

  • Java SDK (development PC)
  • Interactive Development Environment (development PC)
  • Plugins for the Interactive Development Environment (development PC)
  • SDK for RoboRio programs (development PC)

We will discuss each of these tools and how to install them in detail.

The Java SDK is required on your development PC to be able to compile Java programs.

An Interactive Development Environment (IDE) is a tool that makes it easy to create, compile and deploy programs to devices. The IDE we will be using is Eclipse. There are plugins to Eclipse supplied by FIRST that customize Eclipse for use in developing RoboRio control programs and the plugin installer includes the SDK for RoboRio

 

Navigation:

Overview: 
Explore more detailed information about the Core Device Interface module, the Core Device Discovery utility and sensor device access using the I2C interface.
Objectives: 

Gain advanced knowledge of the Core Device Interface and accessing I2C based sensors over the CDI and using the Core Device Discovery utility to configure I2C devices.

Content: 

The Core Device Interface Module is used to connect devices, typically sensors, to the robot control system. There are several different connection protocol options available: digital, analog and I2C. A number of the Modern Robotics sensors use I2C and typically, if you only have one sensor of a specific type, you can ignore the I2C details and let the FTC SDK object for the sensor communication using default parameters. But if for instance you wanted to have 2 color sensors on a robot, you have to move beyond the defaults and perform I2C address configuration so that the two color sensors are not both using the default I2C address assigned to sensors at the factory. Configuring the I2C addresses requires using a utility program called Core Device Discovery.

Here is a detailed discussion of the Core Device Interface.

This lesson at Modern Robotics Education delves into this topic in detail. Follow the lesson, watch the videos and when you are done you will be ready to handle I2C addressing.

 

Navigation:

Overview: 
Explore multi-threading by looking at an example.
Objectives: 

Understand how a multi-threaded OpMode works by looking at an example.

Content: 

If you have not read the lesson on multi-threading in the Advanced Topics unit, do so before continuing.

We are going to look at a simple example of multi-threading (also called multi-tasking). We are going to take the Tank Drive exercise and modify it to have the driving part of the code run in a new thread. The idea is that the main thread can focus on other tasks, perhaps more important or complex and the simple driving code can be in a thread, executing separately from the main thread and just taking care of driving. Create a new class called DriveTankMT and put the following code in it:

The first thing to notice is the use of a private inner (nested) class DriveThread, that extends java.Thread. That class will hold all of the thread specific code, which in the simple case, is just the run() method. Our code to handle driving is in the run() method. We use an inner class because it is simpler and makes accessing the members of the main class easier. Here is more on inner classes.

In the main class at start up we create an instance of the driving thread class and use that instance reference variable to control the thread. Control is pretty simple, when we want to start driving we call the start() method on the thread class and when we want driving to stop we call the interrupt() method on the thread class. While running, the DriveThread class handles the mapping of joystick input to motor power settings and you can see the main thread goes about other business.

In this example, the variables leftY and rightY are shared between the main thread and the driving thread. To reduce concurrency problems, only the driving thread sets the values of leftY and rightY. The main thread only reads from these variables. If high accuracy were needed, we would put the volatile modifier on the definition of leftY and rightY. This is adequate for simple situations. More complex data sharing between threads and a more detailed exploration of concurrency is beyond the scope of this lesson but you can read more about threads and concurrency here.

 

Navigation:

Overview: 
Learn about the Vuforia vision API and how to locate and identify VuMarks.
Objectives: 

Understand of how to use Vuforia to locate VuMarks.

Content: 

Vuforia is a library of classes included in the FTC SDK that supports using the RC phone camera to locate objects in the cameras field of view and return actionable information to your program. That information may allow your robot to locate and navigate to a visual target, locate an object or recognize images. In this lesson we are focusing on a feature of Vuforia called VuMarks. A VuMark is an image that is like a bar code. Contained in the image is encoded information. For instance, in the Relic Revcovery game, the temple images might look identical but each has identifying information (left, right and center) encoded in hexagonal dots. Vuforia can be used to detect the VuMark images when in the camera field of view and read the encoded information and return it to your program. Your program can then determine the relic stacking scheme to gain the most points.

There are several examples in the FTC SDK examples section, but here is a simplified example. This example makes the VuMark finding code generic, meaning it can be used for any VuMark, and puts that code in its own class. This makes the opMode itself simple, it just looks for a VuMark and when found, converts the VuMarks id information to the form (enum) used by the Relic Recovery game. The example also shows X (left/right), Y (up/down) and Z (distance) offsets of the center of the Vumark image in relation to the center of the camera field of view.

 

Navigation:

Overview: 
Learn about timing issues in robotics programming.
Objectives: 

Understand the speed of program execution on a robot and what that means for your program. Understand how to write code that does not fail due to timing issues.

Content: 

When programming robots (or any other real-time system), it is very important to understand how the speed realm of the robot differs from your own. When we look at our robot program, we see the while loop that we use to perform the read-environment/make-decision/act repeating pattern. We tend to think of this loop as happening slowly or at least as we might think of going through these operations.

The reality is that the robot will execute the while loop in our program thousands of times per second. The robot operates much faster than you think. This can lead to bugs in your programs in some situations.

Consider the example code below. The purpose of the program is to perform two actions controlled by the gamepad buttons. The program will count each time your press button A and on each press of button B, toggle a boolean variable from true to false. Download the program in Android Studio and test it on your robot.

So what happened? When you pressed the A button the immediate result is the program counted hundreds or thousands of button presses. Why? Because while the A button press seemed to you to be quick, on the program's time scale the button was down for many repeats of the while loop, and it counted each loop. Same for the B button. The setting of the boolean value bButton seems erratic and definately not a toggle each time the button is pressed. Again, due to the fact that your idea of a button press and the program's idea of a button press are quite different.

What do we do about this? We have to write code to handle this situation and convert the many button presses seen by the while loop into one logical press and act only when the one logical press happends. Here is the example program modified to handle the timing problems:

Download this program into Android studio and try it out. You should see the button presses now handled correctly.

The use of the variables aButtonPressed and bButtonPressed to track the state of the button is called latching.

 

Navigation:

Overview: 
Explore the use of PID controllers to manage motors.
Objectives: 

Understand what a PID controller is and how to use one to control robot motors.

Content: 

With the test robot used to develop this course, there is a problem with the previous examples of turning under gyro or IMU control. When turning at a constant power setting and setting the power to zero when the target angle is reached, depending on motor configuration, gear ratio, robot weight and the turn power, the robot will most likely not stop quick enough to be on the desired angle. This is called overshoot. On our test robot, a 90 degree turn would end up being 110-120 degrees. Fixing this can be tricky to do manually but there is an automated way to better control the turn.

To do this we will use a software routine called a PID controller. PID stands for Proportional, Integral, Derivative. The idea behind a PID controller is to take the desired state value (90 degrees in our turn example), compare that to the actual (feedback) state value (the current gyro or IMU angle) and apply factors to the difference (called the error) that produce a proportional output value. So in our example we start out turning away from zero towards 90 degrees at the full power we specify. As the turn progresses, the angle of turn is fed to the PID controller routine which measures error and produces a value (the turn power) at or near the starting (full) power. As the turn gets closer to 90 degrees, the PID routine starts to return smaller and smaller values thus reducing the power being applied and slowing the rate of turn. In theory this reduction in power and slowing rate of turn will eliminate the overshoot. The PID controller can also apply a tolerance margin that indicates when the actual value is within some percentage of the target to further control robot motors.

A similar example is to use a PID controller to compute the power correction needed to make the robot drive in a straight line. Here the target is zero (gyro not deviating from direction we are traveling) and any change in the measured angle will result in a correction value calculated by the PID controller.

A PID controller can take a lot of tuning to get the desired result but once you get a feel for how they work you can tune them fairly quickly and by using all three of the PID factors you can get quite fine control over motors. 

There are many resources and discussions of PID online. Here, here and here are some resources to start with to investigate PID further. The FIRST forums on programming have extensive discussions of PID in robot applications.

The example below takes the previous DriveAvoidImu example and uses two PID controller instances to manage straight driving and the 90 degree turn on obstacle contact. The PID controller class itself is an inner class inside the example. It would be an obvious candidate to be moved to a utility class.

 

Navigation:

Overview: 
Learn about the REV Hub's built-in IMU or Internal Measuring Unit and how to use it.
Objectives: 

Understand the REV Hub's built-in IMU and how to use it.

Content: 

The REV Expansion Hub has a built-in IMU, or Intertial Measurement Unit. This is a sensor that can measure acceleration (movement) in several axis. It can be used in place of an external gyro. The IMU is not used in quite the same way as the gyro but is similar. Note: you must configure the IMU on I2C channel 0, port 0. Here is the DriveAvoid example converted to use the IMU in place of the MR gyro.

 

Navigation:

Pages