Your FTC Software Map

All right, so before we start installing a bunch of software, I want to show you how the main pieces actually fit together. So the FTC setup can get confusing because you'll hear different terms like Android Studio, the FTC SDK, Gradle, Java, and ADB. And it can sound like they're all the same sort of thing. They're not, and you don't need to memorize this right now. I just want the names to have somewhere to go in your head. So just to switch over to a sort of flow diagram, the main program you're going to open is Android Studio. So that's basically our workspace. It gives us the editor, the settings, and buttons we use to control the rest of the process. Inside Android Studio, we open an FTC SDK project. That project already has the structure and most libraries we need. Most of the code that we write as a team goes in the TeamCode part of the project. When we tell the project to build, Gradle manages that job. It reads the project configuration and handles the different modules and dependencies. It runs the steps needed to turn the project into an app. Gradle also needs Java in order to run, so it uses a JDK. Android Studio includes a Java runtime for this. We'll deal with the exact settings later. For now, just think of the JDK as the thing that lets Gradle do its job. And Gradle then uses the Android SDK and its build tools to compile and package everything for the Control Hub. The result that we care about is the Robot Controller app package, usually called an APK. So the rough path is our code is in the FTC project, and Gradle organizes the build. The Android tools package it, and we end up with an app that can eventually run on the Robot Controller. ADB is a separate part of the process. It is a tool for communicating with Android devices, and we can use it to see available devices, install an app, and get logs when something goes wrong. A successful build does not automatically mean ADB can see a Control Hub, and an ADB connection does not mean the robot code actually works. They're separate things, and we'll handle them separately later. So this separation matters most when something breaks. If Android Studio will not open, changing TeamCode won't help. If the project will not build, we look at the code, Gradle, the JDK, or even the Android tools before blaming the connection. If the build works but no device appears, that points us toward ADB or the network. And if the app installs, but the robot behaves completely incorrectly, then we're into robot configuration and stuff like the wiring and hardware. So try to find the first part that failed instead of changing five different things at once. That's really all this sort of flow is for. You can come back to it later if you need to reference it and when one of these names appears in an error. Next, we're going to install Android Studio and make sure the basic Android SDK tools are actually there. We're not touching the robot just yet. We're just getting your computer ready for all of the software.