Given a Starship-style launch-cost collapse, if we explicitly model software and autonomy for orbital robotics as the main learning curve (rather than hardware mass-production), what specific task categories (e.g., inspection, standardized docking, modular assembly, in-situ repair) should be prioritized to maximize cross-mission reuse and steepen Wright’s-law cost declines for robotic labor across manufacturing, servicing, and debris mitigation at the same time?

starship-orbital-economy | Updated at

Answer

Prioritize a small set of generic, high-frequency task families that appear in manufacturing, servicing, and debris work, and make autonomy/software reusable across all of them.

Priority task categories (in rough order)

  1. Relative navigation, inspection, and state estimation
  • Core behaviors: approach, station-keep, map, classify state.
  • Reused in: constellation inspection, factory-line monitoring, pre-/post-service checks, debris characterization.
  1. Standardized capture and docking
  • Core behaviors: soft-dock to standard fixtures, grapple non-cooperative targets, secure/berth payloads.
  • Reused in: satellite servicing, debris capture, payload handling on platforms, module swaps in factories.
  1. Payload handling and modular reconfiguration
  • Core behaviors: pick/place standard “blocks” (racks, tanks, experiment pods), align/connect to backplanes, re-slot modules.
  • Reused in: orbital manufacturing line changes, replacing failed units, configuring testbeds, staging debris for deorbit.
  1. Simple in-situ repair and part swap
  • Core behaviors: remove/replace ORU-style modules, swap cards/boards, reseat connectors, close panels.
  • Reused in: satellite life extension, platform upkeep, factory tool maintenance, service tugs themselves.
  1. Tug-style orbital logistics operations
  • Core behaviors: rendezvous chains, tow/relocate assets, controlled deorbit, safe-lane transits.
  • Reused in: servicing campaigns, debris removal, moving factory modules/compute racks between platforms.

Why these maximize Wright’s-law effects

  • They are:
    • high-frequency across many missions (lots of cumulative “robot tasks”),
    • similar enough to share perception, planning, and safety stacks,
    • central to any dense, robot-heavy orbital economy (manufacturing, servicing, debris).

De-prioritize (until later)

  • Complex, niche tasks with weaker reuse: precision microgravity process steps tightly tied to a single product, high-DOF dexterous manipulation for custom repairs, large-scale construction unique to one platform.

Implication

  • Treat the “product” as a common autonomy stack for: inspect → dock/capture → move → reconfigure → swap/repair. Hardware can vary; software, interfaces, and task APIs should be as generic as possible to steepen learning curves for orbital robotic labor.