ar
X
iv
:a
str
o-
ph
/0
51
18
42
v1
3
0
N
ov
2
00
5
Astronomical Data Analysis Software and Systems XV P.156
ASP Conference Series, Vol. XXX, 2005
C. Gabriel, C. Arviset, D. Ponz and E. Solano, eds.
Autonomous Observing and Control Systems for
PAIRITEL, a 1.3m Infrared Imaging Telescope
J. S. Bloom1, Dan L. Starr2, Cullen H. Blake3, M. F. Skrutskie4, Emilio
E. Falco3
Abstract.
The Peters Automated Infrared Imaging Telescope (PAIRITEL) is
the first meter-class telescope operating as a fully robotic IR imaging
system. Dedicated in October 2004, PAIRITEL began regular observa-
tions in mid-December 2004 as part of a 1.5 year commissioning period.
The system was designed to respond without human intervention to new
gamma-ray burst transients: this milestone was finally reached on Novem-
ber 9, 2005 but the telescope had a number of semi-automated sub-10
minute responses throughout early commissioning. When not operating
in Target of Opportunity mode, PAIRITEL performs a number of queue
scheduled transient monitoring campaigns. To achieve this level of au-
tomation, we have developed communicating tools to connect the various
sub-systems: an intelligent queue scheduling database, run-time config-
urable observation sequence software, a data reduction pipeline, and a
master state machine which monitors and controls all functions within
and affecting the observatory.
1. Project background and constraints
PAIRITEL, name for the late telescope operator Jim Peters, is an automated
1.3m telescope located at the ridge of Mt. Hopkins in Arizona. The telescope
and simultaneous J ,H,Ks camera were formerly used in the 2MASS project
which ended data taking operations in 2001. Our refurbishing work began in
mid-2003 using a small donation from the Harvard Milton Fund. Basic telescope
automation was achieved by the dedication on October 21st, 2004.
From the outset, PAIRITEL was designed for automated, queue based ob-
serving, with the ability to rapidly respond to targets of opportunity (ToOs)
such as gamma-ray burst (GRB) alerts from space-based satellites. The best
response thus far was 90 seconds from gamma-ray burst trigger (GRB 051109a)
to the beginning of the first observation. Although rapid response telescopes
1University of California, Berkeley, CA, USA
2Gemini North Observatory, HI, USA
3CfA/Harvard, MA, USA
4University of Virginia, VA, USA
1

2 Bloom, Starr, Blake & Falco
User-Weather
good
bad
unknown
Weather
good
bad
unknown
Dome Shutter
Communication
up
down
unknown
Telescope
moving
stable
limit
parked
tracking
unknown
Queue-Observing Sync
up
d
unknown
diskspace
plentiful
low
very low
unknown
dome light
on
off domeshutteropen
closed
opening
closing
unknown
Master
up
down
unknown
Network
local-up__offsite-down
local-down__offsite-down
local-up__offsite-up
unknown
Mirror Cover
open
closed
opening
closing
unknown
Observe
observing
waiting
suspended
halted
unknown
user-system
ok
close
suspend
unknown
Daynight
dawn
day
dusk
night
unknown
Figure 1. Sub-systems, each with their own daemon control, whose
states are monitored by the ‘master daemon’. Shown are some example
sub-systems with corresponding sets of states. Since these states are
enumerated, masterd contends with a finite number of system states.
Matching of state changes and actions taken during state change are
prescribed in a list of rules. The logic for determining the value of the
sub-system states are encoded in the sub-system daemons.
require a significant amount of automation, the remote location of this telescope
required additional levels of autonomy.
We required that the observatory software be able to diagnose inclement
weather and control system problems and respond appropriately, as if an ob-
server were present. PAIRITEL determines the observing schedule using an in-
telligent queuing database which incorporates new observations into a dynamic
scheduling system, while accounting for recently acquired observations. Software
components must also rely upon cross communication. For example, a monitor
of the transmission, acquisition/reduction software, and telescope pointing need
complex interactions to maximize observing efficiency.
2. Master daemon
The key to coordinating our autonomous observatory is a program called the
‘master daemon’ (hereafter masterd). Based on a robotics state machine, mas-
terd monitors the states of all other software processes. Then, using a tem-
plate which defines actions for various state changes, it commands other software
atoms to act.
Separating each observatory task into individual software sub-processes
(‘daemons’) allows them to be managed in a generalized way (Fig. 1). As dae-
mons are initiated and restartable on a system level, we can then assume them
always to be running. If a critical error occurs in a daemon, the master daemon
will notice the timeout of a ‘heartbeat’, and restart it.
The state machine design also allows for self-regulating actions. One exam-
ple is determining the current accuracy of the telescope pointing. By monitoring
a transmission daemon (which determines sky transparency) and possibly the
time of the night, the master daemon can see when a pointing check/correction

PAIRITEL Automated Observing, Control Systems 3
Figure 2. Snapshot of the database interface, a PHP environment
built around the PAIRITEL MySQL database.
is needed. It then commands other daemons to do actions such as: halting an
observation, performing a “soft” pointing check at a known bright star position,
or initiating a hardware-based pointing check by using a custom set of codes de-
signed to interact with opto-interruptors and a tiltometer. In this case, once the
pointing state is ”excellent”, the master daemon will resume the observations.
3. Observation software
The observation software consists of three main parts: the observation database,
the scheduling software, and the observing daemon. Although this software is
controlled by the master daemon on the highest level, the queuing, acquisition,
and time accounting takes place independent of it. The observation database
is MySQL based and generally accessed remotely by astronomers using a PHP
interface. The scheduling software accesses the database using the MySQLdb
Python module. This database is organized as tables hierarchically by: project,
then objects within projects, and observations of objects. Users can set priorities
of objects within their projects; the projects themselves are assigned relative
priorities and total awarded observing time. Bookkeeping for total time observed
per project is performed in a realtime feedback system.
The observation queue scheduler selects which programs and objects are ob-
served during a night (Fig. 1). It calculates the observing plans on a daily basis,
but can also be commanded to recalculate them realtime by an astronomer or
by itself (for instance when a ToO arrives). The resulting queues are optimized
using variables such as airmass, priority, and time since previous observation.
The scheduler also dynamically updates its database by parsing recently ac-
quired FITS files and adding the information to the corresponding programs.
The observing daemon executes observation sequences sent by the scheduling

4 Bloom, Starr, Blake & Falco
Figure 3. Snapshot of the master daemon status web page and views
of the current schedule. See http://status.pairitel.org/
software. It calculates all dithering sequences and using python interfaces, it
controls both the telescope and camera controllers.
The requested observation sequences (and the output metadata from the
camera) are defined in XML files and are automatically queued by the observing
daemon whenever the scheduler sends them. In the case that the observation is
a ToO, the daemon aborts the current exposure, slews the telescope, and begins
exposing. The PAIRITEL reduction pipeline is written in Python using the
pyfits and pyraf modules. The image processing is fairly straight forward, using
realtime created darks and archived twilight flats. In addition, bad pixels are
fixed and the world coordinate WCS is calculated in the final mosaiced image.
The ‘status’ web page (Fig. 3) displays an overview of all states monitored by
the master daemon. The color coded boxes allow a quick assessment of the
system. Additionally, clicking on any state gives a detailed history log of that
state. Real-time quick-look reductions are also available with a click.
4. Summary
Automating the PAIRITEL telescope has been surprisingly fast due to quick
software implementation. We attribute much of this to our choice of Python as
our development language. Python has allowed easy coding of software hooks
into electronic devices using serial, network, and parallel port modules. The
high level aspects of the language also helped us design algorithms which are
template based and thus easily configured and updateable. The overall ease in
producing working code has allowed us to experiment with different approaches
in solving problems. For these reasons, we were able to rapidly develop and test
the master deamon and observation software.
For more information, visit: http://www.pairitel.org/.