Int-Ball and Int-Ball2

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

Overview

Int-Ball is a family of free-flying camera robots operated inside the Japanese Experiment Module of the International Space Station. The first unit, formally the JEM Internal Ball Camera Robot, was developed and launched in 2017 as a technological demonstration and was tested on orbit in 2017 and 2018 [1]. Int-Ball2, formally the JEM Internal Ball Camera 2 System, launched in June 2023 and is in service. Its first on-orbit flight demonstration, including two docking attempts, flew on 17 October 2023, following ground verification by simulation, a hardware-in-the-loop rig and an air-bearing platform [13]. Int-Ball2 and CIMON-2 are, with Astrobee, the intra-vehicular free-flyers currently resident on the station [2].

The program exists to move imagery work off the crew. Astronauts spend more than 10 percent of their time on imagery tasks, and Int-Ball shifts camera setup and field-of-view adjustment to ground control [1]. Intra-vehicular helper robots therefore need to tolerate the cabin environment and recharge themselves, with the internal equipment and stowage adapted to robot handling, under limits on payload, speed and power [2].

Specifications

Parameter	Int-Ball	Int-Ball2
Shape and size	15 cm sphere	20 cm sphere
Mass	approx. 1 kg	approx. 3 kg
Mobility	12 fans at about 3 mN each, 3 reaction wheels	8 propelling fans at 60 to 163 mN each
Navigation	monocular camera, marker based	stereo visual-inertial SLAM
Imaging	approx. Full HD	approx. 4K, 1920x1080 at 30 fps and 4056x3040 at 15 fps
Processor	Armadillo-810	Jetson TX2
Software	Armadillo Base OS	Ubuntu with ROS
Power	Li-ion, USB charge by crew	Li-ion, automatic docking and recharge
Endurance on batteries	2 h	3 h
Data communication	WLAN	WLAN, UART to the docking station connected to a laptop
Payload interface	none	micro-USB and a side attachment

Source: [1].

Reported Int-Ball2 mass differs between 3 kg [1] and 3.3 kg [2]. Both generations are spherical rather than blunt-edged, which is the design choice made across intra-vehicular free-flyers to limit the consequences of a collision with crew or cargo.

Mission profile

Parameter	Int-Ball	Int-Ball2
Host	Japanese Experiment Module, ISS	same
Objective	technology demonstration of a remotely controlled camera	substitute crew work for imagery tasks
Launched	2017	June 2023
Deployed	2017 to 2019	2023 to present
Crew time addressed	imagery tasks, more than 10 percent of crew time	same

Source: [1].

A JAXA crew-task analysis of the JEM found that sample and equipment swap consumed 22 percent of the studied crew time, logistics 10 percent and monitoring 8 percent [2].

Mobility

Int-Ball used 12 micro axial fans arranged around the sphere for translation and pose holding, together with three reaction wheels for attitude stabilization, which makes it the only intra-vehicular free-flyer to have flown reaction wheels [2]. Fan thrust is given as about 3 mN each [1] and as about 1 mN maximum per propeller [2]. That authority was insufficient against cabin ventilation: the propulsion struggled with airflow disturbances from ISS ventilation, particularly near ducts, and the robot was swept away in areas of heavy airflow.

Int-Ball2 replaced the 12 micro fans with eight larger propeller modules producing 60 to 163 mN each [13], about 0.15 N on the dominant X axis [2], and dropped the reaction wheels. The diameter grew from 15 cm to 20 cm to accommodate the change [13]. Fans and propellers are enclosed and covered so the robot is safe to handle [2].

Rotor polarity alternates clockwise and counter-clockwise so that under symmetric operation the blade drag torques cancel; uncompensated drag torque acts as a disturbance on attitude, and it is a distinct torque channel from the r x f thrust-induced torque [4].

Power and energy

Both generations run on rechargeable lithium-ion batteries [1]. Int-Ball is charged over USB by the crew and runs for 2 hours on a charge; Int-Ball2 docks and recharges automatically and runs for 3 hours. Automatic docking uses AR markers on the docking station read by the robot’s cameras [2]. Automated charging was one of the functions validated during Int-Ball2 checkout, along with a low-battery return as an off-nominal transition [13]. No battery capacity in watt-hours is published for either generation. The move from consumables to rechargeable batteries was a lesson carried forward from AERCam [8], the Personal Satellite Assistant and SPHERES [9], and autonomous recharging is one of the capabilities identified as essential for any free-flyer tasked with maintaining an orbiting station [2].

Thermal

No thermal control design is published for either generation. Both operate in the pressurized cabin.

Compute and avionics

Int-Ball carried three control boards: an Armadillo running the Int-Ball operating system, a Phenox dual-core ARM9 handling image recording and processing, and an all-in-one module performing high-precision state estimation and control [2]. The first two ran Linux and the third FreeRTOS, and the flight control and measurement cycle ran at 10 Hz [2]. The program-level summary describes the architecture as a single onboard processor, an Armadillo-810 under Armadillo Base OS, in contrast to Astrobee’s tiered three-processor avionics [1], [10].

Int-Ball2 runs a single Jetson TX2 under Ubuntu with ROS, and is built mainly from commercial off-the-shelf components [13]. The inertial measurement unit is from the Epson M-G370 series, with an angle random walk of 0.06 to 0.03 deg/sqrt(h) in a one inch square package of 10 g drawing 16 mA at 3.3 V [7]. Pose is estimated by fusing visual SLAM output with the IMU data.

Each Int-Ball2 flight software function is implemented as a ROS node, and a node can be enabled or disabled by settings alone without modifying existing source [3]. Internal interfaces for data output and function calls are unified as ROS topics, services and actions.

Autonomy

Int-Ball navigated against two stereoscopic markers installed on the airlock and the portside of the JEM, read by an image navigation camera [2]. Pose in the JEM coordinate system came from fusing that camera information with the IMU and three ultrasonic distance sensors. The requirement that a marker stay in the field of view at all times was the limiting constraint, and markers could be obscured by crew or objects [1].

Int-Ball2 replaced marker tracking with stereo-camera visual SLAM fused with the IMU, taking features from the environment itself, though additional reference markers were nevertheless installed in the JEM during checkout for navigation assessment [1], [2].

Int-Ball has no explicitly stated obstacle detection method; it monitors for large impulse forces and triggers a quick response on collision [2]. Physical contact detection is IMU-based on both generations [1].

Int-Ball2’s relative pose estimate accumulates error. Post-flight analysis shows about 8 percent error encountered during flight, producing a localization shift on longer and more complex maneuvers [1]. The mitigation flown is path planning that produces better loop closures; adding absolute navigation references would reduce the error further. Astrobee’s factor-graph localizer, by comparison, is evaluated against on-orbit ground truth on twelve ISS activities, a level of quantified accuracy not yet published for Int-Ball2’s SLAM [12]. Safety is anchored in hardware rather than software, through a low-impact shell and limits on the propulsion, so that software can be updated without reopening the safety case. Future work is autonomous path planning over the V-SLAM maps for obstacle avoidance and tracking.

Communications

Both generations use the station wireless LAN [1]. The first Int-Ball relied on the wireless link alone and lost communication during operations, which is why Int-Ball2 added a wired UART option available while docked; station Wi-Fi performance can still degrade real-time video. The UART link runs to the docking station, which is connected to a laptop. During a technology demonstration run on Int-Ball2 there is no real-time communication between the user software on orbit and a user on the ground; a demonstration needing it has to be coordinated with the Int-Ball2 base station [3].

Payload and instruments

Int-Ball carried a front camera for the imagery product, a side monocular navigation camera, an IMU, ultrasonic sensors and a microphone [1]. The main monitoring camera was HD with continuous shooting, target tracking and image stabilization [2]. Int-Ball2 carries a front camera, a navigation stereo camera, an IMU and a microphone, and delivers approximately 4K imagery at 1920x1080 and 30 fps or 4056x3040 and 15 fps [13]. Neither generation carries a manipulator: of the free-flyers deployed on the ISS only Astrobee has an arm, and that is a perching arm rather than one used for object handling [2], [11].

Int-Ball had no payload or extension interface [1]. Int-Ball2 adds a micro-USB port and a side attachment, and is offered as a technology demonstration platform: the flight software exposes its sensor data and actuator control interfaces so that a user can substitute their own navigation, such as a different visual SLAM or sensor fusion, and their own guidance and control, such as PID or visual feedback control [3]. The existing visual SLAM cannot be used if the navigation camera video is taken separately, in which case the user implements SLAM themselves.

Modes of operation

Crew interaction is deliberately minimal. The crew interface on both generations is a manual on/off switch plus eye LEDs that indicate the robot state and the imagery state [1]. Everything else is commanded from the ground. Teleoperation from the ground remains the fallback for fault detection and recovery on every intra-vehicular free-flyer regardless of the autonomy level reached [2].

User demonstration programs on Int-Ball2 run under Docker, virtually separated from the native environment [3]. They are uplinked by the operations controllers and started from the Ground Support Equipment, so programs can be added or replaced without affecting the existing flight software or the GSE. Program size is limited by the availability of the Int-Ball2 body and its SD card capacity.

The Int-Ball2 checkout validated power, communication, imagery, flight and automated charging, then exercised crew-interactive features and off-nominal transitions including the low-battery return [13]. Flight data were logged throughout. A user program can be linked to a subset of the existing flight software functions, and the scope of what the user implements is adjusted accordingly rather than being all or nothing [3].

Ground operations

Int-Ball is operated by remote control from the ground with a simple user interface; Int-Ball2 uses a GUI [1]. Ground controllers plan Int-Ball2’s behavior and movement path in real time during operations, and a single command plus the check that it executed takes 1 to 3 minutes under the procedural rules, which limits real-time collaborative work with the crew. Although Int-Ball2 can capture 4K, operators use Full HD whenever the higher resolution is not needed, to hold down the downlink and ground handling effort [1]. Ground verification for Int-Ball was a granite table test with a ground model.

Int-Ball2 verification combined three methods [13]. Software simulation ran in ROS and Gazebo with a custom plugin for airflow, correlated against the hardware by feeding force-torque sensor measurements of the propulsion force back into the simulation. Hardware testing used two-dimensional granite floating tables, which cannot reproduce three-dimensional motion, so the two translational directions and one rotation were verified and the test repeated for each axis before launch. A hardware-in-the-loop simulator then verified the GNC system in three dimensions with flight hardware and software in the loop.

The Int-Ball2 simulator is published under Apache-2.0 as a ROS 1 Melodic and Gazebo 9 stack on Ubuntu 18.04, with the airflow plugin, sensor data acquisition and actuator control interfaces modeled and SLAM explicitly not simulated [6]. It ships with a simulated Ground Support Equipment GUI for user program deployment, telemetry reception and command transmission. JAXA released it publicly so that outside users can create, implement and verify their own programs before running them on the ISS [5].

Technologies developed

The generational step from Int-Ball to Int-Ball2 is the program’s main product, and every change traces to an on-orbit finding: fan thrust raised by more than an order of magnitude against cabin airflow, marker-based localization replaced by feature-based SLAM so that navigation no longer depends on installed infrastructure staying visible, and crew-dependent deployment and USB recharging replaced by a docking station the robot reaches itself [1]. The compact size drew favorable crew feedback, which the team reads as confirmation that being non-intrusive matters when working close to crew. The spherical form was retained for its tolerance of impact and its omni-directional movement, but Int-Ball2 marks its direction visually because the original sphere gave the ground no indication of which way the robot faced.

The Int-Ball2 platform has since been used as a simulation target outside JAXA. A reinforcement learning study of six-degree-of-freedom docking modeled the robot as a rigid body with eight thrusters and trained a PPO policy in Isaac Sim across 300 parallel environments under domain-randomized dynamics and bounded observation noise, with the propeller drag torque and polarity structure modeled explicitly and a docking success criterion of a relative position error below 2 cm [4].

Int-Ball2 has moved from technology demonstration to routine work. Since 2025 it has photographed crew maintenance of the Electrostatic Levitation Furnace and sample exchange for the Protein Crystal Growth experiment, and it performed a remote check of the JEM fire indicator, a task previously done annually by the crew [1]. In 2025 it exchanged data in real time with CIMON in the ICHIBAN activity, which was possible because both run ROS as their middleware. Hardware modularity was deliberately traded away to keep the body compact: replicable hardware is limited to the propeller modules. Commercial off-the-shelf components cut cost and development time, at the price that COTS specifications did not always match real performance and that material selection is constrained by non-flammability and other safety requirements. The batteries had to be developed specifically, because no small enough commercial unit satisfied the required safety controls.

References