Abstract
We describe the New Mexico State University (NMSU) 1 m telescope located at the Apache Point Observatory (APO), and in particular, its robotic mode of operation. Some of the issues we have encountered may be of interest to others developing similar facilities. This telescope provides a good example of the possibilities of locating a moderate-sized university robotic research telescope at a major observatory. We find that this mode of operation provides a significant amount of productive science data on a relatively small budget.
1. Introduction
Many universities and colleges operate, or have an interest in operating, small to medium aperture telescopes with a primary goal of using them for research. In contrast with a primarily educational goal, it is preferred that research telescopes be located at a site with dark skies and good seeing. Since such sites are often not available at a campus location, telescopes often need to be situated at more remote locations. However, this can make them more difficult to be used on a nightly basis, given travel requirements. It can also be a challenge for small departments to supply observers on a nightly basis, especially if there is little or no budget to pay for observers and/or travel.
New Mexico State University operates a one-meter (1 m) telescope at the Apache Point Observatory in southern New Mexico; the site is shown in Figure 1, and the telescope in Figure 2. To fully utilize the telescope, that is, obtain data on essentially all clear nights, a robotic mode of operation was developed. In this paper, we describe our system and discuss how the robotic mode is implemented. While our system does not include anything especially complex, it did take a significant amount of time to work through all of the associated computer and hardware issues, and we hope that outlining these here will be useful to others who are considering implementation of a robotic telescope, to alert them to various issues and possible solutions.
The NMSU/APO 1 m may be different from other telescopes operated by small departments in remote locations as it is located at a major observatory. The benefits of having a robotic telescope at an established observatory location are significant, as we will discuss below, and we suggest that this is a productive setup to consider for small telescopes, as there can be benefits for both the operator of the small telescope and the observatory.
2. Hardware
2.1. Telescope
The telescope is a 1-meter-diameter, alt-az telescope, situated in a small, elevated dome. It was constructed in the early 1990s; the telescope design and construction was provided by the Autoscope Corporation. The optical design is a Ritchey-Chretien, with a system focal ratio of F/6 and a F/2.5 primary mirror. The primary mirror is supported laterally through the central hole and from behind on a nine-point static support system. The secondary mirror has three motorized actuators that allow piston and tilt motions. The telescope originally implemented a single Nasmyth focus, but a new rotating tertiary mount was recently purchased from Astronomical Consultants and Equipment (ACE) to allow instrumentation at both Nasmyth foci; tertiary rotation is motorized and computer controlled. Currently, an instrument derotator is only available at one of the Nasmyth ports.
2.2. Instruments
The primary instrument is a direct imaging camera at the primary Nasmyth focus. The current camera uses a thinned, backside-illuminated E2V CCD, made available through a collaboration with the Los Alamos National Lab; the 13.5 micron pixels subtend 0.46 arcseconds on a side, providing a 15.7-arcminute field-of-view. The chip is located in an IR labs LN2 dewar, and was installed by Astronomical Research Cameras (ARC), who also provided a shutter and the CCD control hardware. The dewar has a hold time of at least 12 hours in its sideways orientation. The location on the Nasmyth port allows a vacuum-jacketed hose to be permanently connected to a 50-liter LN2 dewar that is located below the telescope; there is a commandable cryogenic valve installed in the line.
A filter wheel system, built by ACE, is located in front of the shutter, and holds either 10 2-inch square filters or 6 3-inch square filters, depending on what filter wheel is installed. A guider module was also constructed by ACE that has a dual-stage arrangement to allow for a pickoff mirror to be moved radially in the field, along with an independent focus motion for the guide camera. The guide camera itself was purchased from Finger Lakes Instruments (FLI), and uses a thinned, backside-illuminated E2V CCD in a thermoelectrically cooled camera.
Several years ago, funding was obtained from the National Science Foundation via their PREST program, primarily to enable the use of the second Nasmyth port and to construct a new instrument for it. This is a simultaneous 6-color single-object photometer, which uses a series of dichroics with a combination of avalanche photo-diodes and photomultiplier tubes to provide high speed, photon-counting photometry simultaneously in the UBVRIJ passbands; only a single target can be observed at a given time through a physical aperture of size 15 arcseconds. This instrument is presently being commissioned.
2.3. Building and Dome
The dome is a 15-foot-diameter dome made by Ash Domes. As purchased, it featured motorized dome rotation and motorized control of the upper dome slit. We modified the system to allow for motorized control of the lower dome slit as well, and the original Autoscope observatory control hardware implemented computer control of the dome motors.
The building has louvers to improve ventilation that are hydraulically opened and can be controlled by applying or removing power.
To facilitate remote/robotic operation, most of the telescope systems are powered through an Ethernet-connected power strip, which allows power to be turned off and on via either HTTP or SNMP Internet control. In addition, three USB web cameras are situated in the dome to allow some degree of external monitoring. Four thermal probes are situated in the dome and are attached to web-accessible controllers.
2.4. Telescope and Camera Control
The telescope pointing system, secondary actuators, dome control, filter wheel, and guider stage locations are controlled by a single x86 computer located in a rack inside the dome. Motor control and position sensing are implemented through several Oregon Micro Systems motor control cards and a separate dome encoder card. The azimuth and altitude axes are controlled by motors, but also have separate encoders; the derotator axis only has motor positioning. All three axes have magnetic home sensors. The filter wheel and guider stages are operated with stepper motors. Dome rotation and slit operation are controlled via relays; the slit has built-in limit switches to kill power when it reaches the fully open and closed positions.
The science camera control is handled by a Linux computer in the main APO computer room; communication with the camera is achieved through a fiber optic connection. The guide camera is controlled by the same computer; since it uses a native USB connector, a fiber-USB converter kit was obtained to allow it to be controlled from the remotely located computer. This interface is also used to control the webcams.
2.5. Performance
The telescope performance is adequate but not outstanding. With a pointing model implemented, we have achieved about 20-arcsecond rms pointing, but in practice, the pointing tends to be worse than this. The pointing performance is affected by imperfections in the drive surfaces, occasionally slippage of the motors, and temperature variations. Tracking is adequate for short exposures, but noticeable degradation is often seen in exposures of more than a few minutes, so guiding is generally required.
The image quality has been disappointing. While we have seen images with 1.2 arcseconds FWHM, typical images are between 1.75 and 2.5 arcseconds. The cause for this has been difficult to track down, but is likely due to a combination of dome seeing, imperfect alignment of the optics and placement of the focal plane, and tracking issues. We hope to understand and improve these issues at some point, but we have mostly concentrated our efforts on science programs for which the current performance is adequate to meet the scientific goals. This has been an important criterion for the choice of scientific programs to be executed; we choose ones that are appropriate for the telescope performance and the robotic mode of operation.
2.6. Maintenance and Support
We generally do not schedule any dedicated maintenance time on the telescope. In practice, we attempt to do visual checks and minor maintenance whenever we happen to be visiting the site for commisioning new capabilities at the telescope, resolving problems, or observing with another telescope. Large maintenance items, such as aluminization of the mirrors, are scheduled in coordination with the APO site staff, and we draw on their considerable expertise for the removal of the primary mirror and the recoating, which has been done at the nearby National Solar Observatory. Due to the time and support required, primary mirror aluminization has only been done a few times, with 5–10 years between aluminizations. Several years ago, we realuminized the secondary and the tertiary and had them overcoated with an Al/Si coating by Optical Surface Technologies to minimize the need for realuminization of these mirrors.
Of course, various hardware and software issues have arisen in the course of long-term operation, from system failures, aging of components, or the development of some previously unseen condition. The location of the telescope at APO greatly facilitates relatively rapid resolution of simple problems. Several site personnel have accumulated significant knowledge about the operation of the telescope systems and can often provide quick solutions to our problems, or at the very least, knowledgeable eyes that can report conditions and issues with the telescope. If significant issues develop, we generally send personnel from NMSU to attempt to resolve them.
Another key support item provided by APO is that they arrange for a regular supply of LN2 to the site. As part of our support agreement, our large LN2 dewar below this telescope is regularly checked, and replaced when needed (roughly every two weeks). The availability of LN2 allows us to operate our science detector without significant dark current.
Locating the telescope at APO also provides greater security for the telescope, as there are personnel on site 24 hours a day, 365 days a year.
Another advantage of the location at a major observatory site is that APO has a backup generator in case of a utility power outage, with automatic switchover occurring within a few seconds. Thus, even if the utility power fails, there is still power to continue the operation, or to close the dome if conditions require it. Within the 1 m dome, we also have systems on a UPS to avoid issues with short power glitches.
We contribute a small share of the total observatory budget to account for the floor space we use, electricity, access to facilities, and general site operations. Between this base contribution and typical cost-reimbursable site assistance, we generally spend about $15 K/year on the telescope. Any costs associated with failed or aging hardware are in addition to this. Still, we feel that this is a very economical way to operate a 1 m telescope.
We note that there are benefits to the observatory. Albeit small, any contribution to the overall budget helps. Scientifically, several coordinated programs have been carried out between the 1 m and the 3.5 m, enhancing the productivity of each. The 1 m also provides a capabilityforphotometric calibration of observations taken with the 3.5 m under nonphotometric conditions.
3. Software
The telescope control software is written in C++ and runs on a DOS platform. It was initially developed by Autoscope but has undergone substantial subsequent modification. The telescope control software handles low-level communication with the hardware. Software was obtained for this computer to allow Ethernet connectivity via TCP/IP, which provides a means to send commands from other computers on the network and to update the software remotely. Software updates can be achieved without any action on site by rebooting the computer via the remote power control; after loading the network drivers, the startup file on the DOS computer transfers a copy of the telescope control program from a disk on a Linux machine via TFTP, and then runs it, so software updates are accomplished simply by copying a file to the Linux command machine. This is very useful for adding minor features to the telescope control software without having to go to the site.
The science and guide cameras, as well as the web cameras, are controlled by a Linux computer using internally developed C software, with device drivers and software libraries provided by the camera manufacturers, or as part of the kernel for the webcams. The camera software receives updates from the telescope, so telescope information is placed in image headers. The computer is also synchronized with an Internet time source, so that the time when the shutter is opened is put in the header with an accuracy of better than a second.
The science camera software includes a temperature monitor that triggers an associated autofill system. When the CCD temperature rises above some preset value, a command is sent to open the cryogenic valve to the large LN2 dewar for a preset amount of time. If this happens while observing is in progress, the telescope is appropriately stopped and restarted, however, the normal mode for robotic operation is to automatically do a fill shortly before sunset, since the hold time of the dewar is sufficient to make it through a full night without refilling.
The set point of the guide camera is automatically modified throughout the night based on an ambient temperature reading, since the thermoelectric coolers can only reach some fixed temperature differential from the ambient. This is not much of an issue for the guide camera, but we note it because it was very useful for our old science camera that was thermoelectrically cooled; this feature allowed us to operate at one of a few preset possible temperatures (depending on the ambient), rather than always running at maximum cooling, which would result in temperature drifts. Thus, we were able to construct libraries of dark frames at the few allowed operating temperatures.
The high-level control of the telescope and instruments and the robotic operation are handled by a Linux computer located in the main APO operations building. In principle, this computer could be located anywhere, but we locate it at APO to keep it behind the site firewall to limit access to the telescope. The basic software is relatively simple: there is a master control program that accepts text commands either from the keyboard or from a pipe on the control computer. The control program relays the command to programs running on the telescope computer or the instrument computer, depending on the command, which execute the command and return a success status. Once status has been returned, the next command is processed.
While no specific telescope/instrument commanding protocol was used for the telescope and camera software, it would be trivial to implement a standard command set if desired.
The robotic operation is enabled by sending commands over a pipe on the command computer. Any scripting software can be used to generate such commands. We have implemented our robotic control using the image processing package XVISTA, which has many built-in astronomical image processing routines, internal variables, and flow control, along with the capability to construct basic command procedures for stringing together multiple tasks.
The entire suite of control programs is run on a virtual desktop on the command computer. This allows checking on the progress of observations from any remote location that has the capability to view remote virtual desktops over the Internet.
4. Robotic Operation
The telescope is operated robotically more than 95% of the time, with the nonrobotic time being used for engineering. The robotic mode requires a person only to implement an observing list with observing priorities, as described below, and to start the system at some point during the day. For safety precautions, we usually attempt to look at the system remotely by webcam during initialization, and again in the morning to insure proper dome closure and stowing of the telescope, but this monitoring is not required by the robotic system.
4.1. Weather Conditions and Enclosure Control
A critical issue for a robotic telescope is weather monitoring and associated protection of the telescope. The location of a telescope at a major observatory site facilitates this enormously. We cooperated with the observatory to install a mechanical sensor on the shutter of the ARC 3.5 m telescope that is located at APO, and the status of this sensor is broadcast over the local network once per minute. The software on the telescope computer continually listens for these broadcasts, and if it receives a “3.5 m dome closed” broadcast, or if it fails to receive a “3.5 m dome open” broadcast (indicating that something in the system/network is broken), then the dome shutter is automatically commanded to close and the telescope is stowed.
This is a simple system that takes advantage of the presence of the 3.5 m observing specialists on site, who have experience in judging weather conditions, without requiring any specific action of them. Of course, this system means that if the 3.5 m closes for any reason other than weather, the 1 m will also close, but this is a relatively rare occurrence and a small price to pay for simple protection of the telescope. For extended shutdowns, we also have the capability to switch over to monitoring the status of the SDSS 2.5 m telescope.
Of course, the potential for failure lies with the dome hardware itself; if the dome fails to close when commanded, there is the potential for exposure to weather. In fact, we have had issues with the failure of the dome slit system, so this can be a real issue. Within the past year, we have rewired the system, and it now works much more reliably (actually, it has not yet failed). At this time, a sensor on the 1 m dome slit has not been installed. While this would probably be a good idea, it is not totally trivial because of the dome rotation and the lack of available slip ring connections. We do ask the observatory staff to do a visual check if possible and notify us if anything unusual is seen, such as an open dome when other domes are closed. If all else fails, it is straightforward for site staff to close the dome manually. We also typically take a quick look at a webcam image each morning which quickly shows whether the dome is closed via the amount of light present. However, we stress that no actions by people are actually required by the robotic system, they are just implemented as basic safety precautions.
To avoid issues if the telescope computer fails or crashes, the hardware is wired with a watchdog circuit so that if the software does not regularly reset it, the dome will automatically close.
Aside from potential damage to the telescope from weather exposure, our biggest fear is a dome slit failure leading to direct sunlight shining on the mirror and associated fire/burning potential. To provide some extra insurance against this possibility, the telescope is routinely parked pointing to the NW, and the dome parked pointing to the N, so that the dome slit is not lined up with the primary mirror and both the dome and the telescope point in a direction where the sun will never be seen.
4.2. Startup
For normal operation, the observing software can be started at any time. The telescope and dome are initialized by moving them to home sensors for which the position has been determined. Although not required, we usually do this task with remote personnel monitoring the web cameras to insure that things are operating normally. The system robotically commands a fill of LN2 camera dewar shortly before sunset to insure that the automatic filling of the dewar, as triggered by the temperature monitor, does not occur in the middle of the night.
After the initializations, the telescope simply waits until sunset and a notification that the 3.5 m telescope is open. At this point, the 1 m dome slit is automatically opened. The dome louvers are also opened and a fan is started to facilitate dome ventilation.
4.3. Instrument Calibration
Once the telescope is opened,the local time is checked and compared to local sunset and twilight. If the dome has been opened sufficiently before twilight, it is automatically pointed to the east, and a series of twilight sky flat-field exposures through all of the filters is initiated. The twilight flats start with the lowest throughput filters and successively proceed to flats in filters with higher transmission. The camera software takes a flat field, analyzes the brightness level, and commands a subsequent exposure with an exposure time that will provide high signal-to-noise data, accounting for a fading of the twilight sky brightness with time. It continues taking these until a requested number of good flats are obtained, after which it proceeds to the next filter. If the sky is too bright for any exposure with s to succeed, it waits a minute and tries again. No exposure longer than 30 s is allowed, and no more than 3 such exposures are allowed, so that the entire twilight is not used up in observations of one filter. The telescope is automatically dithered by 30 arcseconds between exposures to aid in the removal of any stars that might appear.
This system works very well, and if the telescope is opened shortly after sunset, we routinely are able to get three high S/N flat fields in all of our ten filters in a single twilight.
4.4. Telescope Pointing and Focus
Once it is sufficiently dark, the telescope pointing and focus are adjusted. For pointing, a catalog of bright stars is consulted, and the telescope is commanded to one at a reasonable azimuth and altitude. A short image is taken, the brightest object is located, the telescope is offset to center the object, and the telescope position is subsequently adjusted to match the expected position of the star. To aid in automatic data reduction, we like to have the actual pointing match the commanded pointing as closely as possible, so we generally repeat this quick pointing correction before the exposure sequence of every new object we observe during the night, since it takes less than a minute.
Focus is probably the most challenging aspect of our robotic observing. To achieve this, we find an intermediate brightness star (V 11) from the USNO-A2.0 catalog and slew to it. The ambient temperature is checked and an estimated focus is determined from a temperature-focus relation that we have accumulated over time. A coarse focus run is commanded, and the master commanding software reads in the images.
A variety of image quality statistics, including the FWHM of the image, are computed for the stars in the images. After substantial experimentation, the statistic that seems to yield the best focus reliably is to compute the ratio of the peak pixel value to the integrated flux in a synthetic aperture around a star, and to associate the best focus with the image that has the maximum value of this ratio. The FWHM can be misleading because hot spots in significantly out-of-focus images can return small FWHM. The ratio of peak-to-total is also robust against changes in transparency during the focus run.
To insure against fluctuations in seeing, we use a minimum exposure time of several seconds, and thus the motivation for avoiding very bright stars. Once the best image has been found, we repeat the sequence using a finer focus run. If the best focus is found on either end of the focus run, we repeat another focus run shifting the range by half the width of the previous run. This generally leads to a reasonable focus value within a few iterations. While we have experimented with fitting a parabola to the derived FWHM values and determining the focus value of the minimum, we have found that it is more robust to just do a relatively fine focus run and adopt the focus value of the best image, as this avoids issues with the parabolic fit being corrupted by one or more bad images or measurements.
Unfortunately, we have found that substantial focus drift occurs with our telescope, especially within the first several hours of the night as the telescope is cooling to the ambient temperature (our dome often gets quite warm during the day). As a result, we generally redo a focus run before every object, since it is usually accomplished in less than 5 minutes (and often less than 2 minutes); if we are near focus, often only a single fine focus run leads to a new focus setting. For objects that are observed for a long period of time, we have developed an autofocus routine that can be run during exposure sequences; this is described below.
4.5. Observing Program
The basic scripting for robotic operations is simple, yet surprisingly flexible. A list of priority-sorted objects is constructed for a list of priority-sorted programs. When the telescope is ready to observe an object, it simply starts at the top of the list and chooses the first acceptable object. The flexibility comes into play when determining which objects are acceptable. The input files allow constraints on acceptable UT time and date (for time critical observations), airmass range, starting hour angle (to avoid starting objects as they are sinking into the west), and moon phase/distance. If an object meets all of the constraints, the desired observing sequence is performed. The observing sequence is defined by the number of cycles to perform a desired number of exposures of a specified exposure time per filter. An option also allows for a sequence of increasing exposure times per filter if a larger dynamic range is required. A parameter specifies whether an initial pointing adjustment and/or focus run should be done before the observing sequence starts. Another parameter specifies whether guiding is desired.
Once an object has been selected, pointing and focus corrections and guide star acquisition are done if requested. After this setup, the observing sequence is run to completion, the object is marked as having been observed, and the next object to observe is found by starting at the top of the list again. A given object can be reobserved by specifying a maximum number of times to be observed (along with a minimum amount of time between observations), or by a flag requesting continuous observations so long as the observing constraints are met. Generally, most objects fall in the class of either requiring a single observation or requiring perpetual observations, although we occasionally have objects which are observed at some particular cadence, that is, once every several hours.
To keep exposures from extending outside the observability windows, and to provide the maximum likelihood that high priority objects will be observed as soon as they are observable, the general strategy is to try to keep the observing sequences as short as feasible, but allow for objects to be repeated, as this allows the list to be checked frequently. Selecting an object from the list only takes between a few seconds and a minute, so not much time is lost by doing this on a cadence of half an hour or so. If the same object is reselected for observing, the script proceeds straight to the observing sequence, without any pointing check, focus, or guide star reacquisition; guiding is continued while checking the list, and not stopped until the telescope is commanded to slew to a new target.
We have found that this scheme covers a large fraction of desired observations. For some special cases, some additional complexity is required, and we have developed several special modes, for example, for elevating the priority of a series of observing sequences if certain conditions are met. For example, one mode triggers a series of dithered exposures of a target once it becomes observable. Another mode switches the science camera into a subframe readout, which allows for a higher cadence of observations.
As previously noted, if the telescope computer determines that the 3.5 m dome is closed, it automatically closes the dome and stows the telescope, independently of any commanding software. The command software checks the telescope status after every exposure, and if it sees that the telescope has been closed, it immediately exits the observing sequence and restarts the initial loop of waiting for the 3.5 m to report open. If the telescope is subsequently reopened, the observing sequence proceeds as before, starting again at the top of the observing list to check for the highest priority object, since the previously observed object may no longer be available.
4.6. Focus Monitoring
As previously noted, the telescope experiences significant focus changes, especially in the first few hours of the night. While focus can be tracked using focus runs done before each new object, if the desired target is to be followed for a long time, then focus runs will not occur. While it is possible to force focus runs after a desired time interval, some monitoring programs prefer a continuous stream of data without interruptions.
To accommodate this, we developed a method for performing focus tracking without interruption of science observations by using our guide camera. To do so, the guider determines image quality as well as image position for each guider image, which are generally taken every few seconds. To account for seeing variations, a series of measurements is averaged over a period of several minutes; this is an adjustable parameter. After the baseline is established, the internal focus on the guider is moved by a small amount. To avoid any image degradation because of the possibility that a focus change will move the star slightly, the guider focus is only allowed to move between science exposures. Another series of exposures is taken, and if the average image quality is better, then the telescope focus is adjusted by the amount corresponding to the guider focus offset (again, only between exposures), and the latest guide series is adopted as the baseline series. The guider offset is maintained so that if further moves in the same direction are required, they will be made after the next series. If a guider series is worse than the baseline series, then the guider offset is returned to nominal and a new baseline series is made to keep track of potential seeing changes, after which a guider offset is made in the opposite direction. The whole procedure continues, keeping the same sign of guider test offsets as long as image quality is improving, and reversing the sign of the test offsets if a previous test offset made things worse.
The procedure does a reasonable job of tracking focus changes. Of course, a key assumption is that the guider focus tracks the focus in the science camera. This is an issue for an offset guider on an alt-az telescope, because the guider is moving in the focal plane as the telescope tracks in image rotation. Thus, if the rotator change is large over the time span of a long image sequence, incorrect adjustment of focus can occur if the system is not well aligned, that is, if the guide focus changes with the rotator position.
4.7. End of the Night
After each exposure, the time is checked, and if morning twilight has arrived, science exposures are stopped and the telescope is slewed to the west for a morning sequence of flat-field exposures, done in reverse order from the evening sequence. After these have been completed, the telescope and dome are stowed, and the dome slit and louvers are closed.
As previously noted, shutdown is automatically forced immediately at any time during the night when the 3.5 m telescope is not reporting an open condition. Twilight is not an exception, so occasionally the flat fields sequence is interrupted if the 3.5 m closes early, but this is a small price to pay for the overall safety that the system normally insures; we could turn off the 3.5 m slaving during flats, but we prefer to be conservative.
4.8. Photometric Calibration
Certain science programs require absolute photometric calibration, which can be achieved by observations of photometric standard stars, but only on totally clear nights. We have not implemented a method to automatically determine if a night is photometric, but instead we manually set a flag if the weather forecast appears to predict a good chance of a photometric night, and elevate the priority of the photometric programs accordingly.
If the photometric flag is set, then the system automatically intersperses observations of standard stars with the science program observations. This is done by setting a minimum time interval between observations of standard stars for stars at low and high airmass. We have compiled a list of fields, spread around the sky, with photometric standards, choosing fields with multiple standard stars where possible. After opening and performing initial pointing and focus, a specified number of fields are observed at low (1–1.3) airmasses and high (1.55–2) airmasses; we usually observe two fields at each. Science exposures then proceed as normal, but after each science exposure sequence has completed, the script determines whether the minimum amount of time between observations of standards has elapsed. If so, then another set of standards is observed. We generally set things to observe a pair of low airmass fields every hour or so (the minimum is set to one hour, but a science exposure sequence must be completed before the time is checked) and a pair of high airmass fields every two to three hours. With multiple standards per field, this provides a large number of standard star observations per photometric night.
4.9. Targets of Opportunity
We have developed software to allow for relatively quick response to the target of opportunity observations, in particular to respond to gamma-ray burst alerts from the GCN. To accomplish this, we run a separate program on the telescope command computer which listens to GCN alerts via socket communications. If an alert is received, the position is parsed, an ALERT command is send to the command program, a flag is set to indicate that an alert was received, and a line is automatically added to an alert target file with the new object for subsequent high-priority normal observing after the ALERT sequence (discussed next) is completed.
The alert flag is continually checked both between exposures and during the photon collection process, and if the flag gets set during an exposure, the exposure is immediately interrupted and control returned to the command program. At this point, ALERT commands have priority over all others. The ALERT command slews the telescope to the desired location and immediately starts a preprogramed observing sequence. To minimize the slew time, the rotator is not slewed to the default north-up position, so the image orientation will be not standard (but is recorded in the image headers). Our default sequence consists of five sets of short exposures (10, 10, 20, 40, 60 s) through each of IRVBU filters, followed by five sets of exposures twice as long, for a total of about one hour of observing. These exposure times were chosen in an attempt to provide broadband spectral information for relatively bright bursts.
After the ALERT sequence is completed, the telescope returns to its normal mode of operation, but usually we make the file with alert targets the highest priority, so that the preprogramed ALERT sequence is followed by a set of longer exposures as specified in the alert target file. The virtue of shifting to the normal target file is that this does a normal image acquisition, including acquiring a guide star. The ALERT sequence exposures are done without guiding, in an effort to get to the target as quickly as possible. This is not such a big problem for image quality, as the exposures are short, but does lead to image drift throughout the sequence. After an hour has passed, we feel that it is worth taking a few minutes to refocus and acquire a guide star before proceeding with longer exposures.
The main limitation of the response time to alerts is the time required to rotate the dome, which moves at about 4 degrees per second. Thus, very rapid response (less than tens of seconds) is not possible unless the telescope happens to be pointed by chance at a location near the alert position, but response within a minute is feasible.
5. Data Analysis
We have developed automatic data reduction for several types of programs, which enables a quick-look capability useful for determining whether observations have been successful or not. This helps to set up observations for subsequent nights. Many of these routines have been developed in the XVISTA image processing environment. However, we have found that many users prefer to do their own data reduction, so we also make the raw data available.
5.1. Differential Photometry
Our most common type of observing program is monitoring of variable stars. Data analysis for such programs generally consists of doing differential photometry between the variable object and one or more reference stars in the field after basic instrument calibrations are done. The procedure is relatively straightforward because the same field is observed over and over again.
We have implemented automated data reduction for such fields during the morning immediately following the data acquisition using our own custom software. During the robotic observations, log files are created for each program and object that are observed; these files list the sequence numbers of the observations in each filter. After the observing for the night is complete, the data and the log files are automatically transferred to a computer on the NMSU campus. A cron job runs every morning that sees what programs and objects were observed, and starts a data reduction script accordingly. Each of the data files is read in and basic calibration (flat fielding and a shutter shading correction) is done. The coordinates are read from the header and small corrections are determined using routines from the WCSLIB package, or by simply looking in the expected vicinity of a bright star to find where it actually lies; this latter technique is used for fields where there are too few stars to reliably determine the pointing via the WCSLIB routines. For each frame, coordinates of the variable star and other stars in the field are then transformed into pixel positions, centroids are computed around these positions, and aperture photometry is performed. The data files are merged with previous data files for the object, and plots are created for the light curves which are placed on a web page for easy inspection, along with links to the data files. The software can be requested to notify one or more users by email when data for particular programs have been obtained, and the email provides links to the web page with the data plots and files.
Under certain circumstances, for example, coordination of observations with other facilities, we have run cron jobs to transfer data and attempt reductions during the night. If real-time data reduction was to become a priority, it would be straightforward to set things up to do reduction within several minutes of obtaining the data.
5.2. All Sky Photometry
We have also developed scripts for automated reduction of standard star photometry on nights when that is obtained. Again, the log files provide a method for automated software to know whether such data were obtained. If so, then the stars are automatically found and photometered, and photometric solutions, allowing for extinction, transformation, and zeropoint terms are determined for each filter. Plots are constructed showing residuals of the observed from the standard photometry as a function of magnitude, airmass, color, and time, which provide a quick means to determine whether the night was indeed photometric and whether there are any bad observations that are affecting the fit.
6. Scientific Programs
The telescope has been used for a number of different scientific programs. As previously mentioned, many of these involve monitoring of variable stars, which is a classic usage of a robotic telescope. Some examples include:
(i)cataclysmic variables (Szkody et al. [1]; Harrison et al. [2]; Osborne et al. [3]; Mason et al. [4]),(ii)X-ray binaries ( McNamara et al. [5]),(iii)eclipsing binaries ( Stempels et al. [6]; Irwin et al. [7]; Hebb et al. [8]; Hoffman et al. [9]),(iv) Scuti stars (Hoffman et al. [10]),(v)M dwarfs: flare stars and a general sample to measure the flaring rate on typical stars (Hilton et al. [11]),(vi)brown dwarfs (Gelino et al. [12]),(vii)exoplanet transits (Coughlin et al. [13]).Other productive uses have been rapid, multicolor followup of GRB 061126 (Perley et al. [14]), support of HST astrometry via photometric observations of parallax reference stars to help to estimate their distance (Benedict et al. [15]; Bean et al. [16]), monitoring of Saturn’s moons during the opposition of 2005 (Miller et al. [17]), and support of several supernovae discovery and monitoring programs.
By agreement with the National Science Foundation as part of our PREST grant, we make a fraction of time available to the general astronomical community. We have been doing this on an informal basis, choosing programs where there is collaborative interest with NMSU personnel (to allow more time to be spent on the projects) and, most importantly, projects that are well suited to the performance and robotic mode of operation of the telescope. Interested parties are encouraged to look at the information at http://nmsu1m.apo.nmsu.edu/1m/obstime.html.
7. Conclusion
We have described the hardware and software systems of the NMSU 1 m telescope located at the Apache Point Observatory. The telescope has been run almost exclusively in a robotic mode for ten years; the experience gained in this time may be of interest to others who are developing similar systems.
We have found that having a small robotic research telescope located at a major observatory site offers a number of advantages. The availability of site personnel for weather monitoring, which we have implemented for our telescope without requiring any direct action on the part of the site staff, and maintenance and repair is a significant benefit. Another advantage is a relatively low cost of operation for a large number of on-sky hours in a good observing site.
Acknowledgment
We would like to acknowledge the support of the staff of the Apache Point Observatory, whose cooperation and knowledge have made the development and operation of our facility possible. We also want to acknowledge the financial support of the National Science Foundation through their PREST program under Grant AST-0519398.