The University of Iowa Automated Telescope Facility

E. C. Downey, R. L. Mutel

Dept. Physics and Astronomy, University of Iowa, Iowa City, IA 52242

Abstract:

1. Introduction

The Department of Physics and Astronomy at the University of Iowa operates an Automated Telescope Facility (ATF) which serves the needs of several hundred high school students, undergraduates, graduates and faculty as well as anonymous users via the Internet. The system routinely acquires several hundred CCD images each clear night. This level of service is made possible by a computerized control system and a set of data analysis tools which eliminate many of the routine steps involved with astrometry, relative and absolute photometry and supernova searches. These tools make the ATF more than just another robotic telescope.

2. Hardware and Software Overview

The telescope is an Astrophysics 18 cm f/9 refractor on a custom equatorial mount located atop the Physics building in downtown Iowa City. The main detector is an Spectra-Source HPC-1 camera with a 1024x1024x16-bit CCD array. Various stepper motors, digital encoders and discrete sensors and actuators provide closed-loop control of the telescope mount, dome, shutter, camera and filter wheel. The computer is a 66 MHz 486DX PC with 2 GB of disk, 32 MB of RAM, CD-ROM, removable optical archive, Ethernet and color graphics display.

The operating system is version 1.1.1 of the UnixWare variety of SVR4 UNIX. Three small, custom device drivers provide access to the hardware interface cards. All telescope control and interactive data analysis is performed via GUI programs written using Motif running over the X Windows graphics protocol. These programs communicate via named pipes and shared memory to small control processes which isolate all machine dependencies. Several conventional command-line oriented UNIX processes provide batch data reduction and analysis functionality. The total amount of code is somewhat more than 60,000 lines of C, including comments, written to appropriate X, Motif, POSIX, ANSI and SVR4 APIs.

The real-time aspects of the system begin with three UNIX device drivers which provide a simple interface to the underlying hardware through ioctl system calls. These drivers are opened and accessed directly only from the dedicated daemon processes, telescoped and hpcd. The interfaces to these processes, in turn, are via named pipes (a.k.a. fifos). Using named pipes fits well in general into the file descriptor scheme of UNIX interprocess communication via the select(3) system call, and particularly with the GUI X Windows clients via the XtAppAddInput() interface. The traffic over these pipes is a simple ASCII, line-oriented command and response protocol. The commands are very basic such as to slew the telescope to a command position, begin tracking and take an exposure. The message format simplifies testing and debugging and insulates all hardware and much of the underlying implementation from the GUI processes. There are eight such pipes, each dedicated to a specific control function. The implementation hides how many daemon processes are actually responding to the various pipes. For example, at one time the dome was controlled by its own daemon but its functionality was later absorbed into telescoped after a change in the dome control hardware without any changes to the processes which use the pipes. Other processes operate off-line, such as photom, a tool to perform photometry, snsearch, which automates supernova searches, and wcs, which calibrates star fields by pattern matching to the Hubble GSC. These processes generally accept files of commands containing processing details and lists of image files and generate output in ASCII files or as image processing or header changes to standard FITS files. We have tried to eliminate proprietary functionality at each stage of the software design in favor of very vanilla UNIX methodology.

3. Example Walkthrough

We describe the operation of the automated observatory by following a typical user from the submission of an observing request to the analysis of the data returned from the system. We also describe what occurs at the control site during the night the observation from our user is performed.

3.1. User's activities

The observer considers the desired observing circumstances for his or her project and implements them in a schedule request file. This is a text file which contains pairs of keywords and values. Some keywords are required while most are optional depending on which control options are required. An example might be to investigate the light curve of an asteroid and request 6 512x512 120-second exposures of asteroid 4 Vesta through visible and IR filters each hour beginning at 22:30 Local Sidereal Time. The schedule file implementing this observing scheme is shown below.

title 'Light Curve of Vesta'
observer 'G. Piazzi' lststart 22:30:00 catalog asteroids
filter V,I duration 120,120
block start repeatdelay 1:0:0
source '4' /
blockrepeat 6

A program chksch checks the observing schedule for simple errors in keyword spellings, syntax errors, and missing required fields. This program must be run on each observing schedule before it is validated to be entered in the incoming schedule queue. For Internet observers, the file is e-mailed¹ to the telescope operator where it is added to an upcoming master telescope schedule. From the observers perspective, nothing more is needed. Once the data has been acquired, the user receives an e-mail message indicating where the requested images may be obtained via ftp. The format of the resulting images is in standard FITS format, two axes, 16 bits per pixel. All observing and instrumental parameters are including in the headers, including World Coordinate System positions accurate to better than one pixel.

3.2. Behind the Scenes

We now shift our attention to the activity undertaken by the telescope operator in order for the data to be collected and distributed to the observer. Note the telescope and the operator may be separated by arbitrary distances. The telescope operator logs in sometime earlier in the day and sees that several folks have sent e-mail which contain observing schedule requests. These mail messages are saved in a directory, sans e-mail header information. The operator also collects other schedule requests in various standard directory locations from students, faculty and special projects which may be going on. Our operator may manually add a special keyword, PRIORITY, to some requests to give them special consideration during the automatic allocation and sorting procedure.

Eventually, all candidate schedule files are collected in the incoming schedule directory. The next step is to generate a master scan list of telescope and instrument instructions for the entire night. The master scan list is prepared using an X Windows program called telsched. This program accepts one or more schedule files and sorts them into an order which makes efficient and safe use of the observatory facilities.

The master scan file is read by the telescope control daemon telrun. Telrun processes the scan list sequentially throughout a night and controls the hardware. The operator may then start the telrun program to accept the new scan list and begin execution. Once the scan list is created and handed over to telrun, the operator typically leaves and does not return until the next morning. Telrun patiently waits until astronomical twilight (or the first scan) and opens the dome shutter to begin the night's observing. It operates the telescope, dome, CCD camera, and filter wheel, collecting data throughout the night, closing up after the last scan or at astronomical dawn (which ever comes first).

Image files gradually appear in directories throughout the night as the scan list is processed. File names are chosen to closely reflect the original schedule file name. Individual logs are also generated for each schedule file as its scans are processed and can be made available to the original user as a record of observing circumstances. A master log of all observatory activities is also accumulated in an archival directory.

As each raw image is acquired, background processes run which apply the appropriate bias, thermal and flat corrections in the usual manner. The image may be in standard FITS format or compressed using the H algorithm (White & Percival 1994). The image is also calibrated for position as follows. First the image is scanned for all stellar features and a list of pixel locations is created. Then, using the nominal telescope pointing directions, a list of calibrator stars is generated from a close region extracted from the Hubble GSC. The two lists are combined in two passes. The first pass assumes no field rotation and discrete shifts in x and y are performed in search of the largest number of nearly coincident pairs from each list. This forms the seed for the second pass which performs a least-squares fit that minimizes the differences in the lists based on the standard offset, scale and rotation FITS world coordinate field definitions.

The current state of the remote observatory may be queried at any time using one of several monitoring programs which use either a X Windows or simple text interface. They are used by telescope operators and observers logging in remotely to monitor telescope status. Work is currently in progress to use these and other programs to offer a remote observer the opportunity to query the state of the observatory in general or the status of his or her observing request via an HTML interface.

The observatory may also be controlled manually using the X client xtelescope. This client may be started and exited at any time. If it detects that telrun is active, it disables all its own control functions and merely displays the current status of the major system components. It may also be used to manually stop and resume the telrun daemon and offers an master Stop command which works under all conditions.

Acknowledgments:

We thank Steve Hauser and Rob Winsor for technical assistance. The ATF has been funded by the National Science Foundation and the Iowa Space Grant Consortium.

References:

¹We are now developing a forms-input Web page where the users enter telescope schedule requests and query the status of the facility in general as well as their own observing program.