The ARC Telescope Control System: Coordinate Conversions
(unfinished)
Russell Owen
Introduction
The Astrophysical Research Consortium (ARC) Telescope Control System presently controls a 3.5m telescope located at Apache Point Observatory in the Sacramento Mountains of New Mexico. It is also planned to control several other telescopes including the Sloan Digital Sky Survey 2.5m telescope. The 3.5m telescope is designed to point to 1" from anywhere on the sky and track without guiding to within 0.1" over a 10 minute interval. The control system is designed to do significantly better than this.
User Input
To track an object, the user specifies the object's position and also the desired orientation and position of the object on the instrument. The control system converts these to the position of the telescope and instrument rotator. Positions may be specified in several different coordinate systems, including FK4 (IAU pre-1985 RA/Dec), FK5 (IAU post-1985 RA/Dec) and apparent geocentric coordinates. This information is converted to telescope position as shown in figure 1. The steps are described in detail below.
Figure 1: Sequence of coordinate conversions.
Observed Coordinates
We use the term "observed coordinates" to mean apparent topocentric coordinates corrected for atmospheric refraction, in other words, the position of the object with respect to the observatory.
Conversion from the user's specified coordinate system to observed coordinates proceeds in two steps: first the position is converted to the mean system FK5 at epoch J2000, then it is converted to observed coordinates. Converting first to an intermediate coordinate system is less efficient, but it greatly simplifies the software, especially because the control system supports conversion between any two coordinate systems. This is one example of our design philosophy, which favors software simplicity over efficiency. Computer power is much less expensive than software development and mainentance.
The procedure for transforming a mean position to observed coordinates is well documented elsewhere (1 2 3 4), and several software packages are available which do most of the work. We use SLALIB (5), written by Patrick Wallace of Rutherford Appleton Laboratory to perform the computations, and APPLE (now called what? written by who? reference?), available from the U.S. Naval Observatory, to test the transformations.
For maximum accuracy in the conversion from FK5 to observed coordinates we use U.S. Naval Observatory's predictions for the orientation of the Earth to compute sidereal time and apparent longitude and latitude. We obtain these predictions via electronic mail; they are also available via modem.
Orientation of the Object
The field of an azimuth/altitude telescopes rotates with time, so for imaging one should use an instrument rotator. To support a rotator it is necessary to transform not only the object's position but also its orientation.
To transform the orientation of the object, we convert both the position of the object and of a point offset slightly from the object. The difference in angle between the initial offset and converted offset vectors gives the difference in orientation between the initial and final coordinate systems. In the transformation from RA/Dec to observed coordinates, the angle from initial to final vector = Obj Az - Obj RA, using the terminology described in Coordinate Frames.
The change in magnitude of the offset may also be of interest. It shows the effect of scale changes, e.g. due to refraction. This is needed for high accuracy drift scanning (unless the telescope is kept fixed). Note that in this mode the initial offset must be oriented along the line of the drift scan. When not drift scanning, the user can ignore the change in magnitude of the offset vector, and hence may ignore the initial orientation of the vector.
Physical Coordinates
The next conversion accounts for the desired position of the object on the instrument. The result is the "physical" position of the telescope and instrument rotatorthe correct positions assuming ideal hardware (i.e. perfectly aligned and perfectly stiff).
The desired position of the object on the instrument is specified in a coordinate frame fixed with respect to the instrument. This allows one to position the object at a particular point on the instrument, e.g. a particular pixel or a point along a slit, without the need to know the orientation of the instrument.
We actually interpret this position as an arc of a great circle whose origin is the center of the instrument and whose length is sqrt(x^2 + y^2). In other words, we make the approximation that the instrument has spherical curvature. This is a slight approximation, but the difference is only significant for large fields of view, where the shape and distortion of the focal plane are complex in any case.
Doing the math this way permits the telescope to be operated near the pole with no adverse effects. It also supports drift scanning, at least in a limited fashion. We permit specifying a non-zero velocity for the location of the object on the instrument, and this causes the telescope to move along a great circle at a constant rate. This simple form of drift scanning does not take into account scale changes, e.g. due to refraction.
We will be working in the following coordinate frames (see figure 2):
- Mechanical: the mechanical frame describes the structure which supports the instrument rotator. We have chosen the origin to be at the center of the instrument rotator, for convenience. One may choose any direction for the x axis.
- Rotator: the rotator frame describes the rotating part of the instrument rotator. The origin of the frame must be the center of the instrument rotator. The x axis is arbitrary. The physical angle of the instrument rotator is defined as the angle Rot x - Mech x (which I call Rot_Mech_ang).
- Instrument: the origin and x axis are arbitrary For a CCD camera, the origin of the instrument frame will typically be the center of the CCD, and the x axis will be along the rows or columns.
- Object: the origin of the object frame is the position of the object on the instrument (in the instrument frame). The user selects this position. For convenience, we define the x axis of this frame to have the same direction as the instrument x axis.
In addition, there are two other important orientations:
- Object RA: the direction of increasing RA at the origin of the object frame (i.e. at the object itself). Obj RA - Obj x is an angle the user specifies.
- Object Azimuth: the direction of increasing azimuth at the origin of the object frame (i.e. at the object itself). Obj Az - Obj x is the result of applying the conversion from mean to refracted apparent topocentric coordinates to Obj RA - Obj x.
- Rotator Azimuth: the direction of increasing azimuth at the origin of the rotator frame (i.e. at the center of the rotator). This angle will be computed as an intermediate result.
Object Azimuth and Rotator Azimuth will usually be nearly equal, but near the zenith they can differ greatly.
Figure 2: Frames of Reference in the Focal Plane
Computation
We know the following:
- The az/alt of the object
- The angle ObjAz_Obj_ang = Obj Az - Obj x. This is obtained by the transformation of ObjRA_Obj_ang (user-supplied) to refracted apparent topocentric coordinates.
- The desired position of the object on the instrument is specified by the user. This vector is called Obj_Inst_xy.
- RotAz_Mech_ang = Rot Az - Mech x. This angle is depends on where the instrument is mounted; at the Cassegraine focus, it is a fixed angle. For Nasmyth foci, it varies with altitude (and the sign of this variation is different for the two Nasmyth foci).
- The instrument is fixed on the instrument rotator. We describe it's position using two fixed quantities:
- the vector Rot_Inst_xy, the position of the instrument rotator center in the instrument frame
- the angle Rot_Inst_ang = Rot x - Inst x.
We wish to compute:
- The az/alt at the center of the rotator; this is the physical position of the azimuth and altitude axes.
- The angle Rot_Mech_ang = Rot x - Mech x; this is the physical rotator angle.
The geometry forms the spherical triangle shown in figure 3. Arc_length (the length of vector Obj_Rot_xy) and Obj_incl_ang may both be computed trivially. One may then use spherical trigonometry to obtain Rot_incl_ang, Rot_ZD and dAz from ObjZD, arc_length and Obj_incl_ang. Simple addition then yields the desired quantities: rotator az/alt (physical az/alt), and Rot_Mech_ang (physical rotator angle).
Figure 3: Spherical Triangle on Focal Plane
Mount Coordinates
So far, we have computed the physical position of the telescope (rotator az/alt) and the instrument rotator (Rot_Mech_ang). These are the desired location of an idealized telescope with perfectly stiff, perfectly aligned hardware. The final conversion required is to "mount" coordinates, which are the actual positions of the real, non-ideal hardware.
To convert telescope position from physical to mount, one applies a "telescope model". A telescope model corrects for repeatable imperfections in the hardware, and is usually based on a combination of computed predictions and measurement of pointing error. We generate telescope models using TPOINT (6), a very flexible analysis package written by Patrick Wallace of the Rutherford Appleton Laboratory. We also apply the models within the control system by calling TPOINT subroutines; as a consequence, any model we can generate in TPOINT we can use to control the telescope and there is no danger of mis-coding the model.
Rotator hardware is typically sufficiently accurate that the physical imperfections can be ignored. However, we do allow a constant offset and sign change in converting from physical to mount rotator angle.
Guiding
Guiding begins by finding a suitable guide star and tracking it with the guide camera.<
p>
To track a guide star, one must convert the guide star position to the position of the guide camera axes, and to the predicted position of the guide star on the guide camera. First the guide star position is converted from mean coordinates to FK5 J2000 coordinates, then to observed coordinates. We allow different wavelengths for the refraction correction of the guide star and object. The position is then converted to a position of the guide camera, and a predicted position of the guide star on the guide camera. The math is similar to that used for converting object positions to telescope and rotator physical positions, but is messier because we support guide cameras with x-y mount, r-theta mount, and for which either or both axes may be fixed. Conversion of the guide camera position from physical to mount coordinates is presently done simply by applying a scale and offset to each axis of the guide camera, but if the guide camera or instrument hardware is sufficiently floppy, we may have to add a guide camera model.
Once the guide star is being tracked, one may begin guiding. When the first guide frame is taken, the guide star will never be exactly where predicted. Usually the user wishes the telescope to remain where it is, so the initial error is treated as a fixed offset. Occasionally the user will wish to move the telescope to correct the guide star position error; this mode is especially useful for accurately re-acquiring a field. The control system supports both modes.
Subtleties: correct guide star mean error or error on the camera?
General Offsets
The control system only has two kinds of offset: the position of the object on the sky ("object") and the position of the object on the instrument (the "boresight"). The former is simply added directly to the user's specified position, and the latter has been discussed at length above. However, more flexibility is needed to support users, especially for a remotely-controlled system.
In a remote controlled system, handpaddle control is usually not a viable option, due to the slowness of data transfer. The main form of offsetting must be graphical, though handpaddle control can also be useful, especially for on-site personnel. The control system has a very general offset command which support graphical offsetters, turning the user's input into the two kinds of offset described above. This is described in detail in (7).
Acknowledgements
I am grateful to Patrick Wallace for his software and assistance. The control system uses two packages written by him and distributed by Starlink: SLALIB and TPOINT (both described above). Starlink is funded by UK SERC. SLALIB and TPOINT are available from:
Starlink Project
Rutherford Appleton Laboratory
Chilton, Didcot, Oxon OX11 0QX, UK
References
1. The Astronomical Almanac, U.S. Government Printing Office
2. R. Greene, Spherical Astronomy, Cambridge
3. L. Taff, Computational Spherical Astronomy, John Wiley
4. P. Wallace, Proposals for Keck Telescope Pointing Algorithms
5. P. Wallace, SLALIB-A Library Of Subprograms, Starlink User Note 67.7, Rutherford Appleton Laboratory
6. P. Wallace, TPOINT-Telescope Pointing Analysis System, Starlink User Note 100.5, Rutherford Appleton Laboratory
7. R. Owen, R. Loewenstein Offsetting a Telescope by Remote Control , preprint