The beginnings of a mobile interface

The goal for today was to work on getting communication down between a mobile phone and the machine running the game, since your phone will be the controller you use to drive the vehicles.  The current model we have developed involves gathering input from the user's phone and sending it to the computer before pulsing out the commands to the vehicles themselves.

To allow for compatibility with both iOS and Android devices, the initial plan was to develop a web application (HTML5) with an interface to control the vehicles.  After attempting this, though, it was discovered that applications developed in Unity and exported to HTML5 are not compatible with mobile web browsers, unfortunately.  For testing purposes, I decided to export directly to Android in the form of an .apk file.

I designed a control scheme reminiscent of "tank-drive", in which you control the left and right motors of the vehicle independently.  For simplicity, there are four buttons, one on every corner of the screen, each correlating to a direction and a motor.

By pressing on the two upper buttons simultaneously, the vehicle moves forward.  If you jointly press buttons in opposite corners, you will spin the vehicle in place.

Communication was accomplished through the use of UDP, with the mobile phone acting as the client as the machine running the game listens to the port for incoming bytes of data.

Although this method works, it is currently excluding iOS devices, which is unacceptable.  Therefore, this Unity method might have to be scrapped in order to facilitate compatibility on multiple platforms.

The fact that the user input passes through the PC before going to the cars opens a few very interesting opportunities.  First, it may be a method of entirely eliminating any camera tracking latency.  If we know where the user wants the car to go (by pressing forward on their phones), we can preemptively assume where the real-life vehicle is going and update the virtual model before the tracking data is finished being processed.  In essence, the IR tracking would then be used as a method of correcting, or homing the location of the virtual car when the data is finally ready.

Secondly, since Unity gets the user input before sending out the commands to the cars, Unity has the power to interrupt, or go against the user input.  What this means is, if there's a virtual wall in front of the vehicle, and the user tries to move forward, Unity can recognize this and disregard the user input, effectively keeping the car from moving forward.

 Alternatively, imagine certain field effects that could cause the car to spin uncontrollably, for example.

Finally, there is an incredibly interesting thing that can be done with Unity at the reigns of these real-life vehicles:  It is possible for these RC cars to be entirely controlled by the computer.  This allows for the possibility of a person controlling an RC car with their phone, while facing a computer-controlled RC car in a soccer match.  Which sounds really awesome.  That will definitely be a stretch goal for the project, if we have extra time before the event.

Progress was definitely made, but the problem of multiple platform phone control still exists.