PaperlayerView exact revision on arXiv

Source-linked AI summary

AstroBench: Benchmarking Free-Floating Capture and Space Robotic Manipulation

Zizhe Wang, Jia Deng, Xin Lu, Zehao Jia, Yi Huang, Yao Zhu

arXiv:2610.31064v1cs.RO

TL;DR

Capturing an unsupported spacecraft object is difficult because it can translate or rotate, and contact can change its motion. AstroBench combines free-floating capture with MELFI-inspired storage and RRM-inspired servicing tasks, and reports acquisition experiments for two existing policy configurations. The experiments record different capture outcomes for the tested generalist and cube-specific policies.

  • Problem

    Capturing a free object requires aligning the gripper with a target whose pose can change before contact and whose motion can change upon contact.

    Source: §I · p. 1

  • Method

    AstroBench combines motion-conditioned free-floating capture with MELFI-inspired storage and RRM-inspired servicing, and evaluates a frozen π0.5 DROID policy and a cube-trained ACT policy.

    Source: §I · p. 1

  • Results

    The frozen π0.5 DROID configuration captured 6/400 targets overall, while the separately evaluated cube-specific ACT policy captured 14 of 20 targets.

    Source: B. Frozen π0.5 Capture Results · p. 5, C. Task-Specific ACT Capture Results · p. 5, §VIII · p. 7

  • Takeaways & Limitations

    The recorded acquisition measurements provide baselines for the tested settings and concrete settings for controlled studies of feedback scheduling and contact formation.

    Source: D. What the Acquisition Evidence Reveals · p. 6, §VIII · p. 7

    The acquisition results characterize the two tested policy configurations and their recorded evaluation settings.

    Source: §I · p. 1, §VIII · p. 7

Abstract

from arXiv · show

Capturing a loose object inside a spacecraft requires a robot to approach a target that can translate and rotate, and whose motion changes when contact is made. These conditions motivate evaluation beyond manipulation of supported objects. We introduce AstroBench, an open benchmark for free-floating capture and space robotic manipulation with a fixed-base arm. The task suite combines four initial-motion tracks with sample-storage operations based on MELFI hardware and cap and captive-screw servicing based on the Robotic Refueling Mission. The two workcells provide nine task definitions and 29 task-target combinations. A metadata-filtered Objaverse inventory supplies 8,414 object instances for asset expansion, alongside five cabin visual contexts and versioned task instructions. We report two acquisition-focused experiments using existing checkpoints. A frozen $\pi_{0.5}$ DROID joint-position policy captures 2 of 200 static targets and 4 of 200 moving targets across twenty object identities. A cube-specific ACT policy captures 8 of 10 static targets and 6 of 10 moving targets in a separate experiment. Each experiment retains its recorded observation, action and capture configuration. The results document difficult direct transfer for the tested generalist checkpoint and successful task-specific capture behavior, while identifying concrete settings for studying motion-aware perception and contact-sensitive control. Code, task definitions and editable workcell assets are available at https://github.com/AstroUpLab/AstroBench.

I. INTRODUCTION

AstroBench addresses the distinct demands of capturing unsupported objects and manipulating fixture-mounted hardware in spacecraft. It combines motion-conditioned capture, storage and servicing tasks with an extensible asset inventory and acquisition experiments using existing policies.

I. INTRODUCTION

  • Free-floating capture requires aligning with a target whose pose can change before and after contact, while capture also depends on object recognition, approach, and gripper coordination.Unlike fixture-mounted storage or service interfaces, a free object has no table to resist an incidental push.Source: §I · p. 1
  • The suite combines static, drifting, tumbling, and faster-tumbling capture with MELFI-inspired storage and RRM-inspired cap, fastener, and tool-interface operations.The robot arm has a fixed base; the capture target is the free-floating body.Source: §I · p. 1
  • The paper evaluates capture as the first satisfaction of a recorded capture detector, using a frozen π0.5 DROID checkpoint on twenty objects and ACT trained for a local cube task.The experiments document what each tested system captures and provide execution traces for further analysis.Source: §I · p. 1
  • AstroBench releases an 8,414-instance object inventory, five cabin visual contexts, editable workcell assets, and explicit language-conditioned task specifications.The authors present these resources alongside acquisition results and reproducible execution settings for generalist-policy transfer and task-specific imitation learning.Source: §I · p. 1

II. RELATED WORK

  • Prior manipulation and space-robotics benchmarks organize tasks and environments, while AstroBench focuses on unsupported-object acquisition and hardware-specific operations without introducing a policy architecture.The related work also describes task and environment variation in LIBERO, CALVIN, RoboCasa, and Space Robotics Bench.Source: §I · p. 1, §II · p. 2

III. BENCHMARK DESIGN

AstroBench distinguishes free-floating capture from operations on fixture-mounted hardware. Its task-instance specification binds each task to its asset, target, initial state, context, instruction, and execution configuration.

A. Physical Setting

  • Capture uses unsupported rigid-body targets whose motion follows the reset pose and twist, environment dynamics, and robot contact; “static” denotes an initial condition, not an attachment.The reference environment has a fixed robot base and zero gravity.Source: A. Physical Setting · pp. 2–3
  • Storage and service workcells use fixture-mounted hardware, where the robot operates movable parts or transfers objects relative to the fixture.Capture emphasizes interception and contact formation; workcells emphasize target selection, alignment, constrained motion, and operation-specific endpoints.Source: A. Physical Setting · p. 3

B. Factorized Task Specification

  • A task instance binds its definition, asset, selected target, initial state, visual context, resolved instruction, and execution and scoring configuration.The selected target can be the capture object or a particular box, cap, or captive screw.Source: B. Factorized Task Specification · p. 3
  • Changing a cap changes the target frame and instruction, while changing from opening to closing changes the initial mechanism state and goal.A new episode run identity does not imply different geometry or a randomized initial pose.Source: B. Factorized Task Specification · p. 3

C. Hardware Reference and Robot Access

AstroBench models hardware geometry and robot access together, while its capture and MELFI tasks vary initial motion, target identity, and operation-specific goals.

C. Hardware Reference and Robot Access

  • The hardware models retain lids, latches, caps, fasteners, adapters, mounting structures, openings, and tool interfaces needed for insertion and engagement.A single solid approximation would remove meaningful openings and interfaces.Source: C. Hardware Reference and Robot Access · p. 3
  • MELFI boxes face the arm from a floor-supported column, while the vertically mounted RRM panel faces an arm on a thin floor plate.The RRM cabin installation is distinguished from its original exterior-mission setting.Source: C. Hardware Reference and Robot Access · p. 3

A. Free-Floating Capture

  • Four initial-motion tracks vary translation and rotation while keeping object identity and task wording fixed; registered seeds determine signed directions.The historical experiments use their recorded static/dynamic settings rather than all catalog tracks.Source: A. Free-Floating Capture · p. 3, Table II · p. 3
  • The twenty-object capture catalog spans distinct geometries and yields eighty object–motion cases per repetition across four tracks.Objects include tools, containers, geometric parts, and portable devices.Source: A. Free-Floating Capture · p. 3

B. MELFI Sample-Storage Workcell

  • Five MELFI tasks cover card transfer, insertion, extraction, and lid opening and closing across three boxes, yielding fifteen task–target combinations.Each task has an explicit initial state; insertion begins with the card held outside, while extraction begins with it inside.Source: B. MELFI Sample-Storage Workcell · p. 3
  • MELFI placement goals require the entire card mesh inside the selected box, while extraction also requires clearance from the opening.Lid tasks use lid and latch states.Source: B. MELFI Sample-Storage Workcell · p. 3

C. RRM Cap and Fastener Workcell

The RRM workcell specifies target-specific cap and captive-screw operations, while the benchmark separates asset selection from physical instantiation and preserves the historical capture endpoint settings.

C. RRM Cap and Fastener Workcell

  • Cap removal requires tool engagement, unscrewing, axial withdrawal, and docking the cap–adapter assembly before driver withdrawal.SMA targets are identified by physical row and column; screw loosening and tightening are separate tasks with distinct initial states.Source: C. RRM Cap and Fastener Workcell · p. 4
  • Four RRM task definitions expand to fourteen target combinations: one FDV1 cap, nine SMA caps, and two screws for each of loosening and tightening.Together with MELFI, the workcells contain nine definitions and twenty-nine task–target combinations.Source: C. RRM Cap and Fastener Workcell · p. 4

D. Object Inventory and Cabin Contexts

  • A metadata filter scans 798,759 Objaverse records and selects 8,414 object instances across 51 LVIS labels and additional unlabeled objects.Selection metadata is retained, but physical instantiation requires separate scale, collision, mass, inertia, and gripper-compatibility fields.Source: D. Object Inventory and Cabin Contexts · p. 4
  • Five cabin visual contexts can change while task bodies and initial conditions remain fixed; the reported π0.5 experiment uses Kibo/JPM.The contexts use NASA Astrobee visual assets.Source: D. Object Inventory and Cabin Contexts · p. 4

A. Capture as the Primary Endpoint

  • Capture is counted when the recorded detector finds a qualifying acquisition event at any evaluated step, and rates use registered attempts as the denominator.Detection requires actual target contact and gripper state, plus geometry and relative motion for the recorded revision; visual overlap or a close command alone is insufficient.Source: A. Capture as the Primary Endpoint · p. 4
  • The historical π0.5 and ACT experiments retain different detector revisions, horizons, and two-condition settings rather than using the current four-track planner specification.The experiments are reported independently.Source: A. Capture as the Primary Endpoint · p. 4

B. Measured Geometry and Task-Specific Goals

The section defines relative target motion in a consistent reference frame and distinguishes geometric capture measurements from operation-specific workcell goals.

B. Measured Geometry and Task-Specific Goals

  • Relative target position is measured from the target and gripper reference points in world coordinates, expressed in the gripper frame.The environment adapter specifies whether the target reference is its center of mass or geometry center.Source: B. Measured Geometry and Task-Specific… · p. 4
  • Relative linear velocity includes a rotating-frame term that matters when the wrist turns during approach.Contact and state signals are sampled at the same step.Source: B. Measured Geometry and Task-Specific… · p. 4
  • Workcell success uses operation-specific measures, including full-card containment, lid and latch states, cap travel and docking, and captive-screw rotation and travel.Captive-screw success also checks that the screw remains attached; a successful intermediate grasp does not satisfy the operation goal.Source: B. Measured Geometry and Task-Specific… · p. 4
  • Table III summarizes workcell tasks and operation goals, with target counts expanding definitions into concrete language-conditioned cases.The caption describes the table’s scope but not individual values.Source: Table III · p. 5

C. Plans, Instructions and Attempt Accounting

The appendix preserves episode identities, execution and rejection accounting, and distinct policy configurations; the frozen π0.5 evaluation shows few captures on its tested object set.

C. Plans, Instructions and Attempt Accounting

  • Episode plans bind task, target, asset, initial-state, and language identities to a task-specification hash and recorded trace.The instruction is resolved before policy execution.Source: C. Plans, Instructions and Attempt… · p. 5
  • Action-interface rejections remain in registered-attempt accounting but are separated from completed executions without acquisition.Measurement and infrastructure errors receive distinct statuses; repeated nominal states are distinguished from randomized test distributions.Source: C. Plans, Instructions and Attempt… · p. 5

A. Questions and Recorded Configurations

  • The experiments ask how often frozen π0.5 acquires twenty tested objects and whether a cube-trained policy acquires targets at tested static and moving positions.Both studies ran in Isaac Sim with Isaac Lab-based interfaces and GPU PhysX.Source: A. Questions and Recorded Configurations · p. 5
  • The frozen π0.5 DROID joint-position checkpoint uses padded 224×224 external and wrist images, executes fifteen actions per second-long replanning interval, and remains unchanged.Invalid joint-limit commands are rejected rather than silently altered.Source: A. Questions and Recorded Configurations · p. 5
  • ACT is a task-specific baseline trained from 400 local cube demonstrations and evaluated at checkpoint step 140,000.It uses thirty-action chunks with temporal ensembling and infers at every action step.Source: A. Questions and Recorded Configurations · p. 5

B. Frozen π0.5 Capture Results

  • The frozen π0.5 checkpoint captures 2 static and 4 dynamic targets in 400 attempts, with a 1.5% overall rate on the tested set.Captures are concentrated on three objects, and the higher dynamic count does not establish that dynamic targets are generally easier.Source: B. Frozen π0.5 Capture Results · p. 5
  • Of the 398 π0.5 attempts that execute without action-limit rejection, 392 do not reach the capture predicate.The six successful captures have first-capture times between 11.47 and 24.33 seconds.Source: B. Frozen π0.5 Capture Results · p. 5

C. Task-Specific ACT Capture Results

The cube-specific ACT policy acquired more static than moving targets, while the records leave the causes of non-acquisition unresolved. The section also identifies feedback scheduling and contact with unsupported objects as questions for further study.

C. Task-Specific ACT Capture Results

D. What the Acquisition Evidence Reveals

  • The π0.5 summary flags do not reveal whether perception, approach alignment, closure timing, or contact-induced motion dominates non-acquisition.The records distinguish completed rollouts without acquisition from rejected action commands.Source: D. What the Acquisition Evidence Reveals · p. 6
  • The one-second π0.5 action interval versus ACT's per-step temporally ensembled commands motivates a feedback-rate experiment, but does not establish causation.A within-policy scheduling experiment would isolate this hypothesis more directly.Source: D. What the Acquisition Evidence Reveals · p. 6
  • A static free object can still move when approached because its initial rest condition provides no support reaction.A matched support-condition experiment could separate this effect from appearance, geometry, and embodiment changes.Source: D. What the Acquisition Evidence Reveals · p. 6

A. From Capture to Hardware Operations

AstroBench’s hardware-operation workcells are supported by editable models, reset definitions, sampled geometric checks, and mechanism demonstrations, while reported policy experiments concern capture. The release records evaluation settings and supports controlled studies, but its authored contact and mechanism models do not establish flight-hardware fidelity.

A. From Capture to Hardware Operations

  • MELFI and RRM are supported by editable models, reset definitions, geometric access checks, and mechanism demonstrations; policy results in this paper concern capture.The RRM review covers 335 sampled poses, while MELFI has a card-to-opening geometry check; these checks are separate from measured policy episodes.Source: A. From Capture to Hardware Operations · pp. 6–7

B. Reproducibility and Research Use

  • Release 0.4.0 provides task and language registries, deterministic plan generation, scoring tools, editable assets, and hashes that identify evaluated assets and protocols.The suite supports studies varying translation, rotation, object geometry, target selection, and cabin visual context; repeated nominal states or a large inventory alone do not establish generalization.Source: B. Reproducibility and Research Use · p. 7
  • The benchmark uses authored contact and mechanism models, so unmeasured properties are not assigned flight-hardware fidelity.Reference photographs and engineering documents inform hardware appearance and task sequence, while collision approximations, friction, and mechanism parameters remain experimental specifications.Source: B. Reproducibility and Research Use · p. 7

VIII. CONCLUSION

  • 6/400 captures for frozen π0.5 and 14/20 for cube-specific ACT provide baselines for their recorded settings, not a controlled model ranking.The conclusion identifies motion perception, feedback scheduling, and contact formation as study directions.Source: §VIII · p. 7
  • Fig. 3 shows one stationary-cube ACT approach; the capture predicate first qualifies at 8.07 s, measured from the synchronized state trace.The displayed frames are sparse samples and do not determine the event time.Source: Figure 3 · p. 8

APPENDIX A EXPERIMENT CONFIGURATION AND PER-OBJECT RESULTS

The recorded experiments use distinct capture predicates and configurations. The frozen π0.5 study records few captures across twenty objects, while the separately evaluated cube-trained ACT policy captures at many of its tested development positions.

A. Capture Endpoint and Evidence

  • A capture requires the recorded native grasp predicate to occur within the episode budget, and the trace-derived events agree with all original episode receipts.The studies use different historical predicates; π0.5 additionally uses a 1 s confirmation window without an instantaneous relative-velocity threshold, while ACT uses 15 consecutive samples and speed gates.Source: A. Capture Endpoint and Evidence · p. 8
  • The π0.5 study tests twenty objects ten times each at rest and ten times with specified translational and rotational velocities, sharing one authored pose across conditions.The fixed-base Panda runs in zero gravity; repeated attempts reuse identical initial poses within each object–motion group.Source: A. Capture Endpoint and Evidence · p. 8
  • 2/200 static and 4/200 dynamic π0.5 attempts captured targets, for 6/400 overall; all four dynamic captures involved pliers.Two predicted joint-limit rejections remain in the denominator, and the ten repetitions per object and condition reuse a nominal pose.Source: A. Capture Endpoint and Evidence · p. 8, Table VII · p. 9

C. Task-Trained ACT Study

  • ACT was trained from random initialization on 400 cube-task demonstrations selected from earlier π0.5 rollouts, and evaluation freezes checkpoint 140,000.The dataset contains 58,925 frames at 15 Hz; the policy uses two RGB views and predicts 30 actions with temporal ensembling.Source: C. Task-Trained ACT Study · pp. 8–9
  • 8/10 static and 6/10 dynamic ACT attempts captured the cube, for 14/20 overall at ten previously used development positions.These results do not estimate capture across the 8,414-instance inventory or support a controlled architecture ranking against π0.5.Source: C. Task-Trained ACT Study · p. 9

A. Hardware references and benchmark adaptations

AstroBench adapts MELFI storage and RRM servicing references into explicit task interfaces and target-specific workcell configurations. Task definitions bind reset states and terminal requirements to named targets and protocol specifications.

A. Hardware references and benchmark adaptations

  • MELFI references motivate the mixed tray and card-handling sequence, while the benchmark’s part meshes, latch, grasp interfaces, elastic parameters, and scoring tolerances are authored choices.The model represents the sample-handling interface, not freezer thermal operation or validated contact dynamics.Source: A. Hardware references and benchmark… · p. 9
  • RRM references distinguish cap removal and tool-mediated servicing operations; AstroBench defines FDV1 and addressed SMA cap removal plus captive-screw operations.Cap tasks require the cap retained in its detached adapter, the adapter secured in its receiver, and the driver withdrawn; merely removing a cap from its thread is insufficient.Source: A. Hardware references and benchmark… · p. 9

B. Task–target expansion

C. Initial states and terminal meaning

  • Reset states distinguish card transfer, insertion, extraction, lid operations, cap removal, and captive-screw tasks; terminal checks require final-state conditions such as retention, docking, and withdrawal.The canonical hardware protocol uses a 30 s horizon and 1 s terminal hold, and each episode binds its instruction, target, asset manifest, and protocol into a specification hash.Source: C. Initial states and terminal meaning · pp. 9–10

APPENDIX C WORKCELL HARDWARE DETAILS

  • Figures 4 and 5 expose the released workcell models’ openings, joints, and tool interfaces.The views support inspection of storage and servicing task hardware.Source: Appendix C · p. 10

A. MELFI Boxes, Lids and Sample Card

The MELFI workcell models card storage, restraint, and lid operations, while the RRM workcell models indexed service interfaces, tool-mediated cap removal, and captive-screw operations. Both workcells encode authored geometry and task-specific terminal conditions.

A. MELFI Boxes, Lids and Sample Card

  • The box’s larger band restrains the inserted card, while vial loops belong to the card; the released-band and around-card resets distinguish their roles.The ESA card dimensions are 100 × 110 mm; the benchmark’s four-vial arrangement and 25 mm upper grasp region are authored details.Source: A. MELFI Boxes, Lids and Sample Card · pp. 10–11, Figure 4 · p. 11
  • MELFI’s mixed tray combines two quarter-size and one half-size modules, each with a hinged lid latch separate from the tray lock.The modeled card carries four vials and has an upper grasp region; insertion and extraction require clearance and containment conditions, with extraction clearing the opening by at least 20 mm.Source: A. MELFI Boxes, Lids and Sample Card · pp. 10–11, Figure 4 · p. 11

B. RRM Panel, Adapters and Receivers

  • The RRM board presents an FDV1 cap, nine row-and-column-addressed SMA caps, and two captive screws; selecting a target rebuilds its movable geometry.FDV1 and SMA use different tools and adapters, and cap-removal tasks require axial withdrawal followed by adapter docking and driver withdrawal.Source: B. RRM Panel, Adapters and Receivers · p. 11, Figure 5 · p. 12
  • Separate receivers accommodate the adapter sizes, while captive screws remain attached to the board and have distinct loosening and tightening requirements.The panel and arm use an authored cabin installation; the original RRM was an external ISS experiment operated with Dextre.Source: B. RRM Panel, Adapters and Receivers · pp. 11–12

Related papers

Loading 2610.31064v1…