The SPHERES Guest Scientist Program: Collaborative Science On the ISS 12

Transcription

1 The SPHERES Guest Scientist Program: Collaborative Science On the ISS 12 John Enright Mark Hilstad, Alvar Saenz-Otero, David Miller Dept. of Aerospace Engineering Space Systems Laboratory Ryerson University Massachusetts Institute of Technology 350 Victoria St., Toronto Ont., Canada M5B 2K3 77 Massachusetts Ave , Cambridge, MA Tel: x4174 Tel: Abstract The SPHERES Guest Scientist Program (GSP) supports the efforts of geographically distributed researchers at MIT, the U.S. Department of Defense, NASA, and elsewhere, in the development of algorithms for the SPHERES formation-flying and docking testbed. The GSP consists of a test development framework, a robust and flexible interface to the SPHERES flight software, a portable high-fidelity simulation, two laboratory testbeds, and data analysis utilities. The SPHERES testbed will be operated in bi-weekly test sessions onboard the International Space Station. Updates to the flight software can be uploaded immediately prior to each test session, allowing guest scientists the opportunity to revise and improve their algorithms from one session to the next. The SPHERES flight software architecture and the GSP interface design contribute to the flexibility of the testbed, and minimize non-productive labor by simplifying algorithm implementation. TABLE OF CONTENTS 1 INTRODUCTION THE GUEST SCIENTIST PROGRAM GSP SOFTWARE CURRENT GUEST SCIENTISTS CONCLUSIONS ACKNOWLEDGMENTS REFERENCES INTRODUCTION Algorithm research in the areas of autonomous docking, formation flight, and other high-risk but potentially high-payoff distributed spacecraft technologies has gained substantial momentum over the last few years [1][2][3]. Many of these techniques can only be tested in simulation or with expensive and risky flight projects. Currently, there are no on-orbit resources suitable for the validation of general simulation results, and most space missions do not push the limits of performance due to the high risk associated with flying unproven algorithms. The SPHERES testbed is an inexpensive and risk-tolerant laboratory for the validation of distributed spacecraft control, estimation, and autonomy algorithms. It fills the gap between the flexibility, risk-tolerance, and uncertainty of simulation-based research and the inflexibility, expense, and credibility expected from future spaceflight missions. The Massachusetts Institute of Technology (MIT) Space Systems Laboratory (SSL) developed the SPHERES testbed as part of our ongoing research innitiatives into technologies and applications of distributed satellite systems [4][5][6]. The SPHERES testbed consists of two parts; a ground testbed located at MIT, and a flight testbed that will be operated by astronauts as an interactive laboratory onboard the International Space Station (ISS). The ISS provides unique opportunities for: Supervised and interactive experimentation. Immediate assessment of test results. Space research in a risk-tolerant environment. Experimentation in three dimensional, microgravity dynamics. The SPHERES testbed will utilize these unique properties of the ISS to create a laboratory environment for the development and validation of control, estimation, and autonomy algorithms. By supporting a wide range of research areas in a single testbed, the SPHERES project provides an effective common laboratory facility and avoids the extra costs of multiple single-purpose flight projects.[7] The SPHERES Guest Scientist Program (GSP) provides a common framework for collaboration, and facilitates access /04/$ IEEE 2 IEEEAC paper #1296 Version 1, Updated October 10,

2 Beacons (5) ISS Laptop SPHERES (3) Crew Member Figure 1 Operational Concept for the SPHERES Testbed in the ISS US Lab (courtesy of The Boeing Company) to the SPHERES laboratory [8]. It is designed to to support parallel use of the testbed by researchers with diverse research interests and goals. Specifically, the GSP enables geographically distributed researchers to implement and test algorithms, obtain experiment data, iterate on algorithm design, and otherwise participate fully in the ground and flight laboratories on time scales of days and weeks rather than years. These requirements are addressed primarily through software, in the form of a flexible, simple, and powerful interface to the SPHERES core flight software and a portable high-fidelity software simulation environment. This paper first presents an overview of the SPHERES testbed operational environments. The following section provides a description of the real-time operating system at the core of the SPHERES flight software. We also describe the simulation that allows guests scientists to test their algorithm implementations in-house before sending them to the SPHERES team. We conclude with a summary of the current researchers utilizing the SPHERES GSP and a discussion of performance to date. station. The following discussion provides an introduction to the hardware used in the ground and ISS laboratories. The most important components of the SPHERES laboratories are the autonomous free-flying "satellites." The satellites can maneuver in six degrees of freedom, communicate with each other and with the laptop control station, and determine their positions, velocities, attitudes, and angular rates with respect to an ISS-fixed or lab-fixed reference frame. Figure 2 shows a CAD model of a SPHERES satellite, in which elements of the propulsion system (thrusters, regulator knob, and propellant tank) and metrology system (ultrasound receivers) are visible. Tank Thrusters Ultrasound Sensors The Spheres Testbed Algorithms written for the SPHERES GSP can be used in three operational environments: a software simulation, a 2D ground laboratory, and the 3-D ISS laboratory. The ISS testbed will consist of three SPHERES satellites and a metrology beacon system. Figure 1 shows an operational concept for the SPHERES testbed in the U.S. laboratory onboard the ISS. The ground laboratory will consist of two flight-identical satellites and a similar metrology system. Each laboratory requires a laptop computer to act as a ground control Pressure Gauge Battery Door Figure 2 SPHERES Satellite Pressure Regulator 2

3 Maneuvers are performed using a cold-gas propulsion system. The carbon dioxide propellant is stored liquid form at 860 psig, and a regulator reduces the operating pressure to 35 psig. Each thruster assembly consists of a solenoid-actuated valve with a micro-machined nozzle. Twelve thruster assemblies are positioned in pairs to provide complete attitude and position control. The propellant is stored in removable tanks. Each tank is expected to provide approximately 30 minutes of active operation in microgravity under normal operation on the ISS. The Position and Attitude Determination System (PADS) is used to generate real-time estimates of the satellite state. By default, the state includes spacecraft position, velocity, attitude, and angular rate. Guest scientists may expand or redefine the state defintion. The PADS measurement systems include a global metrology system used to estimate the satellite state with respect to the external reference frame, and an inertial measurement system with accelerometers and rate gyroscopes that is used to measure high-frequency bodyframe accelerations and angular rates. The global metrology system measures times-of-flight to determine the distances between sensors on the surface of the satellites and ultrasonic beacons placed at known locations in the work volume. The SPHERES team provides a optional Extended Kalman filter that uses the inertial and global systems to determine the states of each satellite with respect to the reference frame. Relative state information (e.g. range and bearing), can be obtained by exchanging the global state information, or by using beacons located on the satellites themselves. The MIT estimation routines may be disabled by guest scientists who wish to test custom estimation algorithms. The processor on each satellite is a Texas Instruments C6701 Digital Signal Processor (DSP). The C6701 performs 167 MFLOPS with un-optimized code, and up to 1.0 GFLOPS with fully-optimized code. Using a powerful processor such as the C6701 ensures that the system flexibility is not constrained by a lack of computational capability. The flight software is stored in FLASH memory, and may be up to 224 kb in size. Updated flight software is uploaded prior to each test session, enabling re-configuration of the system to support the goals of individual guest scientists. Two packs of AA batteries provide power for each satellite. Due to NASA safety constraints, alkaline batteries are used in orbit, while rechargeable, NiMH packs are used in the ground laboratory. A set of batteries provides power for two hours of typical operation. Hinged access panels on the satellite outer shell allow easy replacement of spent batteries. The satellites communicate on two separate radio channels. Each channel has an effective capacity of about 22 kbytes/s. One channel is dedicated to satellite-to-satellite (STS) communications, and the other channel is used for satellite-tolaptop (STL) communications. The STS channel will typically be used for user-defined algorithm coordination, while the STL channel handles telemetry downlink and command uplink. Both channels are bi-directional; however, the communication hardware is half-duplex, meaning that only one station can trasnmit at a time. 2THE GUEST SCIENTIST PROGRAM One advantage of a general-purpose laboratory environment in general is the ability to support multiple research investigations in parallel. By enabling multiple researchers or programs to share common facilities, the individual cost of a series of experiments is greatly reduced, since design and development costs are shared across the programs. The SPHERES project has created a collaborative laboratory environment through the SPHERES Guest Scientist Program [7]. The GSP allows guest scientists working at separated geographical locations to fully participate in the use of the testbed. This use spans the development and implementation of new algorithms to iteration on algorithm design based on feedback of flight data. Figure 3 presents an overview of the GSP, and illustrates the interaction between the guest scientists and the SPHERES team [9]. The key elements of the GSP are the SPHERES simulation, the 2D ground laboratory at the MIT SSL, and the 3D laboratory onboard the ISS. To maximize the productivity during tests on-orbit, guest scientiests are expected to conduct extensive testing of their algorithms using the first two facilities. GSP Simulation The SPHERES simulation provides a means for guest scientists to independently implement, test, and modify algorithms for the testbed, while minimizing reliance on long-distance communication and physical access to the testbed hardware. The simulation is designed to facilitate efficient interaction between guest scientists and the MIT SPHERES team. Custom source code may be compiled and linked into the simulation environment to verify syntax and appropriate interaction with the existing SPHERES software. The simulation engine can be used to predict the behavior of the hardware in both the ground and microgravity environments. The simulation also helps the guest scientists learn how to use the interface to the flight software and reduces reliance on access to the testbed hardware. We anticipate that this tool and should be particularly valuable during on-orbit operations, when rapid turn-around of updated algorithms is an important aspect of maximizing the effectiveness of the testbed. SSL Laboratory The SPHERES ground laboratory provides a 2D, three degree of freedom (3 DOF) environment in which to test algorithms prior to deployment to the ISS. The ground testbed is located at the MIT SSL in Cambridge, MA, USA. The laboratory can be operated at low cost, allowing a large number of iterations during algorithm development. Feedback on experiment performance can be provided to 3

4 Guest scientist at local facility Independent algorithm and source code development GSP interface package Deliver to SPHERES SPHERES team at M.I.T. GSP simulation Laboratory testbed International Space Station Figure 3 GSP Overview. guest scientists almost immediately after the completion of a test. The hardware used in the laboratory is identical to the flight hardware, and is fully flight-qualified. For 2D operations, the satellites are mounted on air-bearing carriages that allow translation in two axes and rotation about one axis. Two metrology systems are available; one is optimized for 2D operations on the air table, and the second serves as a copy of the configuration onboard the ISS. Because the hardware is identical to that on the ISS, operations are subject to realistic imperfections, uncertainties, and effects that are not modeled in the simulation. ISS Laboratory The ISS laboratory provides the opportunity to conduct extended-duration microgravity experiments. Investigators may use up to three satellites in their experiments. The metrology system is set up to provide 3D position and attitude resolution. Tests are started and supervised by an astronaut using a control station, an ISS standard equipment laptop computer. Data are saved onto the laptop harddrive, and are transferred to a ground-accessible network drive after completion of the test session. Download of data to the ground occurs the night after each test session, and video of the experiments will be downloaded within a week of each experiment. The data are delivered by NASA to the MIT SPHERES team and then forwarded to the guest scientists. Operational Summary The first phase of the SPHERES program is scheduled for launch on Space Shuttle flight STS-114, the first scheduled flight after Space Shuttle operations resume. The first onorbit tests will be conducted a few weeks after delivery to the ISS, and experiment sessions will continue for at least six months. Operation of the testbed in microgravity has already been demonstrated using NASA's KC-135 Reduced Gravity Airplane. The airplane flies a series of parabolic trajectories, alternating 20 seconds of microgravity with 40 seconds of increased gravity. A typical test flight consists of 40 of these parabolas, for a total microgravity time of about thirteen minutes. Test flights were conducted in with prototype hardware and software, and two flights were made during 2003 using flight-qualified hardware. In February 2003 the flight hardware was tested with preliminary software to characterize the dynamic behavior of the satellites. In November 2003 the satellites were tested with the software in a flight-ready condition to verify the performance of core algorithms used during on-orbit operations, characterize the inertia of the satellites, and demonstrate general software maturity. The limited time available in each parabola placed constraints on the types of algorithms that could be tested on the KC-135; however, the success of the tests performed demonstrated the operational capabilities of the SPHERES testbed in a microgravity environment, in preparation for deployment in the ISS SPHERES test sessions on the ISS are expected to occur every two weeks. Each guest scientist will have time scheduled in alternating test sessions. This gives guest scientists a one month iteration period in which to analyze data, interpret results, improve algorithms, and deliver new source code. The development process for algorithms for the SPHERES testbed is as follows: 1. The guest scientist develops theory and implements the algorithms according to the software interfaces specified in the GSP interface document. The scientist compiles the custom source code into the SPHERES simulation, and verifies expected behavior. The validated source code and a description of the expected experiment behavior is then delivered to the SPHERES team. 2. The SPHERES team tests the code in the 2D ground laboratory to ensure the code works on the hardware. 4

5 Any preliminary data from these tests are made available to the guest scientist. 3. Shortly prior to a test session, the SPHERES team uploads new programs and descriptions of expected behavior to the ISS. 4. During the test session, the astronaut loads a program on each satellite, and performs the experiments. Upon test completion, the astronaut provides a short description of the observed behavior, including an evaluation of whether the algorithm appeared to work as intended. The data are downloaded within one week. 5. Within one week, data are made available to the MIT SPHERES team. These data are forwarded to the guest scientist. 6. The scientist examines the data, and updates or modifies the algorithms based on the experiment results. This process of iterative development, test, and modification repeats until the guest scientist is satisfied with the results or the resources (batteries and tanks) allocated to that series of experiments have been depleted. Once the process is complete, the scientists will have algorithms with high probability of success in a full 6DOF space environment. Requirements Definition Providing a system that allows multiple scientists to participate in a research program creates a set of requirements that cannot easily be defined as a simple list of quatitative specifications. The requirements of the GSP are qualitative in nature and of a broad scope. The most important, yet broadest, requirement is to provide as much operational flexibility as possible so as to meet the project goals i.e. to develop a testbed for dynamics, controls, and autonomy algorithms in a microgravity environment. Given that the SPHERES development team could not predict the specific needs of future guest scientists, our design philosophy was to utilize the most capable equipment that could be obtained for the available funding. This strategy was adopted to provide guest scientists with sufficient resources to perform a wide variety of useful experiments. This approach is most clearly illustrated by the choice of the C6701 DSP processor. At the time of development is provided excellent FLOPS/Watt performance, and was backwards compatible with the C40 processor used in the prototype hardware [10]. A second requirement was to design the testbed with as much traceability as possible to proposed distributed satellite systems. To meet this goal, the system was sized to include three satellites, the minimum number required to perform complex formation flight, autonomy, and docking experiments. A compressed gas propulsion system with on-off thrusters was chosen, providing thruster dynamics directly traceable to those of many spacecraft thrusters. The system uses two communications channels, to separately service inter-satellite and ground communications. The requirements for the GSP core flight software follow similar guidelines: 1. The interface must support access to multiple guest scientists with diverse research goals. 2. The interface must provide access to a real-time operating system resembling those used in real space systems. 3. The interface must allow the maximum flexibility possible in algorithm design and implementation, while allowing the core software to maintain control over critical processes. These high-level requirements were broken down into a set of functional requirements for the software of the Guest Scientist Program: 1. The satellite onboard software must be re-programmable from the laptop control station. 2. The software framework must make it easy to run different tests. 3. The system must provide multiple levels of abstraction when accessing the SPHERES satellites hardware. 4. The software framework must be designed to ensure that a real-time controller can be implemented. 5. The interface must provide access to software processes operating at different priority levels: High priority for periodic control algorithms and similar tasks that complete in a short time and have strict real-time requirements. Medium priority for estimation algorithms and similar tasks that may take a long time to complete and need not meet real-time deadlines. Low priority for planning, health monitoring, and similar tasks that do not have real-time requirements. 3GSP SOFTWARE Although the collaborative science goals of SPHERES leveled some requirements on the hardware design, the testbed s software design was almost entirely driven by the 5

6 anticipated needs of the end user, namely, the guest scientist. The goal in the software design was to create an architecture that was relatively easy to learn and flexible enough to accommodate a wide variety of the sophisticated applications in advanced control, estimation and autonomy. The main challenge during this process was to balance often contradictory goals of usability and capability. The goal of ease-of-us called for a clear and logical model of software operation, and the automation of tedious or non-productive tasks. In contrast, the goal of versatile functionality suggested an emphasis on real-time performance and a flexible execution model. Clearly, the design must reflect these highlevel goals within the constraints imposed by the testbed hardware. The Real-Time Environment A third consideration, legacy source code and the choice of processor, further complicated the software design. The C6701 is faster and more capable than the C40 processor which powered the earlier prototype satellites. The first generation SPHERES software, written for the prototypes, was inflexible but effective [10]. Substantial effort had been expended to implement algorithms for control and estimation on the prototypes, and it was desirable to minimize needless reimplementation when transitioning to the flight hardware. In the software for the prototype satellites, one interface was provided to a periodic control process, and another to an estimation process. Since only a small amount of source code was required to implement these processes the processor did not need an executive or kernel. This design is illustrated in Figure 4. While this design was simple and functional, it lacked flexibility and did not provide a way to separate user processes from important housekeeping routines such as communications. Consequently, any long duration computation that occurred in user-supplied algorithms had the potential to disrupt other critical functions. In order to support the goal of providing a flexible interface to support varied user requirements, improvements were necessary in the software architecture. In addition, NASA safety requirements influenced the software redesign. Specifically, the NASA safety panel required that a satellite terminate communication and turn off the thrusters if it loses contact with the laptop computer. The model of structured, user-supplied routines was an attractive framework, and with the substantially improved processing power available with the flight hardware, a simple operating system could be developed to meet these needs. An operating system was needed to improve interface and execution flexibility, and to allow multiple threads to execute concurrently The Texas Instruments DSP/BIOS [12] real-time operating system, designed for DSPs such as the C6701, is used as the operating system on the SPHERES satellites. This product provides multi-processing capability, inter-process communication, and a number of input/output management tools. This simple OS (or kernel), interacts directly with the hardware and manages many of the details thread and interrupt handling. Through the addition of multiple distinct execution threads, the core housekeeping functions are separated from the test software. This separation ensures that activities such as communications and telemetry processing are not affected by any computationally-intensive algorithms supplied by the guest scientist. In addition, increased flexibility and other benefits of multi-threading are extended to the end user. Although DSP/BIOS solved of problem of flexibility, it was necessary to take steps to simplify the user s interface to the core software and underlying hardware. Giving the guest scientist general access to the entire OS would give them maximum flexibility, but this approach is undesirable for several reasons. First, to use the DSP/BIOS operating system directly, the user would have to purchase and then learn how to use DSP/BIOS. Second, without knowledge about the structure of the user-supplied code, it would be very difficult for us to guarantee the performance of the housekeeping functions and to meet NASA safety constraints. As a compromise, the model similar shown in the left figure in Figure 4 was adopted. The user is provided with a strict framework into which specialized source code may be inserted. Each module is executed when certain conditions are met. This allows the core software to manage the experiment s execution. The user s code does not interact directly with the hardware or with the DSP/BIOS interfaces. This simplifies the guest scientist s learning process, ensures proper operation of critical housekeeping functions, and facilitates the implementation of the SPHERES simulator. The core services also manage communications between the different processes. This helps to prevent race conditions between the periodic and aperiodic processes by ensuring atomic functions are used when required. Critical variables are accessible only via functions that have been designed to guarantee the preservation of data integrity. Although this model is not flexible enough for general-purpose computing, it is well-suited to the specific applications of estimation, control and autonomy for which the SPHERES testbed has been designed. Let us examine these software services, the user interface and the simulator in more detail. SPHERES Core Services (SCS) The SPHERES Core Services (SCS) software layer performs two functions. First, it acts as a buffer between the user-provided experiment code and the operating system and hardware. Mediating between these layers, the core services control the execution of the user-configurable processes and 6

7 Control PADS Hardware Background Control PADS Task SPHERES Core Services DSP/Bios Hardware Figure 4 Architectural comparison between first (left) and second (right) generation GSP software. Notice the reductions in interface complexity. In the second generation system, the modules can still communicate with each other, but they use the standardized interface with the services. encapsulate the operating system and hardware-specific interfaces. Second, this layer performs a number of background activities that are critical to successful operations. These functions are summarized below. Communications Access to the STS and STL communications channels is controlled by a Time Division Multiple Access (TDMA) scheme. This software module is responsible for receiving and processing incoming communications packets, and for transmitting out-going messages when allowed to do so by the TDMA protocol. The communications module also manages transmission and reception of the messages generated by the experiment code, such as custom telemetry or command data. If a data transfer is too long for a single packet (32 data bytes), the communications module segments the transmission and sends one packet at a time. The communications module on the receiving sphere automatically reassembles the original message from the constituent packets. Housekeeping and Telemetry The SCS performs a number of routine tasks automatically, without direct command by the user. During normal operations, the spacecraft monitors the tank fill status (by tracking thruster firing), battery charge level, and operational mode. In addition, automatic processes perform a rough estimation of the satellite state. These data are broadcast on the STL radio channel, and are monitored by the laptop, which logs the data to disk, and by the other satellites, which maintain estimates each other states. Propulsion Twelve thrusters control the motion of each sphere in translation and rotation. They exert a fixed thrust; and can be used in one of two modes. The simplest operating mode allows the user to command a fixed-duration firing. This approach mimics the standard practice on-board most real spacecraft. For the second control mode, the SCS implements pulse-modulation and provides an approximation of continuously-variable control over force and torque. The user may elect to use this operating mode either for simplicity (e.g. to allow the control law remains continuous), or to represent the behavior of a variable actuator such as a reaction wheel. Test Management A guest scientist s experiment is delivered to the MIT SPHERES team in the form of a number of source-code files. These are compiled into an executable program consisting of the DSP/BIOS kernel, the SCS, and the guest scientist code. Each program can execute one or more tests. Each test is a self-contained experiment and typically lasts a few minutes. When conducting an experiment session on the ISS, the crew member will reposition the satellites prior to each test and then command the test to start. The SCS layer, handles the interaction between the flight units and the laptop. This software must monitor the crew commands, and then initialize and begin the user s test. Once the test completes, the software disables the user code, the thrusters, and the active sensors. During the test operation this module ensures that the user code is run at the correct time and communication bound for the GSP layer is received correctly. By creating a process that oversees all test operations, the SCS layers fulfill the NASA safety board requirements. The SCS layer monitors the communications channels constantly. If no communications is received within a pre-specified period of time from the laptop, the SCS commands any current test to stop, turns off the thrusters, and stops transmitting data. Because the GSP has no access to this level of the SCS this safety measure is always enabled. (Note that the SPHERES software is not validated by NASA for fault pro- 7

8 HW DSP/BIOS SPHERES Core GSP HW Interrupts (User Code Modules) IMU IMU PADS (IMU) Supplemental Libraries (examples) Global PADS Global PADS PADS (Global) Math SW Interrupts Propulsion Propulsion Controller Test Init Control Control Estimation Comm Comm Housekeeping Planning Tasks GSP Background Tasks Task Execution Control User-Accessible Interface Hidden Interfaces Figure 5 Schematic of GSP software architecture. The SCS layer directs the execution of the user-supplied modules, and provides command interfaces to the user. Supplemental libraries can be accessed by the user to simplify common processing tasks. tection, rather the software constitutes the third level of safety on a one-fault tolerant requirement for intentional EMI. The SPHERES testbed meets NASA's limits for intentional EMI, but the safety panel wanted measures in place to ensure the units do not transmit via RF or actuate the thrusters if they are out of range and/or drift to the Russian modules.) User Interface The usefulness of the GSP hinges on the interface to the user s code. There are three main components to this interface: the execution framework, the Spheres I/O interface, and the supplemental libraries. This arrangement is depicted graphically in Figure 5. The GSP Execution Model When writing experimental algorithms for SPHERES it is important to understand the manner in which the code will run. As mentioned earlier, the software framework describes certain modules that the user must provide. These modules are executed by the SCS layer when particular conditions are met. Some modules execute periodically, others in response to events such as incoming communications or sensors. An important feature of our software architecture is that the code is multi-threaded. The highest priority thread waiting to execute is given control of the processor. This helps to guarantee that real-time deadlines are met. Although users cannot create arbitrary threads, they can mix periodic and aperiodic processing. The six GSP code modules are divided between four threads (Table 1). The four threads are described below. The code module Program-Init is run once when the SPHERE is turned on or reset. User code in this module can be used to allocate memory or initialize global data-structures. The control thread is a fairly common construct. It executes periodically at a user selectable rate. Standard, discrete control laws can be implemented in this module. Although execution rates of up to 1kHz are possible, most experiments to date operate at 1-20Hz. A secondary module runs in this thread and is triggered every time a test begins. This routine can be used to implement test-level initialization. The controller has a medium level of priority. This gives good realtime performance. Significant calculation can be performed inside the controller, but execution must finish before a control-period elapses. 8

9 TABLE 1. GSP Code Modules Module Thread Stimulus Priority Time Available Typical Purpose Program-Init Initialization System Startup N/A N/A Perform Global Initialization Test-Init Control Start of Test Medium Medium Initialization before the start of a test Control Control Periodic (up to Medium Medium Periodic controller 50Hz.) PADS-Global PADS Special (Sensor- High Short Store data from ultrasonic sensors Receive) PADS-Local PADS Periodic (Up to High Short Storing data from inertial sensors. 1000Hz) Task Task User-Selectable a Low Long Long term processing, interactive communication, etc. a User configures task to respond to one or more system events The two PADS modules can be used to process incoming sensor data. The first module, PADS-Global, is triggered when data are received by the ultrasonic sensors. Once a measurement is requested, this module will be triggered several times (once for each beacon). The second module controls the sampling of the inertial sensors: the rate gyros, and the accelerometers. This sampling can occur at up to 1000Hz. Both modules are high priority to minimize the response time, hence maximizing temporal accuracy of the incoming data. As a consequence, there is only a short time available to perform calculations typically just enough to store the data and perform some basic processing. The final thread is a special case. The task performs generalpurpose computation in response to specified system events. During initialization, the user s code selects the particular conditions they want to activate the task. Some of these events are unique to the task. For example, the user may make the task responsive to incoming communication. There is also the option to trigger the task from standard actions such as sensor sampling. Once active, the low-priority nature of the task allows long-term background calculations, without the risk of disturbing time-critical periodic activities. SCS Input/Output Interface To simplify control of the Spheres, the user s code issues all hardware commands through a set of intermediate functions. These commands hide the complexity of the hardware interface, and allow the SCS to control when the test code is allowed access to the hardware. These functions can be divided in the follow broad categories: Propulsion. Issue commands to the thrusters to turn on for a specified duration, report propellant usage, check thruster state. Communications. Send messages to the other Spheres or the laptop. Sensors. Read current state of the sensors, request an ultrasonic measurement, read position/velocity transmitted from other Spheres. Supplemental Libraries One of our objectives in the design of the GSP interfaces, is to minimize the effort that the Guest Scientists must expend on non-productive tasks. If they are interested in developing new estimators, we want to minimize the effort spent on getting the control-system to operate satisfactorily. To this end, we have developed a number of applications specific function libraries to help accelerate the development process. The range of functions include highlevel operations like controllers and estimators, as well as low-level routines such as matrix inversion. Although many libraries are tailored to the SPHERES environment, these routines do not issue commands directly to the SCS I/O interfaces. Instead, they perform the requested calculations and prepare a command for the I/O interface. Since the user must perform the last step (e.g. issuing the thruster command), there is never confusion or contention about what the hardware is doing. GSP Simulation The guest scientist begins the custom software development process by writing source code that adheres to the rules described in the GSP interface document [9]. The guest scientist compiles this source code and links it to pre-compiled SPHERES simulation objects; the resulting program is a simulation client, and represents a single satellite in the simulation environment. The build process is simplified through the use of a compiler configuration file and a standardized directory structure, enabling a client to be built in a single step. The complete simulation environment consists of one server program and up to five concurrently operating clients. The server contains a graphical user interface (GUI) for specify- 9

10 ing values for simulation and test parameters, as well as for displaying run-time feedback to the user. Simulation parameters include the dynamics environment, the maximum simulation duration, and the test number. Displayed on the GUI are the power status, maneuver number, propellant usage, and communications usage for each satellite. Errors, warnings and informational messages are printed to the Simulation Messages window. The GUI has buttons that open dialog boxes for specifying additional parameters such as the satellite initial state and the locations of the ultrasound beacons. Each client has a message window and a single button that functions equivalently to the power button on the satellite. The SPHERES simulation server and three client programs are shown in Figure 6 millisecond, the period of the fastest periodic interrupt on the SPHERES hardware. The server enforces synchronization by waiting for all clients to complete each one-millisecond time step before allowing any client to continue to the next time step. This step-by-step process is managed by the server, which sends out step commands and waits for a step completion report from each client. Included in the step command and completion messages are additional data such as state information and communication packets. The clients are multi-threaded, with the main thread handling the user interface and all timed processes, and one child thread running each of five task processes. This multi-threaded implementation allows the use of unmodified SPHERES source code in the task processes, including functions containing infinite loops, and preserves the free-running nature of the tasks with respect to the timed processes. Figure 7 illustrates the relationship between the simulation server and client processes. The simulation currently runs only on Microsoft Windows 2000 and later, and compiler configuration settings have been tested only in Microsoft Visual C and later. It should, however, be relatively simple to port the simulation to Mac OS X or Linux, since the simulation GUI is implemented using the cross-platform wxwindows toolkit [11]. The only platform-specific source code implements named pipes for inter-process communication between the simulation server and the clients. This inter-process communication functionality must be implemented separately for each target operating system. 4CURRENT GUEST SCIENTISTS Figure 6 The SPHERES simulation server and three satellite clients. The simulation supports all aspects of single and multi-satellite SPHERES operations, including start-up and initialization, STL and STS communications, and vehicle maneuvering. The simulation code base consists of almost all of the SPHERES core code, supplemented by additional code that simulates dynamics, communications, and hardware-level interaction. The simulation records the true state of each vehicle at 10 Hz, and saves all STL telemetry as it would be recorded by the laptop control station in the laboratory. A MATLAB function is provided to read, sort, and plot the data. The simulation is used both to verify syntactic correctness of custom code and to predict the behavior of the hardware in the laboratory and onboard the ISS. Once the simulation has shown that the custom code produces the desired behavior, the code is sent to MIT for verification on the SPHERES hardware in the laboratory. The simulation guarantees synchronization between the client programs for all timed processes to within one simulated Current participants in the Guest Scientist Program include NASA Goddard Space Flight Center, NASA Ames Research Center, and the Jet Propulsion Laboratory. Different teams at the MIT SSL, outside of the SPHERES team, also utilizes the GSP to conduct research. In addition, the MIT SSL SPHERES team conducts research for DARPA, which provided the flight-opportunity for SPHERES. The research within the SPHERES team also follows the GSP interface. DARPA provided the MIT SSL an ISS flight opportunity in order to investigate spacecraft rendezvous and docking algorithms. Researchers at MIT are developing control systems that will be tested in the SPHERES testbed to demonstrate the ability of spacecraft to dock autonomously. These technologies will enable missions for autonomous resupply of consumables, as well as autonomous space assembly. Several tests have been done in the KC-135 airplane as well in the 2D testbed. Docking tests will be performed in the first sessions in the Space Station. NASA Goddard Space Flight Center research concentrates on distributed control. The SPHERES testbed provides true 10

11 Other clients Client 1 Server Send step command and forward telemetry Wait for all responses Run periodic processes through completion Send telemetry and step complete message Data Task thread Wait for signal, then run task until function returns. Interrupted occasionally by periodic processes and other tasks. Other task threads Signal task Figure 7 The relationship between the simulation server and client processes. limitations in communications bandwidth, while providing enough telemetry information to determine the robustness and accuracy of the control. Goddard will run test of distributed control algorithms both in the KC-135 during November 2003 and in the first phase of SPHERES in early Goddard has provided multiple KC-135 flight opportunities in past. NASA Ames Research Center investigates different massidentification algorithms using the SPHERES testbed. These algorithms include identification of center-of-mass and well as a the inertia matrix for the system. Mass-ID tests have occurred in the KC-135 in the past, and will form part of the initial tests in the ISS in order to validate the models used in the SPHERES simulation. Research for the Jet Propulsion Laboratory concentrates on assisting the development of the Terrestrial Planet Finder mission (TPF). TPF consists of five separated spacecraft with optical elements that will be able to cancel the light of distant starts so as to see the light coming from planets in other galaxies. The mission requires robust and tested formation flight algorithms. Further demonstration is also needed for stepped controls, where nested control algorithms are used for actuators with overlapping precision (such as the coarse control of a satellite GNC system which overlaps with the medium precision control of a large optical delay line, which in turn overlaps with the fine control of precision steering mirrors). The SPHERES testbed helps develop the coarse formation flight algorithms, and validates them in a microgravity environment. Future upgrades to the SPHERES testbed can include optical elements to test and validate stepped control algorithms. Students within the MIT SSL, but who are not part of the SPHERES team, also use the GSP to perform their research. This research includes estimation, modern control, and autonomy algorithms. 5CONCLUSIONS The SPHERES laboratory not only provides a microgravity environment for the MIT Space Systems Laboratory, it creates an environment where multiple scientists can create and improve their algorithms. The design of the testbed brings forward a new concept in the development of experiments destined to the International Space Station by creating laboratory facilities rather than single experiments. The testbed opens the ability to use the ISS to scientists across the globe. Through this innovative design, the MIT SSL SPHERES team hopes to create a new trend of collaboration between those groups that use the International Space Station, maximizing the utilization of the ISS. The SPHERES Guest Scientist Program provides researches from outside the MIT SSL the ability to run their experiments in a microgravity environment. The implemented pseudo-operating system of SPHERES allows these scientists to access the SPHERES hardware at a level that best meets their needs, be it high-level functions or low-level hardware access. The GSP provides a SPHERES simulation to allow guests to test their code in-house first, before deployment to the MIT SSL facilities, followed by operations in the International Space Station. 6ACKNOWLEDGMENTS The authors would like to thank the sponsors of this work: the Defense Advanced Research Projects Agency, Ames Research Center, Goddard Space Flight Center, the Jet Propulsion Laboratory, and the Draper Laboratory. REFERENCES [1] Carpenter, R., Decentralized control of satellite formations, International Journal of Robust and Nonlinear Con- 11

12 trol (DOI: /rnc.680), Dec 2002, p [2] D. P. Scharf, F. Y. Hadaegh, and S. R. Ploen, A survey of spacecraft formation fying guidance and control (part I): Guidance," American Control Conf., Denver, June [3] Richards, A., Schouwenaars, T., How, J.P., and Feron, E., Spacecraft trajectory planning with avoidance constraints using mixed-integer linear programming, Journal of Guidance, Control, and Dynamics ( ), vol. 25, no. 4, July 2002, p [4] Jilla, C.D., Miller, D.W., and Sedwick, R.J., Application of multidisciplinary design optimization techniques to distributed satellite systems, Journal of Spacecraft and Rockets ( ), vol. 37, no. 4, July-Aug. 2000, p [5] Schweighart, S.A., Sedwick, R.J., High-fidelity linearized J(2) model for satellite formation flight, Journal of Guidance, Control, and Dynamics ( ), vol. 25, no. 6, Nov. 2002, p [6] Shaw, G.B., Miller, D.W., and Hastings, D.E., Development of the Quantitative Generalized Information Network Analysis (GINA) Methodology for Satellite Systems, Journal of Spacecraft and Rockets, Vol. 38, No. 2, 2001, pp [7] Saenz-Otero, A, Miller, D, The SPHERES ISS Laboratory for Rendezvous and Formation Flight, 5th International ESA Conference On Guidance, Navigation and Control Systems, Frascati, Italy, October 2002, paper #29 [8] Hilstad, M, A Multi-Vehicle Testbed and Interface Framework for the Development and Verification of Separated Spacecraft Control Algorithms, Master's thesis, Massachusetts Institute of Technology, Department of Aeronautics and Astronautics, June [9] Hilstad, M., Enright, J., Richards, A., SPHERES Guest Scientist Program Interface Document, MIT Space Systems Laboratory, 2003 [10] Saenz-Otero, A., The SPHERES Satellite Formation Flight Testbed: Design and Initial Control, Master's thesis, Massachusetts Institute of Technology, Department of of Electrical Engineering and Computer Science, August [11] wxwindows cross-platform toolkit, [12] TMS320 DSP/BIOS User s Guide, Texas Instruments SPRU423B, 2002 BIOGRAPHY John Enright is an Assistant Professor in Aerospace Engineering at the department of Aerospace Engineering at Ryerson University. While at MIT, he led the software development for the SPHERES flight project, and the GFLOPS real-time spacecraft simulation testbed. His research interests include systems engineering, flight software, communications, and avionics. He is currently investigating strategic opportunities for low-cost spacecraft avionics. He holds a BASc from the University of Toronto and a M.S. and a Ph.D. from MIT. Mark Hilstad is a Ph.D. candidate at MIT, in the Department of Aeronautics and Astronautics (Space Systems Laboratory). His research experience includes controller and state estimator design, and simulation development for formation flying spacecraft. He holds a SM degree in Aero/Astro from MIT and a BSAAE from the University of Washington. His work experience includes integration and test of the Cassini Saturn orbiter and Mars Exploration Rovers and control system design for the Formation Interferometer Testbed at the Jet Propulsion Laboratory. Alvar Saenz Otero is a Ph.D. candidate at the MIT Aeronautics and Astronautics Department/Space Systems Laboratory. He is the lead research assistant in the SPHERES project; during the program beginnings he was the Teaching Assistant for the capstone laboratory undergraduate class. His research concentrates on formation flight and the design of laboratories. He previously worked on the Origins testbed, part of NASA's NGST program, in the development of automatic optical alignment. He has MEng and BS degrees in Electrical Engineering and a BS degree in Aero/Astro from MIT. David W Miller is an Associate Professor and Director of the Space Systems Laboratory in the Department of Aeronautics and Astronautics at MIT. His research focus is on dynamics, controls and systems engineering as applied to distributed satellite systems and precision optical telescopes. He has developed a series of ground testbed and Shuttle flight facilities for the conduct of research into dynamic modeling and control synthesis for precision optical systems envisioned under NASA's Origins Program. He is 12