RoboRIO

Overview: 
Discussion of how to proceed with the following units depending on which robot hardware platform you are using.
Objectives: 

Determine what Unit to proceed to next.

Content: 

If you are using the EV3 platform, it is simple enough that you have learned enough Java to do some actual programming. You can skip to Unit 9 and start working on some EV3 example programs. As you proceed in the examples you may see Java concepts and constructs that are covered in Unit 8. After doing some of the examples you should return to Unit 8 and complete it as it covers topics that, while not needed to get started, likely will be needed as you write more serious robot programs. After completing Unit 8 and doing the examples you should also study Units 12 and 13 to learn still more about Java, enabling you to do more sophisticated robot programming.

If you are using the Tetrix or RoboRio platforms, you could skip to those Units and start working with the examples. However, you will quickly encounter concepts and constructs covered in Unit 8. If you can't resist starting to program and skip Unit 8, try to return to it as soon as possible, so you will know more about what you will be seeing in the example programs you will be working with. Units 12 and 13 should also be completed to give you a more complete picture of what you will be seeing in the examples and what you are likely to see if you look at the FIRST samples or code from other teams.

Navigation:

What's Next

If you are using the EV3 platform, it is simple enough that you have learned enough Java to do some actual programming. You can skip to Unit 9 and start working on some EV3 example programs. As you proceed in the examples you may see Java concepts and constructs that are covered in Unit 8. After doing some of the examples you should return to Unit 8 and complete it as it covers topics that, while not needed to get started, likely will be needed as you write more serious robot programs.

Packages and Imports

Classes within a project or in a library are organized into packages. A package is simply an identifier specified at the top of a class with the package statement. In a project, all classes with the same package name are grouped together under that name. Packages are important when we want to use libraries of classes published by other programmers, such as the Java Class Library or one of the robot specific libraries.

Overview: 
Introduction to packages and the import statement.
Objectives: 

Gain a basic understanding of packages and the import statement.

Content: 

Classes within a project or in a library are organized into packages. A package is simply an identifier specified at the top of a class with the package statement. In a project, all classes with the same package name are grouped together under that name. Packages are important when we want to use libraries of classes published by other programmers, such as the Java Class Library or one of the robot specific libraries. Packages resolve naming conflicts between classes and help programmers to locate the classes they would like to make use of in their programs.

So how do we make use of packages? If we want to use one or more classes in a package in our program, we tell Java which package (or constituent class) we want to use with the import statement. Placed at the top of our program, one or more import statements make the imported classes act like they are part of our program and we can work with those classes in our code.

You will see various package and import statements in the examples. Packages and importing them are discussed in more detail in Unit 8.

Navigation:

Content: 

 

 

Line Number: x y z k
5 0 0 0 0
8 0 0 9 0
14 0 0 9 0
24 0 0 3 0
27 0 0 0 0
36 0 0 7 0
43 0 0 0 0
56 0 0 99 33
65 0 0 2 0
74 0 0 0 0
87 0 0 9 0

 

Navigation:

IF Statement Quiz 3 Answers

 

 

Customization Description: 
clone of robotics 102
Overview: 

This course is intended to introduce the Java programming language to students using the EV3 (FLL), Tetrix (FTC) and RoboRio (FRC) robotics platforms. For EV3, the course moves the student away from block based robot programming to using an advanced text based programming language. For Tetrix and RoboRio, the course will provide more instruction in Java itself, which is missing in existing materials. The course will teach a basic competency in Java with a focus on robotics applications. Robot construction will not be covered in any depth as it is assumed the student will have or acquire hardware building skills separately.

Get started using this course by clicking the first Unit and then the first Lesson. The Lesson content will be displayed and next/previous lesson buttons will appear at the bottom of each lesson making it easy to move between adjacent lessons.

Education Level: 
Overview: 
Learn about Interfaces which are definitions of the fields and methods implementing classes must expose.
Objectives: 

Understand Interfaces and be able to use them when appropriate.

Content: 

Just as a class is a description of an object, an Interface is a description of a class. An Interface defines the fields (variables) and methods that a class must provide (public access) to users of the class. The Interface does not define how a class derives the value of a field or the result of a method, only that a class that implements an Interface must expose that Interface's fields and methods. As such, the Interface defines a public facing API that the class must provide. Interfaces are also called Contracts, in that the Interface defines a contract or agreement (in terms of the fields and methods exposed) between a class and users of that class. Classes may extend only one (parent) class but classes may implement any number of interfaces.

One power of Interfaces is that any class that implements an Interface can be used where ever that Interface is defined as a required data type. This concept is best explained by an example.

A simplifed view of the PIDController class in the FRC library shows a constructor that takes two classes as input, a PIDSource object and a PIDOutput object. PIDSource and PIDOutput are both Interfaces. Digressing for a moment, a simplified PIDController needs two things to perform its function. An input or process control value that will be used by the PIDController to compute an output value, which must be sent to some other class for action. Now in many cases the input value will come from an encoder (counts) and the output value will go to a motor (power). You could define the PIDController class constructor as Public PIDController(Encoder enc, Motor motor). There are two problems with this. First, the PIDController class and the Encoder and Motor classes have not agreed on how data will pass between the Encoder and PIDController class and how data will pass between the PIDController and Motor class. The second issue is that the PIDController as defined will only work with Encoders and Motors. What if we wanted to use some other classes as the input and output objects? Interfaces solve both of these problems.

The simplified PIDController class constructor actually looks like this: Public PIDController(PIDSource source, PIDOutput output). PIDSource and PIDOutput are Interfaces and they define what fields and methods are required for any class that wants to act as a PID source or PID output object. These Interfaces define the contract between the PIDController class and any class wanting to act as a PID source data provider or a PID output data consumer. The example Interfaces look like this:

A class implementing the PIDSource Interface must provide a method defined as double pidGet(). That method must return the current input value to be used by the PIDController. Since any class passed into the PIDController constructor for input must implement the PIDSource Interface, the PIDController now knows what method to call on the source object reference variable to get the input value. For instance, the Encoder class implements PIDSource and as such must provide the method pidGet() along with its other methods. When pidGet() is called, the Encoder returns the current tick count. So an Encoder object can be passed to the PIDController constructor. But so can any other class that implements PIDSource. A class implementing the PIDSource Interface would look like this:

Any class that implements PIDOuput must provide the pidWrite(double value) method. That method when called, will take the passed value and perform some action with it. The PIDController knows that any class implementing PIDOutput will have  the pidWrite() method and so it knows how to send the output value it has calculated from the input, by calling the pidWrite method on the output object reference variable. A class implementing the PIDOutput Interface would look like this:

For instance, the Motor class implements PIDOutput and provides the pidWrite(double value) method and sets it's motor power from the value. So a Motor object can be passed to the PIDController constructor as an output object. But so can any other class that implements PIDOutput.

A simplified PIDController class would look like this:

An example of using these classes:

The key here is that the single implementation of the PIDController class can handle both the custom source and output classes as well as the standard encoder and motor classes.

Classes can implement more than one Interface along with any other fields or methods they wish. Interfaces are very powerful and allow a class expecting an Interface (like PIDController) to work with any number of other classes that implement that Interface.

Note that Interfaces only define the expected fields and methods to be exposed by the implementing class. The actual implementation (code) is contained in the class implementing the Interface.

Like many things in Java (and other languages), this is a basic introduction to Interfaces. There is a lot more to Interfaces which you can read about here. Here is a video on interfaces. This lesson should be enough to understand Interfaces and use them in your robot code.

 

Navigation:

Overview: 
Explore how the Singleton Design Pattern is used to simulate a static class.
Objectives: 

Understand the Singleton Design Pattern and how it is used.

Content: 

In a previous lesson, we discussed static variables and methods. Static variables and methods are available without an instance of their containing object and are shared with all other object instances that exist in your program. This is used for global variables and utility methods that don't really have the aspect of multiple instances that many objects do. We also said that Java does not support static classes. Lets explore the idea of static classes in more detail.

A static class would be useful when you will have only one instance of a class in existence at any time in your program. A robotics example might be a class that handles the teleop phase of the robot game. You really would not want to have more than one instance of your teleop class existing at the same time since the hardware interface can't be shared. So it would be nice to be able to define your teleop class as static.

Since you can't, you could define all variables and methods in your teleop class to be static and that would technically achieve the result you are looking for. However, it would still be possible to use the new keyword and create multiple instances of your teleop class. This would not make much sense as the fields and methods are static. However, you can disable the new keyword for a class by marking the class constructor private. Now you can't create instances of the teleop class with new and you have to access the class variables and methods using the class name. This will work but at the end of the day it is kind of messy and different than most classes you would write in Java.

A better alternative might be a regular class that is limited to a single instance and that single instance is shared when you ask for a new instance of that class. This can be done using the Singleton Design Pattern.

A quick note about design patterns. Design Patterns are coding techniques or design ideas shared by programmers across the world. Like code libraries, design patterns are idea or concept libraries. Singleton is a design pattern that describes a way to have a single instance object. This is how it works:

To create a Singleton class, you add a private class level static variable with the data type of the class itself. Next you mark the class constructor as private to disable the Java new keyword. Finally you add a method called (by convention) getInstance(). The getInstance() method checks to see if the static class variable is null, and if it is null, creates an instance of the class and stores the reference in the class variable and returns the reference to the caller. If the static class variable is not null, getInstance() returns the existing reference to the single existing instance of the class to the caller. In this way all callers to getInstance() get the same reference to the single instance of the class. The rest of the class can be written just like a normal class and the variables and methods are accessed via the instance reference in the calling class.

Here is an example of a singleton class:

Here is how this might be used:

Here we have 3 references to the singleton class but only one actual object instance has been created. Note that the variable instanceCount and method getInstanceCount() are coded and accessed just they would be in a normal class. This code would print out:

inst=1;req=3
inst=1;req=3
inst=1;req=3

Here is the example code in CodingPoint. Here is a video dicussing the Singleton pattern.

Singleton classes can be difficult to understand at first, but are very useful in Java programming and in robotics in particular.

 

Navigation:

Pages