Delta

Delta-Utec Space Research and Consultancy

Platschelpenbank 3
2317 ML Leiden
The Netherlands
Tel: +31 (0)71 523 0662
Fax: +31 (0)71 523 3309
www.delta-utec.demon.nl

Michiel Kruijff & Erik van der Heide


SSATT

DELTA-UTECS STAR SENSOR ALGORITHM TEST TOOL

VERSION 1.0 - SHAREWARE


The manual
2
Table of Contents
INTRODUCTION 4
CHAPTER 1: BACKGROUND INFORMATION 5
1.1 Development of On-board Database for Triangle recognition 5
1.1.1 Conversion of star magnitudes and Star Catalogue 5
1.1.2 Calculation of triangles 7
1.1.3 Uniformization of the triangle set 10
1.2 Image processing, Star identification and Attitude determination algorithms 13
1.2.1 Centroiding and image simulation 13
1.2.2 Apparent multiples model 14
1.2.3 Identification & validation 15
1.2.4 Attitude determination 15
CHAPTER 2: TEST TOOL START-UP WINDOW 16
2.1 Start-up window buttons and I/O screens 16
2.2 Start-up window: detailed information 17
2.3 SSATT I/O 18
CHAPTER 3: SETTINGS FOR SPATCAT WINDOW 20
3.1 Settings for Camera and Spatcat window buttons and i/o screens 20
CHAPTER 4: DATABASE STATISTICS WINDOW 27
CHAPTER 5: ADVANCED SETTINGS WINDOW 29
5.1 Advanced Settings window buttons and i/o screens 29
CHAPTER 6: TAKE PICTURE AND IDENTIFY STARS WINDOW 33
6.1 Take picture and identify stars window buttons and i/o screens 33
6.2 Reporting 37
6.2.1 Summary file 37
6.2.2 Monte Carlo report 40
3
CHAPTER 7: NOTES 42
CHAPTER 8: TEST RESULTS 43
8.1 Background 43
8.2 Triangle selection algorithm results 45

REFERENCES 48


4
Introduction

Welcome to the SSATT ShareWareVersion!
This manual contains background information on the Delta-Utec Star Sensor Algorithm Test Tool
V1.0 ShareWare SSATT. Additional information is given in the program itself by pointing the
mouse to any specific item. This pop-up information is generally given in the format:

Unit Range Description

SSATT has been performed under the Delta-Utec R&D program 98, as well as under funding by
the Dutch government and ESA/ESTEC.

The purpose of the program is two-fold:
- to help gain insight in the influence of camera parameters on star sensor images
- investigate the influence of various settings on the performance of the Douma and Delta-Utec
Douma Extension star initial recognition, validation and identification algorithms, memory
requirements and computation time.

The Douma algorithm is defined in the thesis work of S.R. Douma
[11]
. A short description of the
algorithm and the changes/additions to it performed under this studies is given in the chapter 1.
This chapter contains some overall background information to help the reader better understand the
following chapters where the pop-up windows of the test tool are explained. In chapter 7 some
additional notes on features of the program are given. Chapter 8 reports some preliminary tests.
5
Chapter 1: Background information

The actual star recognition from a CCD image is performed by extracting a combination of
features (pattern) for each selected star from the observed star positions and magnitudes. We
have restricted ourselves to the triangular pattern, as it is more distinctive than a star pair
[9]
, and
still quite simple.


Fig. 1.1: A triangle pattern plus feature definitions

A feature has to be independent from the camera attitude and can be a magnitude or a great-circle
angular distance between two stars (see Fig. 1.1). The selection of the type of features that is used
is based on a statistical analysis of a star catalogue to yield a uniform pattern distribution of
distinctive features. The triangles that are selected for storage in the database are obtained using a
method based on Douma
[11]
. Douma selects triangles with high likeliness of detection by a camera.
The method was further developed to DUDE (Delta-Utec Douma Extension).

The Star Sensor Algorithm Test Tool SSATT- supports all these characteristics and applies the
QUEST algorithm
[4,6]
to obtain an attitude estimate and investigate performance. With SSATT
whole-sky simulations in large quantities were performed. From these simulations performance
can be compared to principles of Liebe and Quine and results published by Van Bezooijen.

1.1 Development of On-board Database for Triangle recognition

The key part of the autonomous star sensor S/W is the on-board database and its structure to
facilitate efficient search. The database has to be created on-ground by the following steps, that are
automated in SSATT:

- Conversion of star magnitudes from catalogued visual value to instrumental magnitude;
- Calculation of triangles to be stored;
- Selection and uniformization of triangle features for storage.

1.1.1 Conversion of star magnitudes and Star Catalogue

A database of stars needs to be produced from the instrumental magnitude of the catalogued stars
1
.
However, the magnitude of stars is catalogued in visual frequency domain. Such a magnitude can
differ up to 2 from the magnitude as observed by the instrument, depending on its optical
characteristics.


1
Star catalogues are available from www.cdsweb.u-strasbg.fr (Bright Star Catalogue) or at low cost from e.g. ESA/ESTEC [Hipparcos]
or NASA [Hubble Guide Star]. This study has considered the Bright Star catalogue.

C
B
A
Base star
6
To model the star camera, of each specific star the amount of energy needs to be known that will
be absorbed and transformed into a readable current by the instruments CCD array. This amount
can be calculated by integrating the convolution between the responsivity of the camera R
instr
()
and the spectral density of the star light as it reaches the instrument, S
at earth
().

A fair estimation of a star spectral density S() (the amount of emitted energy as function of the
wavelength) is given by Plancks law. In this, the shape of the spectrum depends only on the stars
effective temperature T
eff
. The advantage is that T
eff
can be derived from the spectral type/
luminosity class of each star. Both properties can be found in catalogues.

The ideal Planck approximation would be sufficient if energy transportation through space were
unhindered. In reality however, clouds of interstellar dust can absorb and scatter a fair amount of
the starlight before it enters the optical head of a star camera near the Earth. The combined effect
of absorption and scattering on radiation transport is known as extinction. Radiation on the blue
side of the spectral density (having smaller wavelengths) is dimmed more than that on the red side,
which makes the star appear too reddish and is called reddening. It is difficult to include extinction
into the radiation transport equations analytically
[19]
. However, as empirical methods have shown,
a good approach is to assume a magnitude correction A that would be measured without
interstellar extinction
[20]
:
A cst
eff
=

1 2 .

The effective wavelength
eff
is an instrument property that follows from its responsivity. The
constant is a function of colour indices (B-V) and (B-V)
0
and depends on the amount of extinction.

The step by step instrument magnitude estimation process

1. Find a calibration set of stars for which are available: magnitudes m
cal
, the associated
responsivity curve R
cal
(), colour (B-V) and spectral type [T
eff
and (B-V)
0
].

2. Convert the calibration magnitudes into unreddened values m
cal,unred
through reddening
correction factor A
cal
(R
cal
(), (B-V), (B-V)
0
).

3. Determine the spectral density at the star surface, S
at star
(T
eff
, ) by inserting the effective
temperature T
eff
into Plancks law.

4. A convolution between R
cal
and S
at earth
yields m
cal, unred
(step 2). S
at earth
can thus be derived when
assuming S
at earth
= cst * S
at star


5. Now S
at earth
can be convoluted with the responsivity R
instr
() of the camera to give an estimation
for the unreddened instrument magnitude m
instr, unred
.

6. Add reddening influence to m
instr, unred
that has been subtracted in step 2 with a new correction
factor A
instr
(R
instr
(), (B-V), (B-V)
0
). This step results in the instrument magnitude estimation
m
instr
that was looked for.

(7) Optional step: if the size of the calibration set found in step 1 is not sufficient, it is possible to
plot for all stars available the magnitudes m
instr
against (B-V) and fit trough these points a
suitable polynomial m
instr
= P(B-V). With P, the estimated magnitude can be found for all stars
of known (B-V), although with a somewhat decreased accuracy compared to the original set
[3]
.

7
Step 3 Step 4 Step 5
S
at star
S
at star
S
at earth
R
cal
S
at earth
R
instrument


Fig. 1.2: Visualisation of step 3, 4 and 5

By steps 1-7, the instrumental magnitudes were determined for the catalogued stars. Stars weaker
than the instrumental magnitude threshold plus 3 sigma are unlikely to be observed by the camera.
Such stars are filtered out of the catalogue. The error in above magnitude estimation is an
important source of uncertainty of the star magnitude during the recognition process. For SSATT
the optional step is used to determine the instrumental magnitudes.


Fig. 1.3 Step 7: Polynomial description of B-V (x) dependent Mi-Mv (y)


1.1.2 Calculation of triangles

There are various ways to select a triangle belonging to a star. Quine and Liebe are algorithms
without a need for a priori attitude knowledge and formed the basis for Douma. DUDE is a further
extension of Douma:

Quine triangle: selects the brightest two stars within a certain radius from the base star
[10]
.

Liebe triangle: stores all conceivable triangles that could be used for identification of the brightest
stars in the sky in the database. When an image is taken, each base star in the picture and its two
closest neighbors form a triangle that is looked up in the database
[1]
.
y = -0.1432x
2
- 0.476x - 0.066
R
2
= 0.8563
-3
-2.5
-2
-1.5
-1
-0.5
0
0.5
-0.5 0 0.5 1 1.5 2
Series1
Poly. (Series1)
8

Douma triangle: Douma
[11]
extracts the same Liebe triangles of closest neighbors from a sensor
image, but has stored only the 'most likely' one for each base star. The objective is to save
considerable data and calculation time while limiting the loss in reliability.
Douma follows the philosophy from Quine that a single stored triangle per star should be
sufficient, in case plenty of stars are expected in each picture. From the estimated instrumental star
magnitude for each star the probability is calculated that it is bright enough to be observed by the
camera. The Liebe triangle with the highest probability is selected for the database.

DUDE triangle: This extended Douma algorithm closes the gap between Liebe and Douma and
adds a number of refinements and additional features:

DUDE uses probability offsets to accept or reject a triangle. Triangles that have too low a
probability are rejected. Furthermore, a triangle that is maybe not the most likely one, but has a
probability greater than the acceptance offset is added to the database: a single star can now have a
(controlled) number of triangles for identification.

DUDE takes into account the effect of the relative positions of the neighboring stars and the
limited size of the Field Of View (FOV). These dependencies have an impact on the triangle
probabilities not considered by Douma or Liebe. (Not included in V1.0 delivery).

DUDE includes magnitude buffer for improved rate performance: only the brightest stars in the
catalogue are used.

Example of the different triangle selection algorithms
The next example illustrates the differences in the triangles selected by each algorithm.

Fig. 1.4 Distinctive example for different triangle algorithms: stars in the rectangular FOV of a camera.
Star 2 is out of the image. Star 0 is discussed as base star. Size indicates relative brightness.

Star Magnitude
(TH=5.5, o=0.12)
(Liebe)
Probability
for observability
(Douma)
0 5.35 0.6
1 6.1: too weak 0.0
2 5.0: observed for certain 1.0
3 5.45 0.8
4 3.8: observed for certain 1.0
5 5.46 0.8
6 2.4: observed for certain 1.0
Table 1.1: List of stars used in example, ordered in increasing distance to star 0

0
1
2
3
4
5
6
9
Quine: Quine will search for the brightest 2 stars between the donut around base star 0. The
selected triangle will therefore be:
A
Quine
= 0
6
4


Liebe: All possible triangles that can be made with stars 0 and 1,2,3 and 4 will be stored,
considering that star 1 cannot be detected, and star 2 and 4 will be seen for sure ('certain' stars).
Stop condition for the list of possible first neighbors is the first certain neighbor in the list (star
with a magnitude brighter than the threshold minus 3o): star 2. The same condition is used to end
the list of possible second neighbors: star 3 and star 4. In this example Liebe will yield a total of 2.
For each of these, 18 conceivable possible geometrical descriptions are stored, taking into account
different combinations of measurement errors. Thus:
A
Liebe,1-18
= 0
3
2
; A
Liebe,19-36
= 0
4
2
.
Typically ~180
[7]
triangles per star are stored.

Douma: Douma selects the most likely Liebe candidate. In the above example, the Douma
probability of the 2 possible Liebe triangles is calculated as follows:
12 . 0 ] 4 [ ]. 3 [ ] 2 [ ] 1 [ ] 0 [ ]
4
2
0 , [
48 . 0 ] 3 [ ] 2 [ ] 1 [ ] 0 [ ]
3
2
0 , [
= = A
= = A
P P P P P P
P P P P P

It can easily be seen that all other possible triangles have probability 0 and do not have to be
considered. The 'most likely' triangle stored in the database according to Douma is:
A
Douma
= 0
3
2


N.B. in
[11]
it is proposed to find above Douma triangles by following the trail (going from
neighbor to neighbor in direction of increasing distance) and pick the first two stars with chance
higher than 50%. However, this is not correct. The correct way is to calculate the probability of
any possible triangle, and pik the highest. In searching through all combinations the way to save
time is to use a good stopping condition: e.g. it does not make sense to look for triangles beyond
star 4 in above image. Good stopping conditions have been derived and are described in the
SSATT code delivered with this manual (CamTool.Button1Click.MLTriangle).

DUDE: Both the Liebe and Douma triangles as described above are determined independently of
the FOV of the camera. In reality, very large triangles, even though made up out of very bright
('likely') stars, have a smaller chance of being in the FOV -given their base star in FOV- than very
small triangles. Triangle 0
4
3
could occur more often than triangle 0
3
2
, even though 0
3
2
was
previously determined 'most likely'. There is a complex relation between the triangle size, the
Douma probability and the actual probability that all stars in the triangle are both in FOV and
detected.
The refinement introduces a dependency of the relative angular distances between the stars.
Triangle 0
4
3
was given likeliness 0 using above calculation, but is in fact quite well imaginable
and may even be the most frequent triangle occurring - and would then be selected by DUDE. The
dependency in this case is, that if 4 is in FOV, 2 may very well not be in FOV, and 3 is likely to be
in FOV, together with a rather high probability to be observed by the camera. In general, likeliness
10
of triangles with a distant neighbors and an angle between them close to 180 degrees is severely
reduced (Fig. 1.6).


Fig. 1.5 Graph Correlation vs B


Fig. 1.6 Triangles in Orion according to Quine (left) and Liebe/Douma/DUDE (right). Lighter stars have
been successfully identified.

The effect was quantified and implemented by the S/W developed. It turns out that ~10% of the
triangles differ from that of Douma.

1.1.3 Uniformization of the triangle set

When the triangles have been determined, they need to be stored in a database, in such a way that
they can easily be retrieved.
A logarithmic feature search in case of 4096 entries (=2
12
) would have to compare 12 values before
a target is found, and it can only treat one feature at the time. Using a tiled star catalogue and
rejecting the irrelevant part of the sky could counter these disadvantages, but requires a priori
knowledge of the attitude.
The DUDE method for data storage is to use a pointer array. The range of the feature, say A, is
divided in a number of parts, each part corresponding to a position in a pointer array that holds a
pointer into a candidate array of pointer lines, of which the entries point into the datalines of all
candidates in yet another file (Fig. 1.5).


11

Fig. 1.7: 1D Pointer based data storage



Fig. 1.8: Candidates are drawn from array elements corresponding to feature measurement error
range.

A candidate is searched for within the expected error range from the measured value, as in Fig. 1.6.
It can be shown that the smallest number of candidates that will have to be investigated is achieved
when the size of the pointer array parts is equal to the size of the search range. This pointer array is
called maximally fine array of ~1500 elements, which is rather much. However, the distribution of
the A values and of the triangle features in general is not homogenous (Fig. 1.7). The pointer array
element ranges can be sized by an estimator function such that the distribution is uniformized and
thus data entropy is maximized. A uniform distribution guarantees minimal memory and
processing effort for selection of the right candidate. The described process is called
uniformization of the database.

Increasing A
0: 0
3: 2
2: 0
1: 1
0: No triangle
3: 12,14,98
2: 1
1: 4,5
1: lon = 80.0; lat = 123
4: lon = 9; lat = 238
3: lon = -12; lat = 37
2: lon = 65.7; lat = 340
Pointer array
Candidate array
Data File
Increasing A
0: 0
3: 2
2: 0
1: 1
Measured value for
A
A-3o search range
A+3o search range
Distribution distance to 1st neighbor
0
50
100
150
200
250
300
0 1.206 2.412 3.618 4.824 6.03
Distance [deg]
N
u
m
b
e
r
o
f
S
t
a
r
s
12

Fig. 1.9: Triangle feature distribution: A & B including analytical approximation

We define uniformity by the average number of candidates per array element as a fraction of the
statistically expected array element size when selecting an arbitrary triangle from the complete set.
In formula (1.1):

=
stars of number elements array in candidates rival
elements array in candidates rival
Uniformity
_ _ ) _ _ _ _ (
) _ _ _ _ (
2
2


1 2 4 5 5 4 2 1

Number of candidates in a non-uniformized pointer array pointer array

3 3 3 3 3 3 3 3
A uniformized pointer array

Fig. 1.10: uniformization of data in array by adjusting array element ranges

The pointer array can also be 2 or 3 dimensional, with e.g. feature B in the second dimension etc.
A rough trade-off yielded minimum storage for a 2D array, although a 3D array could also be
favored as it will save some validation effort
[13]
.


Fig. 1.11: Uniformized triangle distribution of A.

Figure 1.10 shows the contents of the 2D pointer array, in terms of number of appointed candidate
triangles per array element, between various features. Correlation is shown before and after
uniformization. The most uniform distribution of features is vs. B.

Distribution distance to 2nd neighbor
0
50
100
150
200
250
300
0 1.206 2.412 3.618 4.824 6.03
Distance [deg]
N
u
m
b
e
r

o
f

S
t
a
r
s
Distribution of distance to 1st neighbor after uniformization
0
10
20
30
40
50
60
70
80
0 6.03
Uniformized distance scale
N
u
m
b
e
r

o
f

S
t
a
r
s
13

Fig 1.12a: Correlation A vs B. Fig 1.12b: correlation C vs. A



Fig 1.12c: Correlation vs. C Fig 1.12d: Correlation vs. B

Fig 1.12: Correlation of features (Vertical vs. Horizontal), left without uniformization, right after
uniformization.

1.2 Image processing, Star identification and Attitude determination algorithms

In this paragraph, some further algorithms are discussed. They are the on-board algorithms that
process a list of star co-ordinates in the camera frame, output of the camera's image centroiding,
into an attitude estimate. Also the apparent multiple star or star group model is discussed.

1.2.1 Centroiding and image simulation

The SSATT simulates the outcome of a centroiding algorithm of a camera, based on statistical
magnitude and position disturbance models.
A more refined method is to simulate an image at a pixel level, including noise, defocus etc. and
adding a centroiding algorithm that delivers its output to SSATT. The overall characteristics of
such a model as implemented by Oude-Lansink
2

[18]
:


2
B-V vs magnitude polynomial used to determine instrument magnitudes (step 7 in 2.1). The total number of created photoelectrons
depends on this magnitude and on the integration time.
14
- Lens properties: focal length, F/no, a rough model for chromatic aberrations, vignetting,
transmissivity (included in the overall instrument response);

- Exponential energy distribution: the standard deviation depends on the amount of defocusing
and the volume is defined by the total amount of photoelectrons produced by the stars
incoming energy. In the TPD-like model, most of the energy is spread over 4 pixels.

- CCD elements included in the model: array dimensions, number of pixels, size of pixels,
integration time;

- CCD noise sources: dark current, photo-response non-uniformity (PRNU), fixed pattern noise
(FPN), floor noise, photon shot noise, bad pixels;

- Detection module: stars below a certain threshold are not detected. A linear combination of the
average pixel energy over the complete array and the standard deviation of the noise is
considered. If there is more noise, the threshold is higher;

- Centroiding done by computation of the center of gravity in a fixed area of e.g. 3x3 pixels
around the star image.


From these models and
[15]
the 1o error in star position on the screen has been chosen to be 12
arcsec for the tests in this paper.
stars in FOV
0 2 4 6 8 10
1
2
3
4
5
6
7
8
9
10

Fig 1.13: Energy distribution over pixel array including noise

1.2.2 Apparent multiples model

For a typical camera with deliberately defocussed star images with angular size of ~0.1 of arc, 5-
10% of the stars is apparently clustered in indistinguishable groups. Of these groups, ~95% are star
couples. As a camera cannot distinguish between them, also the database should take them into
account as single stars, with averaged position and combined magnitude. In case two overlapping
stars are both brighter than the detection threshold of the camera, they jointly determine the
location that a centroiding algorithm will yield, by a first moment like for a center of gravity, but
in this case one of light intensity. In case one star of a couple is weaker than the camera threshold,
0
2
4
6
8
10
0
2
4
6
8
10
0
0.5
1
1.5
2
x 10
4
x-pixel
Istar = 1 mag
y-pixel
e l e c t r o n s s t o r e d
0
2
4
6
8
10
0
2
4
6
8
10
0
0.5
1
1.5
2
x 10
4
x-pixel
Istar = 1 mag
y-pixel
e l e c t r o n s s t o r e d
15
its overlap does contribute to the brightness of the brighter one, but hardly affects its position (no
adjoining pixels will be taken into account during centroiding), see the below schematic image.



Grouping is performed from the catalogue data to build up the on-board triangle database.
Independently, it is also done to reconstruct the appearance on a SSATT simulated CCD image.

Apparent doubles are taken into account as realistically as possible, considering the generalistic
approach of SSATT.
In case of groups of more than two stars, the first two stars are treated as a couple first, then the
next is added to form a new couple etc. etc. Weak stars below a certain user defined offset are not
taken into account at all and can thus break up of a chain of close stars in several multiple groups.
In reality, groups of more than two visible stars are rare. In perhaps a handful of these cases the
multiple model can be expected to create groups with position and/or magnitude that are less
realistic than the pairs, but still quite indicative.

1.2.3 Identification & validation

A triangle is taken from the centroiding information by a 'spiral' algorithm, in terms of base star
and neighboring star positions. The descriptive features of the triangle are calculated. The pointer
array is now used to find the triangle candidates whose features fit within the estimated error
range. Then, the candidate triangles pass through the prevalidation: a user defined filter that is a
comparison to a third or further feature. Validation is performed afterwards. The different methods
implemented in SSATT are mentioned in Chapter 6.

1.2.4 Attitude determination

The performance of the algorithms is assessed by achieved attitude accuracy following from the
QUEST (Quaternion Estimator) method
[4,6]
.


Noise
level
Resulting
position and
brightness
Members
of star
group
16
Chapter 2: Test Tool Start-Up window

The first window that appears is the Test Tool Start-Up window.


Fig. 2.1: Test tool start-up window

The purpose of this window is to transfer the input star catalogue (see Input Catalogue) to a format
that can be easily accessed during the user activities in the SpatCat Settings and the TakePicture
windows. The program prepares files that will be used for image and SpatCat generation and will
minimize the time for investigations of different camera settings, SpatCat properties and
validations.

2.1 Start-up window buttons and I/O screens

The file created on the click of [Transfer Star Catalogue] button is called Neighbors.bin. On a
Pentium 200 it takes 1.5 hour to create an ~12 Mb large file. The filesize is dependent on the
maximum magnitude threshold (user input) and the maximum number of neighbors (system
setting).
The more neighbors are being taken into account for each star, the larger will be the FOV that can
be handled: the image simulation uses a list of neighbors ordered in increasing distance from any
star. Such a list can help to quickly determine which stars are visible in any field of view. The
current setting for the number of neighbors is 450, enough for a 25x25 degree FOV. However, a
larger number of neighbors results in a large file (8 MB) and rather time consuming SPATCAT
production (15 s).
You can request to have this system setting changed.
17

The files produced are valid for a FOV and threshold smaller than the maximum input [Magnitude
Threshold] in the Start-Up window. It is therefore advised that you input maximum values in this
window that encompass all the settings that you envisage to test later on.

There are three parameters for creating the Neighbors.bin file:

Multiple star offset [MaxMultipleStarOffset]: the multiple star offset determines the maximum
distance between two stars in order to treat them as an apparent multiple-star. This distance is
actually a camera parameter. It is the maximum defocus effect or star projection size of a camera
that you think to use, expressed in degrees.
Apparent multiple stars will be grouped as a single star with equivalent magnitude, to simulate the
output of the centroiding algorithm. The SpatCat will be produced with the same assumptions.

[Maximum FOV]: [Deg] determines the maximum guaranteed FOV for an image that can be
created using the Neighbors.bin file; however, if a centering factor > 2 is used in the TakePicture
window [see Chapter 6], FOVs upto 1.5 times this value can be successfully tested.
If you find to many FOV warnings appear during your test, you should use a smaller FOV or you
can contact Delta-Utec to request a setting change in the utility file (at the cost of increased
runtime and program memory).

[Magnitude Threshold]: determines the faintest stars that will be transferred to Neighbors.bin file.

N.B. It is recommended to make a back-up of the Neighbors.bin files, so it is not accidentally
overwritten by a new run.

If the Neighbors.bin file already exists one can directly proceed to the next window by a click of
the [Continue to Settings] button.

2.2 Start-up window: detailed information

Input catalogue

The SSATT needs data on the stars, magnitudes, spectral information and of course, sky position.
The source of this data can be any star catalogue. Different catalogues have different formats.
However, the file that the SSATT actually uses as input is of a standard SSATT format. This file is
called InputCatalogue.txt. Such an input file has been delivered to you with together with the
SSATT software. It is based on the Bright Star Catalogue (BSC). It contains 9096 stars and is
complete upto visual magnitude 6.5.
You can simply produce your own input file based on any other star catalogue. However, the
maximum number of stars is now set by code to the same value of 9096. You can request to have
this setting changed.
If you want to produce your own input file, you will have to process the star catalogue of your
choice in a spreadsheet like Excel, to make it fit the standard format for SSATT. The file
InputCatalogue.txt has the following column description:





18
Star number: For backtrack reference. New ID numbers will be assigned that are used
throughout the program
Equatorial Longitude: Degrees, 0-360.
Equatorial Latitude: Degrees, sorted from 90 to 90.
Galactic longitude: Not used (For backtrack reference)
Galactic latitude: Not used
Visual Magnitude
B-V color (UBV) Optional but preferred. All spectral class>M need B-V value.
Spectral type Format [ ]-optional, *-any character(s):
[d/g/sg] StarClass(O/B/A/F/G/K/M) [*] Subclass(0-9) [*]

The B-V values are needed to make a good estimate of the instrumental magnitude that is
determined by the properties of the camera that is tested. If you do not give an input, an estimate
will be made of B-V based on the stars spectral class.
Remove lines without magnitude or co-ordinate data. All the blanks left should be filled in with
9999.
If you prefer to use the galactic longitudes i.s.o. equatorial, switch and resort their columns.

2.3 SSATT I/O

An overview of SSATT input and output is given below.

Input SSATT
Data Star Catalogue
Statistical Models
Camera FOV Width/Height
Magnitude Threshold
Integration time
Projected Star Diameter
Centroiding Cut off magnitude threshold
Star position accuracy
Models Apparent Binaries
Rate effect
Magnitude conversion & error
Algorithm
settings
Douma/Liebe triangle rejection/acceptance
offset or Quine
Dbase sorting parameters
Dbase size
Dbase uniformization
Validation options
Edge processing options
Imaging Direction/rotation
Rate
# False stars










19
Output of SSATT
Primary performance Position accuracy
Reliability
Successrate
CPU time
Memory requirement
Statistics star recognition: Stars in FOV
Validation fraction
Ambiguity fraction
Failure fraction
Secondary performance Influence apparent binaries
Error messages
Database statistics Uniformity
Correlation
Other

Codes in the following:

[Ref] For reference
[i] Input
[OB] On-Board file

Input files necessary for executable:
- InputCatalogue.txt See above [i,Ref]
- NormDis.txt Normal distribution (see SSATT code & comment) [i]
- InvNormDis.txt Inverse normal distribution (see SSATT) [i]

Files produced by Start-Up window:
- Mainbase.txt Reduced catalogue for SSATT [Ref,i]
- Neighbors.bin List of each star's neighbors [i]
- CloseNeighbors.bin Candidates for apparent multiples [i]
- CloseNeighbors.txt Idem [Ref]
- MultipleGroups.txt Maximally sized multiple groups [Ref]

Files produced by Settings for SPATCAT window:
- PicDB.txt All stars that could possibly be seen by the camera [Ref]
- SCpointarray.txt 2D Array in which each location represents a combination of 2
triangle properties and is filled with a pointer to a line in
SCstararray [Ref, OB]
- SCstararray.bin Each line contains pointers to SCValidation of each stars that
fulfils the triangle property combination as meant above [OB]
- SCValidation.bin Each line contains the OB information on each star: direction &
validation info [Ref, OB]
- Correlat.txt Looks like StarPointArray, but contains number of SC2Array line
entries in place of each pointer, thus giving a correlation between
occurrence of the two triangle properties [Ref, i]
- Histofile.txt Histograms of triangle properties [Ref, i]

Files produced by Take-Picture window (optional):
- *.sum file Summary file of run [Ref]
- *.mc file Results of processing of all individual images [Ref]
20
Chapter 3: Settings for SpatCat window

In this window the SpatCat (Star PATtern CATalogue) and a validation file are created based on
the selected camera and algorithm settings.
For this, the visual magnitudes are converted to instrumental magnitudes using a quadratic
estimation based on visual magnitude and B-V and or spectral class. The quality of the SpatCat
and its properties can be examined in the statistics window [Database Statistics] [Chapter 4]. A
click on [Disturb Sky] button will add disturbances to the star magnitudes and positions,
depending on camera and S/C rate settings. The TakePicture window will also appear. In this
window one can take sky pictures, change further settings, do a Monte Carlo simulation, identify
the stars and store the investigation data [Chapter 6].


Fig. 3.1: Settings for Camera and SpatCat window

3.1 Settings for Camera and Spatcat window buttons and i/o screens

Buttons:
- [Extra]: opens the advanced settings window [Chapter 5]
- [Make SpatCat]: creates a new SpatCat, validation file and PicDB.txt based on the selected
settings
- [Database Statistics]: opens the statistics window [Chapter 4]
- [Disturb sky]: adds disturbances on the star position and magnitude and opens the take picture
and identify stars window [Chapter 6]. Every time this button is clicked, the sky will be
disturbed again, so alternating this button and the ID button in the TakePicture window, for
a given direction, will produce new results every time.


21
Camera group:
- [FOV width]: camera Field Of View width in degrees
- [FOV height]: camera Field Of View height in degrees
- [FOV]: For information only: camera diagonal Field Of View in degrees (N.B. should be
smaller than MaxFOVSize Start-Up window).
- [Cam TH]: magnitude of faintest star that the selected camera can detect.

CCD read-out group:
- [Magnitude TH]: magnitude of faintest star taken into the SpatCat algorithm and passing the
centroiding algorithm.
- [Sigma Magn]: magnitude accuracy of the visual to instrumental magnitude conversion (1
sigma)
- [Sigma Pos]: position accuracy of the centroiding algorithm (1 sigma) in arcsec for star at
Magnitude TH

SC property 1&2 group:
The Douma algorithm prescribes that each star will be stored in a database by the triangle of the
base star and its two neighbor stars that are most likely to be observed as being the nearest two,
taking into account the stars magnitude and the camera magnitude threshold.
Douma does not prescribe how to store and retrieve the data. For quick retrieval and small memory
size, the Delta-Utec implementation of the Douma algorithm sorts all the triangles into a 2D-array,
each direction of which is equivalent with the value range of one of the features of a star triangle.
This feature can be selected from a series of options. The complete range for a feature (e.g. 0-360
degrees for the angle gamma between the two neighbors) is segmented in a number of elements
that can be input as well.
The actual value for the feature itself is not stored: every observed combination of feature values in
the image is mapped to a certain array element of the SpatCat.

The SpatCat generation will be based on the selection of two out of the following triangle features
/properties (see Fig 1.1):
- Distance A: the angular distance from the base star to its nearest neighbor. See figure.
- Distance B: the angular distance from the base star to its second nearest neighbor. See figure.
- Distance C: the angular distance between the base stars nearest- and second nearest neighbor.
See figure.
- Gamma: the angle between the base stars nearest- and second nearest neighbor. See figure.
- MagnitudeCS: the magnitudes of all three stars, combined into a single short integer: the
Magnitude CheckSum. The purpose of this number is to store efficiently the magnitude data
of all three stars of each triangle. When selected, the magnitude range of the uniformized
magnitude histogram will be divided a small number of groups. The number of groups is
determined from the input #Array Els, according to the formula:
NumberOfMagnitudeGroups = Trunc(
3
\(NumberOfArrayElements))

Or:







22
Input Number of
Array Elements
Actual Number of
Magnitude Groups
Actual Number of
Array Elements
in SpatCat
8-26 2 8
27-63 3 27
64-124 4 64
125-215 5 125
216-342 6 216
343-511 7 343
512-728 8 512

Et cetera. A uniformized distribution is created for the star magnitudes divided over the Actual
Number Of Magnitude Groups. Based on the value of its base stars magnitude, each star triangle
entry is allocated to a certain group.
The Magnitude CheckSum is now determined by regarding the Number of Magnitude Groups as
the base number for calculation and adding the magnitude group numbers of resp. the base star,
neighbor A and neighbor B as a powered sum. If there would be 10 groups, The base star would
be in group 3, A in 2 and B in 1, the CheckSum would be 321, which is 3*10*10 + 2*10 + 1. In
the same way, for only 5 groups with the 3 stars distributed among the same groups, the
CheckSum would become: 3*5*5 + 2*5 + 1 = 86.
The advantage is that a lot of validation data can be stored as a single integer. To have only a few
groups may be sufficient, because the magnitude cannot be determined very accurately anyway (3
sigma ~ 0.5 m). Because of the large range for each of the magnitude groups, the search range for
the Magnitude CheckSum is always 1: only one Magnitude CS value is checked when searching
for a certain triangle, so no adjacent magnitude groups are searched for candidates of a certain
observed triangle.

- Magnitude: the magnitude of the base star.
- MaxMagnitude: the magnitude of the brightest star in the triangle.

Number of array elements screen:
[# Array Els.]: for both property 1 and 2, the number of array elements (respectively rows and
columns) in the SpatCat, can be chosen.

SC 1&2 Uniformization group:
The properties can be uniformized in order to increase the efficiency of the created SpatCat.
Uniform (Uniformity=1) means that there is an equal amount of rival candidates in every array
element [see 1.1.3]. Consequently the array element size gets smaller when the density of rival
candidates increases. A uniform distribution gives a well predictable number of rival candidates
for each observed triangle, so recognition of each triangle will take the same time, on the average
less validation effort is needed and, because the arrays are sized for the maximum number of rivals
in the SpatCat, the O/B memory size can be smaller.

The next four options are available:
- None: the SpatCat matrix element width (property 2 array element size) and the height
(property 1 array element size) are (a different) constant for both properties.
- Analytical: analytical expressions have been derived for this purpose for the uniformization of
distance A and distance B. N.B. C is not implemented.
These expressions are based on the assumption of a random distribution of the stars over the
sky.
23
N(A<A
0
) = N*(1- (0.5*(1+cosA
0
))
N
)
N(B<B
0
) = N*(1- N*(0.5*(1+cosB
0
))
N -1
*0.5*(1- cosB
0
) - (0.5*(1+ cosB
0
))
N
)

- Histograms 1: a histogram of the number of occurrences in the SpatCat triangle set for the
selected property (say A) within small subsequent ranges is used to create a uniform SpatCat.
The target number of rivals per array element is NumberOfStars/NumberOfArrayElements
(perfectly uniform distribution). The algorithm walks through the occurrence histogram from
value = 0 to value = property range and sums up the number of occurrences for each
subsequent small interval. Every step it supposes that the current increase in value of the
property (equivalent to the current total number of occurrences since the last array element)
defines the new array element size. It estimates the uniformity of the distribution yet to come
and determines whether adding the new small interval to the array element size improves the
uniformity. If so, the step interval is added to the array element size, otherwise a determination
of the size of a new array element will be initiated.
- Histograms 2: as Histograms 1, but the estimation is more simple. Every step it is evaluated
whether the added number of occurrences bring the total number of rivals for the current array
element closer or further from the target number of rivals per element. This method works just
as good, but may lead to empty (or extra full) array elements at the end of the array, if the
number of occurrences for each step is a little over (or under) the target number.

In figure 1.9 the triangle feature distribution for A & B are plotted including the analytical
approximation as discussed above

The [Make SpatCat] button creates a 2D SpatCat pointer matrix. This matrix is created to allow
for a fast retrieval of possible candidate stars for each observed triangle. Each SpatCat matrix
element (equivalent to a value interval of both property 1 & 2) points to a location in a file
[SCStararray] containing the rival candidates with similar triangle properties. Suppose we have
processed an image [Chapter 4] and found for property 1 (e.g. distance C) 0.59 and for property 2
(e.g. distance B) 1.24 then X in the below figure would point to the line in SCStararray
containing the rival candidate stars. Depending on the accuracy at which property 1 & 2 can be
determined, pointers to rival candidates of neighbor matrix elements need to be taken into account
as well. In a good SpatCat the number of rival candidates will be minimal for every entry.

Validation [Chapter 1& 6] is needed to subtract the right star from the rival candidates.















24



property 1; property 2

X







Fig. 3.1: 2D SPATCAT pointer matrix


Triangle group:
Four triangle definitions can be selected:
- Douma
- DUDE
- Liebe triangle
- Quine triangle

In Chapter 1 and in Development and Validation of a Fast and Reliable Star Sensor Algorithm
with Reduced Data Base
[21]
, the different star pattern recognition algorithms have been explained.
In SSATT the triangles of the Liebe and Quine algorithm as described above are implemented for
comparison. However, the storage and validation methods are always based on DUDE.
Based on the triangle selection the Offset group will automatically adapt.

Offset group:
- [ProbForReject]: most likely triangles with a probability smaller than the rejection offset will
be rejected for the database.
- [TriangleAccept]: triangles that are not most likely, but with a probability higher than the
triangle acceptance offset will be stored in the SpatCat. DUDE setting. Standard >0.5 for
Douma, equal to ProbForReject for Liebe.
- [MagShift]: Stars brighter than MagShift are handled for the database as stars with a
magnitude of MagShift.
- [MaxMag]: Liebe only. Stars less bright than MaxMag are not considered.
- [QR]: Quine only: Quine radii: inner radius (left), outer radius (right), degrees.


0.5-0.6
1.2-1.25
25
S/C rate settings:
[S/C Rate]: the programs rate simulation is effectuated by introduction of a change in camera
threshold and noise in position and magnitude determination accuracy obtained by the centroiding.
The functions used are indicative only for the sort of dependency that can be expected, as in real
life they will be very dependent on the details of your camera system and centroiding. The
functions and limitations are described in the advanced settings Chapter 5.
The threshold dependency assumes that the the star light is distributed evenly over the star spot
diameter (Extra input) on the CCD image. It assumes that if a pixel occurs of the same light
intensity as the equivalent for the camera threshold, it will invoke recognition by the centroiding
algorithm. The equivalent camera threshold is assuming that the (input) Camera Threshold is
determined from a static image with an integration time as defined in the Extra input.

When the rate setting is changed, no new SpatCat needs to be produced. One can proceed directly
with Disturb Sky.

Information windows
There are 4 information windows:
- Starttime making of SpatCat
- Endtime making of SpatCat
- Number of stars (#) used for SpatCat
- Maximum number (Max) of triangles belonging to a single star occurring in SpatCat

26
Message screen:
- Warning 1: The visual to instrumental magnitude conversion failed.
At least for one star, the starclass description is either of an unknown format or unknown.
The visual magnitude is used.

- Warning 2: Array-size failure - Choose SpatCat more distinctive.
MaxRivals: the maximum number of entries for a single SpatCat location (see Correlation
Graph) is larger than the system maximum. Recognition performance will be degraded.
Choose a more distinctive SpatCat, as your current choice of SpatCat would lead to many
ambiguously recognized slowing down and degrading the identification process. This can be
by choosing more or different property elements, a less sensitive camera threshold or better
uniformization.

- Warning 3: Too many property 1(2) array elements for measurement accuracy.
It makes no sense to force a distribution of the triangles over this number of elements, as it
suggests a better quality of centroiding data than your measurement accuracy allows. The
SpatCat will be automatically adjusted. Recognition quality is not affected, but you are using
more memory space than necessary. Reduce the number of property elements.

- Warning 4: SpatCat not filled optimally, because of property 1(2).
There is empty space in your SpatCat following the uniformization. There is no influence on
recognition quality. You can try to use another uniformization method.

- Error 5: Fatal Array Failure - Sigma Too Small, property 1(2).
The uniformization algorithm uses the sigma pos and sigma magn you input to estimate
the property distribution. If this sigma is too small, arrays will be filled out of boundary. You
cannot continue without adjusting the sigma that probably caused the failure. If the indicated
property is related to magnitude, adjust sigma magn, otherwise adjust sigma pos.

- Warning 6: Internal Setting For MaxB Estimate Too Small
The apparent multiples are only determined around a given star within a radius MaxB, a
conservative estimate for the maximum distance B that will occur. If this warning occurs,
unusually large triangles have been found that may not be quite accurate. However they will
only be inaccurate if they were to contain an apparent multiple as a neighbor outside MaxB.








27
Chapter 4: Database statistics window

In the database statistics window one can look at the statistical data of the SpatCat that was
produced.
One can toggle [Toggle] between two screens:

- The correlation between property 1 and property 2 is plotted in a graph [Fig 4.1]. The graph is
build up from 4 colors: white, yellow, red and purple.The white color represents SpatCat
matrix elements with 1 star candidate only. Yellow between 2 and 3 rival candidates, red
between 4 and 6 and purple for all matrix elements containing more than 6 rival candidates.
The numbers that separate the colors can be changed by the user for better interpretation of the
image. Toggle twice to reactivate.


Fig 4.1: Database statistics window: correlation graph

- The occurrence histograms of the SpatCat properties.

Several histograms show the distribution of the occurrence in value intervals of triangle features
and uniformized SpatCat properties for the current camera and SpatCat settings. The horizontal
axis are intervals of the feature value from 0 to the feature range. The vertical axis is the number of
stars (occurrences) that have a triangle with a feature value that fits in the interval of the horizontal
axis. These graphs are auto-scaled in horizontal direction for optimum comparability. The scale in
vertical direction can be set to any integer value or to the maximum (by typing Max).
The selected properties become visible when the mouse covers one of the Property select groups.








28
The histogram result panel shows (column 1 graph 1, column 2 graph 2):
- Uniformity: the uniformity of the SpatCat property, see formula 1.1 = Mean/Exp. Cand
- Exp. Cand.: the expected number of rival candidates per array element
- Mean: the average number of rival candidates over all array elements
- Max # stars: the maximum number of rivals in an array element
- # Groups: the total number of array elements for the property
- Hor. range: the horizontal graph range for the selected property. (Hor. Range/# groups)
gives the range of one array element.
- Average: the average feature value


Fig 4.2: Database statistics window: histograms


29
Chapter 5: Advanced Settings window

The advanced settings window was designed to give the user additional flexibility to change
models used in the SSATT coding.


Figure 5.1: Advanced Settings window

5.1 Advanced Settings window buttons and i/o screens

Magnitude Conversion Function Group:
The instrumental magnitude is approximated by a function of spectral response of the camera,
visual magnitude of the star, the stars (B-V) and its spectral class.
If B-V is known, the instrumental magnitude will be estimated as being quadratically dependent on
(B-V). The estimation is based on the specific camera settings specified in a,b,c. If the stars (B-V)
is larger than the input value B-V, the stars instrumental magnitude will no longer be estimated by
the quadratic function described by a, b, c, but will be estimated by the stars visual magnitude plus
the input value mc-mv. This has been found to be a better approximation, see figure 1.3.

If (B-V) data of a star is missing, it will be estimated by (B-V)
0
that is based on the stars spectral
class
[11]
.

Your change will have effect only if you click Make SpatCat.

B-V Estimation Function From Star Class group:
When in a database no data is available on a stars (B-V), SSATT estimates the (B-V)
0
by a 2
nd

order polynominal function:
c SC b SC a V B
Estimated
+ + = . . ) (
2

30
With a,b,c the input values for the star types Main, Dwarf, Giant, Super Giant. SC is an increasing
number based on the stars subclasses (A0, A2 - A9, etc.). Starting at 0 with O0 and increasing with
decreasing temperature (OBAFGKM, (O Be A Fine Girl Kiss Me)). E.g. B1=11, A5=25 etc.
The reddening effect of the interstellar gas is (for these (B-V)
0
estimations) thus not taken into
account.

If both B-V and spectral class are missing warning 1 appears and the magnitude remains
unchanged.

Your change will have effect only if you click Make SpatCat.

Success group:
These two variables are used in the definition of the success as given by the program in the *.sum
report (see Chapter 6). If the attitude determined by the QUEST algorithm is better than defined by
the following statement, the identification is considered successful:

AttitudeReconError<Factor*FileSigmaRange*SigmaPosition*180/pi*3600*exp(Power*Rate)))

After changing this value you can immediately click ID again, if you wish.

#MCS group:
Number of magnitude array elements for prevalidation using Magnitude CheckSum (see Chapter
7).
N.B. Press [Make SpatCat] button after changing #MCS!

Statistics group:
To allow the user selecting a particular kind of stochastic distribution for the probability that a star
will be detected as a function of its deviation of median magnitude (a stars estimated instrumental
magnitude). SSATT reads the chance distributions from files. By default SSATT uses a normal
distribution as delivered in the files NormDis.txt and InvNormDis.txt. These are automatically
active when you start the program. Add your own files in the SSATT directory, change the names
and sizes in this group and click Continue to Settings & Make SpatCat.

StatFile1 has stored (the left screen) Size values. The first value should be equivalent to a zero %
probability, the last value 100%, the intermediate values are linearly interpolated. The value itself
should be consistent with the description:
For the given distribution, it can be said with the probability (LineNumber-1)/NumberOfLines that
the deviation from a stars estimated instrumental magnitude is smaller than (value at
LineNumber)*o
magn


StatFile2 has stored (the right screen) Size values containing the inverse of StatFile1. The first
element should be 0 and equivalent to a deviation of -Error Range*o
magn
. The last value should be
1 (=100%) and equivalent with a deviation of +Error Range*o
magn
.

Monte Carlo Statistics group:
When one has selected that the SSATT program creates a report of the Monte Carlo simulation
[Chapter 6], the user can include/exclude images in/from statistical processing by selecting any of
the next four special cases:


31
- Also if warning Normally warnings (except No star in FOV) are excluded. If this
option is selected, and an image fits the other requirements, it
will be taken into account (e.g. when many images have
incomplete FOV, but enough stars for attitude determination.
- No multiples Include images in which there are no multiples
- Binaries Include images in which there are one or more binary star groups,
but no groups containing more than 2 stars. This option is
available because the binary groups are modeled better than the
rare larger multiples.
- All other multiples Include images with one (or more) groups containing more than
2 stars.

The selection gives the user the flexibility to do statistical analyses focussed on or less dependent
of e.g. the modelling of the multiples [Chapter 1].

After changing this value you can immediately click ID again, if you wish.

Multiple Centroiding Model group:
As the star images are defocussed, 5-10% of the stars is apparently clustered in indistinguishable
groups. Of these groups, ~95% are star couples. The camera cant distinguish between them and
also the database should take them into account as single stars, with averaged position and
combined magnitude [Chapter 1].

FaintOffset: Stars brighter than the magnitude threshold plus the faint offset are considered for
grouping.
StarSize: SSATT does not work with true pixels, as it has no centroiding algorithm included yet.
The starlight intensity surface (see 1.13a) is therefore modeled as a perfect cylinder with a
diameter starsize in degrees. A good value, depending on the lens defocus, is about 1.5 equivalent
pixel size. This model is used to determine overlap between stars, as well as to determine the
spreading of the light intensity in the presence of a camera rate.
RecogDist: The model assumes that if the distance between two stars is larger than the
RecogDist*StarSize, the camera is able to distinguish a group from a single star. This can be used
for validation purpose or exclusion of unreliable star IDs for the QUEST algorithm.

In the SC and Attitude Algorithm subgroup one can select whether one wants to include multiples
that have been identified for the attitude determination algorithm or avoid them:

- Include multiples
As apparent multiple stars will have a larger uncertainty, not selecting them will increase the
attitude estimation. However in case the image doesnt contain many single stars (e.g. small FOV)
one could still prefer to include the multiples when determining the attitude. If Critic#ValStars or
more single stars have been identified the attitude algorithm will not use the multiples for its
attitude determination. If less then Critic#ValStars singles have been identified in the image, the
identified multiples will be taken into account by QUEST.

- Avoid multiples
If this option is selected, there will be no multiples in the SpatCat. However, the image will still
contain all multiples that the centroiding algorithm cannot recognize (see RecogDist). Only the
groups large enough to be discovered by the centroiding can be avoided for further image
processing.
32

Rate Error Estimation Functions:
The position and magnitude sigma rate dependency functions are interpolations of the tables
referred to by Douma
[11]
.

Defined are:
R: rate [deg/s]
m: the stars visual magnitude
T_I: IntTime: the image integration time in seconds.
D: StarSize: star diameter on image [degrees]
AT: algorithm magnitude threshold
a,b,c,d,f,g: parameters
OBRate: on board rate knowledge as a fraction of the true rate of the spacecraft,
used for the image processing.

The model used for calculating the effect of the spacecraft rate is:

omagn_noise = (a.R
2
+ b.R + c) * e
d*m


omagnitude = (o
2
magn_noise + o
2
magn conversion)

oposition = oposition static /e
f*m_AT
* e
f*m
* e
(g*R)


Atfor rate = ATno rate + 2.5 log (D/R/T_I) [if D/R<T_I]


Assumptions for the rate calculation.

- Magnitude Error Offset is known from calibration and eliminated by centroiding algorithm.
- The influence of the integration time on the centroiding accuracy is negligible and only affects
the threshold. (Data from
[11]
based on 0.2 sec integration time).
- No blooming of the CCD pixels. Performance therefore does not degrade for long integration
time of bright stars, as is sometimes seen in reality.
- No dependency of the magnitude error on the spectral class (influence for K & M in order of
o
magnitude
)
- Total error in position can be considered Gaussian and homogeneous in FOV
[11]
.
- There is no sudden increase in error close to the threshold at high rates as this is considered a
very camera dependent effect. For a very small portion of the users range this could effect a
factor in the error of 2-3.


Function ID Codes in Summary File
The B-V model (B-V Est), magnitude conversion (MagnConv) and the rate model (Rate Error) are
models with many variables that you will only want to change per set. These variables are not
stored in the summary file. If you do want to use different variable sets, it is advisable to make
each of your sets identifiable with an integer code, that you can input here. These codes will be
printed in the summary report and will allow you to trace back exactly which parameter set you
were using for which investigation.

33
Chapter 6: Take picture and identify stars window


Fig. 6.1: Take picture and identify stars window

In this window the image processing is performed and the attitude is determined. It features several
statistical reporting possibilities.

6.1 Take picture and identify stars window buttons and i/o screens

The direction to which the camera is pointing can be manually input by:
- Celestial longitude [deg]
- Celestial latitude JD2000 ECE [deg]
- Rotation w.r.t. North Pole [deg] (clockwise looking ON celestial sphere)

In case that the Choose Random Direction checkbox is checked, the computer picks a random
direction and rotation for the camera. The number of simulations is on default at 1 and can be set at
any value. A hint pops up showing the minimum number of random simulations needed to do one
full sky test. For multiple simulations without display, the average results will be displayed (6.2).

Display options:
- Display image processing: displays the search strategy for every stars first two neighbors. An
example of the image processing is given in figure 6.2. The picture is build up by colored
spirals around the base star, searching for its neighbors. White and yellow are used to indicate
base stars and neighbors respectively. By decreasing grid density the spiral will be more
refined and slow down as well, giving a better idea of whats happening.
34

Figure 6.2: Image processing screen

- Display triangles: displays the triangles found by the image processing, see figure 6.1.

The stars are displayed as yellow spots in the image, they are scaled based on magnitude.

Centering scrollbar:
The centering factor [1-20] is a factor that determines the location of the first star in the field of
view that is selected for the image production and processing. The subsequent stars are organized
by increasing distance to the first star. The image production time increases with an increasing
factor, but there is no influence on the identification time. A factor of 1 will find the first star in
field of view at the edge, a factor of 20 closely in the center of the image. For a FOV close to the
maximum value it is recommended to set the factor to at least 3. This ascertains that the opposite
picture edges are filled with stars.

The first star in the field of view is displayed as a blue spot in the image.

Number of False Stars scrollbar:
One can introduce randomly placed false stars with a magnitude chosen randomly between 0 and
the magnitude threshold according to the following function:

Magnitude False Star:= MagnThreshold*(1-RANDOM
10
)

The false stars will be processed as stars to be recognized. They are displayed as purple spots in
the image.

Grid density
For identifying the triangles, the image screen will be divided by a grid. A triangle will be found
for any star by spiraling out through the grid starting from that star, looking for neighbors. The grid
density determines on the average how many stars each grid square will contain. A large grid
density will save memory space, but will cause many stars to be investigated as candidates for
being one of the stars nearest neighbors. A very small density will minimize the stars to be
investigated for being a neighbor star, but will have a big penalty for memory and (largely empty)
grid construction time. Realistic grid densities are in the range between 0.04 and 4.

Search range scrollbars
For both property 1 & 2 there is a SR scrollbar defining the error range (in o [e.g. sigma pos or
sigma magn]) within which, for each property, the database (pointer array) is searched for when
35
looking for candidate stars. In chapter 1 and figure 1.6 this search method is explained in more
detail.

Edge Processing group:
Stars at the edge of the image have a smaller chance of being identified correctly as there is a
reasonable chance that one of its direct neighbors is not in the image.
Therefore the tool has three options for the processing of the edge of the image:

- No edge: all stars in the image are processed.
- Process edge: all stars are processed, a star will only be used for identification if its second
nearest neighbor is closer than the edge or closer than the edge offset.
- Edge Offset: the stars within the edge offset from the image edge are not being processed. The
edge offset is depicted in the image.

Memory group:
An order of magnitude estimation is given on the resources needed for the selected algorithm and
its validation.
RAM: the memory that needs to be available for identification and validation
FastRef: the memory can be determined making different assumptions (see code), if FastRef is
selected, the memory is determined while optimizing the array layout for calculation speed, if not,
the on-board array layout is assumed to be optimized for memory.
N.B.: FastRef has no influence on the identification process, but only on the memory estimate.

Prevalidation group:
A validation is needed to select the right star from the rival candidates. A simple validation can be
performed on a combination of the following features: Distance A, Distance B, Distance C,
Gamma, Magnitude, MaxMagnitude, MagnitudeCS, AllMagnitudes. Each candidates observed
features are checked for being within 3.1 sigma from the catalogued value.
It is of little use to select a property 1 or 2 feature for validation as the rival candidates are selected
via these features. When AllMagnitudes is selected, Magnitude, MaxMagnitude and MagnitudeCS
are automatically deselected as this would mean a redundant validation.

Validation group:
There are five validation routines that can be switched on or off by the user. Method 1 & 4 require
extra storage, but very little computational effort.

1. Double: Initial validation through doubles
This validation is added to minimize number crunching. When a candidate is found for a base star
(in a direct manner from its own triangle), the candidate's neighbors can be regarded as indirect
candidates for the on-screen neighbors of the base star. If there are two or more identical
candidates for a single star, of either direct and/or indirect origin, by this routine this star will be
validated.

2. DistInit: Initial validation through distance consistency
Two stars in the screen are selected, and the distance between them is compared to the distance
between the candidates' coordinates from the database, until two candidates are found of which the
distance matches within the expected error range. The couple is validated.

3. DistCont: Continued validation through distance consistency
36
If at least one star is validated, other star's candidates can be compared directly to this star's for a
consistency check of the angular distance between them, as in method 2, but less alternatives have
to be processed.

4. Snowball: Snowball validation.
This recursive validation is added to minimize number crunching. If a star is validated being one of
its direct candidates, its neighbors can directly be identified (and thus validated) as being the stored
neighbors of that direct candidate. This process can continue as a snowball growing when rolling
downhill, so computation time is saved and a larger number of stars can be identified than with e.g.
DitsIni/DistCont only.

5. Indirect:
When validation through distance consistency is selected, it validates direct candidates. With this
option also indirect candidates will be validated, meaningful if no direct candidates are present.

[Identify image button]
This button starts the processing of the selected number of pictures.

Stars In Image screen: all stars that are in the image are listed in this screen together with their
SSATT number and position in the image (center = 0,0). In case a star is correctly recognized it is
checkmarked. The final two digit code has the following meaning:

Digit 1: size of star group
0: not an apparent multiple.
1: part of an apparent multiple, but the other stars are very weak.
2: star group of 2.
3: star group of 3
etc.
Digit 2: recognizable bit
0: multiple cannot be distinguished from single star
1: multiple is large enough to be distinguished from single star

Simulation results group:
- Acc: The accuracy of the reconstructed attitude w.r.t. boresight direction. Only longitude and
lattitude are considered. The rotational accuracy is generally an order of magnitude less
accurate. (Needs several cameras).
- Time: time for identification. This value is not very accurate for a single identification (No
QUEST). Look at the average of a Monte Carlo series for a good indication. The time indicates
the time that your computer needs. This value is influenced by your systems processing speed,
other programs being run in parallel (like Windows 95) and by your file access speed. The
CPU time is affected somewhat negatively w.r.t. flight S/W by processing that needs to be
performed because of the general purpose application of SSATT.
- Successfully recognized: reports the number of successfully recognized stars-to-be-recognized
in the image. In case of multiple random simulations the average fraction is given.
Successfully recognized stars to be recognized are displayed as green spots in the stars to be
recognized.
- NVa: Reports the numbers of stars that have been recognized by the recognition algorithm and
are not ambiguous, but have not been validated. They are pink. In case of multiple random
simulations the average fraction is given.
37
- Ambiguously recognized: reports the number of stars-to-be-recognized in the image that were
not uniquely identified, i.e. that still have rival candidates after validation. In case of multiple
random simulations the average fraction is given. Ambiguously recognized stars to be
recognized are displayed as orange spots in the stars to be recognized.
- NRe: Not recognized: reports the number of stars-to-be-recognized in the image that have not
been not recognized, because the processed triangle properties didnt match the SpatCat
triangle properties. In case of multiple random simulations the average fraction is given.
- Falsely recognized: reports the number of stars to be recognized in the image that have been
uniquely, but falsely recognized. In case of multiple random simulations the average fraction is
given. Such false recognitions will lead to decreased attitude determination performance.
Falsely recognized stars-to-be-recognized are displayed as red spots in the stars-to-be-
recognized.

Error and warning screen:

Warning 10: No Star Found in FOV.
Use a larger FOV, more sensitive camera or lower S/C rate.
Warning 11: Array Error. Lower Grid Density
Current grid density causes too many stars to end up within a single image grid
square, causing array overflow. Performance will decrease.
Warning 12: Array Error. Raise Grid Density.
Current grid density combined with the number of stars in the FOV commands too
small an image processing grid that would cause array overflow. It is
automatically set to the smallest possible value. There is no influence on
performance.
Warning 13: FOV incomplete. Raise Centering
There are too little stars in the FOV. This is caused by the method SSATT builds
up its pictures. The center star is selected and the FOV is filled with its 450 closest
neighbors. In case of a large FOV and the center star not being centered, it could
occur that the image is incomplete at the edge. By raising the centering this can be
solved. If the warning still occurs, the user should contact Delta-Utec to see
whether more neighbors can be incorporated for building up the image.
Warning 14: Array Error. Too many recognitions.
More than 150 stars have been identified and validated. The system settings are
such that the QUEST algorithm cannot take more input. QUEST automatically
limits itself to 150 inputs. Performance is (slightly) degraded.

6.2 Reporting
Two types of report can be produced, the summary file of a Monte-Carlo simulation and an
extended file of the full Monte-Carlo simulation. This paragraphs shows the content of these
reports:

6.2.1 Summary file
The summary file start with a list of the selections made by the user for the Monte-Carlo
simulation (see for definitions also 3.1). The contents of the summary file is printed in Courier,
additional comments for explanatory purposes is given in italic Roman.
38
Definitions of terms used:

Success (~probability): the number of successful attitude determinations as a fraction of the total
number of images taken during a Monte Carlo whole-sky simulation.

Successful Identification: the number of correctly identified stars as a fraction of the total number
of stars that were imaged during a Monte Carlo whole-sky simulation.

Reliability: the number of successful attitude determinations as a fraction of the number of images
that have yielded an attitude estimate.

**************************************************************************

Summary of 100 RANDOM sky simulations started at 10/14/98 3:27:53 PM

CAMERA SETTINGS
Camera FOV : width x height Diagonal : in deg
Sigma Magn : 1 sigma magnitude
Sigma Pos : sigma position in arcsec
Algor. TH : threshold used for algorithm
Camera TH : camera threshold

ALGORITHM : name
AccTH : acceptance threshold (probability)
MaxMag : maximum magnitude for Liebe
QRIO : Quine radii: inner & outer, degrees

OFFSETS
StarDiameter : deg
Rejection :
MagShift : magnitude shift

SPATCAT SETTINGS
Property 1 Property 2
Property
Selected property p1 Selected property p2
Elements
Selected # elements p1 Selected # elements p2
Uniformity
Selected uniformity p1 Selected uniformity p2
SPATCAT DATA

1 Sigma
Resulting 1 sigma p1 Resulting 1 sigma p2
Range
Resulting range p1 Resulting range p2

Max#Rivals : resulting maximum number of possible star solutions for the selected SpatCat
#SCEntries : number of stored triangles in SpatCat

MEMORY : estimated RAM memory
Optimized for : memory (fastref off), CPU time (fast ref on)







39
IMAGE PRODUCTION SETTINGS
#FalseStars : number of false stars per image
LstDistTim : last time the disturb sky button was pressed and disturbances on the star
position and magnitude were applied
Rate : S/C rate [deg/s]
IntegraTim : integration time

IMAGE PROCESSING SETTINGS
O/B RateEst : the on-board knowledge of the spacecraft rate as a fraction of the actual rate
GrdDensity : average number of stars per grid element
SearchRange : for respectively property 1 & 2 in sigma.
EdgeProcess : information on the processing of the edge of the image
EdgeOffset : the distance to the edge of the picture in degrees, on which the edge processing
is applied



PREVALIDATION: DistA DistB DistC Gamma Magn MMagn MagnCS AMagn
Marked (x) are the prevalidation methods selected for this MC run:
Distance A
Distance B
Distance C
Gamma
Magnitude of base star
Max magnitude in triangle
Magnitude CheckSum (has MCS# from Advanced Settings instead of X)
All magnitudes

VALIDATION: Doubl DstIn DstCo Snow Indir
Marked (x) are the validation methods selected for this MC run:
Doubles
Distance initiation
Distance continued
Snowball
Also indirect candidates used for distance validation

ADVANCED SETTINGS
Success Law : image Success definition from AdvSet window
Factor Power
Distributio : filename of stochastic distribution model
Multiples : avoided or included
RecogD : Recognition Distance from AdvSet window (fraction of StarDiameter)
CrValSt : Critical Number of Validated Stars (AdvSet window)
FunctionIDs : These numbers can be used to identify the parameter sets for B-V, magnitude
conversion and rate error
B-V
MagC
Rate
IncludeStat : NoMul Bins Rest Warn
Marked (x) are the selected images to be included in the MC statistics: No Multiples, Binaries,
Other Multiples, Also if Warning

40
SIMULATION RESULTS
Longitud : average camera boresight longitude of runs (ABSOLUTE IF ONE RUN ONLY)
Latitud : average camera boresight latitude of runs
Rotation : average camera rotation of runs
Acc : average accuracy of runs
SucR : average success rate
NVa : average percentage of not validated stars
Amb : average percentage of ambigious identified stars
NoR : average percentage of stars not recognized
FaR : average percentage of stars falsely recognized
CPU : average CPU time

#Stars : average number of stars in image
Rel : average reliability = fraction successful attitudes/total attitudes
Suc : average success = fraction successful attitudes/total images
Runs : number of runs for this MC simulation
Exc : number of runs excluded for the statistics
Bin : average number of apparent binaries (per image)
Mul : average number of groups larger than 2 (per image)

WORST CASE INDICATION
MaxNum: lon, lat, rot #StarsFOV see above Acc: see above Suc: see above
Reports the results of the image with the maximum number of stars in FOV
MinNum: lon, lat, rot #StarsFOV see above Acc: see above Suc: see above
Reports the results of the image with the maximum number of stars in FOV
MaxErr: lon, lat, rot #StarsFOV see above Acc: see above Suc: see above
Reports the results of the image with the lowest attitude reconstruction accuracy
MaxFaR: lon, lat, rot #StarsFOV see above Acc see above Suc see above FaR see above
Reports the results of the image with the largest number of falsely recognized stars
NoPos : lon, lat, rot: image without attitude determination with largest # stars in FOV

REMARKS
Remarks added by user for this run

WARNINGS AND ERROR MESSAGES
List of warnings


6.2.2 Monte Carlo report

**************************************************************************

Run of 10 RANDOM sky simulations started at 01/07/1999 3:50:35 AM

CS Longit Latit Rotat Acc Suc NVa Amb NoR FaR CPU

0 6.73 -6.76 303.31 1.0 36 1 0 3 0 0.000
0 161.20 71.00 11.78 0.8 36 0 0 9 0 0.050
1 202.22 -32.05 29.20 1.0 32 0 0 9 0 0.000
1 333.15 -11.72 52.56 1.3 33 1 0 9 0 0.000

See Simulation results group in 6.1.

41
CS: Message Checksum: determined according to:

MessageCheckSum:=0;
if BinsCount>0 then
MessageCheckSum:=MessageCheckSum+1;
if MultisCount>0 then
MessageCheckSum:=MessageCheckSum+2;
if NoPosFlag then
MessageCheckSum:=MessageCheckSum+4;
if WarnFlag then
MessageCheckSum:=MessageCheckSum+8;
if not IncludeFlag then
MessageCheckSum:=MessageCheckSum+16;
42
Chapter 7: Notes

This chapter lists a variety of features of the Star Sensor Algorithm Test Tool v1.0.

Note on the input ranges
Information on the input is indicated when the mouse is moved on top of the value.
There is no protection against values outside the input range.
The program is protected against array overflow and will inform you when such occurs.
This usually means that your program still works but performance will be degraded and its
advised to change your settings.

Note on computational speed
The SSATT program is written for multi-purpose use and its set-up is therefore a trade-off
between:
- computation time
- file size
- memory usage
- wide range of parameters for investigation
Furthermore, often accurate formulas have been used, where more simple approximations would
do the job. Also the inputfile format (e.g. latitude) can be stored more efficiently (cos(lat)), but has
not been done for users convenience.

Note on array Constants and Limitations of your Computer System
The settings for the program are such that they are able to cope with large ranges in input
parameters. The maximum values for array sizes are set in a utility module of your S/W.
They were implemented and tested on a Pentium 200 with 32 MB RAM (17 s for SpatCat).

If your computers calculation time for SpatCat production is more than say 30 seconds or if your
settings are not very demanding, performance can be significantly enhanced by tailoring down
these settings. If your settings (like ultra-high precision of very large FOV) invoke array overflow
you might want to have them changed to higher values.

Additional Settings for Camera
Values derived from
[11]
, different from standard settings, can be used alternatively:

Magnitude Conversion:
A -0.3941
B -0.0155
C 0.1502
B-V 1.6
mc-mv -1.7

CamTH 6.5
MagTH 5.5
SigMagn 0.12
SigPos 15

FOV 16x12


43
Chapter 8: Test results

This chapter reports characteristic results of the tests performed with the DUDE algorithm and
comparisons to the models based on Liebe and Quine.
The camera setting used in this section are based on different industrial suggestions
[15,17]
:

Camera
FOV 15x20
Instrumental Threshold 6 magnitude (5.5 MagTH)
Integration Time 0.3 s
o Magnitude conversion 0.17 magnitude
o Position 12 arcsec
Centroiding model star size 0.09
Pixels 276x385
Table 8.1 Adopted camera parameters

8.1 Background
In the design process of an autonomous star sensor the interaction between H/W and algorithm
performance should be well understood. A trade-off for FOV height and width, instrumental
threshold, processor choice, memory storage and pixel resolution can be made better when
understanding the performance of the final product.
The attitude accuracy of the star sensor is dependent on the number of stars in FOV (Fig. 8.1),
which on its turn depends on the instrumental threshold.

Fig. 8.1 : Accuracy vs number of stars in FOV

Figure 8.2 depicts for the defined camera the average, the minimum and the maximum number of
stars in FOV.
One can extract the maximum obtainable accuracy with the DUDE algorithm from instrumental
magnitude threshold, selected FOV and figures 8.1 & 8.2. Figure 8.2 may be used to determine the
minimum required instrumental threshold to guarantee optimal full sky performance.

# Stars in FOV vs. Accuracy (DUDE, Camera 1), 1E4 runs
0
2
4
6
8
10
12
0 10 20 30 40 50 60 70 80 90 100
# Stars in FOV
A
c
c
u
r
a
c
y

[
a
r
c
s
e
c
]
44

Fig. 8.2: Number of stars in FOV after magnitude conversion

Figure 8.3 shows the number of catalogued stars with a certain visual magnitude and the number
after conversion of visual to instrumental magnitude ( 1.1.1). The detection probability
(magnitude threshold=5.5, o=0.17) is plotted in this graph as well. Overall, the camera is about 0.5
magnitude more sensitive than the visual standard. It can also be seen from the exponential growth
in number of stars, that an underestimate of the error in magnitude estimation will lead to an
underestimate of the number of detectable stars.

Fig. 8.3: Number of stars divided by 1000 for instrumental and visual magnitude and the probability to
be detected for the camera.


Figure 8.4: DUDE performance trends

stars in FOV vs Magn Threshold
0
20
40
60
80
100
120
4 4.5 5 5.5 6
Magn Threshold
#

s
t
a
r
s

i
n

F
O
V
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
3 3.5 4 4.5 5 5.5 6
Magnitude
P
r
o
b
a
b
i
l
i
t
y

&

N
u
m
b
e
r

o
f

s
t
a
r
s
/
1
0
0
0
prob
M_instr
M_vis
DUDE Performance Trends (Cam1) vs. # Stars in FOV
0
10
20
30
40
50
60
20 30 40 50 60
# Stars in FOV
A
c
c
u
r
a
c
y

[
1
E
-
3

d
e
g
]
,

#
S
t
a
r
s

I
d
e
n
t
i
f
i
e
d
,

C
P
U

t
i
m
e

[
m
s
]

Accuracy
# Identified Stars
CPU Time
45
8.2 Triangle selection algorithm results
The selected camera performance of a Monte Carlo whole-sky simulation with DUDE is presented
in figure 8.4. It contains the accuracy, number of successfully identified stars and CPU time.

In the SSATT the Liebe and Quine triangle selection models are tested with the database search
and storage method of DUDE. Table 8.2 gives the results.

mem
[kB]
entries acc arcs reliab succ succ
ID
DUDE 229 9017 1.3 100.00 100.00 82
DUDE high accuracy 542 31480 1.2 100.00 100.00 92.8
DUDE low memory 86 6036 2.3 100.00 98.5 63
Douma 147 6275 1.9 100.00 99.7 54.3
Liebe/DUDE 268 13402 1.2 99.8 99.1 22.6
Quine/DUDE 199 8669 1.4 100.00 99.9 45.8
Table 8.2: Summary of different algorithms for the Lost In Space problem.

A comparison to previously published values of Liebe, Quine and Van Bezooijen
[1,10,9]
cannot be
given directly as results are dependent on processor choice and quality of the hardware. However
the following is suggested from the available data:

- The reliability level as achieved by DUDE is only matched by Van Bezooijen (star pairs).

- The DUDE successful identification of stars is unmatched (upto 93% of the stars in each
image), resulting in highly accurate attitude estimates (Fig. 8.4). A rule of thumb for the
relation between the uncertainty in position of a star in the image and the accuracy is: accuracy
= o
pos
/9. This is a factor 3 improvement with respect to Van Bezooijen in
[9]
, while the
database size is comparable. The Liebe triangles obtain a very good attitude estimate,
especially considering the low successful identification.

- The Liebe and Quine triangles perform better than reported in previous publications.
Especially Quine reliability seems considerably improved.

- The Liebe algorithm using the DUDE database is rather effective in data storage (factor 6 for
same number of stars with respect to
[1]
).
- The tests were performed on an Intel Pentium 200 MHz under W95. The average CPU time
was ~0.013 seconds. A rough conversion for comparison with a 486 66MHz is to apply a
factor 10. Therefore, a possible update frequency of several times per second can be expected
for a PC104-like
[12]
on-board computer.

- About 6000-10000 stored triangles are necessary for optimal reliability. The effect of the
magnitude uncertainty on the obtainable attitude accuracy is small for DUDE.

False stars
Images can contain so called false stars due to e.g. hot spots, radiation or planets. False stars can be
detected during the processing of the image. Nevertheless it is expected that some false stars could
appear in the image. The influence of false stars is investigated in pictures containing a range of 0
to 10 false stars. Figure 8.5 and figure 8.6 show the results.

46

Figure 8.5: Success probability as a function of number of false stars


Figure 8.6: Fraction of successfully identified stars in FOV as a function of number of false stars

There is a clear influence on the number of successfully identified stars in each image, but the
degradation is not sufficient to significantly reduce the attitude success probability. Furthermore,
increasing the number of false stars from 0 to 10, the reliability goes down from 100.00% to
99.8%, while the accuracy degrades from 1.3 to 1.7 arcsec.

Validation
Prevalidation speeds up the post validation by a factor two at the cost of ~20% extra storage
requirement. The total fraction of validation data of total storage is about 33%. The snowball
validation increases the number of successfully identified stars in the FOV with 30%.

Rate
A spacecraft rate smears out the integrated light of a star over a larger area, and therefore has a
large degrading influence on algorithm performance. A rate of a few degrees per seconds is
devastating for most algorithms. The programs rate simulation includes a change in instrumental
threshold and noise in position and light intensity. From interpolation of measurement values
[11]

relations were deduced that are indicative for the sort of dependency that can be expected, as in
real life they will be very dependent on the details of the specific camera system and centroiding.
In order to deal with rate effects, DUDE includes a buffer for magnitude. It takes into account that
fainter stars will not be detected if higher rates are expected. A buffer can be sized for better rate
performance at the cost of decrease in static-case success probability (Fig. 8.7). While a magnitude
buffer of 0.5 still obtains optimal results for very low spacecraft tumbling rates, e.g. a magnitude
buffer of 1.5 performs better for higher rates at an acceptable cost in success.
Influence False Stars on Success Probability
99
99.2
99.4
99.6
99.8
100
0 2 4 6 8 10
Number of False Stars
S
u
c
c
e
s
s

P
r
o
b
a
b
i
l
i
t
y
False Stars vs. Star Identification
0
10
20
30
40
50
60
70
80
90
0 2 4 6 8 10
Number of False Stars
F
r
a
c
t
i
o
n

o
f

s
u
c
c
e
s
s
f
u
l
l
y

i
d
e
n
t
i
f
i
e
d

s
t
a
r
s

i
n

F
O
V
47

Figure 8.7: Success fraction for different S/C tunmbling rates

A magnitude buffer of 2 is too high: equivalent to an algorithm threshold of only 4, it leaves too
little stars bright enough for inclusion in the database and therefore results in a significantly lower
success.

When rate increases from 0 to 4 deg/s reliability decreases from 100.00% to 99% while the
accuracy degrades from 1 to 6 arcsec.

The triangle selection models of Quine and Liebe were compared to the DUDE model with a
magnitude buffer of 1 (Fig. 8.8). It is noticed that for higher spacecraft tumbling rates the Quine
triangles come to have a higher success than the others. This is explained by the bright stars that
Quine selects.


Figure 8.8: Performance of discussed triangle selection methods w.r.t. tumbling rate.



Rate performance of DUDE (Cam1)
0
10
20
30
40
50
60
70
80
90
100
0 1 2 3 4
Spacecraft Rate [deg/s]
S
u
c
c
e
s
s

F
r
a
c
t
i
o
n
Buffer = 0.5 magn
Buffer = 1.0 magn
Buffer = 1.5 magn
Buffer = 2 magn
Algorithm Rate Performance (Cam1)
0
20
40
60
80
100
0 1 2 3 4 5
Spacecraft Rate [deg/s]
S
u
c
c
e
s
s

F
r
a
c
t
i
o
n
# Stars In FOV
Liebe triangles
DUDE (Rate buffer:1.5)
Quine triangles
48
References:


[1] Liebe, C.C., "Star Trackers for Attitude Determination", IEEE AES Systems Magazine, June 1995.
[2] Ketchum, E.A., Tolson, R.H., "Onboard Star Identification Without A Priori Attitude Information",
Journal of Guidance, Control and Dynamics, Vol. 18, No. 2, March-April 1995
[3] Baker, T., Ethridge, D. and Struntz, H.C., Estimation of stellar instrument magnitudes. Clearwater,
Florida, April 1993. Honeywell, Inc., Space & Strategic Avionics Division
[4] Shuster & Oh, Three Axis Determination from Vector Observations, JGC, AIAA81-4003

[5] Eisenman, A, Liebe, C.C., "The Advancing State-of-the-Art in Second Generation Star Tracker",
JPL 1998

[6] Bar-Itzhack, I.Y., "REQUEST: A Recursive QUEST Algorithm for Sequential Attitude
Determination", AIAA Vol 19, Number 5, pages 1034-1038

[7] Liebe, C.C., "Pattern recognition of star constellations for spacecraft applications, IEEE Aerospace
and Electronic Systems Magazine", pages 31-39, 1993

[8] Wertz, J.R., "Spacecraft Attitude Determination and Control", Kluwer Academic Publishers,
Dordrecht, The Netherlands, 1978

[9] Bezooijen, R.W.H., "Automated Star Pattern Recognition", PhD Stanford University, California
1989

[10] Quine, B.M., Durrant-Whyte, H.F., "A fast autonomous star acquisition algorithm for spacecraft, In
proceeding of IFAC Autonomous Control Conference", Beijing, 1995

[11] Douma, S.R., "Development of an Algorithm for Autonomous Star Identification", Delft University
of Technology, Faculty of Aerospace Engineering, 1997

[12] Kruijff, M., Heide, E.J, The YES satellite: a tethered momentum transfer in the GTO orbit, Delta-
Utec 1997

[13] Kruijff, M, Heide, E.J. van der, SSATT user manual, Delta-Utec, The Netherlands 1998

[14] Kruijff, M, Heide, E.J. van der, SSATT shareware version, Delta-Utec, The Netherlands 1998

[15] Boom, de C.W., Maas, A.H., private communications TNO-TPD & Delta-Utec, 1998

[16] Kudva, P., Flight Star Catalog Development for EOS-AM, McDonnell Douglas, 1997

[17] Carroll, J., private communications Tether Applications and Delta-Utec, 1998

[18] Oude Lansink, D.F., title to be released: thesis work at Delft University and Technology and
internship report at TNO-TPD, Delft, 1998

[19] Isral, F.P., Astronomisch Ruimteonderzoek College lrG5, Delft, April 1995, Delft University of
Technology, faculty of Aerospace Engineering.

[20] Allen, C.W., Astrophysical Quantities, third edition. London: the Athlone Press, University of
London, 1976.

[21] Heide, E.J. van der, Kruijff, M., Douma, S.R., Oude Lansink, D., Development and Validation of a
Fast and Reliable Star Sensor Algorithm with Reduced Data Base, Melbourne, IAF-98.A.6.05