Proceedings of the second International
Conference of the World-Wide-Web
, Chicago IL, October 15-20 1994.
- Mark J. Cox and
Dr. John E. F. Baruch
- Department of Industrial Technology, University of Bradford, England.
- To Appear at the
Second International Conference of the World-Wide Web,
October 17-20th 1994, Chicago.
Also available as Postscript 11 pages
- Interactive Exhibits on the Web
- The Bradford Robotic Telescope
- Why use the Web?
- Telescope Operation on the Web
- Server Implementation
- Real-time Control Problems
- Server Security
- Browser Problems
- Caching of Dynamic Documents
- Basic Authentication
- Suggested Protocol Additions
- In-line Vector Graphics
- Permanent Local Image Cache
- Progress Indication
- Future of the Telescope
- Author Biographies
- Mark Cox
- John Baruch
- Electronic Mail Contact Address
The World-Wide Web can be thought of as a distributed multimedia museum.
Museums try to attract a wide audience by making their information as
interesting as possible. One way they accomplish this and provide a complete
learning experience is to use interactive exhibits to challenge and stimulate
visitors. This is also true for information on the World-Wide Web, where
interactive applications excite users and gain media attention. These novel
applications are a form of virtual reality that seamlessly connects users with
remote applications and simulations around the world.
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.
The World-Wide Web initiative is designed to bring a global multimedia
information universe into existence with present technology [Bern92]
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
. 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
, 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.
Before examining our contribution to the Web of a remote and robotically
controlled telescope it is worth looking at what types of interactive exhibit
are possible and at examples of what has already been achieved. We can
currently find four categories of interactive exhibits on the web: computer
simulation, remote sensing, simple remote operation and complete real-time
control. Computer simulations are the most common interactive exhibit
currently found on the Web and there are many examples including an interactive
dissection of a virtual frog
, 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
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.
Figure 1 Remote Camera
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].
The University of Bradford has been working for a number of years on the
development of low-cost robotic and remote telescopes [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 Bradford Robotic Telescope
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
Figure 3 Block diagram of the system
The telescope is connected to the global Internet making it accessible to a
large number of people. Remote and robotic telescopes in the past have used
either custom graphical interfaces limited to a particular computer platform,
or simple electronic mail gateways. Producing a custom graphical interface for
our telescope would allow great flexibility in the operations that could be
performed but would be a huge task, since applications for many different
computer platforms and operating systems would have to be written and
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
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
A Web interface was written for the telescope and can be accessed with URL
. 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.
Figure 4 Telescope main page
Figure 5 Examining observation requests
The Web server runs on the Sun workstation and uses a slightly modified version
of NCSA httpd
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
- Static Documents
- These are pages that do not change automatically: each page is created
by hand or by conversion from another format and they are updated manually.
This category of document includes the majority of pages on the World-Wide Web.
- Periodically Updated
- These are pages that are automatically generated or changed periodically
by external programs. Our observatory reports, weather summaries and other log
files are changed daily by a number of programs.
- With a dynamic document each request from a browser causes the server to
run an external program. The output of this program is used to create a
"virtual page" of information that is then returned to the user. Programs are
interfaced using the Common Gateway Interface (CGI) [McCo93]. Such pages are
often called "Active Pages" and they are essential for interactive exhibits
Figure 6 shows how the server communicates with the various types of document.
For robotic operation scripts are used to accept and process submitted jobs,
and add them to the job database ready to be scheduled. Remote control is more
complex with dynamic pages returning updated status information from the
telescope. Various additional scripts also have Web interfaces: adding users,
assigning priorities and other telescope administration. Other programs are
used to periodically update pages, such as the weather summary and operational
Figure 6 Dynamic, updated and static pages
One important change we made after initial implementation was a way of
improving fill-in forms for the users without any additional changes to the
browsers or protocols. Initially a dynamic program would run to check the form
was filled in correctly. At the first mistake it would return an error message
and expect the user to be able to use the "back" option on their browser to go
back to the form and correct their entry. The submission-correction process
would continue until a user had entered correct data into all the fields: this
is the way many of the forms found on the Web operate. A first improvement can
be made by returning all the error messages at once. This lets the user correct
all the incorrect fields, reducing the number of times the form has to keep
being submitted and returned. A second improvement can be made by returning a
copy of the original form along with the error messages back to the user. The
server can fill in the user's previous entries in the form when it is returned
so that the user can avoid using their browser to go back. This was
particularly useful because it was found that some PC and text-based browsers
would forget all the data entered into a form after it had been submitted, and
so corrections would involve re-typing the whole form each time.
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.
In the same way that text documents on the Web can be dynamic, graphs can also
be generated "on-the-fly" based on the user's request. Applications that use
this ability have been in operation for some time, the Xerox world map viewer
being a good example [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.
Figure 7 In-line rain
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.
When exhibits are controlled in real-time it is useful to be able to
continually monitor the status of the hardware being used. However, the Web
is designed to return a document only when a user requests it and so continuous
updating of information cannot be easily performed. The easiest solution is
to give the user an "update this page" link which they have to periodically
select. Another solution is to write a program that tells a browser to
periodically re-load a particular page using the "remote-control" feature of
some browsers. Both these solutions have their limitations and a possible
alternative is to write a completely separate application for a number of
platforms to provide constant communication and display.
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 basic method of HTTP password security is used to authenticate users and
this provides a simple but fairly low level of access protection: passwords are
transmitted un-encrypted and are vulnerable to detection by IP monitoring
programs. Users can only perform limited functions anyway, and since the
telescope runs robotically there is nothing that can be done to cause damage to
the equipment or render the telescope unsafe. Electronic mail confirmation is
sent when passwords are changed or jobs are completed, so users will become
quickly aware of any unauthorised use of their account. The telescope
administration programs for updating user records, changing software on the
telescope computers and so on, also have Web interfaces. At the moment these
are protected by host-based authentication. Using secure encrypted transfers
for these types of documents is desirable and several organisations are
currently working on additions to the Web protocols to do this
There are now more than a dozen different types of browser that connect to the
telescope server daily. The browsers come from a range of platforms and
operating systems and they all have different sets of features. Differences in
the implementations of the browsers have caused some problems for our project
as it is difficult to tell exactly which browsers support which functions. To a
non-technical user these differences are not immediately apparent and the
compatibility problems can cause confusion. The simple solution to this is to
make sure the telescope application only uses the functions found in all
browsers, but this places limits on the system and would over-complicate its
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.
A very common problem shared by nearly every browser available at the moment is
that they incorrectly cache dynamic documents. Many browsers cache all
documents so that when a user requests a page they have recently seen the
browser does not need to make another connection to the server to get it again.
However, dynamic documents can produce different output each time the same page
is requested. It is important that these pages are not cached by the browser so
that the user always obtains the latest version.
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
Fill-in forms and authentication are both moderately new additions to the Web
protocols. Some browsers support forms and some support authentication. To
submit a job to the telescope a browser needs to support both. At the time of
writing there were no PC browsers available that could submit forms into
authenticated areas. A possible solution is to not use the built in
authentication but instead get the user to enter their username and password
each time they ask to see protected document or submit a form. However this is
very inconvenient for the user. We do not do this, instead a user with an
incompatible browser is told of the problem when they try to submit a job and
it is suggested that they use an alternative browser. In the future
compatibility problems will slowly disappear as competition between browsers
Other interactive Web applications have found problems with the Web protocols:
some need to keep track of users by using state information [Ibra94]
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.
Images displayed in-line in Web documents are currently transferred as
compressed bitmaps (GIF format). Vector based information like graphs or block
graphics have to be rendered onto a bitmap and encoded before they are returned
to the browser. This process is not only slow for encoding and decoding but it
also limits the resolution of the image: lines and boxes become aliased and
small text becomes unreadable. Adding a vector based language into to protocol
would allow a picture to be scaled based on the resolution of the display being
used. For our exhibit in its real-time mode a line drawing of the telescopes
current position could be encoded in only a few bytes.
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
Many of the documents found on the Web have in-line images of some sort and
size. For example menu pages have small coloured "bullet" icons, sound samples
are referenced by a standard small picture of a speaker, and University home
pages have their collection of logos. Over a slow Internet link (such as a
telephone connection) these images can take a long time to download and so
users will often tell their browsers not to load them at all. Some of the icons
are very popular and can be found in use at many sites.
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].
Static Web documents require minimal server processing time and any delays in
displaying such a document are normally due to the time it takes to transfer
the document over the network. Dynamic documents used for searching or other
interactive applications can take much longer to complete on the server.
Current browsers have a "bytes-downloaded" or percentage indicator to give an
idea how long a document being sent from the server will take to arrive. It is
fairly trivial to add to this indicator so that interactive applications can
display a message about their current progress at any time whilst they are
running on the server. Patches for two of the popular browsers have already
been written to allow this [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
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)
The telescope has been available on the Web since November 1993 and it is still
evolving. At the moment only simple observations are able to be performed but
this will soon be altered to allow more complex observations and the tracking
of the planets and comets. More detailed astronomy lessons, telescope manuals
and technical details are also being added.
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
We have found that the World-Wide Web can act as an excellent interface to the
Bradford Robotic Telescope. Reports, user manuals, observation results and
control of the telescope can all be integrated together and with other Web
exhibits. Web browsers exist on many platforms and this makes our application
operating system and platform independent.
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
- Baruch, John E.F., "Robots in Astronomy," Vistas in Astronomy,
vol. 35, 1993, pp. 399-438.
- Berners-Lee, Tim, Robert Cailliau, Jean-Francios Groff and Bernd
Pollerman, "World-Wide Web: The Information Universe," Electronic
Networking: Research, Applications and Policy, vol. 1, no. 2, Westport CT,
- Berners-Lee, Tim, "HTTP: A protocol for networked information," An
electronic document available via WWW
- Goldberg, Ken, Michael Mascha, Steve Gentner, Juergen Rossman, Nick
Rothenberg, Carl Sutter and Jeff Wiegley, "Beyond Cyberspace: Excavating the
Real World via Mosaic," Proceedings of the Second International Conference
on World-Wide Web, Chicago, October 17-20 1994.
- Boutell, Thomas, "Techniques for Server-Side Dynamic Document
Generation," Proceedings of the Second International Conference on
World-Wide Web, Chicago, October 17-20 1994.
- Brown, Lin, "Human-Computer Interaction and Standardization,"
StandardView, vol. 1, no. 1, September 1994, pp. 3-8.
- Glicksman, J., G A Kramer and N P Mayer, "Internet Publishing via the
World Wide Web," Proceedings Groupware '94, San Jose, August 1994, pp.
- Gutfreund, Yechezkal-Shimon, "WWWinda: An Orchestration Service for
WWW Clients and Accessories," Proceedings of the Second International
Conference on World-Wide Web, Chicago, October 17-20 1994.
- Hoke, Franklin, "New Internet Capabilities Fueling Innovative
Science," The Scientist, vol. 8, no. 10, May 16 1994.
- Houch, Henry, Chris Lindblad and David Wetherall, "Active Pages:
Intelligent Nodes on the World Wide Web," Proceedings of the First
International Conference on World-Wide Web, Geneva, May 25-27 1994.
- Ibrahim, Bertrand, "World-wide algorithm animation," Proceedings
of the First International Conference on World-Wide Web, Geneva, May 25-27
- Klements, Anders, "The Design and Implementation of a Media on Demand
System for WWW," Proceedings of the First International Conference on
World-Wide Web, Geneva, May 25-27 1994.
- McCool, Rob,"The Common Gateway Interface," An electronic document
available via WWW
http://hoohoo.ncsa.uiuc.edu/cgi/, National Center for
Supercomputer Applications, 1993.
- Perry, Bill, "Status Information - Summary?," An electronic message
posted to the www-talk mailing list ( Message ID: email@example.com) This
message is available from the archives,
- Putz, Steve, "Interactive Information Services Using World-Wide Web
Hypertext," Proceedings of the First International Conference on World-Wide
Web, Geneva, May 25-27 1994.
- Sollins, K. and L. Masinter, "Requirements of Uniform Resource
Names," An Internet Draft (draft-sollins-urn-00) available via FTP
ftp://ana.lcs.mit.edu/pub/uri/draft-sollins-urn-00.txt, March 26 1994.
- "The CU-SeeMe Frequently Asked Questions," An electronic document
available via FTP.
- Mark Cox
- Mark Cox
is currently studying for a PhD in the Department of
Industrial Technology at the University of Bradford, England. His
research focusses on the use of and interfaces to robotic and remotely
controlled telescopes and his interests include public access to
computer systems and World-Wide Web technologies. Mark is also the
author of a large number of programs, libraries and drivers both
freeware and commercial used in PC applications. Mark holds a BEng
in Electronics, Communications and Computer Systems Engineering also
from the University of Bradford which he obtained in 1992.
- John Baruch
Dr John Baruch has been working on the development of robotic telescopes and
the remote operation of telescopes for over ten years. He has been active in
the parallel development of technologies with industrial partners. The
objective has been to develop technologies that will support astronomical
research and innovation in industry. The robotics programme for astronomy has
a range of industrial spin-offs ranging from Internet developments to
distributed information systems for manufacturing. His current concerns are the
process of innovation and the optimisation both of University research and
wealth creation for the industrial partners.
Mark Cox, firstname.lastname@example.org
Created: 17 Oct 1994