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