Your SlideShare is downloading. ×
Maddy Sataynarayan
Maddy Sataynarayan
Maddy Sataynarayan
Maddy Sataynarayan
Maddy Sataynarayan
Maddy Sataynarayan
Maddy Sataynarayan
Maddy Sataynarayan
Maddy Sataynarayan
Maddy Sataynarayan
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Maddy Sataynarayan

349

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
349
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. WEB INTERFACE TO PLAYER / STAGE USING AJAX Madhuwant Satyanarayan Department of Electrical and Computer Engineering University of Auckland, Auckland, New Zealand Abstract access Player/Stage irrespective of the operating system Platform as well as on any browser that can This report is to determine the feasibility of having a handle Java Scripting. The web interface would also be Web Interface to Player/Stage using AJAX and to required to run efficiently in at least two major explain the tasks that were involved in implementing browsers in use across the world as well to enable it be the prototype web based interface. accessible to a majority of people. The graph below Player/Stage is an open source robotics simulation describes the major browsers in use at present. software available only in Linux and thus available to only a select few users. The web interface to Browsers Usages Statistic Player/Stage incorporates all basic functions of Player/ Stage i.e. viewing maps, executing robots, terminating 60 robots etc. The web interface uses AJAX to make this 50 possible. AJAX or Asynchronous JavaScript + XML is a combination of existing web technologies coming 40 together under a common goal of making web % Users 30 applications more creative and interactive by enabling web pages to reload much quicker as it reloads only 20 items that have changed as compared to the classic web 10 technique of reloading the entire web page for just a few changes. 0 The prototype is based on a client server model IE 7 IE 6 IE 5 Firefox Mozilla Netscape 7 Opera 8 / 9 /8 with the web interface requesting a server (running on Browsers Linux) that was created for this purpose. The server issues a response to the web interface based on the Figure 1: Statistic of Major browsers in Use request received. In conclusion the web interface front (Statistical Data for graph obtained from [1]) to Player/Stage has been implemented using AJAX. The web interface front in the immediate future can This paper is organized as follows. Section 2 also be used to control Pioneer robots based in the describes about the requirements of the project. University Of Auckland based on the assumption the Section 3 describes about tools being used in this web interface goes live. project. Section 4 describes about the how each of the components of the project works. Section 5 describes 1.Introduction about the tests performed and theirs results. Section 6 Player / Stage is an open source Robot and Sensor describes about the future enhancements, problems Research Software that allows users to watch or control that could be solved and the ones that could not be robots by writing programs for the Player/Stage solved as well as drawbacks. Section 7 finally platform. mentions about the conclusions drawn from this The purpose of this project is to develop an project. attractive and secure web browser using an AJAX or Asynchronous JavaScript + XML interface to achieve 2.Requirements the task. The web interface would allow users to watch The main requirements for this prototype based on or control robots and their sensors through their web initial specifications as well as aspects that were browser. considered crucial on our part for the successful The requirement for this project comes in the wake working of this prototype. of the increasing popularity of Player / Stage as a result • Web Interface running on at least two major of significant progress and developments made in the browsers namely Internet Explorer 6 and field of robotics, however the use of Player / Stage is Firefox as 80% of users using the internet use restrictive at present due to its dependency to run only either of these browsers. (Refer to Fig. 1) on the Linux operating system coupled with the • Providing Access to Multiple Users complexities associated with the installation of Player/ Stage. The Web Interface would enable any user to
  • 2. • 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 Figure 3: Picture of a Stage Map window with to control the robot sensors and actuators over a multiple robots running player network. Player is quite flexible as it supports a variety of robot hardware and also provides for 3.3.AJAX (Asynchronous JavaScript + XML) implementation of complex algorithms. [9] 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 Figure 2: Picture of Pioneer Robots running the user makes a change or request. This makes web player (Reproduced from [3]) pages more interactive as well as makes them faster to reload. AJAX applications can be executed on all major 3.2.Stage browsers without causing too many changes to the Stage is a collection of simulated robots that are security settings, thus they can be executed on any sort running Player and operating in a 2d map based of platform or browser as long as JavaScript is enabled. environment. This allows Stage to run hundreds of AJAX applications thus are effectively filling the robots on a single desktop PC as it is simulation based part of niche that was once of Java Applets. [2] 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 4: Compares the normal communication of web server interface (left) with AJAX communication of web server interface (right). (Reproduced from [4])
  • 3. 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 (b) language. [6, 7] Figure 5: Screenshot of Login Page (a) and Web interface designed (b). 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 4.1.Architecture of System interface. This login screen prevents any unauthorized The diagram below assists in understanding all the person from entering the Web Interface. Once logged aspects of this project. The diagram describes the tasks in the user is greeted with the Web Interface with the carried out by each component and also the languages user name displayed on top. The user has access to they were written in. A brief explanation about the various radio buttons enabling access to different maps, diagram follows. 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 Requests Requests interface at anytime by logging out. The shut down Response feature is enabled only if the user satisfies certain ` conditions. The background operation in existence Response Player/Stage during the entire process mentioned above is explained Application in the below lines. Snapshots of the login page and the Client Side Server Side user Python Server web interface are displayed below. Web Browser JavaScript/HTML Player/Stage Application 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 (a) 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]
  • 4. The Web Interface designed makes Asynchronous start Player/Stage. The function is executed in a thread requests using the built in function known as to allow for other processes to run concurrently XMLHttpRequest. This function essentially requests enabling the web interface to function. for an object from a web server by specifying the location i.e. IP address. The request function gets 4.6.Map Selection and Display activated whenever one of the buttons on the browser Player / Stage allows for being executed on different has been activated by the user. The request function environments (maps) to allow users to check the then checks for the browser being used by the user to behavior of the programs written on different decide on the built in function that would be environments as there are a new set of unknowns for implemented based on the specific browser in use by each new environment. This can be related to a gaming the user. A snippet code of the XMLHttpRequest environment where a new map always throws in a new function has been attached in the appendix that shows a set of challenges for the players concerned. new XMLHttpRequest object being created based on Three maps were incorporated for the purpose of the browser being used by the user. [5, 8] our web interface. The maps are chosen by the user for the purpose of choosing an environment to execute the 4.3.Handling Requests program/s on the robot/s. This occurs by the client The communication between server and client (web requesting the server for the particular map selected by interface) was achieved by using ‘SimpleHTTPServer’ the user. The map selection occurs by the user module available in the Python library. The module connecting to the Player/Stage thus resulting in the consists of an event handler class Server initiating a connection between itself and ‘BaseHTTPRequestHandler’ to serve resources from Player/Stage and requesting stage to be initiated on the the base directory of the server. The server program map selected by the user. written in python was configured to listen to clients The live map gets displayed only once a user has requests based on the client connecting to the server by initiated a connection to Player/Stage. The user that specifying the location of the host computer i.e. IP initiates the connection to Player / Stage is known as address (as shown in Fig.6 above). This creates a the “Primary User” and other users on entering the web simple handshake connection between the server and interface are displayed a message stating that Player/ the client where the server responds to the clients Stage is already active. This results in other users being requests [10]. unable to change the existing map to execute the robots. 4.4.Login Page 4.7.Live Image Display The role of the login page comes into play when dealing with multiple users as it enables individual The purpose of Live Image display is to enable the user users to log in based on their username and defined to get a visual impression of Player/Stage as well as password as well as keeping a list of the number of generating interest among people who have not used people logged in as well. This prevents unauthorized Player/Stage as well due to inaccessibility. users from using the web interface. The Live Image display gets initiated only once a The login page works by checking the username user has initiated a connection to Player / Stage and password with a pre existing list containing the resulting in the client sending a request to the server to username and passwords of all users enabled to use this initiate the image display function. interface. If the username and password entered match The image display occurs on server side by using up to the one in the list for that particular user then the the built in Linux image capture function known as user is granted permission to enter Web Interface, else “import” that allows for taking snapshots of the the user is denied permission to log in and is fronted up desktop. The snapshots of the Stage window are taken with the login screen once again. The user on continuously by taking the ID of the stage window into successfully logging in is assigned an ID that is unique consideration to prevent snapshots of any other to that particular user. This unique user ID is used by windows apart from the stage window. On the web the browser whenever the client makes a request to the interface front the snapshots are requested on a server on behalf of the user as it helps to determine the continuous basis. The code below shows how the user making the request and respond suitably. requests are made continuously on the browser end. 4.5.Communicating with Player/Stage This function is essential for the entire operation of the theTimer=setTimeout("reloadImage()", web interface as it initiates the connection between the 1000); server and Player/Stage. The function gets triggered on the server side when a user initiates a connection to Figure7: Code that shows how requests are made Player/Stage on the web interface front. This function continuously on the browser end. makes use of the inbuilt python function “popen” that allows for programs to be executed on command line to
  • 5. The code above is a timer that requests the image to program on that robot at the start using the user id and be reloaded by requesting a new image from the server robot id, if the user had not started executed the every second. This thus results in users getting the program on that particular robot/s then an alert is impression that they are viewing a streaming video as displayed informing the user that the robot cannot be the use of AJAX to achieve this enables the image to killed, alternatively if the user had executed the be updated without the entire page refreshing. program then the server accepts the request and the The whole process is made possible by the use of robot/s is terminated by stopping the program/s that threads. This allows for other functions to continue were executed based on the robot id. This thus results working concurrently with the image capture function in the robot being made available to all active users. in operation. The code for this function is attached in The robots are terminated using the “kill” function the appendix under Windows ID. in Linux that stops a program based on the process id of the program. The two figures below shows the alert 4.8.Program Selection, Display and Execution that pops up when a user tries to stop a robot not The purpose of program selection is to grant the user a controlled by him and also the when the robot is choice of choosing among the five pre existing controlled by that user as well and terminates the robot programs. The text of the program once chosen is respectively. 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 (a) 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. (b) Figure 9: Alerts displayed when a user tries to Figure 8: Alert displayed when user tries to use stop a robot not controlled by him/her (a) and a robot that is already being used. when the user kills a robot (b). The execution of certain programs also results in 4.10.Shut Down the display of data relating the position of the robots to other objects. This further enables the user to get an The role of Shut down is to close the active connection accurate position of the robots concerned with respect between Player/Stage and the Server. The Shut down to the various objects as well as other robots as well. option is made available only to the Primary user i.e. the user that initiated Player/Stage connection initially 4.9.Termination of Robots when there are no other active robots in existence. The The termination of robots is an important requirement shut down feature on being used in this case would as it allows others users to make use of that robot. This result in the connection between server and is achieved by the client requesting the server to kill a Player/Stage being terminated and the primary user particular robot. The server before accepting the status being assigned to the user that initiates a new request determines whether the user had executed the connection to Player/Stage.
  • 6. On the contrary if active robots are in existence 4.12.Multi User Handling when the primary user decides to shut down, an alert is The importance of task scheduling in a multi user issued that directs the primary user to use the log out application is extremely significant as it controls access feature instead. The figure below shows the alert that is to all the resources made available to the users based displayed on the web interface. 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 Figure 10: Alert displayed when a primary user out the primary user status is assigned to the first uses the Shutdown feature when other users element of the list of active users. have robots that are active. Multi user queuing also gets triggered when a user log’s out by removing the user id from the list of active An alternate user is unable to use the shut down user’s using the web interface to prevent the feature at any time and an alert is issued instructing the occurrence of a user logged out previously being user that “you are not the primary user” and hence the denied permission to enter the web interface due to the user has to use the log out feature. security mechanism incorporated in the design in the web interface that prevents the same user from entering 4.11.Logout twice. The role of log out comes into play when dealing with multiple users as was in the case of this web interface 5.Tests and Results as well. Log out is used when there are other robots being 5.1.Multi User executed by other users, thus a user can exit the web interface by using the log out feature enabling other The multi user aspect is one of the essential features of users to continue using the web interface as well as the web interface. This was tested by logging in six using the robot/s that the logged out user was using users at one time as the web interface has currently during his session. been set to allow for only six users because of the Log out works by the client requesting the server to presence of only six robots. One of the users initiated a log out the concerned user. The server on accepting the connection to Player/Stage that resulted in the live map request sends a request to the log out function that display being triggered on all six users using the web results in the user being removed from the list of users interface i.e. all six users see the same image. The logged in at present. In the case of a primary user figure below shows the alert displayed on the web logging out, the next user on the list of active users is interface when connection to Player/Stage was assigned as the primary user. activated by another 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 Figure 11: Alert displayed when a user has different tasks. already initiated connection to Player. The second stage of testing for multi user compatibility involved programs being executed on all
  • 7. six robots based on each user accessing only a single 5.3.Functionality robot. The robots were then killed by the user with an This test was carried out to determine the functionality alert being displayed every time a user tried to kill a of the interface as compared to running Player/Stage in robot that was not controlled by that particular his / Linux. her. The test was carried out by comparing the features The third and final stage of testing involved all of Player/Stage that could and could not be users logging out to check for the functioning of the incorporated in the web interface. The result of this test Multi user queuing mechanism that was mentioned was that the major features of Player/Stage were above. The queuing mechanism performed efficiently successfully incorporated i.e. running multiple by removing the users from the list of active users as programs on multiple robots and viewing the stage the user logged out of the web interface. The shut down interface while this is occurring, however other feature was also tested by the users. The figure below features like moving robots manually using the mouse, displays the alert that gets displayed on the web writing custom programs, zooming in or out of the map interface when a non primary user pushes the shut for resizing etc. could not be implemented as they were down button. 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 Figure 12: Alert displayed when a non primary of Player/Stage. Users that lack knowledge of user tries to use the “Shut down” feature. Player/Stage were found to be having difficulties using the web interface though with the help of appropriate The shut down feature also display a message alerts users lacking knowledge of Player/Stage also “Other robots still active, please logout” when the eventually find their way around the web interface. primary user tried to use the shut down feature when This test helped to remodel certain aspects of the web other robots were being used by other users. The interface to make it friendlier towards users by connection to Player/Stage was terminated as soon as displaying appropriate alerts when a user commits the list of active users is empty as was noticed on the mistake thus acting as a guide. Linux server end as the Stage window closes as soon as this occurs. Thus the tests to prove multi user 6.Discussion compatibility were carried out successfully. 5.2.Browser 6.1.Advancements This test was carried out to test the functionality of the 6.1.1.Immediate Advancements web interface based on the browsers that were used to access the web interface. The immediate advancements deal with advancements This test was carried out by testing the functioning that could be made possible in a short period of time. of the interface when using Internet Explorer 6, Firefox The first advancement would require the university and Opera. The result of this test was that the web to set up a website to enable access to the web interface interface functions properly in all the three browsers designed to a wider audience outside the university that were used for testing apart from the exceptions faculty as well. being that a user once logged out is unable to log back The second advancement that could be made in if the browser window is not closed in the case of possible includes setting up the web interface to work users using Internet Explorer 6. The other exception on an actual pioneer robot thus enabling a user to concerns all the three browsers that the web interface control an actual pioneer robot or any other robot was tested on. This problem was noticed when the running player using the web interface from anywhere browsers were left running over a long period of time in the Auckland University campus initially and resulting in the browsers refusing to make requests to possibly anywhere in the world as well in the future. the server causing the web interface to malfunction and The third major advancement deals with connecting eventually stop working. a camera to the pioneer robot and then feeding the live An extensive discussion about the solution to these image from the robot to the Web interface via the problems is mentioned under 6.2.1 General Problems server. This would enable a user from any part of the solved.
  • 8. world to access a robot as well as view its surroundings that lists all the active windows and their respective for research purposes. window ids, which was then reduced to only account These three advancements if implemented would for the Active Stage window and its respective window significantly enhance the portability aspect of robotics id. The size of the pictures based on using this function as it would enable a large group of people from being dropped from over 100 kb to 60 – 70kb approx i.e. a just a click away from a robot. significant reduction of over 30%. The code for extracting and using the windows id to capture images 6.1.2.Future Advancements is attached in appendix under the title Windows ID. The future advancements deal with advancements that 6.2.2. Browser Specific Problems Solved could be possible over a longer period of time varying from six to eights months. The advancements These problems centered on the three major browsers mentioned are based on the feedback received from that were considered for the purpose of this Web colleagues and superiors after using the web interface. Interface i.e. Internet Explorer 6, Firefox and Opera. The first major advancement deals with web The only major flaw that was encountered dealt with programming that involves a user uploading their own Internet Explorer 6 as opposed to any other browsers program using the web interface that then gets sent to that were not affected by the flaw discussed below. the server for compilation and execution on the desired Internet Explorer 6 has a major flaw that causes the robot concerned. This would enable a user to write any browser to stop making requests to the server if the program to be executed on the robots thus allowing for same browser window is used to log back once the user users to be involved. has logged out of the web interface. This occurs due to The next major advancement relates to interaction caching on the browser end thus preventing the with the Stage window on the server end using web browser from making any requests to the server interface i.e. moving a robot manually using a resulting in the Web Interface ceasing to function. This keyboard, resizing map etc on the web interface end. problem was solved by prompting the user to close the This could be made possible by using Player joystick browser window when the user logs out by and other drivers that are available for this purpose on implementing ‘self.close();’ in the logout function of server end coupled with coordinates of the user being the web interface. sent from the web interface front to implement this Thus a user using Internet Explorer 6 would be significant advancement that would essentially result in required to open a new browser window once he or she player/stage being fully operational from within a web logs out of the web interface in the existing browser interface. window. 6.2.Problems Solved 6.3.Unsolved Problems and their Possible Solutions The problems that were noticed during the testing The major problems encountered that could not be process and design implementation process have been solved deals with the Web Interface as opposed to the mentioned in the lines below. server that operates smoothly and seamlessly. The first problem that was not solved concerns the 6.2.1. General Problems Solved status of the user on the list of active users Server side The general problems solved discusses about the when the user uses the “X” button on the top right problems that were solved during the design corner to close the Web Interface without logging out implementation on the server side. The major problem or alternatively uses the back button on the browser solved concerned with taking snapshots i.e. image while using the web interface. capture. This problem occurs due to JavaScript being unable The image capture function available in Linux to detect an action event when the user performs these makes use of the Linux inbuilt function “import”. The actions on the browser window. problem that was encountered dealt with the size of the There are two possible solutions to this problem. images being taken being too large in size resulting in The first solution would require a time out to be the Live image display on the web interface front implemented on the Server side that would result in a refreshing frequently due to the time taken for the user being logged out automatically if there is no picture to be relayed across to the client side. The size activity over a period of fifteen minutes on the web of the image was found to be too big as the image interface front. being captured was that of the desktop as opposed to The second solution to this problem would deal just the Player/Stage window. The requirement of with sending and requesting a specified data relating to capturing images only of the Player/Stage window a user continuously between the server and client also involved writing a function that checked for the known as a handshake thus when the handshake is window id of the Player/Stage window continuously as broken the server is alerted and it thus results in window id is not fixed. The purpose of checking correspondingly logging out the concerned user. The window id required the services of the “popen” problem however with this solution is that as the function in python to execute “xwininfo -root –tree” number of users increases the data handled by the
  • 9. server would increase thus resulting in increasing the deal faster as it reloads only the changes made to a time taken to log out a user and remove the user from web page as opposed to conventional web pages that the list of active users once the user has closed the reload the entire content. JavaScript would need to be browser window. Thus timeout would be the ideal enabled on the web browser at the client end for the solution to solve this problem. web interface to function as JavaScript is at the heart The other major problem with the web interface of AJAX. The use of AJAX prevents the web interface deals with the web interface refusing to make any from refreshing when the user performs an action on requests at certain times if it has been running over a the web interface in the form of running a robot, period of time. This occurs due to caching based on the stopping a robot etc. The web interface works browser assuming that the data has already been successfully on the major browsers Internet Explorer requested as the requests are similar in nature, hence 6, Firefox and Opera and incorporates all the basic data is not requested from the server. functions of Player/Stage i.e. starting and stopping a The solution to this problem would require a robot, choosing maps and choosing programs for timestamp being assigned to each request, thus execution on robots. The web interface functioning resulting in each request being different as each would depend to a certain extent on the speed of the timestamp is unique. This would prevent the request internet connection as 70kb of data gets transferred to from being cached as each request would be unique. the web interface continuously and also it would The codes below display the syntax for the current depend on the processing power of the server due to code in implementation without a timestamp (a) and the need to handle multiple requests and answering the the code with timestamp incorporated (b). requests effectively. (a) http://130.216.25.135:8000/programfile+robot (b) http://130.216.25.135:8000/programfile+robot+ dummy1157173146732 Acknowledgements Thanks to our project supervisor Mr. Colin Coghill as Figure 13: Syntax for requests made to server for well as Assistant Professor John Morris for their initiating program files and robots without support throughout the project period. Finally thanks to incorporating timestamp (present method) (a) and my project partner Ryan Tarak without whom this incorporating timestamp (suggested method)(b). project would never have been completed. 6.4.Drawbacks 8.References The major drawback as with most web applications is [1] W3 Schools. Browser Statistics. [Online]. Viewed the issue of connection speed that determines the speed 2006 July 15th. Available: with which data is transferred between the server and http://www.w3schools.com/browsers/browsers_stats.as client and also the processing power of the server that p make this whole interface a possibility. [2] Wikipedia. Ajax (programming). [Online]. Viewed The speed of the connection is a significant issue as 2006 March 30th. Available: approximately 70kilobytes of data gets transferred http://en.wikipedia.org/wiki/AJAX continuously each time the client makes a request to [3] Pioneer Robot. [Online]. Image Retrieved 2006 the server. This occurs primarily in the form of the April 20th. Available: Live Image being displayed that results in snapshots http://users.aber.ac.uk/jnw/CS364/pioneer2_at.jpg being sent continuously to the web interface, thus [4] Garrett, J (2005, February 18th ). Ajax: A New requiring a sufficiently fast data transfer speed. A slow Approach to Web Applications. [Online]. Viewed 2006 dial up connection would cause the map being April 15th . Available: refreshed much more actively. http://adaptivepath.com/publications/essays/archives/0 The other drawback aspect concerns server 00385.php processing prowess. This aspect deals with processing [5] Ley, J (2006, January). Using the XML HTTP power of the server, thus the faster the server the faster Request object. [Online]. Viewed 2006 June 2nd . it handles and replies to the requests made by the users Available: on the client side. http://www.jibbering.com/2002/4/httprequest.html [6] Christopher A. Jones and Fred L.Drake, Jr , Python 7.Conclusions & XML, 1st Edition, O’Reilly Media, Inc., January 2002. The paper above states that the prototype to create a [7] S.Holden, Python Web Programming, 4th Edition, web interface to player/stage has been completed New Riders Publishing, January 2002. using AJAX as the basis of the design. The use of [8] Ryan Tarak. AJAX INTERFACE TO AJAX allows for web pages to be much more PLAYER/STAGE, 2006 responsive resulting in web applications working a
  • 10. [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.h tml Appendix A Windows ID def win_id(): fa = os.popen("xwininfo -root -tree") counter = 0 while 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) {} } }

×