SPHERES

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

Overview

A free flyer inside a crewed spacecraft has to translate and rotate in six degrees of freedom with nothing to push against, know its position in a cabin where satellite navigation is unavailable, and do both beside crew and equipment that tolerate only small forces and little noise. Ground analogs reproduce part of that. A flat floor with air-bearing platforms gives planar motion [30], the JPL Formation Control Testbed adds a spherical air bearing for three rotational degrees of freedom on a 40 ft floor [29], the Ames Personal Satellite Assistant crane gave five degrees of freedom [20], and parabolic aircraft give seconds of weightlessness at a time [10]. The station itself is not a clean free-fall environment: the quasi-steady regime lies below 0.01 Hz and the vibratory regime from 0.01 to 300 Hz, and a single ATV docking produced a 12.9 mg disturbance at the accelerometer [24]. Earlier shuttle-era measurements put crew exercise at roughly 1 to 4 Hz and pump transients near 1 mg [25]. These figures come from general station and shuttle characterization, not from SPHERES sessions.

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 [13].

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].

Design space and lineage

Four families of free flyer preceded or followed SPHERES, and they differ most in propulsion and in whether they ever flew.

AERCam Sprint, a 14 in, 35 lb sphere with 12 nitrogen thrusters, flew outside the shuttle on STS-87 in 1997 [21]. As of 2003 no free-flying vehicle had been deployed for operations inside a spacecraft in flight [20]. Mini AERCam was the intended successor: 7.5 in, 10 lb, 12 cold-gas thrusters in four pods, a PowerPC 740 at 266 MHz and a MEMS gyro package sampled at 300 Hz [21]. It was tested on an air-bearing table with nitrogen in place of the flight-design xenon, and ISS-relative GPS was proposed rather than flown [21]. Its autonomy software, a CLIPS expert-system sequencer with a dynamics manager for contingency maneuvers, was exercised on the ground and in hardware-in-the-loop simulation [22].

The Personal Satellite Assistant was the intravehicular line. Model 2 was a 12 in sphere with six pairs of ducted fans, Model 3 was planned with two blowers and four reaction wheels, and the autonomy framework inherited the EUROPA planner from Deep Space One [20]. The paper reports no localization accuracy, endurance or bandwidth figure [20], and its linear thrust capacity is given as 0.5 N [19].

SPHERES took the opposite propulsion choice. Cold gas gives up to 0.2 N per thruster and a 12-thruster layout with any force and torque combination, at the price of a CO2 tank that lasts about 10 minutes and crew who swap it [19]. Fans are quiet and rechargeable but weak: the first Int-Ball produced about 1 mN per fan, which was insufficient to hold pose in some regions of the station [19]. The Astrobee propulsion trade fixed a requirement of 0.6 N maximum thrust on at least one axis and 65 dBA at maximum thrust, and settled on two impellers with flapper nozzles [17]. The flown systems converged on two outcomes: gas for authority in an experiment-driven facility, fans for an assistant that must not disturb the crew.

Navigation diverged in the same way. SPHERES uses fixed ultrasonic and infrared beacons, which confine it to a 2 x 2 x 2 m volume [4]. Int-Ball2 and Astrobee use cameras. Int-Ball2 is 200 mm across and 3.3 kg, with propellers of 51 mN maximum thrust, 1.5 h of operation, visual SLAM and a magnetic docking station, and made its first on-orbit demonstration on 17 October 2023 [27]. Its flight software is ROS based, user programs run in Docker containers on a Jetson TX2, and the visual SLAM cannot run while a user program takes direct access to the navigation camera video [31]. Reinforcement-learning docking for Int-Ball2 has been studied only in simulation: a PPO policy commanding eight propeller thrusts, with success defined as under 2 cm and 2 degrees held for five timesteps [28].

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].

Successors and flight record

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]. The joint review by the three free-flyer teams reaches the same point from the operations side: platforms with a docking station fly often, and SPHERES, the first Int-Ball and CIMON needed crew setup every session [18]. 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 [4]. Its flight software is split across 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]. The 2015 prototype avionics and a first perching arm were benchmarked on the ground; the arm weighed 315 g against a 200 g requirement [23]. Large files transfer over a hard-wired Ethernet connection at the dock [4].

Flight results exist for Astrobee and not for the planning documents above. Through May 2025 the facility completed more than 165 real-time operations and more than 90 Guest Science sessions, with more than 1200 hours of console support, about 220 of which involved crew; the unit named Bumble flew 135 sessions, the dock 164, and the perching arms 23 [17]. The AstroLoc localizer reached 0.0491 m position RMSE in localization mode and 0.2777 m in visual-inertial-only mode over 12 ISS activities, against a ground truth produced by the authors’ own offline mapping [17]. Maximum design speed is about 2.1 m/s, with an over-speed cutoff at 50 cm/s chosen to keep bumper impact below the 556 N astronaut push-off certification. On 27 May 2025 a reinforcement-learning controller was flown on Bumble in one session of about 7 minutes and 8 maneuvers; it did not match the baseline controller’s final position and orientation error in any test, and the first of two docking attempts failed [26]. Mini AERCam, the Personal Satellite Assistant and the learned Int-Ball2 docking policy remain at ground test, design or simulation level.

Localization, survey and learned control on Astrobee

The Astrobee localizer is the part of the successor lineage with the longest published record. The original estimator fused a 62.5 Hz inertial unit with sparse-map landmarks, docking tags and handrail detections at roughly 2 to 5 Hz, and on the ground reached position RMSE from about 5 cm on a slow circle to 16.5 cm on a fast combined motion [32]. It was tested on the ground only, against an overhead-camera reference [32]. AstroLoc replaced it on the ISS units with a factor-graph estimator, cutting average runtime from 1.13 s to 0.21 s and removing the two lost-localization events the previous localizer had on the public ISS dataset [33]. AstroLoc2 separated odometry from map-based correction and lowered absolute trajectory error RMSE by 16 percent over AstroLoc on 10 ISS activities; it is less accurate than DSO and ORB-SLAM3 and runs 41 and 87 percent faster than them [37]. In both cases the reference trajectory is itself imperfect [33], [37].

Two further flown results use the same platform as an instrument. Adding learned object semantics to the sparse-map localizer lowered position RMSE on all five ISS datasets tested, but the detector covered 8 object classes trained on one trajectory, ran offline, and was scored against the pipeline that built the maps [34]. A two-robot change detection scheme recovered unmodified objects in JEM surveys from batches of about seven navigation images, with no detection rate or position error reported [35]. Survey flights in 2022 with the ISAAC payload measured Wi-Fi signal strength through the US Laboratory, Node 2 and the JEM, and found a fitted pathloss exponent of 0.084 along the module axis, so the free-space inverse-square model does not hold; the radio was not characterized before flight, so only relative differences are reliable [36].

Learned control has one flight: a PPO policy trained with curriculum learning in simulation, checked on the Ames air-bearing table (2 degrees of freedom) and flown on Astrobee, replacing the wrench controller [38]. Only the curriculum-trained policy was flown, and the success statistics come from the training simulator [38]. Free-flyer inspection autonomy for a lunar-orbit outpost with keep-in corridors and keep-out zones has been exercised only in MuJoCo simulation, where four simultaneous thruster failures drive the vehicle into the station [39]. It has no hardware result.

Across the lineage, the SPHERES-era contribution that carried forward was the way of working rather than the vehicle: the guest-investigator interface, ground verification on an air table before upload, and a plant model identified from the vehicle itself. The vehicles that followed dropped its propulsion and its beacon metrology and kept that cycle.

What is not established

The plant parameters of the flight satellites are bench and parabolic-flight values, not station values. Thruster strengths, center of mass offsets and inertias come from MIT bench tests and reduced-gravity aircraft sessions in February 2002 with 15 to 40 tests per satellite; load cell mount play of 0.5 mm and liquid CO2 motion remain unresolved error sources in the center of mass, and absolute thruster latency was never measured [10]. Published masses disagree (4.38, 4.16 and 3.5 kg), and no thermal design is available. The SPHERES papers cited do not characterize the acceleration environment at the test volume, so the disturbance figures above are station-wide and shuttle-era values [24], [25], and the ATV event is a single docking with no repeat [24].

Comparisons between free flyers rest on secondhand tables. Thrust figures are defined per nozzle, per fan or as an axis resultant depending on the platform, and the Int-Ball2 navigation error is bounded by a reference marker system with its own error of 28 mm and 1.1 degrees [18], [27]. The Int-Ball and CIMON figures in the Astrobee operations paper are quoted from JAXA and DLR sources and the Astrobee values there are design values [4]. A simulation of an Astrobee-class flyer grasping cargo bags of 1 to 15.4 kg found that the base stabilization torque exceeds the assumed 0.02 N m limit for the heavier bags, using actuator limits taken from a public model and no hardware validation [19]. The Astrobee localization error floor is not independent of the mapping pipeline that defines the ground truth [17], and the reinforcement-learning flight is a single session [26]. Mini AERCam and PSA sources report no flight and, for PSA, no performance measurements [21], [20].

References