This memo is meant to describe the basic behavior of the IOTA star tracker and to supplement the information in header file StarTracker.h, where the first explanation of the new star tracker code is given.
The program is written to deal with three possible star tracker detectors. However, only one is actually being used, so our focus here is understanding the "new ccd" detector code. This is one area where the present program could stand a major rewrite, using better advantage of object oriented design principles.
There are two key subsystems in a star tracker: a detector and a movable "star tracker mirror". In the "new ccd" case, the detector is an area on the ccd chip in which the star is detected and has its centroid measured for feedback to the mirror. The detector is in the IOTA laboratory at the end of the IOTA delay line system.
The mirrors are a part of the equipment at each telescope. We refer to the three telescopes as A, B, and C, where A is the "north" telescope, B is the "south" telescope, and C is the one in between.
For the three IOTA telescope beams, this means that three areas are used on the chip. The light beams come from the IOTA telescopes through the optical delay lines and then emerge in the lab. The beam from each delay line is intended to be directed to a specific area on the detector chip. We refer to the three delaylines as: 1, Fixed, and 2. The specific area on the chip for each beam is refered to as the "target" area in the documentation.
The target areas are located in three of the four quadrants of the ccd chip. The figure below gives the geometry:
The figure below shows the star tracker tracking three telescopes simulataneously:
Quadrants 0, 1, and 2 are the ones used for targets. They are assigned to the delay lines as follows.
| Target | DelayLine |
| Q0 | 1 |
| Q1 | Fixed |
| Q2 | 2 |
The IOTA interferometer optics are such that the same telescope does not always send its light down the same delayline. Fortunately, however, there are only two configurations that are possible, which may be thought of in terms of which of telescopes A or B is attached to the Delayline 1. This means that the target that receives a particular telescope's light changes with the delay configuration
| Telescope | DelayLine | Target |
| A | 1 | Q0 |
| B | Fixed | Q1 |
| C | 2 | Q2 |
| Telescope | DelayLine | Target |
| A | Fixed | Q1 |
| B | 1 | Q0 |
| C | 2 | Q2 |
Finally, to help with the complicated business of placing the individual beams on a single chip, we provide shutters to block the light as it exits from the three delay lines. Thus, the shutters are most logically associated with the delaylines, rather than with the telescopes. Knowledge of the delay configuration allows us to determine which telescope is actually blocked by a particular shutter.
In normal operation, the detector is readout at a regular rate. When a frame readout is completed, then the target areas on the frame are analyzed to find the star's centroid. The key parameters are:
Integration time per frame: the integration takes place during a certain number of ticks of the VxWorks operating system clock. The clock ticks 1000 times per second, so the natural units of integration time are milliseconds.
The frame readouts are simple counts (called ADU's = arbitrary? data units) from the CCD, which is proportional to numbers of photons falling on the chip during the integration time. The system saturates at 4095 ADU's, so integration times must be short enough to make the data for a particular star fall within the linear range.
To determine the flux of light falling on the detector requires normalization by the time interval of the integration. Thus, we may derive a flux (in ADU's per pixel per second) by dividing the number of ADU's read out by the integration time. The log of the flux is inversely proportional to the apparent magnitude of the star.
The detector has a certain background noise level that is always present. To eliminate this background, the observer integrates on blank sky to observe the average level in each detector pixel. This data is then subtracted from the data readout in the frames.
We have to do two things with the data: (1) determine whether a star is present; and (2) compute a centroid.
To determine whether the detector has valid data for star centroid measurement, a threshold needs to be set to distinguish valid star signals. The software currently sets this threshold by specifying a threshold flux, rather than an a threshold ADU level. This is sensible since, eventually this could be related to the expected brightness of the star to be tracked.
In normal operation, only the target area is scanned to search for a pixel that exceeds the threshold value. The method used to do this is called detect_star. detect_star looks in a "detection_zone" on the chip to see if a star is there. Normally, the "detection_zone" is just the target quadrant, but in the special case of searching for a star in one beam with all others blocked, detect_star actually scans the entire array looking for an object above threshold, and it returns a true (non-zero) if a star is found. (This information is used by the spiral search loop to terminate the search.)
The detect_star method also finds the location of the brightest pixel in the target region (variables: br_x, br_y) and uses this information to compute gross movements of the mirror and siderostat to capture the star. If the brightest pixel falls within the target area (called the "tracking_zone" in the code), then an actual centroid is computed to provide feedback to the mirror.
Mirror movement is enabled when the star tracker loop is closed. When the star tracker loop is open, the mirror will generally be at its centered position unless it is being scanned to search for a star. (See below).
The analysis of the detector data leads to mirror movements under three circumstances: (1) centroid measurement; (2) bright pixel above threshold that falls outside the "tracking_zone"; and (3) recenter of mirror in the event that the star is lost.
Mirror movements are initially determined in pixels of image motion. These need to be converted to arcseconds of motion along the chip x and y directions, using the user provided plate scale for the detector. These motions in arcseconds are then converted to mirror motion in the device units of the piezo mirrors.
The actual mirror correction that is implied by the centroid offset may be scaled by a gain factor, since that might give more stable performance. At the present time, though, the gain factor is set to one ... i.e. no scaling ... and we command the piezo mirror to remove all the observed offset. The mirror position itself is then further compared to the central mirror position and small commanded motions to the siderostat are made to remove any offset. The piezo mirror position contains the accumulated error in the telescope pointing, and so the new siderstat position is commanded using this accumulated offset; the siderstat position is updated every 1/4 second.
The equations for mirror motions are as follows. Assuming x,y are the offsets from the target position in pixel units, in arcseconds, with four arcsec pixels:
The software contains a geometric rotation to account for misalignment of the x,y axes of the detector and the mirror motions. So far none has been hinted at, but then none has been really sought either. Thus at the moment, the offset in arcseconds to be sent to the mirror follows x_as an y_as.
If the current mirror position is mir_x, mir_y, then the new mirror position to be commanded is:
where conversion_factor gives the conversion from arcseconds to piezo mirror position units (approx. 55 units per arcsecond) and the sign convention has been determined by observation. The gain factor is applied for possible stability reasons, but currently a factor of 1 appears to work well.
The offset to be removed by the siderostats (in arcsec) is:
where mirror_center is the central mirror position in piezo units and offset_gain is a gain factor to be applied for stability if necessary. Currently this gain factor is one.
The x and y siderostat offsets must be interpreted in terms of the roll and tilt axes of the siderostat system. The roll and tilt offsets (in arcsec) are given by:
The basic control of the star tracker is done in a method of the StarTracker class. The software is located under /home/iota/iotamc/vxworks/star_tracker.
The main method is called do_loop. This method is called in a program running under vxworks. There is a lot going on in this method, which principally coordinates the main elements of star tracking, namely the readout of the detector and commands to the mirror. Much of the logic in the program also deals with what to do in the case that the star isn't present, or handles special modes.
Each time through the loop, there is a command pending, requesting a particular state for the star tracker. At the end of a particular run of the method, the state is updated to reflect current status. The figure below provides a flow chart of the basic operation of the star tracker.
There are three main commands to the star tracker, which correspond to requests for the star tracker to be in a particular "state" of operation.
There are three states of the star tracker system defined in the present software that are reported to the user.
In addition to commands and states reported to the user, there are a set of states (or modes) used within the program, called the FSM states by the author. These offer more insight into what the star tracker is doing. We may organize these internal states into two categories: those that are important when NO star is detected and those which deal with the star data.
The "NO STAR FOUND" states are:
In the special case where a star is actually found while the system is in SEE_NOTHING mode, the system begins to try to deal with the star signal and, perhaps, command the mirror. Thus, SEE_NOTHING can also transition to more interesting states that involve trying to hook onto the star.
The figure below provides a flow chart of the star tracker's activities when a star is found, according to the internal states outlined above:
With respect to searching for the star, which is one of the options when no star is found, the detection of the star shows that this process is over, and the search procedure is abandoned with the location of the star.
These special states are:
If the star is lost at any point, the program reverts to the other branch in which no star is detected. The program will transition to the SEE_NOTHING state, if the beam is blocked by a shutter during initial alignment. In case that the star is really gone, a RESET is done and the mirror is recentered in its range.
The figure below provides a flow chart of the star tracker's activities when a star is found, according to the internal states outlined above:
During the October 2001 engineering run, we implemented a mode for scanning the piezo mirror over its full range of motion to search for a star. As described above, when no star is seem on the chip the program is in its SEE_NOTHING state. If the "PM Search" flag on the control panel is set to yes, then the program executes a raster scan of the piezo mirror over its entire range. A new point is observed each time through the star tracker "do_loop" method, corresponding to every new frame.
The piezo mirror scans a range of +/- 41 arcseconds in two directions. The motion is commanded by a 12 bit integer (0-4095 range). Thus, there are about 50 counts per arcsecond of offset. The scan grid is set by providing the step size in these count units. It begins at 0,0 and increments until the commanded offset exceeds 4095. Thus, to get as close as possible to 4095 edge, one needs to be careful to choose a step size with an integer multiple slightly less than 4095 (e.g. 511 for ~10 arcsec steps).
Tests of the new system showed that it did a good job of finding the star and locking up for offsets of ~20 arcsec or less. However, for larger offsets within the piezo mirror range, the system did not find the star. This is puzzling, and so we made a few additional tests:
