SPHERES
Synchronized Position Hold Engage and Reorient Experimental Satellites
Requirements Document
16.684 Experimental CDIO Capstone Course
MIT Department of Aeronautics and Astronautics
Version : 2.1
Date : 12/8/99
---------------------------------------------------------------Stephanie Chen
Brad Pitts
Configuration Control
SPHERES Requirements Document
1
Table of Contents
INTRODUCTION ........................................................................................................................................ 2
FLIGHT ARTICLE DESCRIPTION ......................................................................................................... 2
EXPERIMENT SCIENCE OBJECTIVE .................................................................................................. 2
SCIENCE OBJECTIVE .................................................................................................................................... 2
SPECIFIC SCIENCE OBJECTIVES ................................................................................................................... 2
ENGINEERING SYSTEMS REQUIREMENTS ...................................................................................... 2
JUSTIFICATION FOR FLIGHT ............................................................................................................... 4
SUBSYSTEM REQUIREMENTS .............................................................................................................. 5
Revision A
Release Date : 12/8/99
SPHERES Requirements Document
2
Introduction
New scientific and economic objectives are creating a demand for small, autonomous satellites
capable of formation flying. Current missions, such as Separated Spacecraft Interferometry, require large
diameter observation areas. Today’s single-unit satellites cannot provide this; they are limited in size by
launch and deployment capabilities. A group of smaller satellites flying in an array would provide the
desired area improvement; furthermore, the smaller size of individual satellites and the increased
modularity of a constellation system would result in a reduction of launch and maintenance costs.
The SPHERES project is designed to create a testbed to prove the viability of autonomous
formation flying control algorithms. SPHERES will provide a testbed with six degrees of freedom to
evaluate the dynamics of a multiple satellite system. It will also test the ability of a constellation of
independent objects in a micro-gravity environment to interactively communicate, maintain position, run
diagnostics, regroup after disturbances, and move to commanded locations.
Flight Article Description
The SPHERES hardware will consist of three or more free-flying satellites. Each satellite will
contain all propulsion, control, avionics, and communications systems necessary for autonomous
communication and maneuvering in a micro-gravity environment. Individual satellites will also measure
their own positions with respect to a pre-defined reference frame, and communicate this data to the other
units. These measurements may involve extra hardware in the test room.
All hardware on the satellites will be standardized. This includes common propulsion, structure,
avionics, Inertial Navigation System (INS), power, and communications subsystems. A common operating
system will also be employed, but control software may be made specific to individual satellites. This may
allow for the creation of hierarchies among the satellites.
The satellites will be accompanied by a laptop computer that will serve as both the ground control
center and the final data storage unit. As a ground control center, the computer will allow multiple
algorithms to be easily tested. It will evaluate the performance of each algorithm by analyzing the stored
data received from the satellites.
Experiment Science Objective
Science objective
The objective of SPHERES is to develop a testbed that demonstrates formation flying algorithms between
multiple autonomous satellites with six degrees of freedom, in a microgravity environment.
Specific Science Objectives
1.
2.
3.
4.
5.
6.
To develop a set of multiple distinct satellites that interact to maintain commanded position,
orientation, and direction.
Allow re-configurable control algorithms, data acquisition and analysis, and the acquisition of a truth
measure.
Demonstrate key formation flying maneuvers such as array capture, attitude control and station
keeping, disturbance rejection, re-targeting, and recovery.
Demonstrate autonomy, onboard re-planning, fault-detection and recovery, and health and status
reporting.
Ensure the implementation of control algorithms is adaptable to future formation flying missions.
Meet requirements for operation on KC-135, shuttle mid-deck and ISS.
Engineering Systems Requirements
1.0
Science Objective: To develop a set of multiple distinct satellites that interact to maintain
commanded position, orientation, and direction.
1.1
Satellites require translational, rotational, and attitude control capabilities. [must]
Revision A
Release Date : 12/8/99
SPHERES Requirements Document
3
1.2
2.0
3.0
4.0
Each satellite must contain its own propulsion, avionics, software, power, communication,
and INS systems within its own structure. [must]
1.3
Software must perform a given task based on inputs from a third-party control algorithm.
[must]
1.4
Satellites must be able to communicate their relative positions to each other and to outside
sources. [must]
1.5
Satellites must maintain constant communication links. [must]
1.6
Satellites must ascertain commanded positions and move to them. [must]
1.7
Satellites must maintain static array under disturbances. [must]
1.8
Satellites should employ handshaking and negotiation for decision-making. [should]
1.9
Array should consist of at least three distinct satellites to fully demonstrate the capabilities
of a control algorithm. [should]
Science Objective: Allow re-configurable control algorithms, data acquisition and analysis, and the
acquisition of a truth measure.
2.1
On board the satellite
2.1.1
Satellite must be able to receive control algorithms. [must]
2.1.2
Satellite must be able to acquire, analyze and send data [must].
2.1.3
Data must allow measurement of orientations and positions of the satellites
relative to each other. [must]
2.1.4
Data must allow measurement of the orientation of the satellite array relative to
the KC-135 / ISS. [must]
2.1.5
Some of the downloaded information must relate to health status information.
[must]
2.2
On board the KC-135 / ISS
2.2.1
An environment must be established (i.e. transponders fixed to KC) by which to
measure the position of the array and individual satellites to verify accuracy.
[must]
2.2.2
Laptop must be able to send control algorithms to satellite(s). [must]
2.2.3
Laptop must have the ability to capture and store downloaded data. [must]
Science Objective: Demonstrate key formation flying maneuvers such as array capture, attitude
control and station keeping, disturbance rejection, re-targeting, and recovery.
3.1
Array capture
3.1.1
Array should perform self-diagnostic on power up [should]
3.1.2
Array must communicate between entities [must]
3.1.3
Satellites must translate to commanded position [must]
3.1.4
Satellites must determine relative position [must]
3.1.5
Satellites must determine absolute position [must]
3.1.6
Satellites must have ability to change commanded position and attitude, as
necessary [must]
3.2
Attitude control and station keeping
3.2.1
Satellites must rotate to commanded attitude [must]
3.2.2
Satellites must maintain commanded position [must]
3.2.3
Satellites must maintain commanded orientation [must]
3.3
Disturbance rejection
3.3.1
Satllelites must have sufficient control authority to counteract environmental
effects [must]
3.3.2
Satllelites should have sufficient control authority to counteract other nontestbed effects [should]
3.4
Re-targeting
3.4.1
Requirements specified in 2.1 and 2.2
3.5
Recovery
3.5.1
Requirements specified in 2.1 and 2.2
3.5.2
Detection of faults [must]
Science Objective: Demonstrate autonomy, onboard re-planning, fault-detection and recovery, and
health and status reporting.
Revision A
Release Date : 12/8/99
SPHERES Requirements Document
4
4.1
5.0
6.0
Each satellite must carry all the components or functions essential to its own operation,
including onboard power, propulsion, communications, control, guidance, and navigation
systems.
4.2
Each satellite should be able to complete its commanded maneuvers without constant
communication with the device that issued the control algorithm or command.
4.3
When necessary, each satellite should be able to compensate for the failure of any or all of
the other satellites.
4.4
Each satellite could be able to detect a total failure of one of the others.
4.5
Each satellite must be able to recognize and compensate for minor failures in its
subsystems.
4.6
Each satellite should be able to report any minor failures back to an external monitor.
4.7
Each satellite should be able to regularly report the status of each of its subsystems.
4.8
All of the satellites should be physically identical.
Science Objective: Ensure the implementation of control algorithms is adaptable to future formation
flying missions.
5.1
Control algorithms for multiple satellites must be traceable to future missions.
5.2
The dynamics of the propulsion system must be representative of expected applications.
5.3
The precision of measurement of the metrology system must be equivalent to that achieved
in actual applications.
5.4
The data communicated between and to each satellite must be the same as that available in
real missions.
Science Objective: Meet requirements for operation on KC-135, shuttle mid-deck, and ISS.
6.1
ENGINEERING REQUIREMENTS FOR KC-135
6.1.1
Functionality needs to be demonstrated in <20 sec.
6.1.2
Formation flying sequence needs to be demonstrated within the space confines
of the KC-135 (TBD)
6.1.3
Touch temperature between -18C and 50C
6.1.4
Start and stop transient within 5 seconds
6.1.5
Controllable and retrievable within (TBD) so as to allow for retrieval and
restraint during 2g fall section of flight
6.1.6
Design must allow for repairs and fault correction within (TBD)
6.1.7
Must meet safety requirements for KC-135
6.2
ENGINEERING REQS. FOR SHUTTLE MIDDECK AND ISS
6.2.1
Satellites and external hardware must fit into shuttle mid-deck locker.
6.2.2
Satellites must resist and compensate for suction into mid-deck air scrubber
vents.
6.2.3
Formation flying must be demonstrated within the confines of the mid-deck.
6.2.4
Temperatures must not exceed range of -18C to 50C.
6.2.5
Experiment must have emergency teardown time within 30 minutes.
6.2.6
Total protocol testing time must be within (TBD) with minimum break times of
(TBD).
6.2.7
Set up and tear down within (TBD)
6.2.8
Weight limitations within (TBD)
6.2.9
Applicable shuttle and ISS safety requirements.
Justification for Flight
The goal of developing an array of autonomous satellites is to produce control algorithms that can
be applied in a variety of fields. Although such algorithms currently exist, they do not allow full modeling
of the dynamics and accuracy necessary. In order to produce new algorithms, an array of satellites must be
developed and tested in an environment that closely simulates micro gravity. Such an ideal environment
would allow natural asymptotic dynamics to emerge, system dynamics to develop, maneuvers with six
degrees of freedom (DOF), time to test the array during slewing and simulated errors, and be as cost
effective as possible. Therefore, the testing environment is subject to the following limitations:
Revision A
Release Date : 12/8/99
SPHERES Requirements Document




5
Simulation of Dynamics: Simulating environmental effects computationally can potentially neglect
important aspects of the natural dynamics. The best way to account for these effects on a system is to
place the system in the environment.
Degrees of Freedom: In order to properly model the system, the full complement of 6 DOF are
required. Fewer than 6 DOF platforms fail to capture the full dynamics of the 6 DOF system. The 6
DOF environment also allows traceability and modeling of formation flying maneuvers, especially
large out-of-plane coordinated movements.
Experiment Duration: To perform complicated formation flying maneuvers, sufficient time per run is
required.
Cost: It is strongly desired to minimize cost while meeting all other requirements.
Several possible platforms have been considered with the limitations above in mind. The results are shown
in the table below. “X”’s indicate the inability of a system to satisfy the requirements.
System
Free Flyer (earth)
Shuttle Payload
Shuttle Middeck
KC-135
Neutral Buoyancy Tank
Robot Helicopters
6 DOF Robot Arms
Helium Balloons
Suspension
Robot Cars
Air Table
Computer Simulation
Drop Tower
Dynamics
X
DOF
Duration
X
X
X
X
X
X
X
X
X
X
X
X
X
Cost
X
X
X
Notes
Cost; propulsion; -g dynamics
High cost; space environment
High cost
Limited time
Drag; propulsion
Wind currents
Unable to model -g dynamics
Unable to fully model 6 DOF
Tether problems; -g dynamics
2 Dimensional
2 Dimensional
Not account environment changes
Max time ~5 sec
After considering these results, the shuttle middeck is the platform that best meets all the scientific
limitations listed. Unfortunately, this is a very expensive platform on which to test the basic concepts. The
KC-135 is a significantly less expensive platform that meets all limitations, except that for duration of
experiment. For very basic formation flying maneuvers, experiment duration is not as critical.
Consequently, the KC-135 has been chosen as a forerunner platform to the Shuttle Middeck.
Subsystem Requirements
1.
Propulsion
1.1. Performance
1.1.1. Large Isp (TBD)
1.1.1.1. Minimum acceleration of 0.16m/s2
1.1.2. System should provide constant performance in 6 DOF.
1.1.3. System must provide for 6 DOF
1.1.4. Propellant supply sufficient to last duration of 20 seconds
1.1.4.1. Propellant supply sufficient to last duration of 20 seconds minimally with all devices
operating at “max” thrust
1.1.5. Propellant supply should be sufficient to last duration of entire flight (KC-135 or shuttle
mid-deck)
1.2. Safety
1.2.1. Non-toxic byproducts
1.2.2. Temperatures not to exceed range (TBD)
1.2.2.1. Temperature and causal temperatures cannot exceed range (TBD)
1.2.3. Non-touch hazard: -18C<T<50C
1.3. System must be self-contained
Revision A
Release Date : 12/8/99
SPHERES Requirements Document
6
1.4. System should employ a means for detecting functionality of system other than satellite
orientation change. (i.e. diagnostic capabilities)
1.5. Minimal computations as a result of “firing”
1.5.1. System should operate such that minimal computations are necessary to calculate the future
trajectory and orientation based upon thrusting profile.
2.
Structure
2.1. Structural integrity
2.1.1. The structure must be able to survive Shuttle launch and landing loads
2.1.2. The structure must be able to survive a drop of 4 feet in 2-g into an impact-absorbent
material
2.2. Satisfaction of mass constraints
2.2.1. Total experiment (3 satellites + support equipment) must fit in standard middeck locker (60
lbs = 27 kg)
2.2.2. Each satellite should be less massive than 7 kg
2.2.3. Structure should constitute approximately 10-20% of total satellite dry mass (0.3-0.7 kg)
2.3. Satisfaction of geometric constraints
2.3.1. The greatest dimension must be less than 9 inches (Shuttle middeck locker)
2.3.2. The smallest “major” dimension must be no shorter than longest component
2.4. Internal components should be provide easily accessible
2.4.1. Fuel tank and battery must be accessible for swap during mission
2.4.2. Components must be accessible for trouble shooting without necessitating major
disassembly of a satellite.
2.5. Must be manufacturable and safe under crew handling
3.
Avionics
3.1. Sufficient data storage capacity
3.1.1. Data capacity must be at least 2k for Satellite to Satellite (STS) Communication
3.1.2. Data capacity must be at least 3.5k for Satellite to Ground (STG) Communication
3.1.3. Data capacity must be at least 3.5k per second for telemetry onboard storage
3.2. The Volume and weight must be below (TBD)
3.3. System must be compatible with communications, propulsion, and metrology
3.4. Low power drain
3.4.1. Power must be lower than 4W (TBR).
3.4.2. Volt and Amp draw must be lower than (TBD).
4.
Power
4.1. Total power should be 18 W (TBR)
4.1.1. 18 W chosen from camcorder battery estimates
4.1.1.1. Should not exceed 3 camcorder batteries due to mass and volume constraints
4.1.1.2. Battery should run for minimum of 1hour- average camcorder battery is 6 V,
conservative estimate for capacity is 1Ahr. (18V*1Ahr)/1hr=18W
4.1.2. Power must be distributed to propulsion, communications, INS, and metrology
4.1.3. Minimun/maximum Voltage requirements
4.1.3.1. Minimum/maximum voltage TBD
4.1.4. Minimum/maximum Amp requirements TBD
4.2. Minimum battery lifetime should be determined by 10 parabolas.
4.3. All hardware must be contained in individual satellite
4.3.1. Total weight of hardware must be less than 2 kg (TBR)
4.4. Components must be compatible with KC-135, Shuttle, and ISS environments
4.4.1. All components of the satellite system must meet the safety and size requirements for each of the three
distinct operating environments
4.5. System should be traceable to existing satellites
4.5.1. The concepts of the power system must be applicable in an actual space environment.
5.
Software
Revision A
Release Date : 12/8/99
SPHERES Requirements Document
7
5.1. Must have common programming language
5.2. Must be flexible to allow execution of complex maneuvers
5.2.1. Must be fast to compile to minimize data transfer time and speed of maneuvering
5.2.2. Must be able to choreograph complex maneuvers efficiently
5.3. Must provide interface between input (metrology) and output (propulsion)
5.4. Must develop efficient code compiling techniques
6.
Communication
6.1. Satellite to Satellite (STS) Communication
6.1.1. Must be real time
6.1.2. Must be able to send, receive, and temporarily store data
6.1.3. Must be compatible with KC-135 / Shuttle systems
6.1.4. Must be traceable to existing satellite technology
6.1.5. Data transmitted to other satellites:
6.1.5.1. Position data - 3 co-ordinates (x, y, z)
6.1.5.2. Velocity data - 3 components (u,v,w)
6.1.5.3. Acceleration data - 3 components (ax, ay, az)
6.1.5.4. Confirmation of maneuver command completion
6.1.6. Must be able to store information such as:
6.1.6.1. Formation flying algorithm
6.1.6.2. Positional information of all other satellites
6.2. Satellite to Ground (STG) Communication
6.2.1. Does not have to be real time
6.2.2. Data must be recorded for post-flight analysis
6.2.3. Must be compatible with KC-135 / Shuttle systems
7.
Guidance, Navigation, and Metrology
7.1. Navigation
7.1.1. Real time information to be refreshed at 50 Hz
7.1.2. Accuracy
7.1.2.1. Position to 5 mm
7.1.2.2. Attitude to 2.5º
7.1.3. Must meet space shuttle and KC-135 interface, interference, & safety requirements
7.1.4. Setup in 20 minutes (TBR)
7.1.5. Interface with other subsystems
7.1.5.1. Communications
7.1.5.2. Avionics
7.1.5.3. Power
7.1.5.3.1. Onboard = 2 W (TBR)
7.1.5.3.2. Off-board = 10 W (TBR)
7.1.5.4. Structures
7.1.5.4.1. Mass = 0.3 kg (TBR)
7.1.5.4.2. Volume = 20 mL (TBR)
7.2. Truth Measure- System development on hold
7.2.1. Accuracy
7.2.1.1. Position to 5 mm (TBR)
7.2.1.2. Attitude to 2.5º (TBR)
7.2.2. Must meet space shuttle and KC-135 interface, interference, & safety requirements
7.2.3. Interface with other subsystems (not an onboard system)
7.2.4. Off-board requirements
7.2.4.1. Power = 2 W (TBR)
7.2.4.2. Volume = 5000 mL (TBR)
Revision A
Release Date : 12/8/99