SPHERES

NASA. Public domain (NASA / US government work).

Overview

SPHERES is a set of self-contained free-flying satellites operated inside the International Space Station as a reprogrammable testbed for guidance, navigation, control and autonomy algorithms for distributed spacecraft. Development began in a senior undergraduate class at the MIT Space Systems Laboratory in autumn 1999 [1]. Two prototypes flew parabolic campaigns on the KC-135 in February and March 2000 and November 2001, and five flight satellites were built at Payload Systems in spring 2002. The program was funded by DARPA and flown through the US Department of Defense Space Test Program [8]. It is formally the SPHERES Laboratory for Distributed Satellite Systems, and its stated purpose is a representative, risk-tolerant environment aboard the station in which metrology, control and autonomy algorithms for distributed satellite systems can be matured through repeated research cycles of increasing complexity [12]. Research supported through the Guest Scientist Program since spring 2000 covers formation flight, communications requirements, mass properties identification, autonomous rendezvous and docking, and tethered formation flight.

Three satellites were deployed to the station in 2006 and the facility has been operated by NASA since 2010 [5]; Astrobee was later designed to replace it [4].

Specifications

Parameter	Value	Source
Wet mass	4.38 kg
Dry mass	4.21 kg
Maximum span	20 x 20 x 25 cm
Structure	18-sided polyhedron	[8]
Wet inertia about the center of mass	2.30, 2.42, 2.14 x 10^-2 kg m^2
Center of mass offset from geometric center, wet	(0.48, -1.19, 1.08) mm
Thrusters	12, cold gas CO2	[1], [7]
Average power	15 W
Endurance per battery set	about 90 min	[2]
Metrology	24 ultrasonic receivers, 12 IR receivers, 24 IR transmitters	[1], [7]

Rows with no marker are from [1].

Published mass figures differ. The flight fact sheet dated 21 November 2002 gives 4.38 kg wet and 4.21 kg dry against a 20 x 20 x 25 cm envelope [1]; the NASA facility fact sheet gives 3.5 kg and 0.2 m diameter [8]; the VERTIGO thesis quotes 4.16 kg and 21.3 cm [6]. The fact sheet values are the CAD mass properties for the flight unit including propellant.

Mission profile

Parameter	Value	Source
Host	International Space Station	[12]
Test equipment launched	one beacon and one beacon tester, August 2003	[1]
First satellite delivered	Progress 21P, 24 April 2006	[1]
Second satellite delivered	STS-121, 4 July 2006	[1]
Third satellite delivered	STS-116, 9 December 2006	[1]
Units on orbit	3, with 3 more retained at MIT for ground work	[7]
Facility operated by NASA	from 2010	[5]
Test sessions	more than 50 by September 2013	[5]
Superseded by	Astrobee	[4]

Mobility

Translation and rotation are produced by 12 on/off solenoid thrusters fed with carbon dioxide [10]. The thrusters sit at +/-5.16 cm and +/-9.65 cm from the geometric center along the body axes, arranged so that any combination of body forces and torques in six degrees of freedom can be produced [1]. Thrust per thruster is below 0.2 N with a unit-to-unit variability of 0.01 N, and the per-thruster values measured on a single satellite fall between 0.1241 and 0.1340 N. The nozzle exit diameter is 0.838 to 0.844 mm.

The gas path runs from a custom chromoly steel cylinder of 337.5 g dry mass, through a brass pin valve carrying a burst disc that ruptures at 20.7 MPa (3000 psi), to a modified Leland regulator [2]. Tank capacity is 172.4 g of CO2 at 5.93 MPa (860 psig), the vapor pressure of liquid CO2 at 22 C. The regulator cannot be set above 379 kPa (55 psi), and the flight nominal operating pressure is 241 kPa (35 psi) [1]. Downstream of the regulator sit a 25 cm^3 stainless gas capacitor, two relief valves holding the low side below 400 kPa (58 psi), MINSTAC manifold tubing and titanium nozzles rounded to meet crew touch-safety requirements [2]. Solenoid minimum open time is 5 ms as built and is modifiable in the firing circuit, and each solenoid has a latency of about 6 ms, which is one to two orders of magnitude shorter than a typical commanded firing [10].

At the 379 kPa (55 psi) regulator setting the isentropic model gives 6.70 x 10^-4 kg/s per thruster, 0.248 N of thrust and a specific impulse of 37.7 s; at 207 kPa (30 psi) the specific impulse falls to 33.5 s [2]. The prototype propulsion budget assumed about 10 minutes of operation with two to four thrusters at 50 percent duty cycle, and noted that all 12 thrusters firing continuously empty the tank in under one minute [3].

Tests are terminated when a satellite reaches the boundary of the test volume defined by the wall beacons [1].

Power and energy

Each satellite carries two packs of AA alkaline cells with a Schottky diode per pack to prevent charging [1]. Average power is 15 W, standby 13.75 W and maximum 16.25 W. Sixteen Duracell Ultra alkaline AA cells are fitted per flight satellite as two eight-packs in parallel at 12 V, giving roughly 90 minutes of operation and drawing about 13.8 W [2]. The bus is stepped to 3.3, 5.0, 12.0 and 22.0 V behind a 1.5 A Polyswitch, with a bypass capacitor sized for the transients thrown by thruster switching. The regulators are Traco TS13.3S2ROSH and TS15.0S2ROSH for the 3.3 V and 5 V rails and MAXIM MAX772, MAX776 and MAX668 for +15 V, -15 V and the 22 V propulsion supply [1].

The prototype used a different arrangement: 13 AA alkaline cells in series at 19.5 V and 2.8 Ah, tested to about 90 minutes with a 6.6 W average draw [3]. Batteries and CO2 tanks are consumables: the crew swaps both on every satellite before each test session, unpacks and stows the supply, and repacks the empty tanks for return to the ground and refilling [4]. The consumable swap is the entire energy resupply path: the satellites carry no solar array and no recharge interface, and were operated for a decade on that basis.

Thermal

No thermal control design is published. The satellites operate inside the pressurized cabin at crew-compatible temperatures and carry no radiator, heater or coolant loop in any of the retrieved documentation.

Compute and avionics

Computation runs on a Sundance SMT375 module carrying a Texas Instruments TMS320C6701 digital signal processor at 167 MHz, rated at 1 GFLOPS peak, with 16 MB RAM, 512 kB cache, 224 kB of available ROM and six comports at 20 Mbps [1]. A Xilinx Spartan II XC2S200 FPGA clocked at 25 MHz handles the metrology timing, and a MAX1294 provides six channels of 12-bit analogue-to-digital conversion. The prototype flew a TMS320C40 at 50 MHz with 512 kB of RAM for control and a separate Onset Tattletale 8 built around a Motorola 68332 at 16 MHz for metrology [3].

The inertial measurement unit is three Honeywell accelerometers and three Systron rate gyroscopes, both sampled at up to 1000 Hz [1]. The accelerometers have a sensor range of +/-30 g conditioned to a designed range of +/-25.6 mg across 0 to 4096 counts, giving 12.5 mg/count, with bias under 8 mg, 300 Hz bandwidth, noise under 7 mg rms from 0 to 10 Hz and under 70 mg rms from 10 to 500 Hz, and axis misalignment under 7 mrad. The gyroscopes cover +/-83 deg/s at 30 mV/(deg/s), which is 0.0407 deg/s per count, with bandwidth 50 Hz at the -90 degree point, bias variation over temperature under 3.0 deg/s, short-term bias stability under 0.05 deg/s over 100 s, one-year bias stability under 1.0 deg/s, and noise under 0.05 deg/s/sqrt(Hz) over 0 to 100 Hz [1].

Flight software runs two timer interrupts over a background process [13]. The medium-priority control interrupt executes at any integer frequency up to 25 Hz and can be changed by the control algorithm at any time; the high-priority propulsion interrupt runs at 1 kHz and gives 1 ms pulse-width resolution on the thrusters. A PADS interrupt fires when new sensor data arrive and propagates the state; the low-priority background loop handles communications, position and attitude updates and housekeeping. State is exposed to the algorithm writer through eight global structures covering communications, control, debug, guest scientist code, position and attitude determination, propulsion and housekeeping, system identification and telemetry. Guest algorithms attach through one of three interface frameworks, standard, direct and custom, distributed with source examples and a simulation environment.

Autonomy

Navigation uses an ultrasonic time-of-flight system that the program describes as pseudo-GPS [6]. A satellite emits an infrared pulse in all directions; each beacon that receives it replies with a 40 kHz ultrasonic ping after a delay fixed by its address, so the time between the infrared flash and each arrival gives range, and the pattern of which receivers heard the ping gives bearing [7]. The ultrasonic carrier is 40 kHz and five battery-powered beacons are set up in the test area [2]. Beacons ping 20 ms apart in address order, and running only the odd addresses on the five wall beacons widens the spacing to 30 ms [1]. Up to nine beacon addresses can be in use at once.

Each satellite carries 24 ultrasonic receivers, four on each of six faces [7], 12 infrared receivers and 24 infrared transmitters at 880 nm, plus a single onboard ultrasonic beacon 10.7 cm from the geometric center on the docking face [1]. The onboard beacon is what makes relative metrology possible: global metrology fixes the satellite in the ISS frame from the five wall beacons, and relative metrology fixes another satellite in the body frame from its onboard beacon, which emulates a sensor with a limited field of view [7]. Maximum metrology update rate is 6.7 Hz by calculation, nominal rate is 1 to 2 Hz and maximum range is 4 m [1].

The global extended Kalman filter updates at 5 Hz synchronized to the beacon ping cycle, while gyroscope data taken at 1 kHz are batch filtered and downsampled to 20 Hz for attitude propagation [1]. Measured position precision is about +/-1 mm near the center of the test volume where all five beacons are in line of sight, and calibrated ultrasonic range measurements are accurate to within 6 mm. Ranging error after bias correction was characterized at +/-3 mm on the ground, with the global ranging update defaulting to 1 Hz and selectable from 0 to 5 Hz [2].

Thruster commands are produced by a mixing matrix that maps the six-axis force and torque demand onto 12 on-times [10]. The top half of the 6 by 12 matrix holds the calibrated force vector of each thruster and the bottom half the cross product of force and thruster location, and its pseudo-inverse converts a command vector into fractions of the control period for pulse-width modulation. Because propellant burn moves the center of mass and changes the inertia, an online mass property identification routine estimates both from thruster commands and gyroscope data during operation. The reconfigurable control allocation extends the same idea to satellites carrying attached payloads, recomputing the mixing matrix when the configuration changes [11].

Communications

Two independent radio channels operate in the 900 MHz band [8]. Both are half duplex and are carried on a token-ring packet network [2]. Satellite-to-satellite traffic uses an RFM DR-2000 at 916.5 MHz and satellite-to-laptop traffic an RFM DR-2001 at 868.35 MHz, each at 18 kbps and 70 packets per second [1]. The scheme is TDMA with a nominal 150 ms frame that the user can change, carrying 32-byte data packets. The expansion port adds a 32-bit global data bus shared with internal components, 31 address lines, three addressable components and one wired RS232 line at 115 kbps [1].

Payload and instruments

The expansion port is the reason the facility outlived its original formation-flight charter. Payloads flown on it include VERTIGO for vision-based navigation, RINGS for electromagnetic formation flight, the Slosh experiment for fluid dynamics in microgravity, the Ames smartphone payload, and the InSPIRE-II payloads, which are the Universal Docking Port and the Halo [15]. RINGS was sponsored by DARPA to test electromagnetic formation flight and wireless power transfer: in the formation flight mode a pair of units generate a synchronized alternating magnetic field whose amplitude and phase are independently controlled on each unit, producing attraction, repulsion and torque as a function of separation and relative orientation. The SmartSPHERES payload adds a Samsung Nexus S handset as an embedded controller, contributing a 1 GHz ARM processor, 512 MB of RAM, 16 GB of non-volatile storage, color cameras, temperature, sound, gyroscope and accelerometer sensors, a touchscreen display and Wi-Fi networking, all running Android [5].

VERTIGO adds a stereo camera head and a separate computer. The specification is a 1.2 GHz Via Nano U3300 single-core processor on a Via Pico-ITX P830 board with a VIA VX900 chipset, 4 GB of DDR3-1066, two 64 GB SATA flash disks and Ubuntu Linux 10.04 Server [6]. The cameras are two IDS-Imaging uEye LE 1225-M-HQ units with 1/3 inch monochrome global-shutter CMOS sensors at 640 x 480 and 6 um pixels on a 9.0 cm baseline with hardware exposure timing and synchronization, behind Fujinon 2.8 mm f/1.3 lenses, running at 87 fps maximum and 10 fps typically with exposures from 80 us to 5.5 s. Two Phillips Rebel Star LEDs at 617 nm and 134 lm at 700 mA each provide illumination. Mass is 1.326 kg without battery and power draw is 16 W idle, 20 W typical and 32 W maximum [6]. It launched on Soyuz TMA-06M on 23 October 2012 and completed five test sessions between February 2013 and July 2014 [6], [15].

Docking ports are classified in the SPHERES design work by whether they are androgynous, radially symmetric, rigid, reconfigurable, reusable or single use, and by optional features including electromagnetic attraction and repulsion to brake the closing motion [16]. The Universal Docking Port replaces the Velcro interface with a mechanism. A protruding lance enters a mating hole and a motor secures it, and each port carries a camera and visual markers that measure relative range and angle during the approach [15]. The flight unit is 14 x 10.7 cm and 0.533 kg, operating at a maximum of 6 V and 5 W peak, against a ground prototype of 7.6 x 3.8 cm, 0.45 kg, 24 V and 60 W peak [16]. Both hold a maximum docking tolerance of 1 cm and 2 degrees, but sensing accuracy improved from 1 cm and 0.5 deg on the prototype to better than 2 mm and 1 deg in flight. The prototype carried an electromagnet wound about an iron mechanism to brake the closing motion, which was removed because the flight port is limited to 11.1 V and could not generate useful force at that voltage, and because the added mass reduces the control authority of the satellite [16]. As a payload the port has mass properties of 0.376 kg with a center of mass 2.48 cm from the primary interface, which the reconfigurable control allocation has to account for [14].

Modes of operation

The baseline docking interface is four 1 inch square Velcro patches, two of hooks and two of loops, arranged around the ultrasonic beacon on the docking face in a pattern identical on every satellite, so any pair can mate [1]. It tolerates +/-1.5 cm of position error and +/-5 degrees of attitude error at contact. On orbit the Velcro was found not to latch reliably when two satellites make an aligned contact at low approach velocity, and undocking requires the crew to pull the satellites apart.

Autonomous docking to a fixed beacon from about 1.2 m separation used a commanded 2.07 cm/s acceleration pulse that achieved 1.85 cm/s and a commanded 0.65 cm/s braking pulse that achieved 0.63 cm/s, holding attitude error under 6 degrees through the glideslope phase and tangential alignment inside a 2 cm by 2 cm box [1]. Docking to a target tumbling at 2.25 deg/s about its z body axis from about 0.6 m held approach velocity within 5 mm/s of the commanded value for 70 percent of the run, with contact at 111 s in the first attempt and 116 s in the second.

Docking missions are decomposed into rendezvous, proximity operations, docking, manipulation of the target and undocking, and the docking port payloads exist so that control algorithms for each part can be exercised on orbit [15]. Formation initialization was run as a distinct mode. Satellites are deployed with no knowledge of each other’s positions, acquire each other with the limited-field-of-view relative sensor, null the range rates and then take station in the array [7]. Fuel balancing regulates consumption across the formation so that mission duration is set by the fleet rather than by the first satellite to run dry.

Ground operations

Test sessions run in the US Laboratory near the hatch, with the five beacons mounted on the walls to define the test volume [1]. SPHERES is not operated in the Russian segment [8]. A session is about 3.5 hours and contains roughly 8 to 12 tests of 10 to 15 minutes each, with sessions about a month apart.

The cycle is fixed. The MIT team is notified about two weeks before a session; the software, already written, is integrated and verified on the MIT 2-D air table; it goes to the DoD Space Test Program office one week ahead for upload [1]. During the session the team watches video and audio in real time over a high-bandwidth link to NASA and passes instructions to the crew member on request. Telemetry is stored on the ISS laptop and emailed to MIT about three days later; the video recording follows a few weeks after that. VERTIGO produces more than 10 GB per session, which is downlinked with weeks of latency because no science result depends on getting it quickly [6].

Ground development before flight used the KC-135 for parabolic tests in August 2002, February 2003 and November 2003, and the MSFC flat floor for autonomous docking to a rotating target in June 2004, tethered formation flight in December 2004, and SWARM assembly and reconfiguration in July and September 2006 [1]. The Guest Scientist Program was developed in autumn 2002, the Universal Docking Port in spring 2005 and the Miniature Video Docking Sensor in summer 2005.

Utilization totals were 36 sessions in the first six years to 2012 [6] and more than 50 test sessions by September 2013 [5].

Technologies developed

The program produced a design method as well as hardware. Seven principles for a microgravity technology maturation laboratory were formulated from the SPHERES experience: iterative research, enabling a field of study, optimized utilization, focused modularity, remote operations and usability, incremental technology maturation, and requirements balance [12]. Requirements balance is the oversight principle over the other six. The principles were derived by identifying the features that let SPHERES satisfy the MIT laboratory design philosophy and then testing their applicability to technology maturation generally, and the same framework was then turned back on SPHERES to propose a further design iteration. The Guest Scientist Program is the operational expression of iterative research, giving outside investigators source access, a simulator and three levels of software interface so that an algorithm can be revised between monthly sessions [12], [13].

Online mass property identification, developed because trifilar torsional pendulum measurements of the principal moments of inertia differed from the CAD predictions by 5.4 to 10.5 percent and because propellant burn moves the center of mass, is the technique that made repeatable control possible across a session [10]. Reconfigurable control allocation extended it to satellites with attached payloads [11], [14]. Vision-based relative navigation matured on VERTIGO: the goggles pose solution differed from the ultrasonic solution by a mean of 1.59 cm in X with a standard deviation of 0.920 cm, velocity differences were typically under 1 mm/s, and geometric reconstruction of the target hull had a mean absolute error of 0.183 cm against hand measurement [6].

Astrobee was designed to replace the SPHERES facility, addressing the limits the SPHERES architecture had reached: beacon triangulation confines a satellite to the two-meter cube defined by the fixed beacons, the CO2 and battery consumables cost crew time, and safety rules forbid operation without crew supervision [4]. Astrobee is a 32 cm cube of about 10 kg driven by fans rather than cold gas, so its only consumable is battery charge, which it replenishes by docking itself. Command and data handling is a three-tier system of three ARM processors, one Android and two Linux: a low level processor closing the propulsion loop against the inertial measurement unit at about 100 Hz and safing the system if the others fault, a mid level processor hosting most of the flight software, and a high level processor that drives the crew touchscreen and runs guest science software in isolation from the flight software [9]. Large files transfer over a hard-wired Ethernet connection at the dock [4].

References