Real-Time Hardware-inthe-Loop Tests of Star Tracker Algorithms

This paper deals with star tracker algorithms validation based on star field scene simulation and hardware-in-the-loop test configuration. A laboratory facility for indoor tests, based on the simulation of star field scenes, is presented. Attainable performance is analyzed theoretically for both static and dynamic simulations. Also, a test campaign is presented, in which a star sensor prototype with real-time, fully autonomous capability is exploited. Results that assess star field scene simulation performance and show the achievable validation for the sensor algorithms and performance in different operating modes (autonomous attitude acquisition, attitude tracking, and angular rate-only) and different aspects (coverage, reliability, and measurement performance) are discussed.


Introduction
Many spacecraft with accurate 3-axis control requirements are equipped with a star sensor to support attitude determination.In recent years, star tracker technology has had a remarkable evolution.In particular, these sensors have gained significant improvements in their autonomy and capabilities [1,2].Modern star sensors are expected to offer new advanced functionalities in addition to the assessed capability of highprecision pointing determination during low angular rate mission phases.They are conceived [3] (i) to produce high-accuracy, high-reliability attitude angle, and rate estimates without external support; (ii) to operate in a wide range of mission conditions; (iii) to solve the lost-in-space problem autonomously and in short time; (iv) to deliver angular rate information also when attitude determination is not feasible, as during platform detumbling or slewing.
The ultimate goal is the achievement of performance, functionality, and reliability allowing star sensors to be the only attitude sensor onboard the spacecraft [4].Latest generation star sensor novel and advanced functionalities should be achieved via additional software routines rather than by hardware enhancements, and different operating modes should control sensor operation.As a result, software for system control and management becomes very complex.
Due to the widened range of functionality and novel hardware characteristics, new problems arise in testing modern star trackers, both for calibration and performance assessment.Angular and photometric calibration can still be operated following the procedures that have been successfully applied up to now [5,6].Differently, all the functions related to processing real star field scenes to platform dynamics effects and estimation and to control logic robustness need the introduction of new techniques.
Specialized laboratory facilities and procedures must be developed to this aim in order to integrate data coming from true-sky tests.The latter, in fact, cannot be avoided [5].But, even if they must be performed for final system validation, they are not adequate for fine calibration of the sensor.Likely, they are also more expensive and time-consuming than indoor procedures because ad hoc external campaigns to adequate locations-typically far sites-are needed, and in International Journal of Aerospace Engineering addition, dedicated hardware setup must be realized.In fact, atmospheric effects (refraction, scintillation, light absorption, and background light caused by light pollution) must be minimized, which is achieved thanks to high-altitude sites, far from urban areas and near-zenith sensor pointing [9].Valid tests for angle measurement stability require longtime (hours) sequences of measures, with firmness of sensor installation.Often these tests are carried out at astronomical observatories installing the sensor on the structure of a telescope, thus taking advantage of its tracking system to keep a fixed inertial pointing during the test [10].
In the following, some problems related to laboratory validation of modern star trackers are studied.In particular, it is considered the solution of testing hardware models in end-toend configuration by acquiring and processing simulated star field scenes that extend over the whole sensor FOV.True-sky scene simulation is analyzed.Specifically, a high-resolution LCD display is adopted to simulate star fields.Aspects dealing with design, realization, and operation of such a facility are presented.Hence, the achievable performance of such simulation is discussed from a theoretical point of view.Finally, a test campaign is presented.It was carried out with twofold objective: firstly, to validate the theoretical performance analysis of the star field simulation system and secondly, to show the kind of validation that can be achieved.

Test Facility Architecture
The tests of modern star trackers cannot be limited to calibration and measurement performance assessment for single star-like light source.The algorithms presently in use, in fact, exploit star field scenes that can be acquired under different operating modes and during different mission phases, with operation capability in a range of dynamical conditions from stabilized attitude to high rate rotations.Relevant performance assessment, as well as the management of the operating modes, typically autonomous, requires validation under realistic input conditions and end-to-end test configuration including the hardware model of the sensor.In particular, the former issue is to be preferred even at the preliminary stage of algorithm testing.Also, extensive test campaigns must be foreseen for adequate validation.After these considerations, the architecture of a laboratory facility to carry out indoor testing of modern star trackers has been defined in order to meet the following objectives: (i) ability to support end-to-end tests with hardware sensor models or functional prototypes; (ii) realistic simulation of star field scenes to allow star field scene acquisition as during in-orbit operation of the sensor and consequent processing; (iii) ability of simulating the orbital and attitude dynamics of a spacecraft carrying the sensor to carry out tests reproducing specific mission phases of interest.
The facility architecture proposed and analyzed by Rufino and Moccia [11,12] has been selected since it meets the above objectives, and it is quite flexible to carry out the mentioned variety of tests.It is presented in Figures 1 and 2. The basic idea is that the LCD screen stimulates the sensor under test.
It shows the star field scene that would be viewed in the sensor FOV for the assigned orientation.Two kinds of simulations are considered, static and dynamic.A static simulation consists of one star field scene corresponding to a given pointing, without attitude dynamics in the inertial reference frame (where sky stars are still neglecting long timescale proper motion effects).A dynamic simulation accounts for orbit and attitude dynamics of the platform carrying the sensor during a finite time interval.It is realized by means of a sequence of star field scene, reporting the apparent motion in the sensor FOV exhibited by the viewed stars.The sequence is characterized by the frequency   at which it is updated, which is necessarily limited but benefits of technology advance.
A single pixel of the LCD screen is exploited to simulate a single star of a star field if a static pointing is considered or in the case of a low rate dynamics of the orbiting platform (Figure 3).Differently, when high rate attitude dynamics are accounted for in the simulation, a single star is represented by the strip of pixels reproducing its apparent trajectory in the sensor FOV during the scene update time 1/  (Figure 4).Pixel brightness control is used to reproduce star apparent brightness, as explained in the following.
Star positions in the FOV are computed as a function of the simulated orientation on the basis of a sky star catalog assumed as reference, which must be completed at least up to the sensitivity limit of the sensor under test for correct, realistic simulation.For the realized facility, the SKY2000 star catalog was selected [13].
At the stage of generation of simulated star field scenes, other effects can be introduced.As an example, space radiation can be accounted for by adding activated pixel besides those representing real stars [10].In fact, radiation may determine star-like features in the images acquired by the sensor.Occurrence of the phenomenon shall be based on models taking account of orbit and epoch.
The realization of the facility presented here has been based on commercial-off-the-shelf (COTS) products.The main components are (i) a high-resolution, computer-controlled LCD display that shows the simulated star field scenes constituting   the input to the sensor under test.With respect to the original solution by Rufino and Moccia, here an LCD is adopted instead of a CRT display which guarantees improved simulation performance thanks to its superior characteristics in terms of image geometry and thanks to its flatness [12].Specifically, the selected unit is a 30  -wide (16 : 9 format), highresolution LCD display by EIZO (Table 1); (ii) an Intel-Quad-based, single-board computer equipped with 1-GB-RAM and a high-resolution video card.In the presented realization of the facility, it is in charge of both the functions of experiment control (EC) and display control (DC) processing units (Figure 1); (iii) a collimating optics that makes the scene on the LCD display appear as if at infinite distance from the sensor.The collimator focal length   is to be selected so that the LCD screen covers the whole FOV of the sensor under test.The lens support allows vertical position and orientation adjustment.For the realization of the facility,   = 1.3 meters was adopted, determining the features in Table 2; (iv) a set of high-precision translation and rotation stages that constitute the basis of the mechanical interface for installation of the sensor in the test chamber.They allow fine adjustment of position and orientation with respect to the LCD screen.In particular, largescale adaptation of the distance from the screen is common to both the collimator and the sensor, whilst micrometric adjustment of orientation and transversal position is available for the sensor; (v) a darkroom that covers the sensor, the collimator, and the LCD screen.In particular, its side opposite to the sensor is constituted by the LCD screen, closely and stably fixed to the darkroom structure to guarantee that no light contaminates the darkroom inside; (vi) an optical bench with pneumatic vibration isolation that supports the facility guaranteeing alignment stability.
Some additional details about the above processing units are necessary to the aim of a clear description.The DC processing unit is in charge of controlling the visualization of sequences of simulated star field scenes on the LCD screen.When a specific dynamics is to be simulated, this must be accomplished respecting a severe timing.As a consequence, for this unit a real-time operating system may be taken in consideration.A DVI link is used to control the display.
The EC processing unit is in charge of experiment management: control of the tasks of the DC unit and of the sensor under test, logging of experiment data (both simulation and sensor I/O), and experiment database, preliminary (off-line) simulation data computation (orbit and sensor pointing, simulated scene sequence).These tasks require less strict timing than display control; hence, a standard operating system has been envisaged.The link to the sensor is serial to support the same format as the typical one used to communicate with an onboard data handling unit.The latter requirement is significant if testing engineering or flight models.In the case of a different communication link, it can be easily met by reconfiguring the port of the EC processing unit.
DC and EC tasks were conceived to be implemented possibly, and preferably, in separate hardware units in order to guarantee the best performance in dynamical simulations, as described in the following.Communication between them is based on Ethernet link and TCP/IP protocol.In the test facility realization presented here, a simplified solution has been validated; they are two virtual units, that is, two distinct software tasks running in the same processing unit that address two distinct Ethernet network ports, both available at the hardware processing unit hosting the two tasks, and are connected to each other.Specific software procedures were developed for the two tasks.Besides the already mentioned functionalities, the EC unit software allows synchronization of display control and commands to the sensor under test to carry out simulation of specific mission phases both in terms of star field scenes in the sensor FOV along with operation and on board I/O of the sensor.With reference to the mentioned function of simulation data computation, any arbitrary sequence of sensor orientations can be processed from external input files to generate the LCD star field scenes to be displayed for their simulation.Also, basic simulations can be generated without input files, adequate to test typical star sensor operation modes: (1) static simulations: to support the development and testing of autonomous attitude acquisition routines.
In this case, a series of independent star field scenes that are uniformly distributed over the celestial sphere are generated, and the sensor prototype is commanded to perform autonomous attitude acquisition for algorithm first validation; (2) dynamic simulations: to test attitude tracking routines.In this case, the generated sequence of star field scenes corresponds to a given orbit and zero attitude, during a selected orbit segment.Keplerian circular orbits can be selected by assigning radius and inclination.This mode allows real operating conditions during a space mission to be simulated.
Figure 5 shows the realized system.The LCD display is the key component of this facility.Table 1 reports its main characteristics.Star brightness simulation can be modeled in terms of the apparent visual magnitude  V as a function of the display luminance  fl with its control scale, and of the distance   from the screen to the collimating lens [11]: where   < 1 is the attenuation accounting for atmosphere absorption (to be assumed in the order of 0.75 according to [14]) and  pix is the area of a single display pixel, activated to simulate a star of apparent visual magnitude  V .Assuming   as large as 1.3 meters, the achievable  V simulation range is −1.5 (brightest star) to 5.7 (dimmest star), thanks to the display maximum luminance of 87 footlamberts.Considering that sky star distribution is larger for low brightness and that, consequently to gain sky coverage ability, typical star tracker sensitivity is up to visual magnitude of 6.5/7, the above range of magnitude can be shifted towards fainter values by reducing the LCD brightness level, thus scaling the entire range downwards.As an example, 50% reduction changes the  V simulation range to −0.7/6.4.A higher reduction may be preferable in order to simulate also stars not observable by the sensor under test but that contribute to the background acquisition noise in true-sky operation; on the other hand, this makes larger the number of bright stars which are simulated fainter than they are.Also, it is worth noting that in dynamic simulations with high rate of rotation, the brightness level of the pixel strip representing a single star is determined by the constraint that the overall radiation from the strip equals the one of the simulated star.Finally, also star radiation spectral characteristic in the visible band could be accounted for in such a kind of LCDbased simulation.It can be accomplished by modifying the ratio between the red, green, and blue pixel color components, but a color display must be adopted of course.This has not been implemented yet in the realized facility since the most common sensor algorithms do not make use of such information, even if this issue is being discussed in the published literature [15].However, it must be pointed out that such technique for star color simulation is not straightforward, but it must be studied before implementation.In fact, certainly the mentioned solution cannot completely simulate the spectrum of a star emission, similar to a black body radiation.Rather, it should exploit the LCD peaked emissions at red/green/blue/frequencies with respect to star visible spectrum and sensor photodetector spectral response.To conclude, in this case more than one pixel should be used to simulate a single star, since in color displays each pixel emits in a single color band and different color pixels are arranged in patterns; this requires additional study to guarantee correct simulation of star fields in terms of star apparent angular size, angular separation between stars, and apparent star motion in dynamic simulations.

Simulation Performance Theoretical Analysis
Star field simulation operated by means of the presented facility has limitations arising from the discrete nature of the star field scenes displayed by the LCD screen: (i) the angular size of the simulated stars is larger than the one of true-sky stars, because of the size of the LCD pixels exploited for their simulation; (ii) star position in the simulated star field is approximated because of the finite number of pixels available on the LCD; (iii) dynamical scenes suffer from discretization problems, because of the consideration at the previous point and, in addition, due to the discrete and finite number of scenes that can be displayed on the screen per unit time.
In terms of the above issues, the quality achieved in the simulation of star fields has been evaluated preliminarily from a theoretical point of view with special reference to the application being considered, that is, functionality tests of a modern star tracker.With this objective, the achieved performance of star field simulation is expressed in terms of the effects on attitude measures operable by the sensor under test.In other words, simulation performance is expressed by means of the uncertainty induced in the measured attitude following a conservative, worst-case approach.This approach presented by the authors in [11], where it was applied to a CRT-based test facility, has been reviewed and used to characterize the presented test facility that takes advantage of state-of-art technologies.

Static Simulation Performance.
In this case, the display resolution determines the accuracy of the star field simulation.In particular, its dot pitch  pix gives the minimum angular separation,  pix , between adjacent positions of simulated stars.On the optical boresight it is Then, the maximum angular error resulting from star position approximation at pixel location is ± pix /2, and this error is expected to be uniformly distributed.The same value can be regarded also as the maximum approximation for the change of the apparent position of a single simulated star when reproducing a pitch-only or yaw-only attitude rotation (i.e., along axes perpendicular to the sensor boresight).In both cases, after uniform distribution assumption, the corresponding standard deviation value of  pix / √ 12 can be regarded as single star position uncertainty in the mentioned angular terms.Figure 6 shows  pix as a function of the off-boresight angle, computed for the adopted display and collimating optics (Table 2).It results that  pix has very limited variations, keeping in the order of 40 or 55 arcsecs, respectively, in H or V direction of the display, and in the pixel diagonal direction.It is worth mentioning that in general LCD displays may have rectangular pixels, so different dimensions can be considered in horizontal, vertical, and pixel diagonal directions.Since LCD display single pixel have  practically size as the display dot pitch, the above values represent also the apparent angular size of the pixel.They are much larger than a real-sky star [16], but are within the typical IFOV of modern star trackers which also adopt defocusing to get subpixel accuracy [1]; hence, this is still a valid simulation solution.
The separation between two positions on the display screen can be expressed also as the angle  pix with vertex at the screen centre, which is a function of the off-boresight separation,  offb , of the considered star positions: as shown in Figure 7 for the adopted display and collimating optics.The angle  pix represents the roll rotation (i.e., along the boresight axis) that determines a 1-pixel position change for a simulated star, viewed at  offb from the FOV axis.As for pitch and yaw, ± pix /2 represents, in terms of roll rotation, the maximum approximation in the simulation of either the position or the apparent motion in the sensor FOV, and  pix / √ 12 is the corresponding uncertainty.
The above single-star position uncertainties can be turned into estimates of simulation accuracy with reference to the measures that the star tracker under test carries out after considering that such measures are based on the observation of several stars, at least two [17].Assuming uncorrelated errors in the position of the simulated stars, for pitch or yaw rotations and for roll rotations, the resulting attitude uncertainties,  , and   , respectively, can be obtained as where  stars is the number of viewed stars exploited for the computation.Table 3 reports the values for the presented test facility.In this table, for each considered off-boresight angle, H or V, average values of  pix and  pix with respect to H or V direction, and pixel diagonal (Figures 6 and 7) are exploited.

Dynamic Simulation Performance.
To carry out tests of the advanced functionalities of a modern star tracker, it is necessary to display a sequence of stellar scenes to the sensor as it would observe them in orbit during real operation.This aspect of star field simulation is addressed here, considering the effects of finite resolution of the simulation in terms of both star positions in the simulated scene and update frequency of the star field scenes (i.e., the number of simulated scene displayed per second).Both of these facts imply that the simulated star apparent motion displayed on the screen cannot be rigorously continuous; that is, simulated star apparent motion continuity is limited because of spatial and temporal discretization of the synthetic scenes that simulate the evolving star field.This limitation can be made little thanks to technology improvements (more LCD pixels, higher frequency of simulated scenes), but cannot be canceled.The resulting effects in terms of quality of simulation are discussed and analyzed quantitatively in the following, introducing some figures of merit and evaluating them for the presented test facility.
The settings of the test facility and of the sensor under test affect simulation performance analysis.In the presented analysis, it is assumed that the simulation display frame rate is   = 10 Hz.In general, it must be   ≥  upd , where the latter one is the sensor update rate, that is, the frequency at which the sensor generates its measures.In the following,  upd = 4 Hz is assumed.

Minimum Angular Rate.
To perform angular rate measurements even if the viewed star apparent motion is not continuous, it is necessary that the simulated scenes show changes in presence of nonzero attitude dynamics.In particular, this means that the position of the simulated stars shall change at least one display pixel in Δ upd = 1/ upd (continuous-motion constraint).The resulting minimum angular rate is obtained after turning the 1-pixel motion into angular terms.It can be derived for pitch or yaw and for roll as The resulting values, based on the data in Figures 6 and 7, are summarized in Table 4.

Accuracy of Angular Rate Simulation.
As described in [11], this performance parameter can be split into two contributions: the first one,  , Δ , is related to the accuracy of simulation of each single star field, and the second one,  , Δ , is related to timing accuracy of sequence display.Based on the following model of angular rate computation: where  and Δ are, respectively, the computed angular rate and the rotation realized during the time interval Δ, it is: the wc label with standing for "worst-case." Finally, for uncorrelated contribution, the overall performance can be expressed as Quantitative results from this model are obtained after some choices: (i)  Δ is assumed equal to  , and   for pitch or yaw rotations and for roll rotations (Table 3), respectively; (ii) Δ is related the frame rate of the star field sequence as 1/  , and its uncertainty,  Δ , depends on the timing capability of the DC computer.The latter uncertainty can be significantly reduced by adopting a real-time operating system (RT os) for the DC computer that guarantees event execution control at microseconds whilst standard (non-RT) operating systems guarantee lower timing performance.Hence, significant difference of performance may result in the two cases.
However, in the present case, where the DC computer does not run any additional task other than frame updating, it can be assumed that  Δ is in the order of 0.01 ms, as confirmed experimentally (see next section).
Under the above assumption for  Δ and for Δ in the order of 0.1 s, in the worst case condition (i.e., non-RT os), the contribution to   from ( 8) is lower than 10 arcsec/s even for  max larger of 25 deg/s whilst the one from equation is much larger; hence, the latter one is dominant.
Table 5 presents the results for Δ = 0.1 s and midrange off-boresight angles of observed star positions.Even if these values may be not completely satisfactory, it must be mentioned that there is not any different test solution to perform such kind of end-to-end tests, that is, with the sensor under test operated in its complete configuration (stars in, attitude out).The only viable alternative is represented by processing simulated acquisitions of the sensor, thus bypassing image forming and image acquisition, but this may not be desirable.True-sky test may offer source scene with better characteristics, even if atmospheric and environmental artifact must be taken into account, but they cannot simulate mission phases or maneuvers, and they are certainly more expensive and time-consuming.

Test Campaign and Validation
A test campaign was carried out, based on the operation of a star sensor hardware model, and it is presented here with twofold purpose.Firstly, the various simulated orbit and/or attitude cases are presented, discussing the relevant star field simulation in terms of performance parameters to assess the theoretical analysis.Secondly, sensor test results are presented to show how its functionality and performance can be analyzed by means of the presented laboratory facility.

Sensor Hardware Model.
A hardware model of advanced star tracker was developed.It is based on COTS hardware components and original software routines that implement the typical operation modes required for modern advanced sensors [3]: (1) Cartography: at each acquisition, this mode returns a list of observed stars and the relevant unit vectors in the sensor reference frame; (2) Autonomous attitude tracking: in this mode, the sensor is able to perform inertial attitude measurement with a selected data rate without need of external information as soon as it receives input about the starting initial inertial attitude from an external source.This function is carried out by exploiting star unit vectors measured in the sensor reference frame and the relevant star unit vectors in the inertial reference frame, that are contained in a star database installed in the sensor processing unit; (3) Autonomous attitude acquisition: when this mode is commanded, the star sensor acquires the initial attitude without need of external information.This function is carried out by comparing star field features extracted from observations and models that are contained in a star feature catalog installed in the sensor processing unit.
In order to ensure that the sensor can operate in any of the above reported operating modes, the sensor itself had to be designed so that its physical and software characteristics allow one to implement the mentioned modes.The criteria for selecting these characteristics are reported in [18].The following list summarizes the sensor specifications to be assessed: (i) on board star catalog size; (ii) on board star feature catalog size; (iii) optics focal length, ; (iv) optics -number, #; (v) minimum brightness visible star magnitude.
Sensor specifications, derived as reported above, and the results of a market analysis of available COTS units determined the sensor configuration described in the following.It is based on the Matrox IRIS P-1200HR system [19] that is composed of the following: The resulting specifications are reported in Table 6. Figure 5 shows the camera head installed on racks inside the darkroom.Sensor algorithms that were adopted for the various operating modes and relevant performances are described in [18,20].
Presently, the laboratory facility has been tuned for operation with this sensor (Table 2).In particular, the focal length of the collimating optics,   , has been selected to match the vertical size of the display to the vertical size of the star tracker prototype FOV.The diameter of the collimator has been determined to avoid vignetting at large off-boresight within the displayed scene on the LCD screen [12].(ii) Dynamic simulations, orbit plus low-angular-rate attitude (referred to as DS1 in the following): three different combinations of orbit and sensor pointing, with no attitude dynamic in addition to orbit, were considered to test sensor operation from autonomous attitude acquisition to tracking during dynamic simulations.Two different orbits (equatorial for case 1 and 2 and polar for case 3), both are circular with radius of 7178 km (800 km altitude, 0.059 deg/s orbital angular rate) and ascending node on the -axis of the earth-centered, inertial reference frame; sensor pointing is along orbit radius toward zenith for case 1 and 3 and perpendicular to orbit plane for case 2. Table 7 summarizes orbit characteristics and inertial attitude angles for the sensor-fixed reference frame for each case.A sequence of star field scene at   = 10 Hz and lasting a complete orbit has been considered in all the three cases.The relevant statistics of the number of simulated stars per frame are in Table 7.
(iii) Dynamic simulations, orbit plus high-angular-rate attitude (referred to as DS2 in the following, Table 8): a single orbit (circular, 500 km altitude, and equatorial, 0.062 deg/s orbital angular rate) is considered, with four cases of additional attitude dynamics that consist in the combination of two angular rates (1 deg/s and 5 deg/s) and two orientation of the rotation axis (perpendicular to and along sensor boresight, in both cases in the orbit plate).Sequences of star field scenes at   = 10Hz and with time extension of 18 to 300 seconds were considered in these cases.In these simulations, rate-only algorithms were tested.In particular, the validated algorithms are not installed yet in the sensor in use, but they were tested off-line.The sensor was operated in the simulation facility to acquire and save star field scenes.
International Journal of Aerospace Engineering First of all, data of the static simulation have been exploited to validate the theoretical estimation of single star position accuracy.On the basis of the pixel activated to simulate each star, the apparent angular position in the facility has been computed and compared to the desired one.In terms of angular separations from FOV planes of symmetry, the results (Table 9) are in perfect agreement with the estimated uniform distribution in the range from − pix /2 to + pix /2.Also, the average number of stars displayed on the LCD is in the order of 175.
Dealing with dynamic simulations, the main concern was checking the adopted solution for the DC processing unit with special regard to scene sequence timing under standard operating system.This could determine serious loss of performance, as already highlighted.It is worth noting that both real-time and nonreal time operating systems have the same ability to measure time, but it is not so for task planning following a time schedule.The latter task is operated always very accurately only by real-time systems since they are designed to have deterministic response time predictability, minimum interrupt latency, and minimal task thread switching latency.Nonreal-time systems, differently, do not base task thread switching on (time) deadlines.After these considerations, during dynamic simulations, the saved log data included the times at which the star field scenes were processed.In particular, two aspects have been analyzed: (i) the duration of the time interval required to "substitute" displayed scenes.This quantity must be as low as possible with respect to the scene display time 1/  ; (ii) the stability of the star field update frequency   .
To carry out these checks, the DC software measures and logs the time at which each star field scene processing starts (i.e., just before canceling the previous scene) and the time at which the scene is completed on the display (i.e., right after the last pixel of the scene is activated).The first figure of merit has been computed as the difference of the above two logged times for the same frame and the second one as difference of the start time of subsequent frames.Statistics of the results is in Table 10.Frame construction is completed in less than 5% of the frame duration; frame duration is stable within 0.6%.It is worth recalling that these results are obtained running the DC unit as a virtual machine in the same hardware unit that hosts the EC unit software and that this processing unit was equipped with standard, nonreal-time-operating system.Even in this case, which does not implement the best solution for time stability of LCD scene sequencing (i.e., a dedicated hardware unit and hard real-time operating system for the DC Unit), the results are definitely good and support the assumption on which the theoretical assessment of dynamic simulation performance was based.

Sensor Performance Assessment
Example.The sensor unit described above was operated during all the mentioned simulations in different modes.
During static simulations, for each star field scene, firstly the sensor was commanded to autonomous attitude acquisition from unknown orientation; then, after attitude identification, it was commanded to attitude tracking.If this mode starts successfully, it is maintained for about 10 seconds; in the case the autonomous attitude determination was incorrect, Tracking fails and the sensor is commanded back to another attempt for autonomous attitude acquisition and subsequent tracking.Running this test, it is possible to check star tracker algorithm: (i) for autonomous attitude acquisition: (a) sky coverage (percentage of the celestial sphere where autonomous attitude acquisition is carried out successfully); (ii) for attitude tracking: (a) accuracy and precision.They were evaluated as in the previous case, in terms of mean and standard deviation of the errors of measure sequence for fixed, stationary simulated star field.this statistics was then averaged over all the 1000 cases to get the overall figure of merit of sensor performance in its FOV.
Table 11 shows the results, globally for sensor orientation over the whole celestial sphere; variability is due to on board star catalog and sky star distribution density, as analyzed in detail in [18].Different precision in the two modes (autonomous attitude acquisition and tracking) is due to the different number of stars exploited for reconstructing attitude.In detail, accuracy and, primarily, precision estimates for Autonomous Attitude Acquisition are strongly affected by the algorithm strategy that aims at fast solution and does not exploit stars uniformly distributed over the FOV in large number.Differently, tracking data is definitely more reliable because of the larger number of exploited stars, covering almost the complete FOV, and, in fact, they are in agreement with the presented theoretical analysis and meet usual performance assessment for modern star sensors [17].
During dynamic simulation DS1, each test started in IA mode and successfully turned to TR mode which was kept for the whole orbit simulation.Sensor inertial attitude was successfully reconstructed by the TR algorithm, and the achieved performance is reported in Table 12 in terms of attitude angle error statistics for yaw, pitch, and roll rotations (i.e., rotations along sensor-fixed axes).Table 12 shows sensor performance in terms of the measure of error statistics.Complete agreement with TR operation in static tests is accomplished, with slight loss due to the dynamic evolution of the input scenes.
During dynamic simulations DS2, innovative algorithms for angular rate determination were examined.In these peculiar test conditions (specifically, high rate of rotation), the stars acquired by the sensor are imaged as strips due to their apparent motion in the sensor FOV during the image integration time adopted by the sensor focal plane subsystem.Consequently, inertial attitude determination is not feasible since star field patterns cannot be identified, but angular rates can be estimated on the basis of the apparent motion, by examining the length of the imaged star strips [21] or comparing subsequent acquisitions of a sequence [22].The application of the latter approach to the images acquired in the described DS2 simulations was carried out by the authors [23].These tests and their results are briefly reported here to show range and variety of tests and validations possible by means of the presented facility.Key point and innovation of the applied algorithm is the optical-flow-based estimation of the apparent motion of the imaged star field [23] as displacement field of the imaged stars in subsequent acquisitions.This is exploited to compute the time derivative of the unit vectors to the viewed stars and hence to inertial angular velocity estimation in least-square sense.Table 13 reports the measurement performance exhibited in these tests in terms of accuracy and precision, that is, mean and standard deviation of the measure errors during the considered mission segment.As in the previous cases, as expected, measures of rotations along the boresight axis are one order of magnitude worse, and precision in all the three components (pitch, yaw, and roll) is compatible with the presented theoretical analysis in most cases.In particular, larger errors are exhibited only in test case 2, due to the significant strip length and the consequent diminution of the signal-to-noise ratio in each frame, which reduces the number of valid star measurements and degrades accuracy in estimating star centroids and their displacement.

Conclusion
This paper presented a laboratory prototype designed and realized to carry out tests of software-based functionalities of modern star trackers and a laboratory facility to carry out such tests indoor.Star field scenes are simulated by means of a high-resolution, large-size LCD display controlled by a computer so that star tracker operation during a generic mission phase or maneuver can be reproduced and tested.Components of both sensor and test facility were detailed, selected among Commercial-Off-The-Shelf products.Also their software components were described.Then, the performance achieved by the star field simulation system was derived.They are in the order of 3 arcsecs and 30 arcsecs for pitch or yaw rotations, and for roll rotations, respectively, in static simulations; in dynamic simulations, they are 200 arcsec/s and 1500 arcsec/s for pitch or yaw rotation rates, and for roll rotation rates, respectively.Even though the attained values may not be fully satisfactory, this test solution allows one to simulate a variety of operation conditions, static and dynamic, that cannot be offered by any other solution.Finally, a test campaign is presented based on a modern star tracker prototype.Facility design solution and the discussed performance analysis were validated.In addition, it was shown that sensor operation can be tested in all the operation modes typical of the latest generation sensors (autonomous attitude acquisition, attitude tracking, and rate-only), to assess various performance aspects (sky coverage, reliability, autonomous mode management, and measurement performance).

Figure 1 :
Figure 1: System block diagram of the star field simulation laboratory facility.

Figure 2 :Figure 3 :
Figure 2: Schematic of the star field simulation laboratory facility.

Figure 4 :
Figure 4: Simulated star field scene displayed in the facility in a dynamic simulation with high rate of rotation along boresight.

Figure 5 :
Figure 5: Darkroom interior volume: sensor installation and position/orientation control system for sensor and collimator (left side), LCD screen (right side, partial view).Base antireflection panels were removed to show the optical table and the large-scale translation tracks for LCD distance adaption of both collimator and sensor.

Figure 6 :
Figure 6: Angular separation of adjacent pixels as viewed from the sensor installation position in the test camera (1/2 of this quantity represents the maximum error in the simulation of the position change in sensor FOV for one star after any pith-only or yaw-only rotation).

Figure 7 :
Figure 7: Angular separation of adjacent pixels as angle with vertex in FOV centre (1/2 of this quantity represents the maximum error in the simulation of the position change in sensor FOV for one star after any roll-only rotation).

( 1 )
sensor processing unit based on a 400 MHz Intel ULP Celeron, 128 MB ram, 128 MB flash disk, Ethernet 10/100, RS-232, and Operating System Microsoft Windows CE 5.0; (2) sensor camera unit equipped with a SONY CCD 1/2  progressive scan photodetector model ICX267AL with a 1280 × 1024 pixel array.The camera can acquire up to 15 frames per second; (3) lens system produced with  = 16 mm and # = 1.4.

Table 2 :
Facility features relevant to sensor FOV matching.

Table 4 :
Minimum angular rates for continuous motion simulation (i.e., 1-LCD pixel simulated star position change between subsequent sensor acquisitions).

Table 9 :
Statistics of the parameters characterizing static frames.

Table 10 :
Star field frame timing performance of the display control processing unit equipped with nonreal-time operating system.The quality of the simulation has been analyzed considering the data describing the simulated frames and their presentation on the screen during tests.This was done by comparing frame data (activated pixels and their apparent angular position at the sensor under test) and star catalog data and analyzing log data saved during test execution to derive figures of merit of the simulated star field and satellite dynamics.

Table 11 :
Test of sensor performance for stationary input (static simulations) global results over the whole celestial sphere.

Table 12 :
Test of sensor performance for dynamic input (DS1 simulations).

Table 13 :
Test of sensor performance for dynamic input in highrate rotations (DS2 simulations).
,Δ : timing accuracy of sequence display  ,Δ : accuracy of a single star field simulation : angularrate  min , : minimum pitch and yaw rates  min  : minimum roll rate.