As it relates to Android Studio By Phil Malone: phil.malone@mr-phil.com

*

*Jargon, Jargon and More Jargon

*Where to find tools/documentation

*The Software Components

*Driver Station

*Robot Controller

*The IDE

*Downloading the Code Template

*The anatomy of an OpMode…

*Creating your own OpMode

*Deployment

*Testing

*

*

*Gradle is a build automation tool that

builds upon the concepts of Apache Ant

and Apache Maven and introduces a

Groovy-based domain-specific language

(DSL) instead of the more traditional XML

form of declaring the project

configuration.

* Android Mobile Phone Operating system, by Google.

Multiple versions with ever growing capabilities.

FTC uses Android 4.4.4 KitKat

* App Application (program that runs on a mobile device)

* IDE Integrated Development Environment.

(Program for writing programs)

* SDK Software Development Kit

(Parts to help you build a program)

Google SDK

FTC SDK

* API Application Programmer Interface

(defines built-in program features)

*Google API Defines built-in Google features

* Android Studio An IDE for writing Java APPs for Android Phones

* Project All the components that go into a specific application.

*Gradle Used to “build” the application from its components.

* Java A high-level text based programming language. A

commonly used foundation for developing and

delivering content on the Web.

* Class A class is template for creating objects by which

defines the object properties and behaviors. Java

class objects exhibit the properties and behaviors

defined by its class. A class can contain fields and

methods to describe the behavior of an object.

*Object Exhibit the properties and behaviors defined by

its class.

* Field Data stored within an object

*Method Action that can be performed by/on an object.

* Refractor Refactoring is the process of changing a software

system in such a way that it does not alter the

external behavior of the code yet improves its

internal structure

* ADB Android Debug Bridge

(A means to deploy and test Apps)

* Deploy Transfer an App to the Android Phone.

(Can be done wired or wirelessly)

* opMode An Operational Mode that defines how your robot

will run during a single match period. One App

contains multiple opModes. These can be for driver

control mode or autonomous.

OpModes are selectable from the Driver Station, prior

to the match starting.

*

*Your team will use Android Studios and the FTC SDK to

write a custom App in Java.

*You will build your app to utilize API 19 which supports

the Android 4.4.4 Operating System (KitKat).

*You will add one or more new classes in the form of

custom opModes.

*You will use Gradle to build the App, and ADB to

deploy it to the ZTE phone on your robot.

** Download Android Studios…

https://developer.android.com/sdk/index.html

* Download FTC SDK https://github.com/ftctechnh/ftc_app

* Phone Setup Video https://www.youtube.com/watch?v=n597U6rcl2Y

* Android Studio Help https://developer.android.com/training/index.html

* FTC Help http://ftcforum.usfirst.org/forumdisplay.php?156-FTC-Technology

* /AndroidStudioProjects/ftc_app-master/docs (Installed with FTC SDK)

** A single App is created which contains all the possible robot operational modes

(opModes).

* All of the typical “App functionality” is already included and locked down.

* Methods are provided for accessing robot hardware and communicating between

Driver Station.

* The App attaches to the hardware using “names” that are set through an offline

“Configuration” process.

* Several sample opModes are included, but need not be used.

* New blank opModes can be added, and then filled in with the desired behavior

code.

* opModes provide several empty “methods” which should be overridden with new

user code.

** init() Called once when the driver selects a new opMode and

presses INIT

* init_loop() Called repeatedly while waiting for driver to hit “PLAY”

button. Robot hardware is updated between each call.

* start() Called once when driver hits “PLAY”

* loop() Called repeatedly while waiting for driver to hit “STOP”

or for a timed match to complete. Robot hardware is

updated between each call.

* stop() Called once when the driver hits “STOP” or a timed

match ends.

* The code in each method should quickly do its job and then return.

**Init() is provided to enable robot setup before the

match begins.

*Devices should be looked up in the Hardware Map,

and made accessible to the rest of the code.

*One-time actions should be performed, like setting

initial servo positions or starting a gyro calibration.

**Init_loop() is provided for ongoing pre-game setup.

*Eg: For proceeding with a gyro calibration that

takes several seconds, or any other action that’s

allowed by the rules prior to the start of the match.

**Start() is provided to set-up any initial match

conditions.

*This could be starting a game clock, or deciding on

an autonomous action.

*Start() can also work in combination with stop() to

allocate/free program storage, or attach/detach

from custom sensors.

**Loop() is the primary control loop.

*Game controller and sensor inputs can be read, and

motor/servo actions can be taken.

*If special timing or sequential actions are required,

one or more state machines may be required to

manage those actions over several loop() calls.

**Stop() is provided to get the robot back to a safre

mode.

*It should be used to end any actions begun in loop()

or close out any resources created in start().

** Strictly speaking you can get by putting code in just two of the

methods.

* init() for connecting with the sensors/motors by name.

(provides a chance to detect bad names prior to running)

* loop() for running the robot during the match.

*Note: There is also a type of opMode called a linearOpMode. This

creates a new thread that lets you write your code in-line, but its

capabilities and limitations were not well defined prior to kickoff. So

we’ll just stick with opMode.

*Now let’s look at the code…

*