Content
- Introduction
- Robot Server
- Robot Class
- Robot Server Requirements
- Central Server
- Natural Language Server
- The Client
- APIs and DLLs
Introduction
The architecture developed in this project enables one to deploy a robot on the
Internet so that it can be controlled via the web. The system has been tested on 1 Robix robot, 1 Lego robot and few Microsoft Desktop
Agents.
There are four major components of the architecture, namely The Robot Server,
The Central Server, The NLP Module and The Client. Below diagram
represents the way in which these components are connected together. The Robot Server is a
machine hosting the robot, which desires to be controlled. Central Server provides a
unique interface to the clients to control all the robots that are connected using this
system. The NLP (Natural Language Processing) Module enables the users to interact with
the robots using Natural Language. Client here is any machine connected to the Internet. A
user can control the robot by opening a web browser on any Client and by visiting the
Central Server website.
We call the guy, who wants to deploy his robot on the Internet, the Middle Level
Programmer. To deploy his robot, the Middle Level Programmer first needs to
write the Robot Server. We, therefore, start by looking at what the Robot Server
is, why it is needed and its working details.
Robot Server
Robot Server is the machine that hosts the robot, which desires to be controlled
through the Internet. A DEA (Device End Application; Device was used instead of Robot
thinking that Robots are also devices and that the system could be generalized for more
general devices as Printer, WebCam etc. in future) runs on this Robot Server, which
provides the control of the robot to the Central Server, which in turn provides it to the
Clients. A Robot Server can host more than one robot with a DEA running on it
corresponding to each robot. That is to say that if 5 robots are to be hosted on a
machine, then 5 DEAs need to be running on it. A DEA is closely coupled to a robot,
i.e. the code of DEA for Robot1 is different from the code of DEA for Robot2.
Now when we talk about writing the Robot Server, its basically writing the DEA.
The Middle Level Programmer needs to write this DEA to be able to deploy his robot on the
Internet. Previously, that is before we proposed this architecture, it might take hundreds
or may be thousands of work hours to write such an application. But we have structured the
DEA in such a way, that the entire process of writing it and deploying on the web becomes
ridiculously easy. The DEA has a modular structure, which is partly due to the advantage
of using an object-oriented language as VC++ .NET and partly due to the Robot Class that
we have formulated. The DEA for a new robot can be written by making minimal changes to an
already existing DEA for another robot.
Robot Class
Upon observation of the APIs (DLL files) for the Robix Robot kit and the Lego Robot
kit, we found that every robot utilized some initialization functions, some clean-up
functions, and some functions that executed commands, and read sensor values.
In fact there was a particular sequence in which these functions needed to be invoked to
perform any operation on the robot. This entire function set could therefore be captured
in form of a Robot class (borrowing ideas from the OOP paradigm), by having initialization
functions in the constructor set, cleanup functions in the destructor, and having
execution commands as public interfaces to this class. Now, code for any robot-control
application can be generated very easily, to an extent that it could even be automatized,
and the programmer need not bother to learn the entire APIs for different robots to write
DEAs for different robots. It is indeed true that the middle level programmer cannot be
totally oblivious of the sequence that is required to program the robot using the API
routines. But at the same time, only a very few functions of the entire API set (that
directly affect the operation of the robot) needs to be made aware to the middle level
programmer. The sample Robot Classes for the Robix, the Lego and Microsoft Desktop Agents
can be viewed by sending a request to the WebMaster.
To know what role do the APIs play in programming a robot, please follow this link. 
Robot Server Requirements
- IIS (Internet Information Server should be installed on the Robot Server.
- Visual Studio .NET should be installed on the Robot Server. (IIS must be installed
before VS .NET)
- Robot API is required. (preferably in C/C++/VC++)
- Robot Class is required.
Central Server
The Central Server is the machine responsible for coordinating the interaction between
the Robot Servers and the Clients as well as using the services of the Natural Language
Server. The Central Server consists of a single Web Service that communicates with the
Robot Servers and the Natural Language Server by consuming (a process in
Microsoft .NET Framework, by which the functions provided by a Web Service can be accessed
from another piece of code) their Web Services.
Natural Language Server
Natural Language Server is the machine that hosts the application for converting the
natural language commands issued by the clients to the robot specific commands. This
application had already been made in an earlier BTP (July 2001-April 2003, by Sumit
Gupta). But for our purpose, we had to make a Web Service, which could expose its
functions to the Central Server and had to make few changes to its code. We have also
incorporated some Error Handling into the application.
This application is basically parser based. It uses some Grammar rules and a lexicon
Database for conversion purpose. More insight into the working of this application can be
found in the Project Report submitted by Sumit Gupta.
The Client
Client in our system can be any machine that is connected to the Internet. A user needs
to run a web browser on the client machine to be able to access the Central Server Web
Site. On the Central Server Web Site, all the Robot Servers that are connected to the
Central Server are enlisted. The user can choose any one of them at a time, following
which the interface for it will come in front of him. Using this interface the Robot
connected to the chosen Robot Server can be controlled.
back