Plan2010

Plans for the automation of the FLWO 1.2m telescope

Emilio E. Falco, FLWO

16 August 2010

1. Introduction

Currently, observers use the Keplercam CCD camera on the FLWO 1.2m telescope in “classic mode,” on-site or remotely from CfA in Cambridge. Components of the telescope system such as the dome slit, mirror covers and ﬂat lamps, are activated by a person on-site, either the 1.2m observer or the 1.5m observer nearby.

Over the past two years, we formed a plan to improve signiﬁcantly the e ciency of observations and the quality and reliability of the 1.2m data. As I will describe in more detail in an upcoming FLWO Newsletter, we are also in the process of having a new primary made for the 1.2m. The Steward Observatory Mirror Lab will cast and polish the mirror; we expect it to be ready by August 2011. The combination of an e cient, reliable automatic system with high-quality optics will be an attractive combination for many projects, includ- ing exoplanet transits, supernovae, GRB afterglows, and follow-up of transients from large surveys such as Pan-STARRS and the MWA.

To achieve our goals, we planned to develop software for autonomous operation of the telescope. The software will have full control of the telescope system and will obtain scheduled observations using a database of objects of interest to projects allocated time by the TAC. We foresee the TAC will see little di erence compared to current operations. It will also be possible to revert to classic mode if needed for particular projects.

In the following sections I describe the current mode of operations, our goals for auto- mated control of the 1.2m system, and the two phases of the software development in our current plans.

2.Classic Mode

2.1.Observing Sequences

The following are the steps necessary to obtain observations with Keplercam.

–2 –

1.Proposers submit proposals, either for scheduled time or in queue mode. The TAC ranks the proposals and allocates time in 4-month periods. Based on the allocations, I compose a schedule.

2.Successful proposers may submit a catalog of targets in a standard format. For TOOs or for queued observations, proposers may add targets to existing catalogs as needed, or they may create ﬁles with lists of commands to control the telescope system (these are the scripts that I describe below).

3.Observers obtain dome ﬂats in the afternoon, a few hours before dark. The sequence is: disconnect the LN2 dewar from Keplercam, enable the telescope drives, reference the telescope if needed, open the mirror covers, point the telescope at the ﬂats screen, turn on the ﬂat lamps, run a script (which may take about 30 minutes to execute), turn o the ﬂat lamps, stow the telescope, close the mirror covers, disable the drives, reconnect the LN2 dewar and ﬁll the Keplercam dewar. Observers on-site operate the drives, mirror covers, ﬂat lamps and LN2 dewar; the 1.5m observer operates the hardware for remote observers. Remote observers use the same GUI and scripts as observers on-site, using VNCviewer from their computer.

4.Observers start observations after sunset. The sequence is: disconnect the LN2 dewar from Keplercam, enable the telescope drives, open the dome slit, open the mirror covers, enable telescope and dome tracking, run scripts to measure and set optimal focus, obtain sky ﬂats if desired, check pointing using a bright star catalog and observe science targets per the schedule. Exposures longer than 300 sec require autoguiding, which is enabled with a GUI or from scripts. At the end of the night, the sequence is: stow the telescope, close the mirror covers, disable the drives, reconnect the LN2 dewar and ﬁll the Keplercam dewar.

5.The data from each night are stored in a directory with the date as a name. After the end of each night, the contents of the night’s directory are transferred to the TDC archive in Cambridge. Projects such as supernovae and planetary transits run their own pipelines for reduction of the data. Otherwise, observers reduce their data on their own, generally with IRAF, which has well-established reduction procedures.

2.2.Hardware Components

The autoguider uses a picko mirror that views just outside the edges of the CCD ﬁeld. The guiding ﬁeld is divided into segments in a horseshoe pattern surrounding this ﬁeld. The guider focus is set for each location in the horseshoe, as a function of telescope focus. When

– 3 –

a star is located in a given segment, the system maintains a ﬁxed position for the center of brightness of the star. We use a script to locate HST Guide Star Catalog stars in the segments. The script starts guiding once a star is found.

The ﬁlter wheel has 8 slots; we have a complement of Sloan griz, Harris BVRI and several narrow-band ﬁlters (see the Keplercam web page). Filters cannot be changed during the night, unless a qualiﬁed observer is present. The list of mounted ﬁlters is in a ﬁle always available on the system.

The system includes a Vaisala weather station that monitors RH, barometric pressure, wind speed and precipitation. The unit updates its output continuously and displays is mea- surements on the FLWO web site. Its output is used by PAIRITEL to monitor weather con- ditions. We also monitor, display and record mirror and ambient temperatures. We control the mirror temperature using a glycol-circulating system. Observers use these measurements to decide whether to observe (the requirements are humidity under 90%, no precipitation, wind under 40mph). If conditions are acceptable, observers may decide what to observe based on conditions such as how far is the moon and in what phase, how bright is the sky, and what is the cloud cover.

The MMT skycam and the MEarth cloud monitor provide additional weather informa- tion. Because the mountain weather may turn inclement very rapidly, observers must be prepared to stop observing and shutdown the telescope quickly, on short notice. For remote observations, the 1.5m observer is the ultimate arbiter for shutdown if deemed necessary. This is essential for the safety of the equipment.

2.3. Software Components

Telescope system commands that may be included in scripts are sent to the system via Telshell, which is an enhanced version of the tcsh Unix shell. The available commands enable or disable telescope and dome tracking, select centering on one of 4 ampliﬁers or at the center of the CCD, slew the telescope to target coordinates given as parameters, select a ﬁlter, give a name to the next exposure, and command the CCD to acquire an exposure for a length of time given as a parameter. Observing with scripts that use these commands is preferred as they minimize errors and operate the system most e ciently.

Scripts are available to obtain sets of biases and ﬂats using standard sets of ﬁlters. Scripts are also available to obtain sequences of exposures of targets such as various tran- sients. These are routinely modiﬁed with the coordinates of new targets, as needed. A script is also available to acquire sky ﬂats.

– 4 –

A script is available to measure stellar FWHMs at a range of focus values and to deter- mine and set the optimal focus. A companion script monitors mirror temperatures and sets the focus using a measure curve of focus versus temperature.

3. Automated Mode

It is conceivable to operate the telescope system components of the previous section in an automated fashion. All we need is software to decide which observations to acquire and to command the telescope to follow suit. Of course, a few details need to be addressed to get to that point.

We received FY10 funding from the SI Scholarly Studies Program (PI Falco, Co-Is Fabricant, Soderberg and Greenhill) for the automation of the telescope system. Next, I describe a feasible avenue that we intend to pursue.

Petr Kubanek (Institute of Physics, Prague, Czech Republic, currently completing his PhD studies at U. of Valencia, Spain) has developed a software package called RTS2 for robotic control of telescopes that is in use at several telescopes (see rts2.org). Josh Bloom (now at Berkeley) was the PI of the conversion of the 2MASS telescope at FLWO to the robotic PAIRITEL. Josh recommended Petr to us based on his experience with PAIRITEL and with his more recent collaboration with Petr on the RATIR camera project for a 1.5m telescope in San Pedro Martir, Baja California. We decided to investigate the possibility of adapting RTS2 for our project.

Petr visited FLWO on June 22-24 to familiarize himself with the 1.2m telescope system. He then visited CfA on July 20 and 21. Dan Fabricant, Edo Berger and I met with him on the 20th, and I introduced him to a number of astronomers who are or have been regular users of the 1.2m. On July 21, Petr gave a presentation at OIR that was well attended in spite of the very short notice of the announcement. So far, everyone has been very receptive. We are now planning to have Petr work on the automation. The following is a description of the project. We are interested in and will attempt to take into account, any and all comments that potential users may have. Project documents and updates may be found in www.sao.arizona.edu/FLWO/48/robot.html.

Petr will adapt RTS2 to our 1.2m telescope system. He will work in close collaboration with FLWO sta members Ted Groner (software) and Wayne Peters (electronics and hard- ware) under my supervision. We divided the project into two phases, ﬁrst to automate the scheduling of observations without control of hardware such as the dome slit, and second to add control of this hardware. The ﬁnal result will be a fully automatic telescope system.

– 5 –

I will refer to a version of RTS2 that will be adapted to the 1.2m telescope system as RTS2-F.

3.1. Phase 1

In this phase, RTS2-F is integrated with the existing telescope and control software.

3.2. Database

RTS2-F will schedule observations and generate scripts to control the telescope system. The target list will be a database similar to current catalogs, but expanded with entries to indicate exposure, ﬁlter and repetitions, priority, and airmass, seeing, moon proximity and weather limits. Other requirements may be added to the database as they emerge with experience. We envision an observing queue that is interruptible for TOOs that require immediate attention. However, a sequence of observations may stipulate that it cannot be interruped at all.

Observers will submit a catalog in the new database format, once the TAC allocations are available. RTS2-F will optimize the schedule for each night, according to the priorities and requirements in the database. The current method in RTS2 utilizes a merit function, which is e ective on a nightly basis. However, it may be possible to apply a genetic algorithm that Petr will investigate. RTS2-F will record a log of observations, with access through a web interface, and use the logs to decide whether targets need to be re-observed.

3.2.1. Scripts

RTS2-F will generate scripts, or ﬁles with lists of commands and parameters to control the telescope system to run in the existing Telshell. Observers currently use these scripts to obtain their observations, as well as biases and ﬂats. The available commands also reference and point the telescope, select ampliﬁer centering, select ﬁlters and direct the CCD to obtain exposures as required. Additional commands are now available to control the hardware components of Phase 2. RTS2-F will be installed and tested on the existing, Linux-based control computer ﬂwo48.

The ﬁlter wheel has 8 slots and we have a complement of Sloan griz, Harris BVRI and several narrow-band ﬁlters (see the Keplercam web page). Filters cannot be changed during

– 6 –

the night, unless a qualiﬁed observer is present. The list of mounted ﬁlters is in a ﬁle always available on the system. RTS2-F will be able to decide which requested observations are feasible based on that list.

RTS2-F will also produce scripts to acquire a standard set of CCD biases and dome ﬂats, as well as other calibrations such as sky ﬂats and photometric standards, as needed.

RTS2-F will start a typical set of observations with a script to set the dome and telescope to tracking. RTS2-F may ﬁrst obtain sky ﬂats in a fashion similar to that for science targets, as I describe next. RTS2-F will use database information to select a target, ﬁlter, exposure time and number of repetitions. It will slew the telescope to the target coordinates and initiate exposures once the slew is completed. It will repeat the sequence for the targets in the queue for each night. At the end of each night, RTS2-F may acquire sky ﬂats if needed, and ﬁnally stow the telescope. In Phase 2, it will take additional steps at the beginning and end of each night, to open and close mirror covers and the dome slit, as I describe below.

3.2.2. Timescale

Petr is visiting FLWO to install and conduct initial tests of RTS2-F mainly without sky for one week starting August 16, 2010. The estimated timescale for completion of Phase 1 is by the end of August 2010, with additional testing on the sky overlapping with Phase 2 activities starting in September 2010.

Once RTS2-F successfully passes all our Phase 1 tests, it will progressively be expanded with the capabilities of Phase 2, as follows.

3.3. Phase 2

In this phase, RTS2-F is modiﬁed to interface with existing controls of telescope hard- ware components and with components to monitor and record telescope, ambient and sky conditions.

3.3.1. Hardware

The telescope hardware that we plan to control includes: the mirror covers, ﬂat lamps, dome slit and guider. The conditions we monitor with existing hardware include: the primary mirror and ambient temperatures, sky brightness and weather (humidity, wind, precipita-

– 7 –

tion).

We plan to leave the telescope drives enabled at all times. That will eliminate the possibility of uncontrolled starts by the automated system, and will allow for referencing the telescope periodically without the need for an operator to enable the drives.

Currently, all the hardware to control the dome slit and the mirror covers is assembled. Installation and testing of new dome components, including wiring and hydraulic lines for the dome slit, is planned for the upcoming shutdown.

Although RTS2-F will not control LN2 ﬁlls, the hardware side of the project includes an autoﬁll system for the Keplercam Dewar. We plan to emulate the successful system in operation at the PAIRITEL, redesigned with new electronics.

3.3.2. Controls

RTS2-F will interface with existing Telshell commands to control all telescope hardware. It will reﬁne the observing queue based on current conditions and using the requirements in the database.

RTS2-F will command the dome slit and mirror covers to open/close at the beginning and end of observations each night. It will ascertain whether weather conditions are ac- ceptable for observing. When they are not, RTS2-F immediately will stow the telescope and close the mirror covers and dome slit. RTS2-F will be able to obtain a standard set of calibrations, and to enable quick-look reductions and visualization of data.

Typical operations will include:

1.RTS2-F will periodically run a script to reference the telescope, except during obser- vations. It will obtain a standard set of ﬂats and biases during each afternoon, e.g., a ﬁxed number of bin by 2 biases and dome ﬂat exposures using all mounted ﬁlters with known exposure times. It will open the mirror covers, point the telescope at the dome screen, turn on the ﬂat lamps, take exposures, turn o the ﬂat lamps, stow the telescope, and ﬁnally close the mirror covers.

2.RTS2-F will start observations at the beginning of each night with a script to open the dome slit, open the mirror covers, and will proceed to scheduled targets as described for Phase 1.

3.If requested, RTS2-F will acquire sky ﬂats either at the beginning or at the end of each night, depending on sky conditions.

–8 –

4.RTS2-F will obtain focus exposures at the beginning of each night, and adjust focus as a function of mirror temperature throughout each night using existing scripts as described above.

5.The backup safety mode is for the 1.5m observer to have the ability to shutdown observing and the telescope through an RTS2-F command.

6.RTS2-F will monitor and record conditions such as Vaisala measurements, mirror and ambient temperatures in the logs. It will be able to modify the observing queue as a function of these measurements.

7.RTS2-F will include access to a quick-look reduction facility similar to that available for FAST and TRES on the 1.5m telescope. This capability is useful to observations requiring immediate follow-up, such as GRBs or young SNe. The observer will need to monitor the data acquisition and trigger quick-look reductions using extant calibra- tions.

8.RTS2-F will be able to use an existing script to autoguide, and to stop guiding once all exposures are completed for a given target.

3.3.3.Timescale

Petr will work remotely but in close collaboration with FLWO sta during the period September-November 2010, with 2 one-week visits to FLWO for testing and additional inter- action with sta . Engineering nights are reserved in the schedule for testing of the system during Phase 2.

For a period of one year following the end of Phase 2, Petr will provide remote support of RTS2-F. We will require appropriate documentation for RTS2-F, to allow for maintenance of the software by FLWO sta .

3.4. Associated activities

RTS2-F will not be involved in the processing of Keplercam data, but given the gains in e ciency that we foresee, we also plan to add standard processing capabilities to the 1.2m system.

We plan to add a pipeline for processing of the data automatically. Processing will take place in Cambridge, once each night’s data are in the archive. Because we weill continue