In this section, I will describe the Robot Control Software.
 
A Few Words about Security:
Before I begin discussing the software, I should emphasize that this is a home (hobbyist) project.  It is not a commercial product nor intended to be one.

• No IT security is currently implemented. Anyone with access to the network at the robot's location can take control of the robot or view video from the navigation camera.  
  
• The firmware version currently used on the OpenWRT router has known vulnerabilities.  If the remote location's network was opened to the internet as described below, these vulnerabilities could allow an outside attacker to attack the remote network from the inside.
  
• A network connection to the IP address of the robot must be allowed (Open firewall or DMZ).  While this is also an obvious security risk, It can also be used to mitigate the above by letting only the operators IP address (or possibly MAC) to control the robot;  Although since the connection is not encrypted, an attacker could easily determine the address needed to spoof the connection.
  
• Access to the facilities IT infrastructure would be need to either assign a static IP address to both the robot control and video connections, or to determine the assigned (DHCP) IP addresses.  
  
• To implement this properly, a central server (most likely a 3rd location) would need to be set up to mitigate all of the above.  In other words, practical control of the robot would work just like the Teleconferencing software or other IoT (Internet of Things) devices like Thermostats, etc.
  
• In order to explain the need for IT security in commercial products further, consider this.  One may not think that the robot control commands would need to be encrypted or obfuscated assuming that actual control of the robot was secure; But consider this:  Someone accessing the commands used to drive the robot around a given facility would eventually be able to construct a map of that facility -- including where the robot was used frequently -- which could reveal the locations of important things inside that facility.  Commanding should be encrypted and padded.
  
• The chosen Teleconferencing software (and thus it's security/privacy) is not modified or affected by the Robot Control software.  The Teleconferencing software does not utilize or connect through the vulnerable router or the robot control connection. The teleconferencing hardware/software is merely along for the ride.
  
• It is also assumed that "good" WiFi access exists throughout the building or facility where the robot is used.
  

In other words: Don't implement what is described below in a secure network, or as a commercial product. Think when you build software.
 
User Interface:
As mentioned in the previous post, the Telepresence Robot may be located far away from the operator.  This means that common remote control methods such as those used for a Radio Controlled (R/C) car or a connection over Bluetooth would not be applicable.  However, basic Bluetooth code such as found here was used as a starting point.
It was also desired to have the Robot Control universally accessible, and not require software development on multiple platforms or operating systems.  
 

User Interface during use of the Telepresence Robot.  Image property of Linuxslate.com
 
This means that the Robot Control is via a web app that resides on the robot.  All one has to do is initiate a standard HTTP connection to the robot's address, and they will be presented with the interface shown above.  Note that the person-to-person interface is provided by a Google Hangouts session in another window.
 
Implementing the user interface in this manner was more complex than originally thought.  It is implemented as a ESP8266WebServer running on the ESPDuino board.  The ESPDuino web server delivers an HTML page that in turn contains CGI and Javascript.
 
The concept of Javascript and CGI embedded in HTML, which in turn is embedded in Arduino C code was a bit much for my son to follow, and frankly a stretch for my programming skills.  I'll just say that both of us got really good at reading through several levels of escape characters.  
 
Esentially, movement is controlled by starting the respective motors on a mouse down event, and the motors are stopped on a mouse up event for each button.
 
An iFrame at the top contains the separate video connection, and another iFrame just below that serves as a basic instrument panel showing the main battery voltage and the strength of the wireless signal.
 
In the next post:  The Code.

20 x 4 LCD Display
 
It has been mentioned previously in this thread that it would be desirable to have a simple display on the Telepresence Robot for information like the Robot's IP address, battery voltage, etc.  It may also be useful to allow the remote user to display simple messages such as the remote user's name, or the organization the remote user represents.
 
To this end, I went to Sky Craft Surplus in Orlando, FL., and purchased 2 LCD displays.
 
This post will concentrate on a 20 character x 4 line display that was inside some sort of digital audio device. The surplus device was being sold for US$ 9.95.  So in addition to the display, I got the steel chassis, a small PC-like power supply, an optical drive, fan, and various other potentially useful parts.
 
The display is very similar to the one shown here:

20 x 4 Alpha-numeric LCD display removed from surplus equipment
 
I had quite a bit of difficulty finding the Datasheet for this display, or any specific information on connecting it to common Arduino modules.
 
So I thought I would do a simple write up on getting these boards working with Arduino.

• While of course I have only tested this with the display I have, I believe what is here should work with boards marked as
  EDT 20-20072,  EDT 20-20072-2, EDT 20-20072-5, EW20400YMY, Winstar WH2004A, Raystar 2004A,  Raystar 2004A-LLH-JSV, RC  QC2004A and others.
  
• The datasheet for the same or compatible device is here.
  
• This is an 8 bit parallel device.  All 8 lines must be used.  There is (apparently) no support for 4 bit mode as with similar 2 line displays.
  
• This pinout is similar but not the same as other similar displays.  In particular, the last 2 pins (pins 15 and 16) are not used and should be left open.
  

 
Here is the pinout from the Datasheet and corresponding Arduino Pins and Functions:
 
Code:

Arduino    LCD   Function
GND             1     Ground
5V              2     5.0 VDC LCD Supply
GND             3     Operating voltage for LCD (Contrast Adjustment?)
D12     12      4     RS
GND             5     R/W
D11     11      6     E (Enable)
D2       2      7     DB0
D3       3      8     DB1
D4       4      9     DB2
D5       5      10    DB3
D6       6      11    DB4
D7       7      12    DB5
D8       8      13    DB6
D9       9      14    DB7
15              Vee    - Leave unconnected
16              K      - Leave unconnected
 

 
The code is equally simple.  These displays work with the standard Arduino provided LiquidCrystal Library; however, some special characters or display functions may need changes to code to appear on the display as desired.
Here is sample code to display a childish message using all 4 lines (rows) of the display:
Code:

#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 11, 2, 3, 4, 5, 6, 7, 8, 9);

void setup() {

lcd.begin(20, 4);
}

void loop() {
 
  lcd.clear();
  lcd.setCursor(0, 0);
  lcd.print("You are ugly");
  lcd.setCursor(0, 1);
  lcd.print("and your mother");
  lcd.setCursor(0, 2);
  lcd.print("dresses you");
  lcd.setCursor(0, 3);
  lcd.print("funny.");
delay(500);
}
 

 

The display connected to an Arduino Nano, and displaying a childish message.
 
Another note on the picture:
-- Yes, I tack soldered the wires directly to the Arduino Nano.  Pins and connectors would have been better, but this was just for a quick test.  It will be properly connected to the pins on the ESPDuino on the Robot.  The holes on the Arduino NANO can be easily cleaned, and pins soldered in.
-- This requires almost all of the digital I/O pins, but most of the pins used on the Robot currently are Analog pins.  I don't anticipate a problem, but the actual design of connecting the LCD to the Robot has not been done yet.
-- Another solution would be to leave the LCD connected to the NANO, and write a simple serial or I2C - to - parallel program, but in addition to the extra hardware, this would require maintenance of 2 sets of code.
 
Look for an update -- and updated Robot code -- once the LCD is attached to the robot.