5. Guider System and Object Acquisition Software

5.A The Guider System

5.0 Overview

The guider system, or simply "guider", consists of the guide camera(s) and related electronics, optics and software. For purposes of discussion here, we will refer to the optical system bringing light onto the detector as the "TV optics"; the detector and related controlling electronics as the "guide camera"; and the software and electronics for maintaining a position on the sky as the "autoguider". The guide camera, autoguider and the image display and analysis tools will be referred to collectively as the "TV image subsystem". The TV optics include elements such as filters, diaphragms, reticles and focusing mechanisms, and is considered part of an individual science instrument such as DEIMOS. The guider has two major and alternating functions:

target acquisition; and
holding a fixed position on the sky ("guiding").

In addition, the guider may be used for some other valuable (but sometimes non-traditional) functions, including:

evaluating and monitoring observing conditions (eg, seeing, transparency);
approximate aperture photometry;
calibrating the telescope pointing and focus; and
at Keck, checking alignment of optics (eg, stacking of segments).

The guider software consists of these elements:

Control of the guide camera(s);
Image display for the guide camera images;
Analysis of the guide camera images for acquisition (image display);
Command of offsets to the Drive & Control System (DCS) for acquisition;
Analysis of subimages for guiding (autoguider);
Command of corrective offsets to the DCS (autoguider);
Monitoring of sky and telescope conditions (eg, seeing; focus); and
Miscellaneous analysis functions (eg stellar photometry) available via the image display.

Control of the TV optics, as part of a science instrument, falls under "instrument control," although the status of such elements must be available to the guider.

5.1 The DEIMOS Guider Requirements

Guider requirements for slit-mask guiding are more stringent than for normal direct-imaging or long-slit observing, as both the x-y coordinates and the PA need to be held to a high precision. Furthermore, the mask alignment process requires more small-scale offsets (in three axes) than is typically required for single-slit spectroscopic observations. For these reasons, it is important that the observer have access to an easy-to-use control of the guider. As part of that access, we recommend a guider console that should be located between the Observing Assistant and the DEIMOS observer(s). More on the rational for a separate console can be found in Section 5.10.

For the remainder of this section, we will assume a single guide camera, of size 1K x 1K (or 1K x 0.5K) pixels and field-of-view about 3 arcmin across. (Note that a second DEIMOS guide camera may be constructed in the future; such a camera would enable tracking of image rotation.) The camera will look at either an offset field or at the slitmask (semi-polished) or polished long-slit jaws, as chosen by the observer. We assume a reticle (parfocal with the slitmask) in the offset position, and reference marks on the slitmask itself; these enable us to focus the camera independently of telescope focus, and to track guide-camera flexure. We will not discuss the design or requirements of the CCD control (guide camera), nor the TV optics.

We have the capability of using this guider as a science instrument, and we choose to use it to provide supplemental information for the actual science observations. Such functions include monitoring

FWHM (that is, seeing and focus changes);
counts (that is, transparency);
sky background (very useful for beginning and end of nights);
autoguider offsets (history of motions as diagnostic).

In addition, we propose the option of coadding guider images during each science integration - this summed image would be attached to the science image file, and would provide a record of the average conditions during the exposure. In a slit-viewing mode, this would also provide an unambiguous location of the slit across targets of interest. Depending on the ability to calibrate the guider throughput (particularly off the slitmask), it may be possible to derive photometric calibrations from these images as well.

Finally, since the DEIMOS TV optics will have some sort of reference objects at the telescope focal surface (ie a reticle in offset mode; the slitmask itself in slit-viewing mode), we will be able to focus the guide camera on the telescope focal plane. Once the camera is focused, we have a means of focusing the telescope. The guider should take advantage of this opportunity for real-time focus of the telescope - perhaps even during a pause in a long science integration.

5.2 Figures

Fig. 5.1 - Possible Guider Image Display

Fig. 5.2 - Possible Guider GUI

Fig. 5.3 - Proposed Control Room Layout

5.3 Nomenclature

See terms for the guider components in Overview above. in image display (Chapter 8). With regards to the guider image display, transfer function refers to the mapping of intensity data into the [effective] video memory of the display, while look-up table (LUT) refers to how the video memory gets mapped into colors and intensities on the screen. More details may be found in image display (Chapter 8).

Acronyms used in the chapter: DCS is the Drive and Control System; LRIS is the Low Resolution Imaging Spectrograph; OA is Observing Assistant.

5.4 Software Functional Requirements

5.4.1 Guide Camera Control

The user needs control of the following from the guider control interface:

binning
gain
read-out modes (eg subrasters)
integration time / frame rates

5.4.2 Guider Image Display

The image display is used for several purposes, including target identification and positioning, selecting a guide star and analyzing conditions. While it may or may not be the same image display tool that is used for display of full DEIMOS images, it is essential that the implementation of simple display functions (zoom, pan, LUT control) and analysis functions (eg distance measurement, coordinate system overlay, stellar image analysis) appear identical between the two. The necessary features for the guider image display are:

Full image display;
Zoom and pan capability;
Lookup table (LUT) and colormap control;
A "ruler" to measure distances (in various coordinate systems) on the display;
Compass rose to indicate orientation of N and E;
Optional coordinate grid overlay on image;
Optional overlay of catalog object positions on image;
Stellar image statistics, including FWHM and approximate magnitudes;

It is necessary to have a default mode in which the transfer function limits (ie min, max) should be automatically selected to provide useful threshold and contrast for most applications. However, the user should also have the ability to adjust these limits (or reset them to default values).

We also propose that the most recent guide camera images (say up to 8) can be stored in memory so that they may be optionally averaged as a "leaky" memory. The images automatically displayed would then be either the most recent (ie "real-time") image or an average of the last two (or four or eight).

5.4.3 Object Acquisition (Offset Control)

Graphic "handpaddle" control (buttons for left, right, up, down, CW, CCW; two speeds);
Offsets by numerical value (eg, 8 arcsec N, 2.3 arcsec E). If the autoguider is on, the target position will be graphically indicated by a circle or box so that it is trivial to visually confirm that the expected offset was achieved;
Point-and-drag offsets: by this, we mean that a reference object is selected by mouse click, then the position where the observer wants it is selected, with the offset vector "dragged" out by the mouse. The target position is marked as above;
Identification of target object, for which the needed offsets to a nominal position - eg, the center of the longslit - are automatically derived (target position marked as above);
Optional centroiding during selection of reference object (target ID, "point-and-drag" above);
"Memory" of selected locations (eg, for alternating between two positions on the sky);
Graphical position marker(s) - eg circles or crosses to mark positions of interest to the user.
Simple Autoguider ON/OFF switch;
All offsets for which the autoguider must be interrupted will perform the interruption/resume automatically. This primarily concerns rotations, in which case the autoguider should stop guiding, then calculate the offset introduced by the rotation about the instrument center, reposition, and then resume autoguiding.

In order to keep offset methods consistent and to have a reasonable degree of user verification, we propose the following rules for offsets:

Clicking on (and/or holding) the "handpaddle" buttons will instantly apply offsets;
Offsets entered by numerical value (or point-and-drag - see below) will require an "apply" button to be pushed;
For this latter kind of offset, there will be three associated switches: "clear," "apply," and "reverse" (undo);
Offsets by numerical value will be specified by the three fields delta-Dec, delta-RA and delta-PA. However, a blank field implies an offset of 0. Thus, clicking on "clear" will clear all fields and values may be entered into one, two or three fields as desired.
The mask alignment program and the "point-and-drag" option will both talk to the "Numerical Offset" fields. Completion of the mask alignment analysis will place the calculated offsets into the numerical offset window, and the "apply" command must be sent to actually perform the offset.

5.4.4 Software for Autoguiding

Center on reference marks and update the guider coordinate system (see note 1);
Center on object image(s) (see notes 2,3), calculate and send correct incremental offsets to the DCS.
Keep a running record of applied offsets, and take corrective action if needed - eg, adjust the "track rates" for repeated similar offsets, or slightly adjust integration times or offset rates if position is oscillating;
Perform stellar image analysis and keep a running record of count rates, FWHM and sky level; sound warning alarm (voice message) if count rates drop too low (ie, clouds; guide star lost).

Note 1: The reference marks at the focal plane serve as fiducial points, so that flexure in the guide camera system can be automatically removed.

Note 2: There are several possible algorithms for centering, and at least two should be available to the user. One is the "balanced quadrants" method, where the object is divided into four and the amount of light in each quadrant is equalized. This method is particularly useful if autoguiding on spilled light from an object in a slit. A cross-correlation algorithm would also be quite useful if the guide object is extended rather than stellar.

Note 3: Ideally, we should be able to autoguide on several objects simultaneously, by either coadding the images or averaging the offsets. This would enable the use of several fainter stars if a suitably bright guide star is not available. Also, it provides a "pass-off" mechanism for guide stars which move outside the camera field-of-view during offsets.

5.4.5 Miscellaneous Software

We will need software (as yet unspecified) to support image analysis for focusing of both the TV camera and the telescope.

We will need software to coadd the guider images during science integrations, and to communicate with the DEIMOS exposure control and data stream.

5.5 Possible designs

Two sketches of a possible image display and guider GUI are shown in the figures.

5.6 Existing Software and Tools

The ESORTD image display tool may be adaptable for this component.

5.7 Other Resources Required

The hardware for the guide camera is yet TBD.

5.8 Dependencies on Other Components

The guider images and related information about seeing, transparency and sky background will be logged. Object catalogues for positional overlays will require access to the database. (See Database/logging, Chapter 9).

5.9 Outstanding Issues

There is some concern that the read-out and display rates can be made sufficiently fast. We expect camera read-outs at a frequency of about 1 second; for each readout, we will need to coadd the data (for the integrated science images), possibly coadd the data in memory for a "leaky-memory" scheme, and display the image.

5.10 Control Room Layout for DEIMOS Observers

DEIMOS is a large and sophisticated instrument. It is likely that its efficient use will require at least two observers, particularly if two barrels are in place. However, the instrument should be operable with only a slight loss in efficiency by a single observer. In addition, effective interaction with the Observing Assistant is essential. As part of the DEIMOS design, we wish to consider a physical layout that promotes efficient observing, for the cases of one or two observers plus an Observing Assistant. We adopt the standpoint that:

The physical environment for control of the telescope and instrument must facilitate ease-of-use. The physical layout of computer keyboards, monitors and image displays, and access to telescope information or control via the Observing Assistant, should be carefully considered. A well-planned layout can considerably aid efficiency of operations such as target acquistion, mask alignment and guiding; whereas a poorly-planned layout can contribute significantly to mistakes in communication and lost observing time.

Part of this consideration requires that certain ``territorial rights'' be defined. We propose the following:

The observer(s) will nominally have exclusive control of the following:
- Spectrograph internal stages, including the mask changer and hatch;
- Detector (shutter, CCD controller, and all downstream data flow).
The Observing Assistant (OA) will have exclusive control of:
- large telescope motions (ie motions larger than about 2 arcmin);
- Dome (including general dome lighting);
- LN2 operations.
The observer(s) and OA will share control of:
- small telescope offsets (ie motions smaller than about 2 arcmin);
- Guider;
- Instrument rotator;
- Dome calibration lamps.

(In the above, we have selected 2 arcmin for the critical size as it is roughly the radius of the guider field. The actual critical size is TDB.) With these divisions of ``territory'' we propose the following physical layout, in sequential order:

Console 1 - the OA's console, for performing OA exclusive functions;
Console 2 - the guider console. Either the observer or the OA could sit down and control the guider, the responsibility to be negotiated by the observer and OA. This console is also used for other shared functions.
Console 3 - the instrument control console, for performing observer-exclusive functions;
Console 4 - the observer's data-analysis console, for performing quick-look and automated spectral reductions.
DEIMOS image-display monitors (two) will be located above or beside the instrument console (Console 3). Another two image-display monitors will be located beside the data-analysis console (Console 4).

Please note that shared functions may be monitored from any console, but control should be from Console 2 (primarily or exclusively, depending on the function - TBD).

5.B Object Acquisition: Slitmask Alignment

5.11 Overview

Slitmask alignment is an extension of object acquisition, at a much higher level of precision. For direct imaging, positioning of the telescope to within a few arcseconds is usually sufficient. For single-slit observations, positioning must be precise to within a fraction of an arcsecond perpendicular to the slit width; usually the position angle is unimportant or perhaps accurate to, say, 1 degree. On the other hand, multislit observations require positional accuracy of order 0.1 arcsec in both axes over the entire length of the slitmask. Our problem is to position the telescope and instrument rotator to within the tolerances in a simple and efficient manner, with minimal operator involvement.

Slitmask alignment requires the use of both the guider and the DEIMOS CCD array. The guider is used for approximate positioning during the initial stages and for autoguiding during the final adjustments.

5.11.1 Goals

The following goals are included in mask alignment design:

The alignment process must be fast. Ideally, we would like an acquisition and alignment overhead of only a small fraction of a typical science integration. We set a target of 8 minutes for the process.
The process must be simple. All user inputs should be kept to a minimum and, as much as possible, should be limited to oversight of automated routines.
The process must be accurate. Tolerances should be a fraction of the slit width - of order 0.1 arcsec rms.

The procedure described here is based on that developed for LRIS slitmasks by the DEEP group at UCSC. It uses alignment boxes and alignment objects (stars) to position the mask against the sky, by centering the stars within the boxes. This approach has the following advantages:

Alignment stars are chosen to be fairly bright, so that relatively short exposure times (of order 30s) are sufficient to obtain accurate positions;
The mask remains installed throughout the procedure - no overhead in moving the slitmask and no repeatibility worries;
Only a small area of the detector is involved, so we may employ subraster read-out of the CCDs to speed the process.

5.11.2 Steps in the Alignment Procedure

Suitable alignment objects are selected during mask design and corresponding alignment boxes (typically 3 arcsec square) are cut during mask fabrication. To set up on a mask at the telescope:

The field is acquired and PA is set; the spectrograph is placed in direct imaging mode and the mask inserted. The guide star is placed in its expected position on the guide camera, and guiding is started. (This should be sufficiently close to correct alignment that the alignment star images will fall in the boxes on the mask.)
The observer takes a direct image through the mask. For DEIMOS, we will need to read out and analyse only those small regions near the alignment boxes.
The location of each star relative to its alignment box is measured via a semi-automated routine, and a solution to delta-RA, delta-Dec and delta-PA is determined. These offsets are sent automatically to the guider/offset control and the offsets are applied.
Repeat the last 2 steps as needed until the alignment stars are centered in their boxes.
The grating is moved into place and the science integration begins.

With LRIS, CCD positions for the boxes are obtained from direct images through the masks taken with calibration lamps during the daytime, but in principle we should be able to adequately predict the CCD positions of alignment boxes.

The centering algorithm used by the DEEP group for LRIS is based on edge detections for both the stellar image and the alignment boxes. The only required inputs are star FWHM and box size in pixels (see Fig. 5.15-1). For each star/box pair, a plot shows both x- and y-profiles through the box; the user sets a single sky level and the algorithm finds both the box and star centers. Generally only two keystrokes are needed for each alignment star/box. After all the alignment stars are examined, the solution is shown graphically and the user must simply use a single keystroke to exit. The entire alignment solution takes well under 1 minute to execute once the image is available for analysis.

Using this general procedure, we have performed successful alignments of LRIS in under 20 minutes, from the end of one science integration to the start of the next. LRIS requires close to 10 minutes for two grating-mirror changes and a mask-to-mask change. DEIMOS overhead for the equivalent operations will be about 4 minutes both because of simpler grating motions and because stages will run in parallel. Furthermore, it is likely that specialized read-out for DEIMOS alignment will be shorter (15 sec or less) than the entire LRIS read-out (40 sec). Based on our experience, it seems likely that we may acquire and align on a field within our target of 8 minutes (not including telescope slews).

Note that the mask in the second barrel (when constructed) must be aligned relative to the first mask, ie., by internal motions, rather than by repositioning the telescope and instrument rotator. The procedure above is therefore slightly modified, with offsets being calculated for the internal-stage motors rather than for the telescope and instrument rotator.

5.12 Figures

Fig. 5.4 - Alignment Box/Star Centering Algorithm.

5.13 Nomenclature

5.14 Specific Functional Software Requirements

The needed functionality already exists for LRIS, with the exception of communicating the offsets directly to the telescope and instrument rotator. All of the steps will be executed by a single command.

Find precise box location (must be robust, but box size and approximate location are known a priori).
Find precise star location within box (must be robust; star FWHM is roughly known a priori).
Derive offsets and rotation from the values above. This function must be interactive in an easily visualized fashion, so that spurious points can be detected and removed easily.
Communicate offsets and rotation directly to telescope and instrument rotator. (We envision that the Observing Assistant or observer will be required to give a confirming "go ahead" command from the guider.)

The mask alignment for the second barrel differs only in that commands must be sent to motors in the spectrograph which reposition the mask.

5.15 Design Notes

With a priori knowledge of the size of the alignment boxes and approximate FWHM of the alignment stars, a very robust centering algorithm is available (similar to that used in the IRAF "identify" task). The profile is convolved with the profiles shown in Figure 5.15.1, and the zero-crossing indicates the center. This method weights toward the edges of the features (stars or box) provided the FHWM is appropriate. It is insensitive to errors in background level and the presence of most cosmic rays.

5.16 Existing Software

As noted above, comparable software for LRIS has already been developed at UCSC. Except for communication with the DCS/instrument rotator, no significant modifications would be required.

5.17 Additional Resources Required

(none)

5.18 Interfaces with Other Modules

The software must access the mask design and the current distortion maps in the database (Chapter 9) to get the approximate locations of the alignment boxes on the CCD array. It must also communicate with the "offsets" section of the guider control (5.5 above) or the DCS. The software will be interfaced with the image display (Chapter 8) in order to display residual vectors on top of the alignment object images.

5.19 Outstanding Issues and Concerns

(none)

Chapter 5 was assembled by Drew Phillips.

phillips@ucolick.org

Last modified: 19 mar 96