Pointing Control
for a giant segmented mirror telescope
Patrick Wallace
Rutherford Appleton Laboratory
United Kingdom
GSMT Control Workshop
Tucson, September 11-12, 2001
Presentation Outline

Platforms

Software

GSMT Challenges
GSMT Control Workshop
Tucson, September 11-12, 2001
TCS Platforms

Use mass-market hardware and software: PC,
running Linux/RTL or even Windows. C++, Java,
CORBA. Avoid expensive RTOS, minority-interest
middleware and specialized hardware.

Work mostly on the “Unix side”: use strict real-time
only when necessary; use computers as intelligent
managers, not as mere “programmable hardware”.
GSMT Control Workshop
Tucson, September 11-12, 2001
TCS Design Philosophy

The science requirements, plus observing scenarios,
merely sample the required functionality.

The TCS must deliver those functions as points in a
“functionality envelope”.

The different modes of operation come from
parametric control of a single, integrated, system.

As far as possible, all the code runs all the time.
GSMT Control Workshop
Tucson, September 11-12, 2001
Specifying the Pointing


Not simply where the optical axis is aimed.
The user tells the TCS three things:
» where in the sky to look
» where in the focal plane the image is to fall
» which way up the image is to be

The TCS predicts the mount and rotator angle
demands that will realize the specified image.
GSMT Control Workshop
Tucson, September 11-12, 2001
The Pointing Flow



Starts with target position.
Astronomical transformations lead to
“observed” [Az,El].
Allowing for non-perpendicularities, flexures
and other pointing effects produces the
required mount angles.
GSMT Control Workshop
Tucson, September 11-12, 2001
Pointing “Filters”

Science pointing  current pointing:
» imposes offsetting speed limit

Current pointing  mount pointing:
» apportions motion between mount and M2

Guider  pointing model:
» offloads M2 bias

All filters have adjustable time constants etc.
to achieve a variety of effects.
GSMT Control Workshop
Tucson, September 11-12, 2001
TCS/Mount Interface



TCS sends timestamped mount coordinates
over a LAN at (say) 20 Hz, defining locus.
Mount gets its position/velocity/acceleration
demands by interpolation, using the last two
or three TCS demands.
Same “locus” strategy for rotator, guide
probes, even M2 in principle.
GSMT Control Workshop
Tucson, September 11-12, 2001
“Virtual Telescope”
target direction
pointing origin
celestial transformation
pointing model
position angle
mount coordinates
GSMT Control Workshop
Tucson, September 11-12, 2001
Guiding




Each guider is a separate “virtual telescope”.
Given the guide star [,], the current mount
demands define the [x,y] we want the guide
star image to occupy.
Differential refraction and atmospheric
dispersion are taken care of automatically.
The guider system is more important than the
mount in pinning down the WCS.
GSMT Control Workshop
Tucson, September 11-12, 2001
World Coordinates



Predicting [x,y][,] is the objective.
Using the current pointing state, the TCS
generates the transformation describing the
focal plane in [x,y][,] terms.
Packaged support for transformation to
instrument coordinates and for writing FITS
headers is also required.
GSMT Control Workshop
Tucson, September 11-12, 2001
GSMT Challenges





In terms of pointing, not much is new in fact.
Pointing integrity must extend into AO, including
adaptive M2.
Probably not possible to locate the rotator axis; the
guider probes will define the WCS, so calibration
methods need attention. And/or peripheral CCDs?
Encoders not enough. Need accelerometers and
structural sensors.
10 mas PSF means variable refraction across the
pupil and atmospheric dispersion need attention.
GSMT Control Workshop
Tucson, September 11-12, 2001
The “Servo Engineer” Problem

How do you keep your servo engineer(s) between the
design phase and telescope commissioning?

Alternatively, how can the knowledge be mothballed
during the construction phase?
GSMT Control Workshop
Tucson, September 11-12, 2001