1American Institute of Aeronautics and Astronautics

A DISTRIBUTED FLIGHT SOFTWARE DESIGN FORSATELLITE FORMATION FLYING CONTROL

Joseph B. Mueller and Margarita BritoPrinceton Satellite Systems

33 Witherspoon StreetPrinceton, NJ 08542

{jmueller, megui}@psatellite.com

ABSTRACT

Several NASA and DoD missions are envisioned thatwill utilize distributed, autonomous clusters ofspacecraft. The Air Force Research Laboratoryinitiated the TechSat 21 mission to demonstrate thekey enabling technologies of formation flying anddistributed radar. Princeton Satellite Systemsdeveloped the Formation Flying Module (FFM) forTechSat 21 to provide autonomous reconfiguration,formation keeping, and collision avoidancecapabilities to the three-satellite cluster. The processof developing flight software for such a distributedsystem has brought to light significant designchallenges. Examples include developing a cluster-level fault management plan, designing anautonomous control system which respects thevarious constraints imposed by the spacecraft design,and defining a sensible ground command interface tothe cluster. These challenges are likely to remainimportant issues for future missions, especially as thecomplexity and size of the cluster grows. This paperpresents an overview of the FFM design along withthe motivations and challenges associated with thedesign process.

1. INTRODUCTION

There is a growing interest in many organizations,including NASA and the Department of Defense, touse cooperative fleets of autonomous spacecraft toaccomplish complex mission objectives. Themotivations for the distributed satellite paradigm areoften linked to the physical requirements of themission, such as synthetic aperture radar. Additionalbenefits include greater redundancy, improvedperformance and reduced cost.

The attractive qualities of a formation flying solutioncome at the cost of significant design challengeswhich should not be overlooked. Primary drawbackswith the distributed satellite approach includesignificant dependence upon communication, the riskof collision, and increased demands on fuel tomaintain tight relative position control. Furthermore,the proper coordination and management of a satellitecluster is a challenge in and of itself. The complexity

of the overall mission is increased substantially asthe number of satellites in the cluster grows. It iscertain that the potential benefits can be fullyachieved only if the onboard software is sufficientlyrobust and autonomous.

Princeton Satellite Systems has been working forseveral years to address the autonomy-relatedchallenges of formation flying. A key component ofthis research has been the development ofObjectAgent™. The ObjectAgent system has beendeveloped under Air Force Research Laboratory(AFRL) Phase II Small Business Innovative Research(SBIR) funding. Development continues under theCross-Enterprise Technology Development Programand through internal IR&D funding. A briefdescription of ObjectAgent is provided in Section 3.

Previous papers have addressed the MATLABprototyping and real-time C++ development ofObjectAgent, and have described the research intoagent organizations for distributed satellitecontrol1,2,3,4,5,6. These papers have also described thevarious multi-agent, multi-satellite simulations thathave been assembled.

This paper describes a specific ObjectAgent-baseddesign of a distributed, formation flying controlsystem, and highlights both the engineering andsoftware-level design issues that have surfaced. Thefollowing section describes the formation flyingoperations that were envisioned for TechSat 21.Section 3 provides an overview of the FormationFlying Module as implemented in ObjectAgent.Section 4 describes the design of the formation flyingcontrol system, while Section 5 details the faultmanagement design. Finally, the current status of theFormation Flying Module is presented and directionsfor future work are provided.

2. FORMATION FLYING OPERATIONS

The TechSat 21 cluster was planned to consist ofthree identical spacecraft, each with a mass of 180 kg.They were to be launched on the same rocket andinserted into a circular orbit at an altitude of 550 kmand a 34.5 degree inclination. The spacecraft design

Space 200323 - 25 September 2003, Long Beach, California

AIAA 2003-6373

Copyright © 2003 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved.

2American Institute of Aeronautics and Astronautics

is 3-axis stabilized, using a star tracker, sun sensor,and magnetometer for attitude determination andreaction wheels and torque rods for attitude control.Each spacecraft was to be equipped with an inter-satellite link (ISL), which provides communicationas well as range / range-rate measurements. Therelative navigation unit was designed to use the ISLalong with an onboard propagator and a GPS receiverto estimate the relative position and velocity. Therelative motion of each satellite was to be controlledby means of a single Hall-effect thruster (HET),which nominally produces 11.4 mN of thrust.

The main objectives of the mission were to performdistributed radar experiments and to conductformation flying operations. In many cases, sustainedformation flying control would be required before theradar experiment could be conducted.

The scope of the planned formation flying operationsis best described by the mission profile. According tothe nominal profile, the cluster was to be initializedto a leader-follower formation, with approximately 5km of separation between the spacecraft. Over severalweeks, the separation distance was to be graduallyreduced to 100 m. At this point, the cluster wouldreconfigure to achieve relative elliptical motion, or a"football orbit". The size of the relative ellipse wouldthen be gradually increased over several weeks.Finally, an out-of-plane component could be added,depending upon fuel availability.

Before designing the control system, it is firstimportant to understand the manner in which themission developers wish to command the cluster.The command interface to the cluster represents asignificant portion of the control and software designeffort, and should be fully examined prior todeveloping a control strategy. In general, three typesof formation control are desired:

1) ground-commanded reconfigurations2) autonomous formation keeping3) autonomous collision avoidance

In a reconfiguration, the ground-station identifies thedesired type of relative motion for each spacecraft,and the control system computes the delta-v's toachieve that motion. Autonomous formation keepinginvolves intermittently applying orbit corrections inorder to reject disturbances and maintain the desiredrelative motion. Collision avoidance maneuvers areplanned only in response to cluster-level failures thatresult in a significant probability of collision.

The first step in defining the ground-cluster interfaceis defining the relative frame. At all times, one of thespacecraft in the cluster is specified as the reference,which defines the origin of the relative frame. The

remaining two spacecraft are considered relatives. Thedesignation of the reference spacecraft may bechanged at any time by the ground.

A particular formation is defined by expressing thedesired relative motion of the relative satellites. Aspecial coordinate system was developed in which theground-station can express this desired relativemotion. The chosen coordinate system consists of aset of static geometric goals. The goal set consists ofthe following five parameters:

• y0 Along-track offset• aE Semi-major axis of the relative ellipse• b0 Phase angle on relative ellipse at the

ascending equator crossing• zi Cross-track amplitude due to an inclination

difference• zW Cross-track amplitude due to a right

ascension difference

This static geometric goal set defines the desiredrelative state of a spacecraft with respect to thereference throughout the entire course of its orbit. Itis worth noting that the goals have only 5 degrees offreedom as opposed to 6. This is because a constraintof zero secular drift is imposed. The diagram inFigure 1 illustrates the relative motion described bythe above parameters in Hill's frame. In this frame,xH points in the radial direction, y H along thevelocity vector, and zH in the orbit-normal direction.

xH

y0 aE

b0

yH

|z|

zH

xH

aE

2

side view

trailingview

Figure 1: Relative Motion of Geometric Goals

3American Institute of Aeronautics and Astronautics

Here, the distance labeled

†

z is the total cross-trackamplitude,

†

z = zi2 + zW

2 (1)

In general, the motion can have three distinctattributes: 1) along-track offset, 2) relative ellipticalmotion, and 3) out-of-plane component. These threeattributes can be combined in a total of six differentways. This has led to the formal definition of thefollowing 6 types of relative motion.

Table 1: Types of Relative Motion

Type Description RestrictionIPLF In-Plane Leader-Follower

†

z = 0

†

aE = 0CIPE Centered In-Plane Ellipse

†

z = 0

†

y0 = 0NCIPE Non-centered In-Plane

Ellipse

†

z = 0

OOPLF Out-of-plane Leader-Follower

†

aE = 0

COOPE Centered Out-of-planeEllipse

†

y0 = 0

NCOOPE Non-Centered Out-of-planeEllipse

none

It should be noted that this geometric goal set mayalso be applied to eccentric orbits. The goalsprovided by the ground would correspond to aparticular point in the orbit, and the desired parametervalues would vary with the argument of latitude.

3. SOFTWARE ARCHITECTURE

One of the objectives of TechSat 21 was to providean autonomous on-board Cluster Manager whichwould enable a cluster of satellites to function as asingle virtual satellite. The Cluster Manager wouldhandle all cluster level commanding and telemetry,implementing formation flying control and clusterlevel fault management, providing knowledge sharingand health summarization for the cluster, andproviding payload control.

The Cluster Manager would reside on each spacecraftalong with traditional flight software, as shown inFigure 2. The Spacecraft Command Language (SCL)provides the infrastructure, performing command anddata handling, command execution, and managing ashared database of telemetry across the cluster. TheSoftware Bus provides a connection between SCLand the other software modules of the ClusterManager.

Cluster Manager

Software Bus

FFMSCL

Database

Other Modules

FlightSoftware

Spacecraft Subsystems

Figure 2: Cluster Manager Organization

The Formation Flying Module (FFM) is thecomponent of the Cluster Manager that providesformation flying control capability to the cluster. TheFFM has been designed and implemented within theObjectAgent environment. It is appropriate to firstprovide an overview of ObjectAgent beforeproceeding to the discussion of the FFM architecture.

ObjectAgent is an agent-based software architecturefor the control of autonomous, distributed systems.Agents are the main "software units," used toorganize and implement all of the functionality. Eachagent is implemented as a separate thread, has a fully-defined set of inputs and outputs, and is responsiblefor carrying out a specific task. Communicationbetween agents is provided through the PostOffice –a powerful messaging system modeled after theinternet. The architecture includes built-in support forTCP/IP and has an extensible framework forsupporting other protocols.

Formation Flyi ng Module

The FFM design consists of 10 agents, which maybe classified into three different categories as shownin Figure 3. The module is connected to othersoftware components on the spacecraft, including theattitude determination and control system (ADCS),the relative navigation system, the HET and the ISL.This connection is made through the Software Bus.

The architecture is distributed in that a separateinstance of the FFM exists and runs onboard eachspacecraft in the cluster. Communication betweenmodules on separate spacecraft is achieved via theISL.

A centralized management and control approach isused. Maneuver planning for the cluster is performedonboard a single spacecraft, designated as the

4American Institute of Aeronautics and Astronautics

supervisor . The other satellites are consideredsubordinates. The designation of the supervisorspacecraft may be changed at any time by theground.

SWB DataInterface

SWBCommandInterface

CollisionMonitor

CollisionAvoidance

CoordinateTransform

FormationPlanner

HardwareMonitor

FormationKeeper

ConstraintManager

Formation Flying Agents

Fault Management Agents

Interface Agents

DetectionFilter

Software Bus

Groundcommands

FFMTelemetry

SpacecraftTelemetry

Attitude & ThrustCommands

Figure 3: Agent Architecture of the FFM

Interface Agents

The interface agents are responsible for handling theinterface between ObjectAgent and the Software Bus.Their primary role is to convert between SoftwareBus messages and ObjectAgent messages.

The SWB Command Interface agent has two roles.One is to receive all formation flying commandssupplied from the ground, and route them to theappropriate agent(s). The other is to receive hardwarecommands from the Formation agent, and execute thecommands using predefined scripts.

The primary role of the SWB Data Interface is toretrieve a variety of telemetry data from othersubsystems, and route the information to theappropriate agent(s). It also receives periodictelemetry messages from the FFM agents, andsupplies the data to the software bus for futuredownlink.

Fault Management Agents

The fault management agents implement threedifferent aspects of fault management for the cluster.

• Collision Monitoring and Avoidance

• Thruster Fault Detection

• Maneuver Constraint Identification

The collision monitoring and avoidance is carried outby the Collision Monitor and Collision Avoidance

agents. The Collision Monitor uses guaranteed setmembership methods to predict spacecraft’s positionsforward in time9. This agent updates every secondand computes the probability of intersection with oneof the other spacecraft in the cluster. If the probabilityof collision exceeds the designated threshold(currently set at 1%), it notifies the Coll is ionAvoidance agent with the expected time of collision.

The Collision Avoidance agent remains inactive untilnotified of a potential collision by the CollisionMonitor agent. At this point, it plans an avoidancemaneuver. The avoidance planning approach wasdeveloped according to the following objectives:

1. Move one satellite away from the collision point2. Expend a limited amount of delta-v3. Do not drift away from the cluster

Based on these objectives, a simple two-burnmaneuver was chosen, consisting of equal andopposite burns applied in the along-track direction.Only the satellite which has detected the potentialcollision performs a maneuver. The length of eachburn is subject to a maximum delta-v parameterwhich may be changed on-orbit at any time. The timeof the burns is chosen such that a maximum amountof radial offset is generated from the point and timeof the potential collision.

Monte Carlo simulations have shown this simplemethod to work quite well, successfully avoidingcollisions in each of several thousand simulations.However, it is desirable to develop a more rigorousapproach based upon the same set-membership theoryused in collision monitoring. In this context, amaneuver which guarantees no intersection betweenellipsoids over a specified horizon could be planned.

The role of the Detection Filter agent is to detectfailures in the Hall-effect thruster. The approachincorporates a nonlinear model of the system andcompares the system’s performance to that of themodel. The model receives the same control inputs asthe system. If a failure occurs, the outputs diverge. Aspecific combination of residuals identifies a failurein the thruster. Thus, when a failure occurs, theresidual vector is fixed in direction, or at worst isfixed in a specific plane in the residual space. Thisgreatly simplifies failure detection and generallyeliminates the need for complex post-processing ofthe filter outputs for failure identification. Theresponse to a detected thruster failure is part of theoverall fault management plan, which is discussed inSection 5.

The role of the Hardware Monitor agent is todetermine the maneuvering capability of thespacecraft. In order for a complete formation flying

5American Institute of Aeronautics and Astronautics

maneuver to be carried out, the various sub-systemsof the spacecraft must be operating within nominalbounds. For example, there must be sufficient poweravailable to fire the HET, the HET must beoperational and sufficiently cool, and the ADCSmust be operating nominally. These represent asample of the FFM dependencies on sub-systems.The full range and scope of sub-system dependencieshas not been completely identified. The spacecraft isconsidered to be "delta-v operational" only if all ofthe dependent conditions are met. When thisoperational status changes, the Hardware Monitoragent notifies the Constraint Manager.

Formation Flying Agents

The formation flying agents implement the mainfunctionality of the formation flying control system.This includes a series of coordinate transformations,maneuver planning, thruster alignment calculations,checking spacecraft constraints, and preparinghardware commands.

The Coordinate Transform agent first receives theabsolute and relative position and velocity of boththe reference spacecraft and itself, expressed in theECI frame. It then performs a series of coordinatetransformations to express these measured states inframes that can be used by other agents in the FFM.

The Formation Planner agent plans reconfigurationmaneuvers in direct response to ground commands.The ground supplies the geometric goals of eachrelative satellite, defining the desired relative motion.The measured relative state is supplied by theCoordinate Transform agent. This information isused by the cluster supervisor to plan a multi-burnreconfiguration maneuver for all relative satellites.

The Formation Keeper agent is similar to theFormation Planner in that it implements the samecontrol law, and may only plan maneuvers when ithas the role of supervisor. The difference is that thisagent autonomously plans formation keepingmaneuvers when the specified deadband is exceeded.The deadband represents the allowable relativeposition error, and may be updated at any time fromthe ground.

The Constraint Manager agent receives a proposeddelta-v sequence for one or more spacecraft, andprepares the necessary ADCS and HET commands toachieve these delta-v's. The proposed plan is ignoredif a maneuver is already in progress, or if theHardware Monitor has indicated that one or more ofthe spacecraft is not "delta-v operational."

An important role of the Constraint Manager is toensure that the cluster is capable of achieving the

proposed maneuver prior to initiating the commandsequence. Initiating a maneuver that cannot becompleted due to spacecraft limitations (i.e., thermalor power restrictions) can result in relative motionthat is extremely undesirable and potentially mission-threatening.

4. CONTROL SYSTEM DESIGN

The general control approach is outlined in Figure 4.The functionality represented in the upper box iscarried out in the Coordinate Transform agent. Thefunctionality shown in the lower box is implementedin both the Formation Planner and FormationKeeper agent.

Coordinate Frames and Transformations

The relative navigation unit provides an estimate ofthe absolute position (r) and velocity (v) of thereference spacecraft, as well as the relative position(dr) and velocity (dv) of the other spacecraft withrespect to the reference. All measurements areprovided in the inertial frame. A simple Kepleriantransformation provides the osculating orbitalelements of the reference (eosc) and the osculatingorbital element differences (deosc). The elements areosculating at this point due to the J2 perturbation. Anosculating-to-mean transformation7 provides the meanreference elements (emean) and the mean elementdifferences (demean).

The orbital element vector is defined as follows:

†

e = a q i q1 q2 W[ ]T(2)

where a is the semi-major axis, q is the trueargument of latitude, i is the inclination, and W isthe right ascension. The dimensionless q-variables aredefined as follows:

†

q1 = e cosw (3)

RelativeNavigation

Unit

KeplerianTransformation

r

v

dr

dv

eosc

deosc

Osculatingto

MeanTransformation emean

demean

goalsGroundStation

Geometric Goals

toElement

DifferencesTransformation

Demean

de*mean

Dv(t)

ImpulsiveControl

Law

time window

Figure 4: General Control Approach

6American Institute of Aeronautics and Astronautics

†

q2 = esinw (4)

where e is the eccentricity and w is the argument ofperigee.

The ground station provides the geometric goals ofthe cluster (g), as discussed in Section 2. This staticgoal set is transformed to desired element differences(

†

de* ) through the following procedure:

†

dxH* = fgx (emean ,g)

de* = fxe (emean ,dxH* )

(5)

where

†

fgx is the transformation function fromgeometric goals to Hill's frame coordinates, and

†

fxe

is the transformation function from Hill's framecoordinates to element differences7. The

†

fgx

transformation is expressed as:

†

xH = -12

aE cos a0 +q( )

yH = aE sin a0 +q( ) + y0

zH = zi sinq - zW cosq

˙ x H =12

aEn sin a0 +q( )

˙ y H = aEn cos a0 +q( )˙ z H = n ¥ zi cosq + zW sinq( )

(6)

where the angle

†

a0 is termed the complementaryphase angle. It is related to

†

b0 through the equation

†

a0 = sin-1 sin b0

4 - 3sin2 b0

Ê

Ë

Á Á

ˆ

¯

˜ ˜

(7)

The physical meaning of

†

a0 is best describedthrough the diagram in Figure 5.

The ellipse represents the actual motion of thespacecraft in the relative frame. The superimposedcircle represents the evolution of the absolute orbit.As the orbit is traversed, the relative spacecraftfollows the path of the 2x1 ellipse. The angles arerelated by the fact that the y-component of the circleand ellipse are always equal.

Impulsive Control Law

The control law is an impulsive approach initiallydesigned by Alfriend8 and further developed byMueller. The approach is derived from Gauss'variational equations, which provide the expressions

for the instantaneous change in orbital elementdifferences due to an impulse. A closed-form solutionis obtained which expresses a finite delta-v sequenceas a function of the errors in orbital elementdifferences. The derivation assumes zero eccentricityand does not account for the J2 perturbation.

xH

b0

yH

a0

Figure 5: Physical relationship between

†

a0 and

†

b0

The element error (

†

Demean ) is computed as thedifference between the desired and measured elementdifferences.

In general, the burn sequence consists of three in-plane delta-v's and a single out-of-plane delta-v. Theout-of-plane delta-v is given by the equation

†

Dvn =hr

Di( )2+ DW sin i( )2

(8)

where h is the angular momentum and r is themagnitude of the position vector. This delta-v isapplied at the following argument of latitude:

†

q = tan-1 DW sin iDi

Ê

Ë Á

ˆ

¯ ˜ (9)

The immediate goal of the out-of-plane burn is toadjust the cross-track amplitude by changing i andW . It is clear from Gauss's variational equations,however, that this out-of-plane burn will also affectthe elements q1, q2 and q . These cross-couplingeffects are added to the initial errors before computingthe in-plane burns, as follows:

†

Dq1 = Dq1 -rp

q2 sinq cot iDvn (10)

†

Dq2 = Dq2 +rp

q1 sinq cot iDvn (11)

7American Institute of Aeronautics and Astronautics

†

Dq = Dq +rh

sinq cot iDvn (12)

where p is the semi-latus rectum.

The required set of in-plane delta-v's is given by thefollowing equations.

†

Dv1 =na

3NpDq 0 -

32

Da q1 -q 0( ) - 2D˜ q 0È

Î Í ˘

˚ ˙

+na4

MN

-1Ê

Ë Á

ˆ

¯ ˜ Dq -

MN

+1Ê

Ë Á

ˆ

¯ ˜ Da

È

Î Í

˘

˚ ˙

(13)

†

Dv2 =na4

Dq - Da ( ) (14)

†

Dv3 = -na

3NpDq 0 -

32

Da q1 -q 0( ) - 2D˜ q 0È

Î Í ˘

˚ ˙

-na4

MN

Dq -MN

Da È

Î Í ˘

˚ ˙

(15)

where n is the mean orbit rate, a is the semi-majoraxis,

†

q 0 is the current argument of latitude, and

†

q1 isthe argument of latitude at which the first burn is tobe applied.

†

q1 = tan-1 Dq2

Dq1

Ê

Ë Á

ˆ

¯ ˜ (16)

Furthermore, we have

†

Dq = Dq1 cosq1 + Dq2 sinq1 (17)

†

D˜ q 0 = Dq1 sinq 0 - Dq2 cosq 0 (18)

†

Da = Daa

(19)

The parameters M and N are maneuver time variables.Each is a positive integer, with M representing thenumber of half-orbits between the 1st and 2nd burn,and N the number of half-orbits between the 1st and3rd burn. They are subject to the followingconstraints:

†

N ≥ M +1N Œ evenM Œ odd

(20)

The time window supplied by the ground station (seeFigure 4) indicates the minimum and maximumnumber of orbits that the maneuver may last. The M

and N parameters are varied within this specified timewindow to find the combination which requires thesmallest delta-v.

It is interesting to note a few observations about thesensitivity of the delta-v to the maneuver timevariables. Only the first and third delta-v burns aredependent upon M and N. The magnitude of the thirddelta-v is inversely proportional to N . Thus, as themaneuver duration increases, the size of the thirdburn approaches zero. This can be a useful fact forplanning maneuvers in which limited power isavailable for the final burn.

The total delta-v savings can be seen in the sum ofthe absolute values of the first and third burns. Forleader-follower resizing maneuvers, the expressionreduces to:

†

Dv1 + Dv3 =2na3Np

Dq (21)

In this maneuver, the second delta-v is zero.Therefore, the total required delta-v is inverselyproportional to N . When the nature of the motion isconsidered, this result makes perfect sense. An along-track distance of Dy is covered in time D t, with twoequal and opposite burns applied at the beginningand end of the maneuver. The first burn creates adifference in the semi-major axis, da, which resultsin along-track drift. The final burn sets da back tozero, eliminating the drift. The change in semi-majoraxis corresponds to a difference in the mean orbitrate, n, expressed as:

†

dn = -32

na

da (22)

This represents the relative drift rate. The final along-track offset is found to be:

†

Dy = -32

nÊ

Ë Á

ˆ

¯ ˜ da( ) Dt( ) (23)

This equation shows that the same amount of along-track offset can be achieved with a smaller da byallowing more time to complete the maneuver.

Another interesting result is found when we considera reconfiguration from IPLF to CIPE, for the specialcase where

†

y0 = aE . In this case, the size of the firstand third delta-v's reduces to:

†

Dv1 + Dv3 =na8

Dq (24)

8American Institute of Aeronautics and Astronautics

Thus, the required delta-v is independent of themaneuver time variables. For the more general case of

†

y0 ≠ aE , however, significant fuel savings can beachieved with the proper selection of M and N.Consider a reconfiguration from a 300 m offset IPLFformation to a CIPE formation with aE = 60 m. Twoseparate cases of the reconfiguration are shown below.

Figure 6: IPLF to CIPE Reconfiguration, 1 orbit

Figure 7: IPLF to CIPE Reconfiguration, 3 orbits

The single orbit maneuver requires 0.048 m/s ofdelta-v, whereas the 3-orbit maneuver requires only0.016 m/s. The dependence of the total delta-v on theM and N parameters is shown in Figure 8. This plotnicely illustrates the fuel savings that can be achievedby choosing the burn times appropriately. Recall thatM indicates the number of half-orbits between the 1st

and 2nd burn. If the second burn is applied one orthree half-orbits after the first, then the optimal delta-v can never be achieved. By allowing more timebetween the 1st and 2nd burn, the spacecraft is able todrift at a slower rate, which requires less delta-v.

Spacecraft Constraints

The physical constraints of the spacecraft can have asignificant impact on the control system design.Consider the thruster related constraints, for example.Since each spacecraft is outfitted with a singlethruster that is fixed to the bus, it is necessary toslew the entire spacecraft prior to each burn such thatthe thruster is pointed in the proper direction. Thermal constraints on the HET limit the frequencyand duration of thruster firings, and operating theHET requires significant power.

Considering these constraints, in order to schedule aburn one must first ensure that sufficient power willbe available, that the HET will be sufficiently cool,and that the ADCS will have had enough time toslew to the delta-v orientation. If these conditionscannot be guaranteed, then there is no guarantee thatthe proposed burn will be successfully applied. As

previously discussed, canceling a burn in the midstof a maneuver can have serious consequences.

Figure 8: Delta-V Dependency on Burn Times

In general, the thermal constraints on the HETimpose a duration limit of 10 minutes on any singleburn. If two burns are applied close together,however, this limit must certainly be reduced. Froma formation flying perspective, the constraint is mostmeaningful if expressed as a function of the previousburn duration and the time between burns. Thrusterperformance is typically not presented in this fashion,however, and therefore requires collaboration betweenthe control system designers and the thrustermanufacturer.

In order to satisfy the power constraints, thespacecraft must remain in a sun-pointing mode for asufficient period of time. Since a maneuver requiresthe re-orientation of the spacecraft, it impacts theamount of available power. Thus, a constraint whichmust be adhered to in maneuver planning is directlycoupled with the maneuver itself. The simplest wayto resolve this issue is to impose conservative power-related constraints on the planning process and ignorethe coupling. Otherwise, a detailed model of thepower profile as a function of time-on-sun and otherfactors must be generated and used within theplanning algorithm. A conservative approach waschosen for TechSat 21 given the challenges inobtaining such a model.

Another interesting constraint involves the pointingof the star-tracker while aligning the thruster for aburn. The star-tracker sensor is required for preciseattitude determination. Pointing it at bright objectscauses the sensor to turn off temporarily, therebyreducing the accuracy of the attitude determination.When the thruster is fired, it is important to have theleast amount of attitude error possible to avoidsubsequent errors in the relative motion. Therefore, it

9American Institute of Aeronautics and Astronautics

is necessary for the star-tracker to continuefunctioning nominally prior to and during everyburn.

This constraint required the development of a separatealgorithm to determine an orientation that properlyaligns the thruster while pointing the star-tracker asfar away as possible from the brightest natural objectsin the sky—the sun, earth and moon.

For each commanded burn, a specific orientationmust be chosen so that the appropriate commandsmay be sent to the ADCS. The ADCS may becommanded to track a specified orientation within thelocal-vertical local-horizon (LVLH) frame. Prior tothe start-time of the burn, the ADCS is commandedto transition to “LVLH Tracking” mode, and to stayin this mode throughout the duration of the burn. Inorder to command this mode, two parameters mustbe supplied: 1) the body vector to be aligned with thevelocity, and 2) the body vector to be aligned withnadir. These two body vectors provide sufficientinformation to define a desired orientation that isfixed with respect to the local frame.

The solution is found subject to two constraints.First, the bore-sight of the thruster nozzle must bepointed in the opposite direction of the desireddelta-v. Second, the bore-sight of the star-trackercamera must be pointed as far away as possible fromthe sun, earth and moon.*

An infinite number of orientations exist which satisfythe first constraint. This can be envisioned by firstaligning the thruster in the desired direction, thenrotating the spacecraft about the bore-sight of thethruster nozzle. A discretized search is performed inthis fashion, where the average angular distancebetween the star-tracker bore-sight and the threebright bodies is calculated at each step. Theorientation with the largest average angular distanceis chosen.

5. FAULT MANAGEMENT DESIGN

Fault management design for a cluster of spacecraft ischaracterized by a higher level of complexity thanthat for a single spacecraft because it must account forthe effect of faults on the entire cluster in addition toaccounting for the effects on the individual spacecraft.The various types of spacecraft faults can be generallycategorized into two basic groups: spacecraft-levelfaults and cluster-level faults. Spacecraft-level faultscan be handled by the individual spacecraft without

* It should be noted that reflections off of other spacecraft maybe sufficiently bright so as to interfere with the star-tracker.These reflections are not yet taken into account by the algorithm.

affecting other members of the cluster. Cluster-levelfaults impact the performance of the cluster as awhole, and may require additional action by at leastone other member of the cluster.

The classification of a fault as spacecraft-level orcluster-level is highly dependent on the design of theparticular spacecraft. For example, a thruster failuremay mean a cluster level fault on a spacecraft with asingle thruster, but it may be only a spacecraft-levelfault if the spacecraft has multiple thrusters and iscapable of compensating for the loss of one. Generally, though, failures in the attitude control,propulsion, inter-satellite communication and relativenavigation subsystems are most likely to producecluster-level faults.

The purpose of the cluster fault management systemis to first identify and then respond to cluster-levelfaults. The primary objectives are to ensure the safetyof the cluster and to maintain its overallfunctionality. In traditional designs, a typicalresponse to most faults is to enter safemode.However, this is not necessarily the safest response tocluster-level faults. It is therefore important to definea cluster-level safemode.

The goal of safemode is to prevent the spacecraftfrom incurring damage. It is generally designed touse a minimum amount of power and collect amaximum amount of energy. When a spacecraft is amember of a cluster, however, the impact on clusterperformance and safety must also be considered. Assuch, the ISL and the relative navigation subsystemsshould be considered critical subsystems and shouldbe active during safemode. Enabling communicationbetween a safed spacecraft and the rest of the clusterallows the cluster to remain aware of the safedspacecraft's position, thus making collisionmonitoring and avoidance more effective andallowing the cluster to maintain formation for alonger period of time. This translates to an easierrecovery of full cluster functionality should the safedspacecraft return to operational mode.

In the case of TechSat 21 spacecraft, safemode doesnot keep the ISL operational. Therefore, anyspacecraft entering safemode must be considered lost.In order to ease recovery of full functionality, thecluster uses the last known location of the spacecraftin the collision monitoring algorithms and maintainsthe current formation as long as possible. However,the relative position uncertainty of the safedspacecraft increases while the ISL remains down, andeventually the cluster is forced to make collisionavoidance maneuvers.

10American Institute of Aeronautics and Astronautics

Collision monitoring and collision avoidance areessential to the safety of a cluster. Under nominaloperations, when the control systems of clustermembers are fully operational, the threat of collisionis minimal. In the event of a cluster-level failure,however, the performance of relative estimation andcontrol are degraded. It is imperative during thesetimes to have a robust method for detecting possiblecollisions and a feasible approach for avoiding them.The collision avoidance approach must balance theobjectives of safety and performance. Factors such asmaintaining cluster functionality, permanentlyremoving a failed spacecraft as a collision threat,equitable distribution of fuel consumption amongcluster members and spacecraft system constraintsshould form part of the collision avoidance system ofan operational cluster. The methods of collisionmonitoring and collision avoidance developed for theTechSat 21 cluster are briefly described in Section 3.

One of the expected benefits of the cluster paradigmis its robustness to single-point failures. Maintainingcluster functionality in the face of full or partialfailures of cluster members is therefore a primaryobjective of the cluster fault management plan. Theseadjustments may be designed to be madeautonomously or to require ground intervention. Inthe case of TechSat 21 the high level decisions tomaintain cluster functionality are made outside of theFFM, but the features that enable the execution ofthose decisions are incorporated into the FFM. Forexample, if one of the members were to experience aHET failure, the FFM would detect the anomaliesthrough a detection filter. Because of theexperimental status of the FFM, the only action itwould take would be to report the anomaly to theground. Once the ground verified the failure, it wouldnotify the cluster and the FFM would then adjust bymaking the spacecraft with the failed thruster becomethe reference, since the reference does not need tomaneuver.

6. CURRENT STATUS & FUTURE WORK

A preliminary build of the Formation Flying Modulehas been completed and delivered to AFRL with avariety of closed-loop control demonstrationsincluded. Four different formation flying scenarioshave been developed in which the following featuresare demonstrated:

• In-Plane Reconfiguration• Out-of-Plane Reconfiguration• Formation Keeping• Collision Monitoring and Avoidance• Reference Rollover• Supervisor Rollover

In every scenario, the FFM agent code runs as threeseparate executables on a Linux workstation while thesimulation of the three-satellite cluster is conductedusing MultiVehicleSim™ on an Apple PowerBook.Each ObjectAgent application connects to thesimulation via TCP/IP. Commands for the FFM areentered at the command line and sent as ObjectAgentmessages to the Interface Agent of each spacecraft.

One scenario involves both a reference rollover and asupervisor rollover, followed by an out-of-planereconfiguration. The three satellites – named Athos,Porthos and Aramis – are initialized in a 100 meterLeader-Follower formation. Porthos lies in the center,and initially serves as both the reference and thesupervisor. The reference orbit and spacecraft modelused in the scenario are consistent with theinformation outlined at the beginning of Section 2.

Several steps are taken in the command sequence.First, the reconfiguration goals are supplied. Thiscommand supplies the necessary information todefine the desired relative motion of each spacecraft.In this case, Porthos is desired to have a 250 meteralong-track offset and a 25 meter cross-trackamplitude, while Athos is desired to have a 500meter along-track offset and a 50 meter cross-trackamplitude. The reconfiguration goals are not suppliedfor Aramis, because it will soon become the newreference.

Table 2: Reconfiguration Goals

Athos Porthos Aramisy0 500 m 250 m -aE 0 m 0 m -b0 - - -zi 0 0 -zW 50 m 25 m -

The next command in the sequence is a referencerollover. This command is sent to all spacecraft,identifying Aramis as the new cluster reference. TheCoordinate Transform agent receives the command,and begins to treat Aramis as the origin of therelative frame when computing the mean orbitalelement differences.

Following the reference rollover, a command isissued for a supervisor rollover. Here, the identity ofthe supervisor changes from Porthos to Athos. TheFormation Planner and Formation Keeper agents onall spacecraft are notified. From this point forward,only Athos may plan formation keeping orreconfiguration maneuvers.

Finally, the reconfiguration is commanded. Theestimated mean orbital elements are provided from

11American Institute of Aeronautics and Astronautics

the Coordinate Transform agent with Aramis treatedas the reference. The Formation Planner agent onAthos transforms the supplied reconfiguration goalsinto desired element differences. The error betweenthe measured and desired element differences issupplied to the control law to compute the requireddelta-v sequence. This proposed plan involves amultiple burn sequence for both Porthos and Athos.The plan is sent to the Constraint Manager agent,which computes the required orientation of eachspacecraft for each burn, along with the set of timesat which the HET must be turned on and off.

The target attitude for each burn is achieved by meansof a separate attitude control system which wasdeveloped specifically for FFM validation. Perfectstate knowledge and actuation is used, as theobjective is to validate the overall softwarefunctionality rather than the algorithm performance.Figure 9 illustrates the successful achievement of thedesired formation geometry.

Figure 9: IPLF to OOPLF Reconfiguration

The Air Force Research Laboratory has discontinuedthe TechSat 21 program. However, the experience ofdesigning this control system within the context ofan evolving mission profile and subject to theconstraints of an existing spacecraft design hasbrought increased awareness of the complex issuesinherent to formation flying. The sensitivity ofmission performance to relative navigation accuracy,the requirement of a cluster-level safemode, and theneed for detailed knowledge of subsystem dynamicsfor accurate maneuver planning are a few of the mostimportant issues discovered.

7. ACKNOWLEDGMENTS

This work has been supported by two United StatesAir Force SBIR Phase II contracts from theSurveillance and Control Division of the Air ForceResearch Laboratory's Space Vehicles Directorate.The contract numbers are F29601-02-C-0029 and

F29601-01-C-0134 and the program manager is PaulZetocha.

8. REFERENCES

[1] Schetter, T. P., M. E. Campbell, and D. M.Surka, “Comparison of Multiple Agent-basedOrganizations for Satellite Constellations,” 2000FLAIRS AI Conference Proceedings, Orlando,Florida, May 2000.

[2] Schetter, T. P., M. E. Campbell, and D. M.Surka, “Multiple Agent-Based Autonomy forSatellite Constellations,” Second InternationalSymposium on Agent Systems and ApplicationsProceedings, Zurich, Switzerland, September 2000.

[3] Surka, D. M., M. Brito, and C. G. Harvey,"The Real-Time ObjectAgent Software Architecturefor Distributed Satellite Systems", 2001 IEEEAerospace Conference Proceedings, Big Sky,Montana, March 2001.

[4] Mueller, J. B., D. Surka, B. Udrea, "Agent-Based Control of Multiple Satellite FormationFlying", The 6th International Symposium onArtificial Intelligence, Robotics and Automation inSpace: A New Space Odyssey, Montreal, Canada,June 2001.

[5] Thomas, S. J., J. B. Mueller, D. M. Surka, C.G. Harvey, "Monitoring and Analysis of MultipleAgent Systems", 1st Workshop on Radical AgentConcepts, Goddard Space Flight Center, January2001.

[6] Zetocha, P. and M. C. Brito, “Development ofa Testbed for Distributed Satellite Command andControl,” 2001 IEEE Aerospace ConferenceProceedings, Big Sky, Montana, March 2001.

[7] Gim, D. W. and K. T. Alfriend, “The StateTransition Matrix of Relative Motion for thePerturbed Non-Circular Reference Orbit," AAS 01-222, AAS/AIAA Space Flight Mechanics Meeting,Santa Barbara, CA, February 2001.

[8] McLaughlin, C., K. T. Alfriend, and T. A.Lovell, "Analysis of Reconfiguration Algorithms forFormation Flying Experiments", InternationalSymposium for Formation Flying Missions andTechnologies, October 2002, Toulouse, France.

[ 9 ] Campbell, M. and B. Udrea, "CollisionAvoidance in Satellite Clusters", American ControlConference, Anchorage AK, May 2002. Submitted tothe AIAA Journal of Guidance, Control, andDynamics .