attitude estimate is provided by extrapolating an initial attitude using a model of the spacecraft attitude motion.
For example, after triplets of SAS-2 N-slit star scanner observations have been grouped together using the initial spin rate, a better spin rate estimate is obtained from the time differences between the slit 1 and slit 3 crossings within the same triplet This improved spin rate is then used to calculate observed star unit vectors at some nearby epoch time. This set of observed star vectors at an epoch time is called a snapshot. It is assumed that within the period of interest the spacecraft is spinning uniformly and, therefore, that each star transits slits I and 3 of the sensor with the same time difference. Any deviation of the spacecraft from the uniform spin model may cause significant distortion in the snapshot and thus interfere with star identification.
If an accurate snapshot is needed, greater precision and sophistication in the spacecraft model is usually required. The system used for the SAS-3 star trackers modeled spacecraft motion as the simple spin and nutation of a symmetric rigid body in a torque-free environment (Section 16.3). The variation of the individual measurements of the same star with respect to time is used to estimate spin and nutation parameters, which are then used to extrapolate a relative attitude from the epoch time to the time of each measurement. This relative attitude is then used to calculate an observed star snapshot in the spacecraft frame at the epoch time. If the accuracy of the model begins to degrade because of spin rate variation, for example, the snapshot may frequently be improved by shortening the time span of data used in its creation.
The HEAO-I system uses gyros to propagate an attitude estimate to the time of each star tracker observation (Section 17.1). This procedure is capable of providing very accurate attitude estimates for snapshot generation. Even if the initial estimate is imprecise, the relative accuracy of snapshots created in this fashion is generally greater than in either of the previously described methods.
After the star coordinates and corresponding attitude estimates are computed at a reference time, star identification is attempted. The star coordinates are generally in the form of a snapshot, which may contain only one star or many stars. If it contains only one star, it must be identified using a direct-match algorithm, as described in Section 7.7. If it contains more than one star, any of several pattern-matching techniques may be appropriate, depending on the size and quality of the snapshot and the accuracy of the initial attitude estimate. A typical SAS-3 star tracker snapshot with superimposed catalog stars is shown in Fig. 21-7. Observations are denoted by open circles and catalog stars by plus signs. Double circles correspond to multiple sightings of the same star.
After pattern matching, all observations but one have been identified with catalog stars. The star which caused the unidentified observation was apparently not in the catalog. Note that after matching, the catalog stars have been shifted to the right and upward about 2 deg. Details on alternative pattern-matching methods, including the direct match, are given in Section 7.7.
After observations have teen identified with catalog stars, the final step is attitude model refinement. This involves the calculation of attitude using some averaging or optimization process, such as least-squares or Kalman filtering. This procedure may also include the optimization of other model parameters, such as environmental torque variables, angular momentum components, or gyro drift rates.
AZIMUTH IDE Gl
Fig. 21-7. Snapshot of SAS-3 Spin Plane Star Tracker Observations
AZIMUTH IDE Gl
Fig. 21-7. Snapshot of SAS-3 Spin Plane Star Tracker Observations
213.2 Construction of Batch and Sequential Attitude Systems
Whether the star sensor attitude determination components should be assembled to form a batch or a sequential system depends on various circumstances. Sequential systems require less computer resources because information regarding only one (or, at most, a small number) of stars must be stored at any one time. For this reason, sequential systems are usually chosen for onboard processing. Because they are frequently restricted to direct-match star identification algorithms, sequential systems are often unsuitable when more sophisticated star identification techniques are needed. Therefore, a batch system will be most appropriate when star identification may be difficult—for example, when errors in the initial attitude estimate or the attitude model are large relative to the spacing between stars visible to the sensor. If the system must operate in a variety of attitude accuracy environments, a hybrid system which incorporates both sequential and batch capabilities may be desirable.
The software support systems for the N-slit star scanner in the three SAS missions were all batch systems. The SAS-2 Star System, as described by Rigterink, et al., , received an initial attitude estimate accurate to approximately 2 deg from a Sun sensor/magnetometer system. The program was then required to identify stars observed during 30- to 60-min intervals, which generally spanned several spacecraft spin periods, and to calculate attitude solutions accurate to 0.25 and 0.5 deg about the spin and lateral axes, respectively. After selection of transits, initial spin rate estimation, and association of triplets, an improved spin rate was calculated and a snapshot was created using a uniformly spinning spacecraft model. A congruent triangle distance-matching technique [Fallon, et a!., 1975] was then used to identify the observations with stars in a band catalog. An attitude was then calculated for the epoch time of the snapshot using a least-squares process. A spin rate smoothing and phase angle computation procedure then allowed attitude computation for any time within the segment.
The system being used to support HEAO-I is also a batch system. A coarse single-axis attitude estimate is provided by a Sun sensor. This estimate, a snapshot consisting of star tracker data obtained from one spacecraft rotation (approximately 30 minutes), and a band catalog are used in a phase search star identification procedure enhanced with distance-matching tests in an effort to identify specific stars. A batch least-squares program then uses the identification results to calculate an attitude which is required to be accurate to at least 1 deg. This attitude is then propagated forward in time to provide an initial estimate for a triangle-type star identification algorithm which attempts to identify 5 to 20 star tracker observations measured within a 5- to 8-minute time span. Assuming that identifications are successful, the batch least-squares program calculates a snapshot attitude solution accurate to 0.005 to 0.010 deg. This solution is then used to estimate an attitude correction which is sent to the spacecraft's onboard computer to improve its attitude reference. The onboard computer uses the gyro data to propagate its attitude reference forward in time. Because this onboard reference is required by spacecraft control procedures to maintain at least 0.25 deg (3a) accuracy, it is updated typically 5 to 20 times a week using ground attitude solutions to counteract the effects of gyro-related errors. Comparison of attitudes propagated by the onboard computer during the periods between attitude updates with ground attitude solutions calculated at the same times as corresponding propagated attitudes yields information regarding gyro drift and misalignment parameters (Section 7.8). Refined gyro calibration parameters are then sent to the spacecraft to improve the quality of the propagated attitude reference.
The performance of the HEAO-1 reference and gyro calibration update procedure can be assessed by examining the total arc difference between ground attitude solutions and corresponding onboard propagated attitudes. Figure 21-8 shows the onboard versus ground profile for the week following September 16, 1977. During the first 5 days of this week, onboard attitude accuracy was maintained to within approximately 0.05 deg—significantly better than the 0.25-deg accuracy requirement. Note that the drift rate update sent on September 18 significantly decreased the onboard attitude error growth due to gyro-related errors. On September 21, however, a commanded scan rate change caused a rapid increase in onboard error due to the strong dependence of drift rate solutions on the scan rate. A new drift rate was estimated using data following the scan rate change and sent to the spacecraft on September 22. Propagation accuracy then returned to the 0.05-deg level. Additional details concerning the structure and performance of the HEAO-1 attitude ground support system are given by Fallon and Sturch .
An example of a sequential system which uses a spacecraft dynamics generator with simple environmental torque models is given by Foudriat . An attitude reference is extrapolated to the time of each star scanner measurement by the dynamics generator and then updated using a limited-memory Kalman filter, assuming that the direct-match star identification attempts are successful. By appropriate selection of star scanner measurements for attitude refinement, attitude and model parameters may be refined well enough to permit attitude extrapolation for periods as long as 1000 sec with arc-second accuracy. Another example of a sequential system is the Space Precision Attitude Reference System (SPARS) developed by Lockheed and Honeywell for onboard attitude determination [Paulson, et a/., 1969], SPARS uses gvro data for attitude extrapolation instead of a
spacecraft dynamics model. The direct-match identified transits are used by a Kalman filter to sequentially refine attitude and gyro drift parameters.
21.4 Attitude Data Simulators
In the design and development of mission software, the attitude data simulator is usually the first system to be built. The simulator is used in all mission phases; therefore, it is important to understand in advance the functional and operational requirements for the entire satellite program. A summary of these requirements is presented below. Their implementation within the simulator software is then illustrated by discussion of the structure of two specific simulators. This section is concerned with mission-dependent software, which is used in conjunction with mission support software, rather than mission-independent programs such as ADSIM [Gray, et al., 1973], ODAP [Joseph and Shear, 1973], and FSD [NASA, 1978] which are used primarily for prelaunch analytical studies.
Functional Requirements. Attitude data simulators are used primarily in the following application areas:
1. Development and testing of mission support attitude determination systems. Here, the simulator is used to provide data to exercise and test all capabilities of the attitude determination system.
2. Prelaunch simulation sessions in which both nominal data and contingency data situations are generated to train mission support personnel.
3. Analytical studies to aid in the planning of mission timelines and maneuver control procedures. The testing of new analytic procedures is most readily carried out using simulated data because of data control and the knowledge of all parameters which define the simulated data set. Mission requirements will dictate the need for spacecraft dynamic modeling, based on either a slowly varying attitude responding to time-averaged external torque or a detailed model, including such effects as onboard torquing devices and flexible appendages.
4. Real-time mission support for the identification of systematic variations (such as the Pagoda effect, described in Section 9.4) and prediction of the availability and quality of future data. For a simulator to provide adequate support in all of the above areas, its data generation capabilities should satisfy the following criteria:
1. The simulator should.generate realistic mission data (e.g., constant attitude data, maneuver data, or nutating data). The sophistication level of simulator modeling should equal or surpass that of the attitude determination system to allow the latter to be tested to the limits of its accuracy.
2. Provisions should be included for noise, random bit errors, quantization errors, and realistic sensor biases to test the performance of the attitude determination system with data that have been degraded to increasing levels of severity and to clearly identify the effect of various errors and biases.
3. For real -time support requirements, the simulator should be able to generate data both at a reduced rate with artificial delays added to simulate real-time spacecraft telemetry and at the normal high-speed rate with no delays applied.
Simulator Structure. As an example of the implementation of these functional requirements, we describe the structure of two specific simulators, CTSSIM and PLOTOC, used for the Communications Technology Satellite, launched in January 1976. CTSSIM [Smith, 1975] is an independent simulator used in the development, testing, and prelaunch phases; PLOTOC, which is capable of comparing real and simulated data, [Plett, el at., 1975; Nelson, el at., 1975] is an integrated subsystem of the attitude determination system, utilized primarily for launch support.
Figure 21-9 shows the functional baseline diagram for CTSSIM. The simulator operates under the Graphics Executive Support System, described in Section 20.2, and uses the core allocation/deallocation, graphics displays, and interactive processing services provided by this executive. Program flow through the simulator proceeds from left to right. Starting conditions for a simulation run are set via graphic, card, or data set NAMELIST input. Attitudes for a maneuver trajectory may be either internally generated or read from a tape created by an external program. Ephemeris data is read from disk data sets or tapes or is generated internally. Simulated data may be perturbed by applying noise and biases to sensor hardware parameters. Plot displays allow the user to critically examine the simulated data. The interface with the attitude determination system is either a raw or a processed telemetry data set. Data is generated on a frame-by-frame basis with a variable sampling frequency controlled by the timing routine. The simulator can also read processed telemetry data (e.g., nutating data generated by a dynamic simulator) and use it to simulate raw telemetry data.
In a typical prelaunch simulation, data covering a large time interval (approximately 6 hours), with noise and sensor biases applied, are generated in a single simulation run, carried out at the high-speed rate. The attitude determination
system is then required to process these data and solve for the attitude and applied biases. In contrast, maneuver simulations are generally carried out in real time to provide launch support personnel with realistic monitoring conditions. During real-time simulations, data are generated at a rate close to that expected during mission support. Spacecraft control commands, provided by an external control system, are used as input to the simulator to generate the maneuver data; these data are then analyzed in real time. The maneuver may be allowed either to continue to completion or be stopped and retargeted, depending on the current simulated attitude. Further stopping and retargeting is carried out until the thruster has been calibrated and the maneuver is proceeding on target.
The PLOTOC simulator is a subsystem of the attitude determination system. Its prime function is to allow the operator to compare the observed infrared Earth sensor data with simulated data based on the attitude and bias solution obtained by the attitude determination system, as illustrated in Fig. 21-10. The plus signs in the figure represent observed data points for the horizon-in and horizon-out rotation angles measured by the Earth sensor. The solid lines represent the predicted rotation angles for two possible attitude solutions. The inner pair of rotation angle curves clearly represents the superior solution. Predicted-versus-observed rotation angle plots can reveal the presence of systematic variations in the observed data (e.g., the Pagoda effect) and by judiciously editing the data span, a more reliable solution may be obtained. PLOTOC can also be used to generate predicted data in advance of the observed data to provide Earth sensor coverage information.
Was this article helpful?