TPF-I SWG Report - Exoplanet Exploration Program - NASA

F ORMATION F LYING A L G O R I T H M D E V E L O P M E N T
torque commands into thruster and reaction wheel commands. The FACS software is the same for all
spacecraft, and so any spacecraft can assume the role of leader in the formation-control architecture.
The FAST will be validated by simulating FCT formation scenarios. The FACS residing on the FCT robots
has two additional subsystems, an absolute translation system (ATS) for positioning the robots
independently on the experiment floor, and a formation drift controller (FDC) that keeps the formation
approximately centered on the experiment floor without affecting formation performance. A secondary
mode commander, called the FCT-FACS MDC, coordinates these additional subsystems. The ATS uses
raw sensor data, and so it does not require an estimator.
The Software Executive (SE) provides a flight-like environment for execution of the FACS and is designed
to support a wide variety of formation-control architectures and algorithms. The SE provides commanding,
telemetry handling, device-level communication, inter-spacecraft communication, and scheduling within
the real-time VxWorks operating system. A TCL command interpreter functions as the command
executive. The formation-control algorithms are also commanded via TCL commands. These commands
are simple to implement, and we have found that adding new commands can be done in less than an hour.
Telemetry is available in ASCII or binary format, and the process for generating telemetry has been
automated in Matlab. In addition, telemetry identifiers, telemetry generation, telemetry decoding, and
telemetry display code are all automatically coded from a telemetry specification written in a standard
spreadsheet tool. We are able to automatically code the memory map describing the interface between the
simulation and the VxWorks hardware boards, again based on a spreadsheet specification. The auto-coding
tools were written in Java.
Two crucial services provided by the SE are spacecraft-to-spacecraft clock offset estimation and controlcycle
synchronization. Clock offsets are necessary for formation estimation. Control-cycle synchronization,
which is the process of making control cycles on separate spacecraft start at the same true time, is required
for the highest precision formation control. By using time echo packets similar to NTP, the SE Time
Manager determines the clock offsets between spacecraft. Then, each spacecraft communicates the time at
which its most recent control cycle started. With this data the SEs determine the amount to lengthen their
control cycles. No shortening is allowed. The SEs then command their SCLKs to appropriately delay the
next control-cycle interrupt to bring all the control cycles into synchronization. For example, if control
cycles are 1 s in duration and SC1’s control cycle starts 100 ms before SC2, then the SE on SC1 would
command the SCLK to send the next control cycle interrupt in 1.1 s. A refined version of this basic scheme
has been implemented wherein the control cycles are resynchronized periodically. In steady state with no
additional SCLK drift added to the inherent processor clock drift, cycle shifts are on the order of a few
milliseconds.
The SE also hosts the ISC manager. Currently, a time division multiple access (TDMA) architecture is
implemented for sharing the wireless link between the ISC, the console uplink and downlink, the time-echo
packets, and the control cycle synchronization messages. Existing communication protocols (such as TCP
and user datagram protocol (UDP)) are not satisfactory since TCP can disrupt real-time performance
through continual packet resends, and UDP is not robust to packet drops. A new protocol was developed
called real-time UDP that adds timeouts and a limit to packet resends.
187