WEB INTERFACE TO PLAYER / STAGE USING AJAX

Madhuwant Satyanarayan

Department of Electrical and Computer EngineeringUniversity of Auckland, Auckland, New Zealand

Abstract

This report is to determine the feasibility of having a Web Interface to Player/Stage using AJAX and to explain the tasks that were involved in implementing the prototype web based interface.

Player/Stage is an open source robotics simulation software available only in Linux and thus available to only a select few users. The web interface to Player/Stage incorporates all basic functions of Player/Stage i.e. viewing maps, executing robots, terminating robots etc. The web interface uses AJAX to make this possible. AJAX or Asynchronous JavaScript + XML is a combination of existing web technologies coming together under a common goal of making web applications more creative and interactive by enabling web pages to reload much quicker as it reloads only items that have changed as compared to the classic web technique of reloading the entire web page for just a few changes.

The prototype is based on a client server model with the web interface requesting a server (running on Linux) that was created for this purpose. The server issues a response to the web interface based on the request received. In conclusion the web interface front to Player/Stage has been implemented using AJAX. The web interface front in the immediate future can also be used to control Pioneer robots based in the University Of Auckland based on the assumption the web interface goes live.

1. Introduction

Player / Stage is an open source Robot and Sensor Research Software that allows users to watch or control robots by writing programs for the Player/Stage platform.

The purpose of this project is to develop an attractive and secure web browser using an AJAX or Asynchronous JavaScript + XML interface to achieve the task. The web interface would allow users to watch or control robots and their sensors through their web browser.

The requirement for this project comes in the wake of the increasing popularity of Player / Stage as a result of significant progress and developments made in the field of robotics, however the use of Player / Stage is restrictive at present due to its dependency to run only on the Linux operating system coupled with the

complexities associated with the installation of Player/ Stage. The Web Interface would enable any user to access Player/Stage irrespective of the operating system Platform as well as on any browser that can handle Java Scripting. The web interface would also be required to run efficiently in at least two major browsers in use across the world as well to enable it be accessible to a majority of people. The graph below describes the major browsers in use at present.

Browsers Usages Statistic

0

10

20

30

40

50

60

IE 7 IE 6 IE 5 Firefox Mozilla Netscape 7/ 8

Opera 8 / 9

Browsers

% U

sers

Figure 1: Statistic of Major browsers in Use (Statistical Data for graph obtained from [1])

This paper is organized as follows. Section 2 describes about the requirements of the project. Section 3 describes about tools being used in this project. Section 4 describes about the how each of the components of the project works. Section 5 describes about the tests performed and theirs results. Section 6 describes about the future enhancements, problems that could be solved and the ones that could not be solved as well as drawbacks. Section 7 finally mentions about the conclusions drawn from this project.

2. Requirements

The main requirements for this prototype based on initial specifications as well as aspects that were considered crucial on our part for the successful working of this prototype.

Web Interface running on at least two major browsers namely Internet Explorer 6 and

Firefox as 80% of users using the internet use either of these browsers. (Refer to Fig. 1)

Providing Access to Multiple Users Prototype should incorporate basic functions

of Player/Stage Displaying Live Images Displaying the Textual Content of the

Executed Programs A basic security mechanism in operation to

prevent unauthorized users from using the web interface.

3. Tools Used

3.1. Player

Player is a robot device server that allows for a robot to be controlled, it provides a clean and simple interface to control the robot sensors and actuators over a network. Player is quite flexible as it supports a variety of robot hardware and also provides for implementation of complex algorithms. [9]

Figure 2: Picture of Pioneer Robots running player (Reproduced from [3])

3.2. Stage

Stage is a collection of simulated robots that are running Player and operating in a 2d map based environment. This allows Stage to run hundreds of robots on a single desktop PC as it is simulation based software. [9]

The purpose of Stage is to simulate a whole population of mobile robots, sensors in a multi variable environment without access to any of the actual robot hardware and environment, thus enabling rapid development of controllers all over the world that would eventually drive real robots. [9]

Figure 3: Picture of a Stage Map window with multiple robots running player

3.3. AJAX (Asynchronous JavaScript + XML)

AJAX or Asynchronous JavaScript + Xml is a term that was coined in 2005 that refers to the use of several existing web technologies coming together with the goal of making web applications more creative and interactive in an efficient manner i.e. without a significant increase in the use of bandwidth. [4]

AJAX achieves this by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not need to be reloaded each time the user makes a change or request. This makes web pages more interactive as well as makes them faster to reload.

AJAX applications can be executed on all major browsers without causing too many changes to the security settings, thus they can be executed on any sort of platform or browser as long as JavaScript is enabled.

AJAX applications thus are effectively filling the part of niche that was once of Java Applets. [2]

Figure 4: Compares the normal communication of web server interface (left) with AJAX communication of web server interface (right). (Reproduced from [4])

3.4. Python

Python language was chosen as the language that would be used for achieving our goals because of its excellent support for Unicode and an impressive range of encodings, as well as an excellent and fast XML parser that provides character data from XML as Unicode strings. Python’s standard library also contains implementations of the industry standard DOM interface for working with XML data i.e. AJAX, and additional support for alternate parsers and interface is also available. These features when combined with its features of its source code being easy to read and maintain, portability and powerful object oriented capabilities make this an ideal language for our project. The general familiarity in using the Python language from past projects and assignments also played a crucial role in the selection of this programming language. [6, 7]

4. How it works

The user initially is met by a login screen that is displayed when the user attempts to connect to the web interface. This login screen prevents any unauthorized person from entering the Web Interface. Once logged in the user is greeted with the Web Interface with the user name displayed on top. The user has access to various radio buttons enabling access to different maps, programs and robots for running the programs. Once the user connected to Player/Stage and has selected the map, robot and the program to be executed the live images start being displayed. The user can exit the interface at anytime by logging out. The shut down feature is enabled only if the user satisfies certain conditions. The background operation in existence during the entire process mentioned above is explained in the below lines. Snapshots of the login page and the web interface are displayed below.

(a)

(b)

Figure 5: Screenshot of Login Page (a) and Web interface designed (b).

4.1. Architecture of System

The diagram below assists in understanding all the aspects of this project. The diagram describes the tasks carried out by each component and also the languages they were written in. A brief explanation about the diagram follows.

Figure 6: Architecture of System (Reproduced from [8])

The diagram mentions that the architecture of the system essentially comprises of a Client Side i.e. Web Interface or Browser, Server side i.e. Linux based remote server written entirely in python and the Player/Stage application running on the remote Linux based server.

4.2. HTTP Request

HTTP request is carried out on the client side i.e. web interface side as it provides a method for client side JavaScript to make HTTP requests. It makes scripting options more flexible by allowing for POST requests without changing the page. This provides for snappier user interaction that uses lower bandwidth as well. [5, 8]

theTimer=setTimeout("reloadImage()",1000);

The Web Interface designed makes Asynchronous requests using the built in function known as XMLHttpRequest. This function essentially requests for an object from a web server by specifying the location i.e. IP address. The request function gets activated whenever one of the buttons on the browser has been activated by the user. The request function then checks for the browser being used by the user to decide on the built in function that would be implemented based on the specific browser in use by the user. A snippet code of the XMLHttpRequest function has been attached in the appendix that shows a new XMLHttpRequest object being created based on the browser being used by the user. [5, 8]

4.3. Handling Requests

The communication between server and client (web interface) was achieved by using ‘SimpleHTTPServer’ module available in the Python library. The module consists of an event handler class ‘BaseHTTPRequestHandler’ to serve resources from the base directory of the server. The server program written in python was configured to listen to clients requests based on the client connecting to the server by specifying the location of the host computer i.e. IP address (as shown in Fig.6 above). This creates a simple handshake connection between the server and the client where the server responds to the clients requests [10].

4.4. Login Page

The role of the login page comes into play when dealing with multiple users as it enables individual users to log in based on their username and defined password as well as keeping a list of the number of people logged in as well. This prevents unauthorized users from using the web interface.

The login page works by checking the username and password with a pre existing list containing the username and passwords of all users enabled to use this interface. If the username and password entered match up to the one in the list for that particular user then the user is granted permission to enter Web Interface, else the user is denied permission to log in and is fronted up with the login screen once again. The user on successfully logging in is assigned an ID that is unique to that particular user. This unique user ID is used by the browser whenever the client makes a request to the server on behalf of the user as it helps to determine the user making the request and respond suitably.

4.5. Communicating with Player/Stage

This function is essential for the entire operation of the web interface as it initiates the connection between the server and Player/Stage. The function gets triggered on the server side when a user initiates a connection to Player/Stage on the web interface front. This function

makes use of the inbuilt python function “popen” that allows for programs to be executed on command line to start Player/Stage. The function is executed in a thread to allow for other processes to run concurrently enabling the web interface to function.

4.6. Map Selection and Display

Player / Stage allows for being executed on different environments (maps) to allow users to check the behavior of the programs written on different environments as there are a new set of unknowns for each new environment. This can be related to a gaming environment where a new map always throws in a new set of challenges for the players concerned.

Three maps were incorporated for the purpose of our web interface. The maps are chosen by the user for the purpose of choosing an environment to execute the program/s on the robot/s. This occurs by the client requesting the server for the particular map selected by the user. The map selection occurs by the user connecting to the Player/Stage thus resulting in the Server initiating a connection between itself and Player/Stage and requesting stage to be initiated on the map selected by the user.

The live map gets displayed only once a user has initiated a connection to Player/Stage. The user that initiates the connection to Player / Stage is known as the “Primary User” and other users on entering the web interface are displayed a message stating that Player/ Stage is already active. This results in other users being unable to change the existing map to execute the robots.

4.7. Live Image Display

The purpose of Live Image display is to enable the user to get a visual impression of Player/Stage as well as generating interest among people who have not used Player/Stage as well due to inaccessibility.

The Live Image display gets initiated only once a user has initiated a connection to Player / Stage resulting in the client sending a request to the server to initiate the image display function.

The image display occurs on server side by using the built in Linux image capture function known as “import” that allows for taking snapshots of the desktop. The snapshots of the Stage window are taken continuously by taking the ID of the stage window into consideration to prevent snapshots of any other windows apart from the stage window. On the web interface front the snapshots are requested on a continuous basis. The code below shows how the requests are made continuously on the browser end.

Figure7: Code that shows how requests are made continuously on the browser end.

The code above is a timer that requests the image to be reloaded by requesting a new image from the server every second. This thus results in users getting the impression that they are viewing a streaming video as the use of AJAX to achieve this enables the image to be updated without the entire page refreshing.

The whole process is made possible by the use of threads. This allows for other functions to continue working concurrently with the image capture function in operation. The code for this function is attached in the appendix under Windows ID.

4.8. Program Selection, Display and Execution

The purpose of program selection is to grant the user a choice of choosing among the five pre existing programs. The text of the program once chosen is displayed in the display box.

The execution of Player / Stage and test files is initiated by the server on the request of the client program. The server makes use of the “popen” command to execute Player / Stage as well as run the precompiled program files.

The execution of the program occurs once the user has chosen the program and the robot that the program needs to be executed on. The program/s once executed on the desired robot/s would result in the robot/s being inaccessible to other users and a message is displayed informing the user that he or she does not have access to that robot. Thus only the user that executed the program/s on the robot/s has control over the robot/s. The figure below displays the alert that pops up when a user tries to access a robot that is being used by some other user.

Figure 8: Alert displayed when user tries to use a robot that is already being used.

The execution of certain programs also results in the display of data relating the position of the robots to other objects. This further enables the user to get an accurate position of the robots concerned with respect to the various objects as well as other robots as well.

4.9. Termination of Robots

The termination of robots is an important requirement as it allows others users to make use of that robot. This is achieved by the client requesting the server to kill a particular robot. The server before accepting the request determines whether the user had executed the program on that robot at the start using the user id and robot id, if the user had not started executed the program on that particular robot/s then an alert is displayed informing the user that the robot cannot be killed, alternatively if the user had executed the program then the server accepts the request and the robot/s is terminated by stopping the program/s that were executed based on the robot id. This thus results in the robot being made available to all active users.

The robots are terminated using the “kill” function in Linux that stops a program based on the process id of the program. The two figures below shows the alert that pops up when a user tries to stop a robot not controlled by him and also the when the robot is controlled by that user as well and terminates the robot respectively.

(a)

(b)

Figure 9: Alerts displayed when a user tries to stop a robot not controlled by him/her (a) and when the user kills a robot (b).

4.10. Shut Down

The role of Shut down is to close the active connection between Player/Stage and the Server. The Shut down option is made available only to the Primary user i.e.

the user that initiated Player/Stage connection initially when there are no other active robots in existence. The shut down feature on being used in this case would result in the connection between server and Player/Stage being terminated and the primary user status being assigned to the user that initiates a new connection to Player/Stage.

On the contrary if active robots are in existence when the primary user decides to shut down, an alert is issued that directs the primary user to use the log out feature instead. The figure below shows the alert that is displayed on the web interface.

Figure 10: Alert displayed when a primary user uses the Shutdown feature when other users have robots that are active.

An alternate user is unable to use the shut down feature at any time and an alert is issued instructing the user that “you are not the primary user” and hence the user has to use the log out feature.

4.11. Logout

The role of log out comes into play when dealing with multiple users as was in the case of this web interface as well.

Log out is used when there are other robots being executed by other users, thus a user can exit the web interface by using the log out feature enabling other users to continue using the web interface as well as using the robot/s that the logged out user was using during his session.

Log out works by the client requesting the server to log out the concerned user. The server on accepting the request sends a request to the log out function that results in the user being removed from the list of users logged in at present. In the case of a primary user logging out, the next user on the list of active users is assigned as the primary user.

The server connection to Player/Stage gets terminated automatically if there are no active users.

Logging out and Shut down can effectively be described in terms of the Microsoft Windows environment. The role of log out in Windows comes into play when there are multiple users accessing the same computer with different profiles being loaded for every particular individual. Thus an individual merely

needs to log out to complete his session as opposed to Shutting down that only results in the computer being turned off and the next individual having to start up the computer once again before using it. Thus Shut down and log out are two distinct functions performing different tasks.

4.12. Multi User Handling

The importance of task scheduling in a multi user application is extremely significant as it controls access to all the resources made available to the users based on the feedback received from other users.

The handling of multiple users requires Multi user task scheduling i.e. essentially a queuing mechanism that was designed for the purpose of this web interface. The queuing gets initiated at the start when the user logs into the web interface. The pre assigned ID of that user is entered onto an array of active user ID’s using the web interface. The first element in that array is defined as the Primary user unless player/stage has not been initiated at the start, leading to the primary user being assigned to the user that had initiated the player/stage connection, however once that user logs out the primary user status is assigned to the first element of the list of active users.

Multi user queuing also gets triggered when a user log’s out by removing the user id from the list of active user’s using the web interface to prevent the occurrence of a user logged out previously being denied permission to enter the web interface due to the security mechanism incorporated in the design in the web interface that prevents the same user from entering twice.

5. Tests and Results

5.1. Multi User

The multi user aspect is one of the essential features of the web interface. This was tested by logging in six users at one time as the web interface has currently been set to allow for only six users because of the presence of only six robots. One of the users initiated a connection to Player/Stage that resulted in the live map display being triggered on all six users using the web interface i.e. all six users see the same image. The figure below shows the alert displayed on the web interface when connection to Player/Stage was activated by another user.

Figure 11: Alert displayed when a user has already initiated connection to Player.

The second stage of testing for multi user compatibility involved programs being executed on all six robots based on each user accessing only a single robot. The robots were then killed by the user with an alert being displayed every time a user tried to kill a robot that was not controlled by that particular his / her.

The third and final stage of testing involved all users logging out to check for the functioning of the Multi user queuing mechanism that was mentioned above. The queuing mechanism performed efficiently by removing the users from the list of active users as the user logged out of the web interface. The shut down feature was also tested by the users. The figure below displays the alert that gets displayed on the web interface when a non primary user pushes the shut down button.

Figure 12: Alert displayed when a non primary user tries to use the “Shut down” feature.

The shut down feature also display a message “Other robots still active, please logout” when the primary user tried to use the shut down feature when other robots were being used by other users. The connection to Player/Stage was terminated as soon as the list of active users is empty as was noticed on the Linux server end as the Stage window closes as soon as this occurs. Thus the tests to prove multi user compatibility were carried out successfully.

5.2. Browser

This test was carried out to test the functionality of the web interface based on the browsers that were used to access the web interface.

This test was carried out by testing the functioning of the interface when using Internet Explorer 6, Firefox and Opera. The result of this test was that the web interface functions properly in all the three browsers that were used for testing apart from the exceptions being that a user once logged out is unable to log back in if the browser window is not closed in the case of users using Internet Explorer 6. The other exception concerns all the three browsers that the web interface was tested on. This problem was noticed when the browsers were left running over a long period of time resulting in the browsers refusing to make requests to the server causing the web interface to malfunction and eventually stop working.

An extensive discussion about the solution to these problems is mentioned under 6.2.1 General Problems solved.

5.3. Functionality

This test was carried out to determine the functionality of the interface as compared to running Player/Stage in Linux.

The test was carried out by comparing the features of Player/Stage that could and could not be incorporated in the web interface. The result of this test was that the major features of Player/Stage were successfully incorporated i.e. running multiple programs on multiple robots and viewing the stage interface while this is occurring, however other features like moving robots manually using the mouse, writing custom programs, zooming in or out of the map for resizing etc. could not be implemented as they were not part of the requirements of the project.

A brief guideline on incorporating the above unimplemented features is mentioned under 6.1 Advancements.

5.4. Interface

This test was carried out to test out how user friendly was the web interface and the ease with which users could use the web interface. The results from this test outlined that the web interface was easy to use for users that have a basic knowledge of the functionality of Player/Stage. Users that lack knowledge of Player/Stage were found to be having difficulties using the web interface though with the help of appropriate alerts users lacking knowledge of Player/Stage also eventually find their way around the web interface. This test helped to remodel certain aspects of the web interface to make it friendlier towards users by displaying appropriate alerts when a user commits mistake thus acting as a guide.

6. Discussion

6.1. Advancements

6.1.1. Immediate Advancements

The immediate advancements deal with advancements that could be made possible in a short period of time.

The first advancement would require the university to set up a website to enable access to the web interface designed to a wider audience outside the university faculty as well.

The second advancement that could be made possible includes setting up the web interface to work on an actual pioneer robot thus enabling a user to control an actual pioneer robot or any other robot running player using the web interface from anywhere in the Auckland University campus initially and possibly anywhere in the world as well in the future.

The third major advancement deals with connecting a camera to the pioneer robot and then feeding the live image from the robot to the Web interface via the server. This would enable a user from any part of the world to access a robot as well as view its surroundings for research purposes.

These three advancements if implemented would significantly enhance the portability aspect of robotics as it would enable a large group of people from being just a click away from a robot.

6.1.2. Future Advancements

The future advancements deal with advancements that could be possible over a longer period of time varying from six to eights months. The advancements mentioned are based on the feedback received from colleagues and superiors after using the web interface.

The first major advancement deals with web programming that involves a user uploading their own program using the web interface that then gets sent to the server for compilation and execution on the desired robot concerned. This would enable a user to write any program to be executed on the robots thus allowing for users to be involved.

The next major advancement relates to interaction with the Stage window on the server end using web interface i.e. moving a robot manually using a keyboard, resizing map etc on the web interface end. This could be made possible by using Player joystick and other drivers that are available for this purpose on server end coupled with coordinates of the user being sent from the web interface front to implement this significant advancement that would essentially result in player/stage being fully operational from within a web interface.

6.2. Problems Solved

The problems that were noticed during the testing process and design implementation process have been mentioned in the lines below.

6.2.1. General Problems Solved

The general problems solved discusses about the problems that were solved during the design implementation on the server side. The major problem solved concerned with taking snapshots i.e. image capture.

The image capture function available in Linux makes use of the Linux inbuilt function “import”. The problem that was encountered dealt with the size of the images being taken being too large in size resulting in the Live image display on the web interface front refreshing frequently due to the time taken for the picture to be relayed across to the client side. The size of the image was found to be too big as the image being captured was that of the desktop as opposed to just the Player/Stage window. The requirement of capturing images only of the Player/Stage window involved writing a function that checked for the window id of the Player/Stage window continuously as window id is not fixed. The purpose of checking window id required the services of the “popen” function in python to execute “xwininfo -root –tree” that lists all the active windows and their respective window ids, which was then reduced to only account for the Active Stage window and its respective window id. The size of the pictures based on using this function dropped from over 100 kb to 60 – 70kb approx i.e. a significant reduction of over 30%. The code for extracting and using the windows id to capture images is attached in appendix under the title Windows ID.

6.2.2. Browser Specific Problems Solved

These problems centered on the three major browsers that were considered for the purpose of this Web Interface i.e. Internet Explorer 6, Firefox and Opera. The only major flaw that was encountered dealt with Internet Explorer 6 as opposed to any other browsers that were not affected by the flaw discussed below.

Internet Explorer 6 has a major flaw that causes the browser to stop making requests to the server if the same browser window is used to log back once the user has logged out of the web interface. This occurs due to caching on the browser end thus preventing the browser from making any requests to the server resulting in the Web Interface ceasing to function. This problem was solved by prompting the user to close the browser window when the user logs out by implementing ‘self.close();’ in the logout function of the web interface.

Thus a user using Internet Explorer 6 would be required to open a new browser window once he or she

logs out of the web interface in the existing browser window.

6.3. Unsolved Problems and their Possible Solutions

The major problems encountered that could not be solved deals with the Web Interface as opposed to the server that operates smoothly and seamlessly.

The first problem that was not solved concerns the status of the user on the list of active users Server side when the user uses the “X” button on the top right corner to close the Web Interface without logging out or alternatively uses the back button on the browser while using the web interface.

This problem occurs due to JavaScript being unable to detect an action event when the user performs these actions on the browser window.

There are two possible solutions to this problem. The first solution would require a time out to be implemented on the Server side that would result in a user being logged out automatically if there is no activity over a period of fifteen minutes on the web interface front.

The second solution to this problem would deal with sending and requesting a specified data relating to a user continuously between the server and client also known as a handshake thus when the handshake is broken the server is alerted and it thus results in correspondingly logging out the concerned user. The problem however with this solution is that as the number of users increases the data handled by the server would increase thus resulting in increasing the time taken to log out a user and remove the user from the list of active users once the user has closed the browser window. Thus timeout would be the ideal solution to solve this problem.

The other major problem with the web interface deals with the web interface refusing to make any requests at certain times if it has been running over a period of time. This occurs due to caching based on the browser assuming that the data has already been requested as the requests are similar in nature, hence data is not requested from the server.

The solution to this problem would require a timestamp being assigned to each request, thus resulting in each request being different as each timestamp is unique. This would prevent the request from being cached as each request would be unique. The codes below display the syntax for the current code in implementation without a timestamp (a) and the code with timestamp incorporated (b).

(a) http://130.216.25.135:8000/programfile+robot

(b) http://130.216.25.135:8000/programfile+robot+ dummy1157173146732

Figure 13: Syntax for requests made to server for initiating program files and robots without

incorporating timestamp (present method) (a) and incorporating timestamp (suggested method)(b).

6.4. Drawbacks

The major drawback as with most web applications is the issue of connection speed that determines the speed with which data is transferred between the server and client and also the processing power of the server that make this whole interface a possibility.

The speed of the connection is a significant issue as approximately 70kilobytes of data gets transferred continuously each time the client makes a request to the server. This occurs primarily in the form of the Live Image being displayed that results in snapshots being sent continuously to the web interface, thus requiring a sufficiently fast data transfer speed. A slow dial up connection would cause the map being refreshed much more actively.

The other drawback aspect concerns server processing prowess. This aspect deals with processing power of the server, thus the faster the server the faster it handles and replies to the requests made by the users on the client side.

7. Conclusions

The paper above states that the prototype to create a web interface to player/stage has been completed using AJAX as the basis of the design. The use of AJAX allows for web pages to be much more responsive resulting in web applications working a deal faster as it reloads only the changes made to a web page as opposed to conventional web pages that reload the entire content. JavaScript would need to be enabled on the web browser at the client end for the web interface to function as JavaScript is at the heart of AJAX. The use of AJAX prevents the web interface from refreshing when the user performs an action on the web interface in the form of running a robot, stopping a robot etc. The web interface works successfully on the major browsers Internet Explorer 6, Firefox and Opera and incorporates all the basic functions of Player/Stage i.e. starting and stopping a robot, choosing maps and choosing programs for execution on robots. The web interface functioning would depend to a certain extent on the speed of the internet connection as 70kb of data gets transferred to the web interface continuously and also it would depend on the processing power of the server due to the need to handle multiple requests and answering the requests effectively.

Acknowledgements

Thanks to our project supervisor Mr. Colin Coghill as well as Assistant Professor John Morris for their support throughout the project period. Finally thanks to my project partner Ryan Tarak without whom this project would never have been completed.

8. References

[1] W3 Schools. Browser Statistics. [Online]. Viewed 2006 July 15th. Available: http://www.w3schools.com/browsers/browsers_stats.asp[2] Wikipedia. Ajax (programming). [Online]. Viewed 2006 March 30th. Available: http://en.wikipedia.org/wiki/AJAX[3] Pioneer Robot. [Online]. Image Retrieved 2006 April 20th. Available: http://users.aber.ac.uk/jnw/CS364/pioneer2_at.jpg[4] Garrett, J (2005, February 18th ). Ajax: A New Approach to Web Applications. [Online]. Viewed 2006 April 15th . Available: http://adaptivepath.com/publications/essays/archives/000385.php[5] Ley, J (2006, January). Using the XML HTTP Request object. [Online]. Viewed 2006 June 2nd . Available: http://www.jibbering.com/2002/4/httprequest.html[6] Christopher A. Jones and Fred L.Drake, Jr , Python & XML, 1st Edition, O’Reilly Media, Inc., January 2002.[7] S.Holden, Python Web Programming, 4th Edition, New Riders Publishing, January 2002.[8] Ryan Tarak. AJAX INTERFACE TO PLAYER/STAGE, 2006 [9] Brian P.Gerkey, Richard T.Vaughan and Andrew Howard. The Player/Stage Project: Tools for Multi-Robot and Distributed Sensor Systems. In Proceedings of the International Conference on Advanced Robotics (ICAR 2003), pages 317 – 323, Coimbra, Portugal, June 30-July3, 2003.[10] The Python Programming Language. 11.18 SimpleHTTPServer – Simple HTTP request handle.[Online] Viewed 2006 April 3rd Available: http://docs.python.org/lib/moduleSimpleHTTPServer.html

Appendix A

Windows ID

def win_id():fa = os.popen("xwininfo -root -tree")counter = 0while True:

info = fa.readline()if not(info):

break

temp1 = info.split(":")

length = len(temp1[0])if length == 25:

temp2 = temp1[0].strip()temp3 = temp2.split(" ")length1 = len(temp3)if temp3[length1-1] == "Stage":

window_id = temp3[0]fc=os.popen("import-

window" + " " + window_id + " " + "map.jpeg")

XMLHttpRequest

if (window.XMLHttpRequest) { // Mozilla, Safari,... //alert("in step2");

http_request = new XMLHttpRequest(); if (http_request.overrideMimeType) { http_request.overrideMimeType('text/xml'); }

}else if (window.ActiveXObject) { // IE

try { http_request = new ActiveXObject("Msxml2.XMLHTTP");

//alert("in explorer"); } catch (e) { try { http_request = new ActiveXObject("Microsoft.XMLHTTP");

//alert("in 2nd attempt"); } catch (e) {} } }