A web architecture for ROS

Lately, I have been working on a new architecture for shifting ROS onto the web. Its critical that this problem is given due diligence.

Before I jump into the solution to this problem, lets list out what we expect from this architecture.

1. We want to access to the robot from anywhere over the internet. 
2. Critical maintenance of the robot should be possible from a remote site.
3. Easy intuitive user interface which is also easy to develop and debug
4. Consistency in the UI.
5. Minimum latency overhead on the server side to transfer data to and from the ros sub-system.
6. Freedom to use any server-side programming language.
7. As software development becomes very complex for a robot, distributed development should be facilitated. ie. minimum interdependencies b/w the various teams developing the features.
8. Granulate the server side like ROS nodes and facilitate the inter-communication b/w each of those nodes.

Problem 1:
        Set up a web server on the internet that listens to get requests and somehow publishes relevant data to the ROS sub-system. If the web server is on the same local network then publishing is rather easy. The solution which addresses this problem may use CGI.

        Setup ROS on the web server. We will be creating ros packages on the webserver that shall process GET requests from the webserver and communicate with the robot like any other node communicating over multiple manchines. For more info on setting up ROS over the network refer to the following documentation:

                 http://www.ros.org/wiki/ROS/Tutorials/MultipleMachines

        Simple apache configuration can setup the webserver for CGI.

Problem 2:
        A simple ssh to the robot is sufficient in case the robot is visible over the internet. Otherwise, make a simple web based terminal, that forwards all input characters and executes it on the robot. Use ssh keys for security.

Problem 3:
       There are many front end UI toolkits like yui, gwt that can address this problem. I have chosen GWT ( Google Web Toolkit ). GWT sdk is an amalgamation of GWT compiler (which compiles java code to javascript) and AppEngine that runs java servlets on the cloud. You can ignore the latter as we intend on using CGI as our server side programming technology.

          One thing we need to understand about GWT is that it is only a client side technology, that can be connected to any server side technology like servlets, php, CGI, etc.

          I initially thought of using AppEngine on the server side (as it comes default with the SDK) to create servlets and communicate to the ROS subsystem directly from the servlet. AppEngine is a java based server programming technology that is meant for the cloud. Although there is a rosjava package that allows creation of java packages that can communicate with ROS, its useless in this context as google programmers have enforces a security protocol on the api that blocks JNI (used in rosjava). I even tried creating a socket network b/w the servlet and a backend stub that would communicate with ROS on its behalf. But even sockets are blocked. You can see the faq of AppEngine for more info.

          So, that leaves us with a CGI based server side programming technology. I used ajax requests to communicate to the CGI code.

          In GWT, the front-end UI is written in java and then compiled to javascript. So, debugging is a breeze. Also, the use of GWT Composites ensures a high degree of abstraction required for the distributed development.

Problem 4:
       The usage of GWT ensures consistency in the UI. Since, modules have their views as independent GWT composites they do not have a code dependency on other modules.

Problem 5:
       Usage of a same ROS node as a CGI node means that no more additional hops have to take place before the communicating to the ros subsystem. However, the latency in communication with the end-user is a point of concern. This is frankly outside our scope.

Problem 6:
        The CGI based server side technology means a host of languages are supported. However, only C and python are currently supported by ROS. That's a restriction.

Problem 7 & 8 :
        ROS nodes on the server side ensure that we can use messages to communicate between nodes on the server effectively sharing processing. These nodes may behave like services and create a pseudo service oriented architecture.

         For eg: A login node may have its own private DB that stores login info of all clients. Every other node may make use of this login service to authenticate the user.

Sample Scenario:
        Lets consider a sample scenario, of addition of a new module on a robot -- Flickr node. This node takes pictures from the robot camera and uploads onto a flickr site.

         For this, we shall create a flickr node on the robot that subscribes to the webcam driver and also subscribes to a "CaptureAndUpload" topic. The "CaptureAndUpload" topic gets a message when a remote user over the web wants a pic to tbe taken. In the callback function, for the "CaptureAndUpload" topic we shall use the flickcurl library to actually upload to flickr.

          For the client side UI we shall intuitively create a GWT module which has a Composite (containing a GWT button). We shall write a simple onClick handler for this button, that shall send an XMLHTTPRequest to a server side CGI node to take a pic. All this is written in java (or a pure GUI designer - Window Builder) and debugged and then finally compiled to javascript.

          On the webserver, the ROS+CGI node on receiving a request publishes on the "CaptureAndUpload" topic to take a pic.

          This shows a sample scenario where a development team can develop and end-end solution to the requirement of a flickr node without any knowledge of the rest of the modules on the web server.

This model has been tested to work.