What are the details on the wireless interface?

[NoahAndrews]

The press release mentions an "Advanced communication architecture uniquely suited to mobile robotics". That doesn't sound like wifi to me, which is probably a good thing IMHO. What's being used instead?

[Tom Eng]

Hi NoahAndrews - thanks for your post.

The new platform uses WiFi Direct technology to provide point-to-point communications between the driver station and the robot. WiFi Direct is an industry standard and it provides reliable, robust and scalable communications between mobile and other devices (laptops and devices such as printers can support WiFi Direct). The wireless radios that are available on the new Android devices are significantly faster and can tolerate a greater amount of background wireless noise than our previous wireless control system.

Also, since the new platform is based on Android, as wireless technology and WiFi standards evolve, these changes will be incorporated into the Android platform and become available for use with our control system.

Tom

[AlanG]

Tom,

Up to now, the team I mentor (#3734) has been doing software development on PCs, and then downloading code from a PC to a robot, so that testing can be done under control of the connected PC.

I assume that we will run Android Studio on PCs rather than Android phones. So I need to know what I and the students need to do to get WiFi Direct running on our various laptops and PCs, and linked to robot SnapDragon platforms. (My laptop is a 6-year-old HP Pavilion (incompatible with "Intel My WiFi"), and the laptops and PCs owned by the school and the students are typically at least 3 years old.) Furthermore, the AP Computer Science teachers at 3734's school are VERY excited about the possibilities of FTC-like robots and their Java code becoming part of classroom examples, demonstrations, and projects. This school, The School of Science and Engineering (Dallas), is very capable of enhancing the AP CS curriculum in ways that are of interest both to FIRST and to the AP CS program.

So, please advise us:
What are you recommending to us to get WiFi Direct running on older Windows 7 PCs, especially those not compatible with "Intel My Wifi"?
How about Windows 8 PCs?
How about MACs?

[mlsamuelson]

AlanG,

My understanding of the process is: you'll develop with Android Studio on a PC, compile and download to two separate Android devices - one to serve as the brain of the bot and the other being the driver control device. The wifi connection then will occur between the two Android devices. When the bot is operational, there's no need for the PC/Mac/whatever, as there's no Field Control System to run.

[Jerry McManus]

When the bot is operational, there's no need for the PC/Mac/whatever, as there's no Field Control System to run.

Yep, that's it in a nutshell. For teams that were using bluetooth and/or USB to test code from RobotC that workflow has changed with the new platform. You will now be developing code in your favorite Java IDE that is configured with the Android SDK (and ADT), compiling and downloading that code as an app (an apk in android speak) via USB to either the driver side device and/or the robot side device and then testing directly from the devices themselves. No connection to the development machine required.

Based on the latest tech talk there is a "crawl" option for teams new to Android and Java in which FTC provides both the driver side app and the robot side app. The driver side app is a "plug and play" teleop program and the robot side app has options for discovering and configuring your hardware options such as motor controllers, etc. Very similar to the "motors and sensors" setup in RobotC, except it is performed on the robot side device itself.

Apparently there will also be precompiled autonomous apps available, but will only work if your hardware setup and device names matches what's in their code.

[Tom Eng]

Tom,

Up to now, the team I mentor (#3734) has been doing software development on PCs, and then downloading code from a PC to a robot, so that testing can be done under control of the connected PC.

I assume that we will run Android Studio on PCs rather than Android phones. So I need to know what I and the students need to do to get WiFi Direct running on our various laptops and PCs, and linked to robot SnapDragon platforms. (My laptop is a 6-year-old HP Pavilion (incompatible with "Intel My WiFi"), and the laptops and PCs owned by the school and the students are typically at least 3 years old.) Furthermore, the AP Computer Science teachers at 3734's school are VERY excited about the possibilities of FTC-like robots and their Java code becoming part of classroom examples, demonstrations, and projects. This school, The School of Science and Engineering (Dallas), is very capable of enhancing the AP CS curriculum in ways that are of interest both to FIRST and to the AP CS program.

So, please advise us:
What are you recommending to us to get WiFi Direct running on older Windows 7 PCs, especially those not compatible with "Intel My Wifi"?
How about Windows 8 PCs?
How about MACs?

Hi AlanG,

Thanks for the post - I would like to clarify the development process/environment for the new platform. As mlsamuelson and Jerry McManus mentioned, a typical team would use a computer or laptop to run the Android Studio software. The laptop can be a Windows machine, a Mac, or a Linux machine. The team will write their programs on the laptops, and then can transfer/upload them to the Android device on the robot with a USB cable. In general, your laptop/PC does not need to support WiFi Direct. You can use a simple USB cable to connect and load your programs onto the robot controller (Android device).

Also, it is possible to set up a "wireless adb" connection to upload your program and debug your program wirelessly. With a wireless ADB connection you can connect your development laptop to the Android device wirelessly. You can upload programs to the Android device via the wireless adb connection. You can also monitor/debug the program that is running on the Android device that is attached to the robot through the wireless connection. You can do this even as the Android device on the robot is also being controlled by the driver station.

So to summarize, if you'd like to develop programs for this new platform you can use a Windows PC (7 or 8 are both fine), a Mac, or a Linux machine. You can upload your programs to the Android devices using a USB cable (similar to how you can upload a RobotC or LabView program to an NXT device using a USB cable). You also have the option of doing a wireless ADB connection to upload programs to an Android device and to debug a program running on an Android device.

Hope this info helps.

Tom

[AlanG]

I understand what you're saying about moving compiled code to the bot and to the driver device, when practicing or playing in game-like conditions. But we've had a lot of experience and success with very quick-turnaround code modification followed by practice-field testing under control of the PC.

But I'm not talking about Bluetooth or USB connections between PC and bot. For the past several months, I've been using WiFi communication between PC and bot, to develop and test leJOS Java code for my own personal solar-powered EV3-driven bot. Once the EV3 boots up, associates with an AP, and gets an IP address from DHCP, my PC can reach the bot at that IP address, so that WinSCP can download the latest code. Then, I just push the "start" buttons for the EV3, and for my Java control application on the PC.

My PC Java code and the EV3 Java code do all bidirectional communication through standard Java TCP Socket and ServerSocket objects, using a message protocol hat I developed to suit my purposes. Neither the PC nor the EV3 have any idea of how, in detail, they are each "doing their business" with joysticks, mouse pads, arrow keys, GPSs, motors or sensors.

So, I interpret "Wifi Direct" as the potential for the PC to set itself up as the AP for a SnapDragon-driven bot that's running Java (SE? ME?) on top of the Android OS. I assume that FIRST is going to give us some well-documented "FTC" communication protocol based on standard java.net classes. If that is so, then we should be able to develop our SnapDragon driver device app, compile it for both the PC and the SnapDragon targets, and go forward with efficient quick-turnaround testing as we have done before. The bot should be none the wiser.

Is this avenue now closed to us? If so, why? After all, we're talking about Java, the language that "runs on 3 billion devices".

[Jerry McManus]

Also, it is possible to set up a "wireless adb" connection to upload your program and debug your program wirelessly.

Hope this info helps.

Tom

Thanks Tom!

This is great info, and a very cool feature that I was not aware of. Not sure how useful it may be to someone who wishes to

develop and test leJOS Java code for my own personal solar-powered EV3-driven bot

but I for one very much appreciate your help with FTC and Android.

Thanks!

[AlanG]

I think the point of my original question has been lost.

"Wireless adb" works for Android phones and tablets. I am asking about "WiFi Direct" hardware and software that runs on Windows and MAC laptops and PCs, especially those that are as old or older than the "WiFi Direct" standard is.

My PC-to-EV3 WiFi connection is only an illustration of what my team and I would like to do, to give us some conveniences when doing quick-turnaround testing of the new SnapDragon/Java/Android robot platform. One of Java's founding principles is its great advantage here: Whatever limits PCs and SnapDragon devices have in common, the same Java "FTC driver station" program should run equally well on either platform. The SnapDragon robot platform should have no idea what machine is driving it.

So, I ask again: What advice can anyone give us about hardware and software that makes "Wifi Direct access points" run on Windows 7, Windows 8, or MAC OS machines?

I have a 6-year-old HP Pavilion dv3510nr on which the "Intel My WiFi Dashboard" will not generate an access point. However, I have found that the 2-year-old open-source Codeplex Virtual Router Manager will turn the built-in "Microsoft Virtual WiFi Miniport Adapter" into an access point. My Galaxy S5 phone (still running KitKat 4.4.4) can associate with that virtual AP and access the Internet because the PC shares its WiFi association with my FiOS router. My EV3 can associate with the virtual AP, and WinSCP can transfer files in both directions. Next, I'll see if my PC and EV3 Java programs can do their usual TCP socket communications.

I and my team members would still appreciate any other "WiFi Direct" recommendations that folks can give us about Windows and MAC hardware and software.

[Jerry McManus]

I and my team members would still appreciate any other "WiFi Direct" recommendations that folks can give us about Windows and MAC hardware and software.

FWIW, I was able to make the connection with a wireless hosted network running on my Dell Inspiron running Win 8.1 with only the 802.11b onboard wireless adapter and no access point or other wifi network involved. Use the "netsh" command line options on the windows box and the adb options in your Java IDE, as follows:

START WIRELESS HOSTED NETWORK ON WINDOWS

http://www.serverwatch.com/server-tu...windows-8.html

Open Windows command prompt as administrator
Enable the Wireless Hosted Network:

> netsh wlan start hostednetwork

Retrieve the Wireless Hosted Network details:

> netsh wlan show hostednetwork

Configure the Wireless Hosted Network password:

> netsh wlan set hostednetwork key=[your_network_password]


ENABLE ADB WIRELESS

http://developer.android.com/tools/help/adb.html

Connect Android device to wireless hosted network configured above via wifi settings.
Connect the device with USB cable to host.
Make sure adb is running in USB mode on host.

$ adb usb
restarting in USB mode

Connect to the device over USB.

$ adb devices
List of devices attached
######## device

Restart host adb in tcpip mode.

$ adb tcpip 5555
restarting in TCP mode port: 5555

Find out the IP address of the Android device: Settings -> About tablet -> Status -> IP address. Remember the IP address, of the form #.#.#.#.
Connect adb host to device:

$ adb connect #.#.#.#
connected to #.#.#.#:5555

Remove USB cable from device, and confirm you can still access device:

$ adb devices
List of devices attached
#.#.#.#:5555 device

You're now good to go!

If the adb connection is ever lost:

Make sure that your host is still connected to the wireless hosted network.
Reconnect by executing the "adb connect" step again.
Or if that doesn't work, reset your adb host:

adb kill-server

and then start over from the beginning.

Hope this helps.