Free Flyer Guidance

An intravehicular free flyer must hold and change a six degree of freedom state inside a volume it can collide with, without GPS, without a fixed base, and on a processor small enough to fly inside a pressurized module. The three families that have operated on the ISS solve the navigation half differently: ultrasonic ranging, fiducial markers, and visual localization against a prebuilt map [2][1].

The vehicles

	Astrobee	CIMON-1 and 2	Int-Ball	Int-Ball2
Developer	NASA	DLR	JAXA	JAXA
Deployed	2019 to present	2018; 2019 to present	2017 to 2019	2023 to present
Size and shape	30 cm cube	32 cm sphere	15 cm sphere	20 cm sphere
Mass	about 10 kg	about 5 kg	about 1 kg	about 3 kg
Actuation	12 nozzles fed by centrifugal impellers, 300 mN maximum x-nozzle	12 propelling fans, about 120 mN maximum in x	12 fans at about 3 mN each plus 3 reaction wheels	8 propelling fans, 60 to 163 mN each
Navigation	graph localizer	stereo camera VSLAM plus IMU fusion	monocular camera, marker based	stereo visual-inertial SLAM, feature based plus IMU fusion
Compute architecture	tiered onboard, LLP, MLP and HLP	two onboard processors plus a ground AI server	single onboard processor	single onboard processor
Processors	Wandboard Dual, InForce IFC6501, InForce IFC6601	Pokini F WIFI, AMD A4-6700T	Armadillo-810	Jetson TX2
Software	Ubuntu and ROS on LLP and MLP, Android on HLP	Ubuntu and ROS	Armadillo Base OS	Ubuntu and ROS
Power	Li-ion, automatic docking and recharge	Li-ion, crew-replaceable or wired	Li-ion, USB charge by crew	Li-ion, automatic docking and recharge
Operating time on batteries	3 h	2 h and 3 h	2 h	3 h

Source: [1], Table 1.

SPHERES: ranging beacons and what they cost

SPHERES localized against fixed ultrasonic beacons, which is why its operating volume was a 2 m cube [3]. Global metrology ran at a maximum 5 Hz update rate, giving position and 1 to 2 degrees of orientation, which caps estimator bandwidth at 2.5 Hz, the theoretical limit for a 5 Hz sampled system [2]. The control loop ran at 50 Hz and the navigation modules sub-sampled it. Each satellite masses 4.3 kg and each thruster produces 0.09 N [2].

Static estimator performance was measured with the satellite held still: all position estimates fell inside a 2 mm by 2 mm box [2]. The docking port Velcro pattern tolerates plus or minus 1.5 cm of position error. Experiments showed that state errors larger than 10 cm degrade behavior, that the glideslope algorithm needs an initial error under 15 cm on the axes it controls, and that with errors above 20 cm in position or 45 degrees in attitude the approach does not work [2]. Fusing the relative estimator with a single beacon estimator raised the effective bandwidth to 50 Hz.

The flight result was the first on-orbit autonomous docking to a tumbling target, achieved over 15 successful experiments in the fifth and sixth ISS test sessions, at a target tumble rate of 2.25 deg/s from 40 cm separation [2]. Terminal performance was range within 3 cm with tangential error regulated within 2 cm under a PD attitude controller.

Astrobee: localization against a prebuilt map

Astrobee has no ranging infrastructure. A sparse feature map of the module interior is built offline from imagery, and the robot localizes against it in flight [3]. Mapping is deliberately separated from localization: SURF features are used for map building because they are expensive but computed offline, while BRISK features are used onboard. The original estimator was an augmented-state indirect extended Kalman filter fusing map feature matches, AR tags as the robot approaches its dock, handrail measurements from a depth sensor when it perches, optical flow for velocity, and the IMU. WiFi was evaluated as a localization modality and rejected: the commercial radio and the existing ISS access point geometry do not give sufficient position accuracy. Granite table testing gave position RMSE between about 4.9 and 18 cm and angular RMSE between about 1.3 and 14 degrees depending on configuration [3].

AstroLoc and what a single core costs

The operational problem was drift and lost events when the prior map does not match a changed environment [4]. The separation of mapping from localization that made the original design tractable is also what makes it brittle when the module is rearranged [3]. AstroLoc replaced the MSCKF-based filter with graph-based optimization, run on Astrobee’s InForce 6501 Micro SoM with a Qualcomm Snapdragon SoC, on a single processing core that runs roughly 10 times slower than an Intel i9-9980HK at 2.4 GHz and shares the machine with a suite of other processes [4].

The design is shaped entirely by that budget [4]:

Parameter	Value
Camera rate	15 Hz
IMU rate	62.5 Hz
Sliding window graph duration	3.5 s
Maximum smart factors in the factor graph	12
Maximum measurements per smart factor	5
Localizer output rate	about 5 Hz, extrapolated to 62.5 Hz by the IMU augmentor
Huber loss threshold	1.345

Smart factors avoid explicitly estimating three-dimensional feature positions, and measurement selection reduces off-diagonal terms in the graph Hessian; optimization uses GTSAM with both a relative error threshold and an iteration limit as convergence criteria.

Measured over 12 ISS activities, with a lost event defined as drift exceeding 1.5 m [4]:

Metric	Previous localizer	Base GTSAM	AstroLoc
Position RMSE, localization mode	0.0948 m	0.2417 m	0.0491 m
Orientation RMSE, localization mode	0.0439 rad	0.0505 rad	0.0275 rad
Position RMSE, VIO mode	0.6212 m	0.5328 m	0.2777 m
Position RMSE with outliers, VIO mode	2.4179 m	0.7508 m	0.3721 m
Lost events, VIO mode	2	2	0
Average runtime, VIO	not applicable, fixed 62.5 Hz	1.0588 s	0.1785 s
Average optimization time, VIO	not applicable	0.8525 s	0.1259 s
Average runtime, VIO plus map	not applicable	1.1335 s	0.2050 s

Source: [4]. AstroLoc runs about six times faster than the base GTSAM implementation, an 83 percent runtime decrease and an 85 percent optimization time decrease in VIO mode, and 82 and 84 percent in localization mode.

SPHERES sets the contrast: its 5 Hz metrology capped estimator bandwidth at 2.5 Hz, while Astrobee’s constraint is not sensor rate but the optimization time available per 15 Hz image on one core [2][4].

The operational payoff is measured in crew time rather than meters. Reduced reliance on the prior map cut the activities run specifically to collect new map imagery by about 40 percent and the images per such activity by about 30 percent, and Astrobee has since executed ISS activities with over two hours of flying time [4], against a 3 hour battery endurance [1].

Failure modes

Losing the position fix is the dominant one, and its consequence is crew intervention [4]. On Astrobee the localization fix was occasionally lost during activities, initially mitigated by returning the robot to its dock and renewing the fix by visiting mapped areas, and later by updating the localization algorithms to tolerate environmental change [1][4]. Int-Ball2’s relative pose estimation accumulates error, and post-flight analysis shows about 8 percent of flight time encountering errors that produce a localization shift; the recommendation is absolute navigation references [1].

Sanity checking is therefore built into the estimator rather than left to the operator: the AstroLoc navigation state is checked against a covariance threshold and against a pose history check comparing the localiser output with map-derived poses, and the localiser resets if either fails [4].

Infrastructure fails alongside the robot. Both Astrobee and Int-Ball2 use a dedicated docking station for recharge and wired communication, and separate Astrobee dock anomalies involving its Ethernet connection, plus on-orbit Wi-Fi behavior, caused loss of communication during operations; Int-Ball2 added a wired UART option while docked in response [1]. Docking station and robot problems together led to multiple on-orbit repairs.

Actuation asymmetry is a control problem in confined volumes. Int-Ball2’s eight propellers produce 60 to 163 mN each, and the plant carries aerodynamic drag, fan polarity structure and geometric actuation coupling that classical controllers must be tuned against; drag torque is distinct from the standard thrust-induced torque term [6].

Ground verification

None of the guidance can be tested at full six degrees of freedom on Earth. All three programs used a combination of simulation and partial-gravity surrogates: Astrobee uses a Gazebo simulator plus a granite table facility with two ground models, CIMON used software simulation, ground model testing, an elegant breadboard and hardware-in-the-loop simulation, and Int-Ball2 uses Gazebo, a granite table with a ground model, and hardware-in-the-loop simulation [1]. The granite table constrains motion to a plane, which is why SPHERES-era results distinguish between 2D table results and on-orbit six degree of freedom results [2].

Onboard software as the product

Astrobee’s value as a platform comes from guest scientists deploying software and hardware payloads onto it. Astrobee has four payload bays, of which three can carry guest hardware at once, each bay port supplying 14.4 VDC battery power and USB 2.0 data through a blind-mate connector [1][5]. Guest investigations have spanned autonomous rendezvous and docking between two Astrobees, mapping and change detection inside the station, acoustic mapping, orbital debris capture, path planning, novel grippers, and propellant-free motion in which the perching arm tosses the robot between handrails [5]. Int-Ball2 exposes the same idea through a technology demonstration platform in which user software is uplinked and started under Docker from the ground, with no real-time ground communication during the basic demonstration [1].