Last Updated: April 13, 2017
What is the problem?
Programming an FTC robot normally requires the user to connect the robot’s Android device (phone) to the computer via USB and press the “Run” [▶] button in Android Studio. This means getting up from the comfy chair, removing the device from the robot, plugging it into the computer, and then reconnecting it to the robot. This is slow and inefficient. This also means repeatedly unplugging and plugging the Micro-B USB connectors, which are fragile and easily broken. What if that wasn’t necessary?
To get straight to the “how-to” and skip the explanation of how or why this works (and if it’s okay to lose Internet access on the PC while programming or debugging the robot), see the following three most important sections:
- Simple: Join the WiFi Direct network from the PC
- Add several useful “External Tools” for ADB to Android Studio
- Connect wirelessly to program and debug an FTC robot
To avoid losing WiFi internet access on the PC while programming or debugging the robot, see the following additional sections:
- Appendix: USB WiFi Models – Acquire a small WiFi adapter.
- More elegant: Add a second WiFi adapter to the PC
Otherwise, on to the explanation!
What is ADB?
The Android Debug Bridge (ADB) protocol allows Android Studio to communicate via the adb program with the device, normally attached via USB. ADB allows programs to be stopped and started, files to be copied to or from the device, new APKs to be installed, running processes’ CPU and memory to be monitored, and logs to be accessed (amongst many other actions). When pressing the “Run” [▶] button in Android Studio, adb is used to copy the resulting APK file to the device and install it.
Using ADB over a network
The ADB protocol can be used over a network, so long as it is enabled on the device, via USB, after each time the device has been rebooted. This can be accomplished by running an adb tcpip command to enable TCP/IP (network) access to ADB on the device. This is normally accomplished by running the adb tcpip command (specifying which TCP/IP port to listen on) from the command-line1, while the device is attached via USB:
adb tcpip 5555
Once ADB over TCP/IP has been enabled (in this case on TCP port 5555), any computer can be connected to it over the network by running an adb connect command (and accepting access on the device when prompted):
adb connect 18.104.22.168:5555
The IP address “22.214.171.124” must be replaced with the IP address2 of the Android device being connected to. Once the device is connected over TCP/IP, Android Studio can be used exactly as though it were connected via USB.
A big snag: The FTC Robot Controller uses WiFi Direct
This is where things get somewhat interesting, and specific to FTC robots. The FTC Driver Station and Robot Controller apps use WiFi Direct to communicate with each other. (And normally are disconnected from all other WiFi networks.) This establishes a private WiFi network between the two devices – so, normally, the two devices are not on the same wireless network as the PC where Android Studio is running. There are two solutions to this, but both involve getting the PC onto the same network with the Android devices.
Simple: Join the WiFi Direct network from the PC
It is possible to join the WiFi Direct network created by the FTC Robot Controller app from a PC. The name of the WiFi Direct network is usually known by the team because it’s based on the device name, which is visible in the FTC apps: something like “DIRECT-xy-1234-RC”3. If an attempt is made to join the network from a PC, though, a password is needed to do so. This password can be found using the “Programming Mode” screen in the Robot Controller app’s main menu.
Once the passphrase has been obtained, any PC (or other device) can join its network by selecting the Robot Controller’s network name from the list of WiFi networks on the PC, and using that passphrase for the WiFi password when prompted. Once the PC has successfully joined the WiFi Direct network, ADB can be connected using the Robot Controller’s WiFi Direct IP address (instead of the one obtained from the Android settings menu), which is always 192.168.49.1.
However, this poses a different problem: Now the PC is no longer on the Internet. If while programming, it’s necessary to communicate with team members, use Google to search documentation, or use GitHub to manage code, this becomes very awkward, and would require frequently switching networks, which defeats a lot of the point of this exercise.
More elegant: Add a second WiFi adapter to the PC
A PC is actually quite happy to coexist simultaneously on multiple WiFi (or other) networks, so long as each network has a different IP address scheme. The WiFi Direct network created by the Robot Controller uses 192.168.49.x IP addresses, so as long as the local home/work/school WiFi network uses some other scheme (10.x.y.z or 192.168.0.x are quite typical) then there will be no conflicts.
In order to join the second network, the PC will need an additional WiFi adapter, but fortunately these are quite cheap and very small today: see Appendix: USB WiFi Models for several available models.
After installing the drivers for the new WiFi adapter and plugging it in, simply join the Robot Controller’s WiFi Direct network using the above instructions, but using the new WiFi adapter instead of the computer’s main WiFi adapter. Once connected in this way, the PC should be remain connected to the main WiFi network, and should still have Internet access through that network, while also being able to communicate with the Android device over WiFi Direct.
One possible problem, however, is that the order in which the network devices are connected (or their priority as network adapters) can mean that Internet access may not be available while connected to the Wi-Fi Direct with the second adapter, because Wi-Fi Direct provides an Internet (default) route–even though the device doesn’t itself have Internet access–and the PC may try to use it instead of the other WiFi connection.
This, too, is fixable:
- On Mac OS X, open the System Preferences and then the Network pane. Click the “gear” icon and select “Set Service Order…” and drag the entries to put “Wi-Fi” above the second Wi-Fi adapter (in the case of the TP-Link adapter, named “802.11n NIC”).
- On Windows, this problem has not been observed.
Making ADB over TCP/IP easy to use with Android Studio
One additional problem with the above solution is the need to use the adb command – from a command line – to enable TCP/IP and connect to the device. However this is not entirely necessary, either. It can be made to be extremely easy to use in Android Studio!
Add several useful “External Tools” for ADB to Android Studio
Android Studio allows the creation of “External Tools”, which will appear in the main window’s “Tools” menu. These tools can do just about anything, but they can easily be used to run adb commands so that using the command line is no longer required.
In Android Studio, open the main settings panel:
- On Mac OS, click “Android Studio”, then “Preferences…” (or simply press the hotkey “⌘,”).
- On Windows, click “File”, then “Settings…”.
In the settings panel:
- Expand the “Tools” item
- Click “External Tools” to open the External Tools list. The list is normally empty.
- For each of the following tools below, click the [+] button, and fill in the provided fields (leaving all others unchanged). Once each tool screen is filled-in, click “OK” to save. (Note: The “Program” field is the same, so the value can be cut and pasted to avoid re-typing.)
- Once all tools have been added, click the main settings panel’s “OK” button to save.
“Enable ADB over TCP/IP”
|Name:||Enable ADB over TCP/IP|
“Connect to ADB over WiFi Direct”
|Name:||Connect to ADB over WiFi Direct|
Bonus: To program the device over a non-WiFi Direct network
The following External Tool is not necessary for programming FTC robots over WiFi Direct, but can be added in order to program any Android device via any other WiFi network. It will prompt for the IP address to connect to.
“Connect to ADB over TCP/IP”
|Name:||Connect to ADB over TCP/IP|
Connect wirelessly to program and debug an FTC robot
Once the above External Tools are added, connecting to an FTC robot wirelessly to program it and debug it is trivial (after having used USB to program the device at least once4). After each reboot of the Android device (and it doesn’t hurt any other time), follow these steps:
- Connect the robot’s Android device to the PC via USB.
- Ensure that a file (such as an OpMode) is open and the cursor is in that window5.
- Click Tools → External Tools → “Enable ADB over TCP/IP” to enable ADB.
- Disconnect the USB cable from the Android device and ensure the computer is connected to the WiFi Direct network with its WiFi adapter.
- Ensure the “FTC Robot Controller” app is running on the Android device.
- Click Tools → External Tools → “Connect to ADB over WiFi Direct” to connect to ADB.
After the above steps, it may be useful to open the Android Monitor and ensure the connected device is selected in the device drop down (there may be a “[DISCONNECTED]” entry as well, from the previous USB connection; it is not the correct one).
Android Studio should work exactly the same as when it’s connected via USB: the “Run” [▶] button should transfer new APKs to the Android device, and Android Monitor will work even while the robot is running.
A bonus: Use Android Monitor logcat in real time!
Since the device can now remain connected via ADB while the robot is running… that also means that Android Monitor is usable while the robot is running. If the Android logging API (android.util.log) is used to log messages in a program, they will appear in the Android Monitor’s logcat in real time!
Appendix: USB WiFi Models
The author has purchased the below WiFi adapters and tested some of them in the course of writing this document. Reports of good or bad results with additional USB WiFi adapters is welcome either in the comments below or by email.
Nano USB WiFi Adapters
These adapters are small enough not to protrude annoyingly from a laptop computer, and should allow use of a laptop sleeve or case without removal of the device.
TP-Link N150 Wireless Nano USB Adapter (TL-WN725N)
Price: ≈$10 (March 2017, Amazon.com).
Works on Mac OS X and Windows. Have had many signal reception issues on MacBook Pro, possibly caused by antenna not protruding far enough from metal casing. Switched to D-Link DWA-131.
Mini USB WiFi Adapters
These adapters are small (similar in size to a USB thumb drive) but will have to be removed before use of a laptop sleeve or case.
D-Link Wireless N USB Wi-Fi Network Adapter (DWA-131)
Price: ≈$25 (March 2017, Amazon.com).
Works on Mac OS X and Windows. Excellent signal reception and no driver issues on Mac OS X. Appears as a wired-Ethernet adapter with a special app (in the status bar) to configure the WiFi network. Exactly the same chipset as TP-Link N150 (clone of the drivers and app).
NETGEAR AC600 Dual Band Wi-Fi USB Mini Adapter (A6100)
Price: ≈$31 (March 2017, Amazon.com).
Linksys Wireless Mini USB Adapter AC 580 Dual Band (AE6000)
Price: ≈$28 (March 2017, Amazon.com).
Windows-only. Purchased but untested as yet.
Happy wireless programming!
3 The network always starts with “DIRECT” followed by two random letters/numbers, followed by the device name. The device name is required by the FTC game manual rule <RS01> to match this pattern.
4 The FTC Robot Controller app is responsible for creating the WiFi Direct network, so if the app doesn’t exist on the device, it will not be possible to start it to connect over WiFi Direct. Connect the device over USB and program it that way the first time, start the app as instructed, and then wireless programming should work.
5 If the cursor is not in an Android-related file, running the External Tools from this guide may fail with an error about not finding “/platform-tools/adb” – because the $ModuleSdkPath$ macro used in the External Tool definition will not have been filled with the appropriate Android SDK path. To make the External Tool work with any cursor location, just replace the $ModuleSdkPath$ macro with its actual value, which can be found by clicking “Insert macro…” and selecting $ModuleSdkPath$. The downside of this solution is that if the path changes (for instance due to an upgrade), the External Tool entry may cease to work anymore.