The University of Bradford have a prototype low-cost autonomous telescope using a World-Wide Web gateway to provide access for schools, amateurs and professionals. This seamlessly integrates the telescope into the rest of the Web allowing user manuals, live reports, and astronomy lessons all to be accessible from the same interface. The telescope is controlled robotically using a simple form interface where jobs are submitted in advance, or remotely for real-time events.
Using the World-Wide Web makes an interface to the telescope available on most computer platforms and hence widely accessible. In this paper the design and implementation is discussed. It is found that some modifications to the protocols to aid remote control of equipment are useful but not essential: It is recognised that it is important not to over-complicate the protocols by adding specific features for every new innovative application.[Bern92]. When researchers were asked to predict the future of the Internet they said that it would support on-line multimedia collaborations, sophisticated information retrieval and remote control of expensive or unique scientific instruments via tele-experimentation [Hoke94]. The Internet of today is not far from this goal; the World-Wide Web gives access to a wealth of distributed hypertext documents. Extensions already being planned by organisations will support collaboration [Glic94], and attempts at tele-operation are also now being performed on the Web using remotely controlled machinery.
In this paper we look at the details of how and why we connected a Robotic Telescope to the Web, we uncover some problems with the compatibility of browsers and then make suggestions for future changes to the protocols. , and a gallery of interactive on-line geometry .
The simplest form of hardware connected to the Web is that used for remote sensing. Readings from a machine or sensor are made available periodically or in real-time. There are many examples of this on the Web: weather sensors  radiation detectors, , traffic flow sensors , and fun exhibits such as a video camera looking at an iguana .
The next category of exhibits are those machines which the user has a limited ability to interact with: the Web user makes some change to the state of the hardware. Interaction is limited to the user sending a single request and receiving a single response. Examples of this are the soft drinks machine  that can dispense cans for users with accounts, and a speech synthesiser connected at a research student's house that lets a Web user talk to his cat .
There are also some examples of complete real-time control of machinery over the Web. One example is a remotely controlled camera from Børre Ludvigsen in Norway. A small video camera is mounted on a base unit that can move the camera in two dimentions as shown in Figure 1.
An authorised Web user can control the movement of the base by using simple controls . Pictures from the camera are not relayed via the Web but instead can be watched in real time by using another application called CU-SeeMe. CU-SeeMe is a program for both the PC and Macintosh that shows live video pictures sent over the Internet in a small window [Unkn94]. Another example is from the University of Southern California where a robotic arm with an attached camera and air jet can be controlled. Using the Web  users can take turns at controlling the robot and excavating dirt to solve a collaborative puzzle [Gold94].[Baru93]. A fully robotic telescope can decide when conditions are good enough and make observations of the sky by itself: an astronomer does not need to be present and waste time waiting for clear weather. Robotic telescopes are also useful in education where students can send observations to the telescope from their classroom and pick up the results the next day.
Our prototype robotic telescope is situated on the Pennines in West Yorkshire, England. The telescope computer systems are connected to the rest of the world using the global Internet and a large number of environmental, safety and security sensors enable it to operate completely autonomously. The telescope is currently acting as a proving vehicle to assess the feasibility of a global network of similar automated telescopes. The network would be used not only by professionals, but also by amateurs and in education to increase public understanding of science.
Figure 2 shows a picture of the telescope inside its custom-built building. The telescope is a 46cm Newtonian reflector with an alt-az mounting and a cooled CCD camera. Four PCs interface with the telescope and its instruments, and a block diagram of their connections is given in Figure 3. A control computer handles job scheduling, system logging and communication with the University computers. Environmental and security sensors are monitored by a weather computer and when conditions are good enough to make observations the sliding roof is opened. The telescope's CCD camera is connected to an image computer that takes the pictures of the sky, processes, compresses and analyses them. This computer also has to control the selection of viewing filters and to make sure that the telescope is correctly focused. The telescope positioning is controlled by a forth PC that is responsible for accurately finding a position in the sky and tracking the stars as they move during a night. Communication between the telescope and the user is handled by a Sun workstation at the University, ten miles from the telescope building.
The telescope normally operates in a "Robotic" mode. Users of the telescope can request observations and these requests are scheduled and uploaded to the telescope based on a priority. The telescope works by itself during the night and returns processed results, operational logs, statistics and weather details the next morning. The telescope can also be controlled in real-time, in its "Remote" mode. In this mode the user submits a request in a similar way but the job is processed immediately and the results are available for analysis or viewing as soon as the telescope has finished the observation. In both modes the telescope is always operating robotically and this ensures that no damage can be caused to the telescope and that it is safe to leave unattended. The remote control facilities are reduced but this makes operation much easier since there is no need for the user to learn complex operating procedures. For effective use of the telescope's resources there is an ability to eavesdrop, where multiple users can watch the results of the telescope being controlled by a single operator.
The telescope is designed to be used by a wide range of people with different backgrounds and so the selection of a good user interface is of critical important to the success of the project. The interface needs to be available over a wide range of machines, should preferably be graphical and must be able to integrate the telescope control with on-line educational and instructional material.
We estimated that there were four platforms used by the majority of people interested in controlling the telescope: PCs using Windows, Macs, UNIX Workstations and text based terminals. Our early developments were with a custom PC interface, and this was used to allow a group of UK school children to interact with the system to generate instructions for using a telescope on Mount Hopkins, Arizona.
It is important to have a consistent user interface over different platforms and operating systems. Users must invest their time in learning a new interface and this time is wasted unless the skills they build up can be easily transferred [Brow94]. The World-Wide Web was considered as a way of providing an interface to the telescope which was independent of the platform and operating system: Web browsers have been written for a range of text based and graphical environments and there are an increasing number of users and applications. The Web also has mechanisms for supporting fill-in forms and virtual documents that let browsers act as remote display interfaces for hardware.
With a Web interface, the telescope can become part of a seamless virtual reality linking in not only its documentation, technical reports and astronomy lessons but also any other relevant work done by anyone else around the world. Users need only a standard Web browser to be able to submit observing requests, find out about our telescope  and compare it with the large Apache Point remote telescope . They can look at an image taken from an observation with our telescope and compare it with one taken from a standard star database held at NASA .http://www.eia.brad.ac.uk/rti/. The main menu is shown in Figure 4. Users can read an on-line user guide about the telescope, find out technical details of the hardware and software, learn more about stars and galaxies, read weather reports, and control the telescope - all from the same interface.
Job submission and observation results are password protected. On entering the correct username and password a user can look at their jobs' progress from the database, as shown in Figure 5. New jobs can be submitted by filling in a simple form; users specify what object or area of sky they wish to examine and a few other details. Once checked for errors the job is scheduled based on the user's priority ready for processing by the telescope. Just before it turns dark the jobs for the night are collected and sent up to the telescope. The next morning the completed jobs are returned and users can look at their results and download any images.
Reports of telescope performance and the previous day's weather details are also returned from the telescope and made generally available. Since the English weather tends to be poor, there is often a delay of several nights waiting for good conditions and so users are notified automatically via electronic mail when their jobs have been completed.
Anyone on the Internet with a compatible Web browser can submit a low priority job to the telescope as a guest user by using the username "guest" and the password "astro". During our testing phases these will be completed as time allows. Details will be available in the future about becoming a registered telescope user.. A collection of programs are used to interface the Web to the telescope and these are written in a combination of C and Perl. The C programs are slowly being rewritten in Perl which will make them easier to maintain and keep consistent. User authentication is provided by the standard HTTP basic authentication protocol.
We use three ways of creating the documents for use with the Web interface. The user however is not aware of the mechanism used to create a particular document.
The Perl language is ideal for writing these programs: being an interpreted language it allows the form and processing to be changed without the need for re-compilation. The same script handles both the data submissions (POST) and the generation of the initial form (GET) so that only one program has to be updated when the form needs to be changed.[Putz94]. It is useful when submitting jobs to the telescope to get an idea of the weather conditions, and data is collected for this purpose from many weather and security sensors at the telescope site  . The user can choose to look at graphs of the data from any sensor on any date using a simple form interface. A script checks the form and returns a page that references dynamic in-line images. When the browser requests these in-line images graphs are created from the data archives and returned. A library of C routines, GD [Bout94], is used to render the graph onto a bitmap ready to be returned as an in-line image. To reduce load on the server a cache containing the most recently requested images is kept and these are returned where possible.
The graphs can then be added into any documents as required. For example, including the following in a document would insert an in-line image showing a graph of the times when it was raining on the 6 September 1994, as shown in Figure 7.
<img src="http://www.eia.brad.ac.uk/rti/reports/weather/archive.doit? graph=1&date=060994&asens=Rain+Average">
Another problem with real-time control is keeping state information: knowing what the user is doing and making sure you can only have one operator at a time. Solutions are currently possible by using application programs running on the server to keep track of users' movements through the system. It is easy for a user to become confused however by saving references to the documents or by using the browser's "Reload" or "Back" options..
The system can identify what browser is currently being used by the user most of the time. We use this information to look up a browser's capabilities in a table. When the user makes a request to submit a job a dynamic page informs them if their browser has the right support and if not what other browsers on their platform will work instead. This is not ideal as new browsers and versions are being written all the time and we have to keep track of which ones support which functions. In the future compliancy testing of browsers might make users more aware of the compatibility problems. There are two main problems with some browsers that affect us: the caching of dynamic documents and the built-in basic authentication.
The "Expires" header in the HTTP protocol [Bern94] is designed to stop browsers and proxy servers from caching frequently changing pages. Unfortunately there are very few browsers that take notice of this header and so a work-around has to be used on the telescope pages. A simple and effective way of stopping documents being cached is to append a different string to the URL each time a dynamic page is referenced (encoding a string from the current date and time works well). This fools browsers into thinking that the document is different each time.[Ibra94], others find that the interface itself is limiting [Klem94]. Whilst writing the various gateway programs to interface the telescope to the Web we have thought of a number of changes and additions to the protocols. These changes would also be useful for other interactive applications and so they are briefly outlined in this paper. Whilst the changes would increase the usefulness of the telescope exhibit they are not essential and it is important that the protocols are not made over-complicated by new additions for every innovative application. Browsers should be kept as simple as possible, since adding more and more complexity to the protocols will put off potential authors. New protocol additions would also have to be implemented in all the current browsers. One solution to this would be to have small applications that can be integrated with browsers as proposed by Gutfreund [Gutf94]. These applications would have a defined way of talking to a browser and allow many new possibilities such as real-time status displays for remote-control applications.
We propose three possible additions. In-line vector graphics are a useful way of increasing the speed of producing graphical output; a permanent image cache would allow users with slow Internet links to still see the attractiveness of Web exhibits; and a progress indicator would be useful during searches and other processes that take a long time to complete.
There are frequent requests for large numbers of other image formats to be supported such as JPEG images which are smaller but take a long time to decode. It is unlikely that new formats will be added to the specifications as every browser writer would then have to include and maintain code to render or decode the new format images; with only one format currently widely supported this task is quite manageable.
In-line images could have the option of being assigned a unique identifier. When a browser is about to download an image it would first look in its permanent cache. If the browser does not already have a copy of the image locally it would then request it from the server and the user would have the option of adding it to the permanent cache for the future. A standard pack of the icons most commonly found on the Web could be distributed with all browsers, and institutes such as Universities could install their logos and other graphics on all campus machines. A standard pack of graphics and icons for our telescope could be downloaded and installed in advance and our application would be visually attractive even if used over a slow serial line. The format and assigning of the unique identifier is left for further discussion, although it would be reasonable to use the work being done on the Universal Resource Name (URN) scheme [Soll94].[Perr94] and the implementation does not affect existing servers or browsers. A certain type of dynamic document (a non-parsed header CGI script) can output an extra "Progress" header as many times as required before the main body of the page. This is incredibly useful for the telescope as some scripts that involve connecting to the telescope site and retrieving data can take several minutes to run. An example is given below of what the header of a dynamic document would look like after the initial HTTP headers.
Progress: Starting to dial remote site (pause) Progress: Connection established, sending command (pause) Progress: Command accepted, retrieving data (pause) Content-type: .. (rest of html document)
In the future we will be working on the robustness and ease of use of remote operation to allow control of the telescope by students and other World-Wide Web users around the world whilst it is dark in England. Another addition will allow a number of observers to eavesdrop while the telescope is being controlled remotely by a single operator. The ability to see or hear the telescope moving in these situations is a great benefit and this will involve the connection of our security cameras to a frame capture board or possibly a CU-SeeMe system.
The World-Wide Web interface to a robotic telescope has demonstrated that it is possible to revolutionise astronomy for users such as school students, undergraduates and amateurs. For professional astronomers it opens up whole new areas of astronomy based on the rapid reaction to events and the continuous observation of objects. The interface allows any Internet user to explore real objects and events and make them available to all interested parties - a truly planetary museum.
Created: 17 Oct 1994