Design
The basic flow of a series of observations will look like this: the operator will input a catalog file into the scheduling system. This file will consists of stellar targets and some basic information about each one: celestial coordinates, magnitude, color, etc. The scheduler will store these targets in an internal table or database that extends the input information on each target with their local (alt-azimuth) coordinates, their current grid assignment, and whether or not the target has been observed.
Design diagram (click to enlarge).
As the night progresses, a particular target changes its local coordinates and grid assignment. To keep up with this, the scheduler must continually update the catalog. It keeps track of the current time (periodically synchronizing with a trusted source) and converts the celestial coordinates to current local coordinates. It also compares the local coordinates with the arbitrary grid and links the target to a particular grid location.
When the operator is ready to select a new target, the scheduler presents its best guess of suitable targets. Typically these will be the targets in the nearest grid locations from the last one observed. However, if a grid is obscured then the operator may override the choice and force the scheduler to present the next best choices. Within a grid, only the targets previously unobserved will be available for choosing and will be presented in an order based on criteria that the operator chooses. However, the operator may select any target within a grid, overriding the recommendation of the scheduler.
An example star grid user interface (click to enlarge).
Once the operator has selected a target, it is passed to the TCS for observation. The operator can signal to the scheduler the success or failure of the observation before requesting the next target. If the observation was successful, both the target and its associated grid are marked as observed so the scheduler will prioritize other grids and not repeat targets in future selections. This cycle of selection and observation continues until the observation period ends or all targets have been observed.
Aside from the challenge of the scheduler itself, the main challenge will lie in the user interface. Imagine a situation where much of the sky is obscured and many of the visible targets have already been observed. Since the scheduler does not know the sky conditions, it will present targets inappropriately and the operator will have to repeatedly reject targets until at last the scheduler cycles back to previously viewed (and viewable) grids. The alternative, having the operator pre-mark grids as un-viewable, will be cumbersome in a list-based user interface such as our core prototype. We hope, with our second prototype, to introduce a graphic display where an operator may quickly point and mark grid locations that are obscured, which the scheduler can then ignore. As conditions change, the operator should be able to, as easily, mark viewable areas.
A couple of side requirements exist. First, the client is heavily invested in LabView. This means that inter-system communications are most seamless if we adopt a similar environment. However, LabView does not lend itself to graphical interface, so we need to build a hybrid system that uses LabView at its core and some other language, such as Java, for the interface.
Second is the need to modularize the functions of the scheduler. While a good idea in any case, this is to allow for future development and interface with systems. For example, if the TCS interface is a module, then if the TCS itself changes in the future, our system need only have its interface module changed, rather than requiring a complete rewrite.