The software architecture of the Palomar Autoguider.

The heart of the Palomar Autoguider is a Motorola 68040 single board computer, mounted in a VME crate. This executes a number of cooperating VxWorks tasks that control various pieces of external hardware. The following diagram shows the main tasks and the hardware components that they control.

The Exploder task

Of the displayed tasks, the most important is the Exploder task. Apart from starting up and shutting down the rest of the tasks, the main purpose of the Exploder task is to receive and notify clients of changes to a distributed database of objects. This database is the primary means of communications between tasks. Access to the database on the local CPU is via shared memory. This is handled by a library of functions that maintain the integrity of the database and take responsibility for informing the Exploder whenever an object is updated. Remote clients on other computers can also access the database via TCP/IP connections to the Exploder task. Each remote client maintains its own copy of the database, so that it always has the latest version of each object at hand. After connecting to the Exploder, no object updates will be sent to a client until it has told the Exploder which objects it is interested in. This reduces the amount of traffic that the Exploder has to handle.

The Exploder task is actually designed to be project independent. Thus on startup it requires a template that describes the contents database, and a list of tasks to be started.

The contents of the Autoguider database.

The following list describes each of the Autoguider database objects, along with their contents.

The Configuration Manager Task

The Configuration Manager task reads and writes configuration files. These are text files that describe the contents of database objects. When an update of the Status object is received that has the done member of a Status object set to 0, the configuration manager looks at the save member to see whether it should load or save objects from/to the file name specified in the dir and name members. It then performs the file operation.

The Aspect Finder Task

This is the task that provides the pixel-size autocalibration facility. When it receives a Orient object update in which the initiate member is true, it enters a state-machine that takes over control of the autoguider. By moving the telescope in specific directions and watching the resulting guide star motion across the camera frame, it measures the dimensions and orientation of the camera pixels wrt the sky. It also determines whether the image is mirrored. This task is the only task that should ever write to the Geom object. It keeps this object up to date with the tv_angle member of the Camera object and the xscale and yscale members of the Tcs object.

The Log Manager Task

All Autoguider tasks, including the Exploder use a plug in replacement for fprintf() called lprintf() (log printf). This function passes the resulting formatted message to the log manager task via a custom non-blocking I/O-system device driver. The log manager then copies the message into a Status object and uses it to update the Status object in the database.

The Tracker Task

This is the task that computes guide-star solutions and turns them into telescope move requests (or into target motion in Drift mode). It is also responsible for background subtraction. When the Frame Grabber task is ready to hand the Tracker the target area pixels of a new frame, it updates the Sync object. The Tracker task sees this update and looks in the MUTEX protected area that the Frame Grabber places the pixels in. It then checks that there actually is some new data to process, and if so, determines a new guide-star solution. It then releases the MUTEX so that the Frame Grabber can deposit a new array of target pixels there.

The Gain Controller Task

This task controls the CCD and Image Intensifier gains via a serial line and two serial I/O modules. It responds to explicit gain requests via Gain object updates, as well as being responsible for turning down the gain of the image-intensifier whenever the Tcs says that the telescope is slewing, or when the camera has been disabled via the Imaging object.

The TCS gateway Task

This task handles all communications with the Telescope Control System, via a serial line. Initially it establishes a connection to the TCS by sending it a GI (guider information) request. The TCS is expected to respond with a GC (guider configuration) message. This contains the name of the current instrument, the angle of North clockwise from the top of the guider display, whether the TCS is ready for use and whether the telescope is currently slewing. The TCS also sends this message whenever any of these items changes. Whenever this happens the TCS gateway task updates the Tcs database object with the new values. In addition, if the instrument name changes, the task updates the Config database object with the new instrument name. This, in turn causes the Configuration manager task to reconfigure the autoguider for the new instrument.

The TCS gateway is also responsible for forwarding move requests, received via Move object updates, to the TCS. The TCS doesn't reply to such messages until the move has completed, at which point the task resets the fields of the distance and rate fields of the Move database object to zero. If the TCS doesn't reply for much longer than the predicted duration of the move, then the Tcs gateway task sets reports the error and sets the ready field of the Tcs object to false. The next time that a move is requested, or if an update of the Ping object is received, the task attempts to reestablish a connection with the TCS by sending a GI message.

The Display Manager Task

This task is responsible for the primary graphical user interface of the autoguider. It consists of a general widget library in tvdisp.c and a guider-specific set of functions in display_manager.c which call on the library to create widgets and register callbacks.

The widget library implements buttons, sliders, leds, labels, frames etc.. using the fill-rectangle, line drawing and text rendering primitives of the ITEX DM-PC overlay plane. It provides geometry management, event management and many other features that are common to X-window widget libraries. It also reads input from a mouse via a serial line and converts this to motion of the cursor and to mouse callback events.

It would take too long to describe all of the ways that the display manager displays and updates database objects at the user's behest, but there is one behind-the-scenes interaction with the database that deserves a mention. Since the display manager controls the overlay plane and the frame grabber controls the image plane of the tv, the display manager and the frame grabber tasks have to collaborate in setting the size and position of the camera window. This is managed through updates of the View and Frame database objects. There are two events that can cause the size of the viewport to change.

  1. A new camera type can be requested via the Camera database object. This may have a different number of pixels from the previous camera, so the camera window needs to be resized to fit, if possible.
  2. A new monitor type can be requested via the Monitor object. This also may have a different number of pixels than the previous monitor, so the amount of room available to the camera window may have changed.
In the first case, the frame grabber receives the camera-type change and works out the size of a camera frame. It then records this in the Frame database object. The display manager sees this and tries to reconfigure itself to expand or shrink the camera window to the size of the camera frame. If there is insufficient room, it truncates the size of the camera window to the maximum size that will still allow the controls on the right edge of the display to be accessible. It then records the resulting size and position of the viewport in the View database object. The Frame Grabber task then sees this and uses it to configure the dimensions and position of the images that it places in the image-plane of the display.

The second case is similar to the first. In this case when the Monitor update is received the current version of the Frame database object is used by the display manager to determine the desired size of the frame grabber, and after reconfiguring the display, the View object is updated to inform the frame grabber of the newly achieved size.

The Frame Grabber Task

The Frame Grabber task controls pipeline video processing on the Imaging Technology hardware. It also controls the readout-inhibit line of the Xybion camera via an ITEX strobe line. It receives frames from the camera using the AM-VS, passes them through the CM-CLU to average frames, displays the processed frames on the autoguider display, and acquires the pixels from within the target area for subsequent processing by the Tracker task.

Simplified illustrations of the three main video pipelines are shown in the following diagram.

The camera pipeline is active at all times except when the frame grabber is disabled or when the frame grabber is reconfiguring itself. The camera pixel clock is much slower than the internal clock used for the other pipelines, so each camera frame is accumulated in the camera frame buffer before being pushed through the second video pipeline. Each cycle of the second video pipeline operates during the vertical blank period of the camera, so it can read out of the camera frame buffer before the camera starts to overwrite it. Once the required number of camera frames have been cycled through the second pipeline, the accumulation frame buffer is copied to the image-plane frame buffer of the display.

The frame averaging algorithm, as implemented by the second pipeline, is an 8-bit integer version of:

  for i = 1..n
    mean(i) = mean(i-1) + (intensity(i) - mean(i-1)) / i
This is mathematically identical to an arithmetic mean, but given limited precision, it preserves low brightness features much better than the more familiar:
  for i = 1..n
    mean(i) = mean(i-1) + intensity(i) / n
which throws away the bottom log(n)/log(2) bits of every input frame, and the 8-bit running mean:
  mean(1) = intensity(1)
  for i = 2..infinity
    mean(i) = s.mean(i-1) + (1-s).intensity(i)

  where s = exp(-log(2^8)/n).
which throws away the bottom -log(1-exp(-8.log(2)/n)) / log(2) bits of each input frame.

The adopted averaging equation requires that the two input frames be scaled down by factors that change from one frame of the sequence to the next. This scaling is performed using 256-entry lookup tables which map input pixel values to appropriately reduced output pixel values. These lookup tables are updated just before each new cycle of pipeline 2 (ie. up to 30 times per second). The box that is labelled 16-bit to 8-bit filter is implemented by a collection of lookup tables and comparison operations that map all 16 bit values that are above 256, to 256, and all values below 0, to 0.

The above diagram only shows the three most important pipelines. In addition there is one that, at the user's request, copies the latest output frame into a spare frame buffer. Another pipeline is responsible for subtracting this from subsequent output frames when frame subtraction has been requested. Finally, a pipeline has to be set up to apply the current grayscale lookup table to the target area. The output of this pipeline is the accumulation frame buffer, after its contents have been safely copied to the display frame buffer. Having filtered the target area, the frame-grabber copies its pixels across the VME backplane for further processing by the Tracker task.

Note that all pipelines except pipeline 1 require the same resources, so each pipeline has to be set up and torn down every frame cycle.

The Digital I/O Reader task

This task controls a VME digital I/O board. This board is currently only used by the guide-defeat line. When 5v is applied or removed from between pins 2 and 4 of the P3 connector on the front of the VMIVME1001 digital I/O board, an interrupt is delivered to the digital I/O reader task. It then reads the state of the input and updates the defeat member of the Defeat object to true if 5v is currently applied, or false if the input is floating or set to 0 volts. The rational for the guide-defeat line is that it was predicted that future instruments might want to turn off the guider at critical moments. The pinout of the front-panel connector is illustrated in the following diagram of the front panel.

Martin Shepherd (