F) Wireless Communication Method
Overview
The RP10 robotic platform must have a method for user input of coordinate input, remote control and general information transfer to a client. Past iterations of concepts have focused on discrete implementations of each concept. In other words, there was a hand-held remote controller with a tether to the platform and a wired link between the platform and a PC for coordinate input and general information transfer. Drawbacks to this method are many, not the least of which is the fact that the robot had to be physically connected to a device that the user would be using. Other caveats include operating range, data transfer speed and expandability. Also, no provision was made on the platform that would give the user a choice of communications with the platform. We were planning to use a RS-232 port on the single board computer (SBC) for data transfer.
After more thought and familiarity with the SBC, it appears that it will be easy to offer RS-232 or a wireless method for external connectivity.
Offering the user a choice of connectivity is more in line with the customer needs of an open and scalable platform. It also frees the customer from complicated development hardware since RS-232 will be supported; even a basic stamp can be interfaced to the platform.
No extra hardware would be needed to support this functionality as the SBC and any PC or development kit already support these communication methods. Further, only a small amount of software will need to be added to determine the communication method being used; both cannot be used simultaneously.
That’s all well and good, but the real development is the realization that wireless communications are well within reach of this project. The wireless communication method followed the realization that the SBC has an Ethernet port. So, in addition to offering RS-232, we could provide support for wireless communications with the RP10.
The proliferation of the Ethernet communication protocol is a testament to the benefits of using it, which will not be outlined here in detail. It is assumed that the user has used Ethernet communications enough to have a grasp of its reliability, scalability and general benefits.
The Ethernet port on the SBC has such profound impact on the future direction of this project that it is difficult to limit the documentation outlining the awesome possibilities. Wireless control is but a tiny piece of what can be accomplished. How about wireless video? What about wireless audio? Imagine being able to interact with the robot in real time from the other side of the world, while hearing the sounds from the robots environment! How about remotely updating the platform software? What about putting a common off-the-shelf (COTS) GPS module on the robot? The possibilities are nearly endless.
Details
First of all let’s go over why we want a wireless switch/router and not just a wireless access point. Wireless access points only allow one Ethernet connection. This would be enough for all of the project requirements for this track. The caveat here is that you can only plug one device into an access point. This device would have to be the SBC. This obviously limits expandability. Routers and switches enable massive expandability by providing multiple Ethernet ports to plug devices into, and they are cascade-able.
So we want a wireless switch/router. Either will work, although the routing ability probably wouldn’t be needed unless the platform network became substantially more complex. However, routers are often less expensive than switches. There is ample documentation on the internet covering the differences between switches and routers; they will not be covered here.
Power
The platform has ample DC power reserves to supply the router. The requirement for most COTS routers is 12V @ 1A (maximum).
Software
Linux is well known for its reliability in network server applications (the SBC runs Linux). A requirement needed to achieve this reliability is ease of network based support. It is incredibly easy to write programs which communicate over Ethernet on Linux platforms. On the client side, LabView also has exceptional support for Ethernet communications. The fact that the Ethernet link is implemented in a mixed wired/wireless stream is of no consequence. The physical layer is transparent to the high level developer, and of course to the user. The complexities are handled by the COTS hardware.
Integration
So how does this all hook up on the platform? Not much to it really. A CAT5 cable connects the SBC to the router. Power will come from a regulated voltage source on the RP10 platform as needed to meet the requirements of the router.
Possibilities
OK, so it looks like at the very least, remote control is possible, but I dropped a couple bombs up there, like wireless video. The user can buy a wireless camera, affix it to the RP10, power the platform and then go back to their couch and enjoy a live video feed on their laptop. Well you do have to know how to tunnel the data stream, but that is trivial and I’ll show you how. I may even write a small VI to handle it for the user.
In addition to adding complex peripherals remember, anything that connects to the standard platform (like a sensor connected to the DAQ module) can still be used without added complexity. Adding wireless Ethernet does not complicate existing platform features.
Alas, there is one caveat. In order to have this plug and play feature for adding components, the user is limited to buying devices that have Ethernet connectivity. This sounds like a massive drawback, but it isn’t. Ethernet has become ubiquitous. There are many Ethernet compatible camera systems with pan and tilt control for under one-hundred and fifty dollars. There are also neat things like laser range-finders and other high performance systems like GPS that all have Ethernet connectivity.
Further, if a user wants to add something separate from what the standard platform can easily integrate, they can use a five dollar microprocessor to control the system they need. Many microcontrollers have Ethernet peripherals and the manufacturers offer open source (FREE) TCP/IP software stack to support them. For example: PIC18F86J65. And if the user wants to use a microprocessor that does not have an Ethernet peripheral, there are SPI to Ethernet bridges available to ease the development (Microchip).
Third Party Software Requirement
The backbone of what makes this idea simple is the understanding of tunneling and port forwarding of packet data. Please refer to the figures now to get an idea of what is going on here. For now, you may ignore the RS-232 data stream as it is only there to give a complete overview; it is not covered further in this documentation as there is no need. The figures are placed in order from the user all the way to the platform. To cover in detail how this all works is beyond the scope of this document, but a simplified explanation follows. Following are some links that explain some of the concepts used to implement the communication method:
Concept Links (Wikipedia)
Ethernet
TCP/IP
Port Forwarding
Secure Shell (SSH and SSHD)
AES Encryption
Tunneling
Switch vs. Router (About.com)
Figure 1.1 User’s Local Environment.
Figure 1.2 Hostile Network Environment.
Figure 1.3 RP10 Platform Environment.
Basic Walkthrough
As I said, to cover every piece of this puzzle is beyond the scope of this document, but I will try to explain the macro level here. Don’t be put off by the initial perception of the figures; it is simpler than it looks. Basically, by using common open source (free) software, all the complexities are hidden; the figures show much more than will be visible to the user and even the developer.
OK, let’s walk through, starting with the user in figure 1.1. The user will be sitting at a PC or laptop that has a GUI running (probably LabView). The only requirement here is that the user’s computer has a valid route to a wireless access point (I will use access point from here on out which may mean router or switch, it doesn’t matter). So, in the GUI there will be a method of selecting which communication method to use; this may be implemented via a radio button for example. The GUI will then take the information and send it to the correct module within the ‘guts’ of the GUI software which will handle the necessary protocol abstractions with the operating system. The data is now encoded as RS-232 or TCP/IP data depending on what the user has selected. For the wired protocol (RS-232) the data is streamed right to the platform. For TCP/IP data, it is more complex. For now, don’t worry about the wireless method, I will explain that later. The GUI will setup a secure tunnel by using a program called ‘Putty’ on port 8000. This will make it so that any data coming from the GUI on TCP/IP port 8000 will be ‘forwarded’ and encrypted (AES) to the platform. So, Putty will be listening on port 8000 (of the user’s PC) and any data it gets will be encrypted via AES and sent over the Ethernet link to the platform
On the platform side, SSHD will be setup to listen for information from an SSH client on port 8000. The platform software will be listening here for data.
It is obvious that the modular approach to platform and GUI software will make this very easy to implement and change in the future. All that is needed is a module that establishes a link to a client and then pipe that data to the platform software (see platform software document).
Ok, so the wireless part of things is hardly even worth talking about. The off-the-shelf hardware handles everything here.
Expandability
This port forwarding scheme is commonplace, which is nice because it should be easy to find someone with the required expertise to help setup new tunnels for talking to other Ethernet devices on the platform.
As an example, let’s say the user wants to put a pan and tilt video camera on the platform. The user chooses a camera to meet their needs with the requirement that it have Ethernet connectivity, like the one pictured (click picture for link).
Figure 1.4 Ethernet Pan/Tilt Video Camera.
These systems are standalone; they need nothing in terms of resources from the platform (besides power). On the client side (User’s PC) all that is needed is to setup a tunnel that will forward requests from the camera software (which is running on the client pc) to the platform over Ethernet, via Putty. The cameras come with software for controlling them. It may be possible to integrate the camera control into the main GUI; this will depend on many factors mostly dealing with the vender’s openness.
Conclusion
This document has explained a valid method for controlling the RP10 platform from an Ethernet/RS-232 enabled device. Further, methods for wireless communication and data transfer have been covered. Using Ethernet on the SBC as a means for connectivity clearly offers amazing expandability and secure, reliable data transfers.
G) Wireless Proof of Concept
Overview
The document platform_communications.doc examines a method for bi-directional communications with an RP10 platform via wireless Ethernet. To verify this concept, this test plan has been developed. Two laptops will be used, each with wireless Ethernet cards (built in). One laptop will simulate the platform (host) and the other will be the remote interface (client). The host will be running the SSHD and an Apache web server inside Cygwin. SSHD will be forwarding requests to port 8000 which is where Apache is configured to listen. The client will run Putty to tunnel requests made from its port 9000 to the host on port 8000. On success, the client will see the stock apache web page. This proves two way communications via Ethernet as HTTP requests are bi-directional.
Phase 1
First, all this will be done on the same laptop (you can tunnel ports on localhost). This will prove the test concept. This was successful as this is how I attained the following screen shots used in the figures.
Figure 1.1 Proof of Concept Overview.
Figure 1.2 Successful on localhost, on to phase 2. Note port specification on address bar.
Phase 2
Set up as outlined in the figures and stated in the overview
Phase 3
Setup with the host as the PC104 board.
Results
Phase 1 Successful. 1/31/2007 BW
Phase 2 Successful. 2/02/2007 BW