1. The station that could not wait for instructions from Earth

Stanisław Lem’s Solaris returns as the recalled work because the research station above Solaris is isolated, subject to forces it does not fully understand, and cannot rely on real-time guidance from Earth. Its survival depends on automatic systems that maintain orientation, power, and life support while the crew argues about what is happening. A LEO desktop is not dealing with sentient oceans, but it is similarly alone for most of each orbit. Autonomous attitude management is not a software module; it is a system-level contract between the bus and the autonomy.

This entry wonders what the desktop must provide for autonomous attitude management to be trustworthy.

2. Sensors and actuator margin

Autonomy cannot manage what it cannot measure. The desktop must provide:

  • redundant attitude sensors with overlapping fields of view and failure modes;
  • rate gyros that do not drift so fast that the estimate becomes useless between updates;
  • magnetometers placed far enough from actuators and power converters to be usable;
  • star trackers with enough sky visibility and thermal stability to acquire when needed;
  • reaction wheels with torque and momentum margin beyond the worst-case disturbance plus slew requirements;
  • magnetorquers sized for detumbling and routine dumping;
  • thrusters or other backup actuators for emergencies.

Margin is the difference between nominal operations and the physical limit. Autonomy spends margin to recover from unexpected disturbances. If the hardware is already operating at its limit, the autonomy has no room to maneuver.

3. A model of the platform itself

The attitude manager needs an accurate inertia model, including mass properties, flexibility, and the location of every moving part. It also needs a thermal model, because the shape of the platform changes with temperature, and a power model, because actuators and heaters compete for the same energy budget. The model must be updated when attachments are added, removed, or deployed.

The desktop must expose this model in a form the autonomy can use: not just a static CAD file, but parameters that can be estimated and refined on orbit.

4. Constraints from other subsystems

Attitude does not exist in isolation. The autonomy must receive constraints from:

  • Power: how much actuator use is affordable before the battery reaches a critical state;
  • Thermal: which surfaces must avoid the Sun, and which need it;
  • Communications: when ground stations are visible and what antenna pointing is required;
  • Payloads: what each instrument needs, when, and with what tolerance;
  • Navigation: orbit position and velocity for predicting geometric events;
  • Fault protection: when to abandon normal pointing and enter safe mode.

These constraints change continuously. The bus must publish them, and the attitude manager must subscribe to them, with agreed units and freshness guarantees.

5. Calibration and commissioning after change

Every attachment swap changes the platform. The desktop must support a commissioning sequence: detumble, identify inertia, calibrate sensors, verify actuator authority, and only then resume nominal operations. Autonomous attitude management is not credible if the platform cannot re-learn itself after a change.

6. What this changes

  • The desktop must be designed as a controllable plant whose properties are observable and updateable.
  • Autonomy needs more than sensor data; it needs constraints, models, and margin from the bus.
  • The next entry will close the wondering arc and set up the test arc.