1. The cloister that planned in centuries

Neal Stephenson’s Anathem is about a community that takes the long view. The scholars of the concent measure time in decades and centuries, not because they are slow, but because some problems need that kind of patience. They also know that no single contemplation solves everything; each one clears the ground for the next. The desktop is a much smaller enterprise, but the ADCS arc has the same rhythm: a few entries to frame the problem, a few to examine the parts, and one to close the circle.

Entries 259 through 263 defined the attitude determination and control system. This entry closes that arc and decides what comes next.

2. What the ADCS arc settled

The desktop’s ADCS is now a coherent subsystem rather than a vague need to “point somewhere.”

The decisions are:

  • ADCS is its own attachment because it negotiates between the pointing needs of the imager, solar arrays, radiators, star trackers, antennas, and thrusters.
  • The desktop needs five core pointing modes: nadir, Sun, inertial, target tracking, and safe mode.
  • Pointing accuracy is moderate for routine operations, coarse for safe mode, and finer for target tracking or short-exposure imaging.
  • The sensor suite is a star tracker, coarse Sun sensors, a MEMS gyro triad, a three-axis magnetometer, and a GPS receiver.
  • The actuator suite is four reaction wheels, three magnetorquers, and thruster assist from the propulsion attachment.
  • Attitude is estimated with an extended Kalman filter that fuses all sensors and rejects outliers.
  • Control uses nested attitude and rate loops, with momentum dumping via magnetorquers.
  • Safe mode is a simple survival state: Sun acquisition, power-positive, beacon, wait for ground.
  • Fault detection and isolation allow the ADCS to reconfigure rather than immediately give up.

These decisions give the propulsion attachment the torque authority it needs. They also give the structure the sensor and actuator mounting constraints it must accommodate.

3. What remains outside the arc

Several integration questions were deliberately deferred:

  • How exactly does the operations attachment schedule mode transitions and slews?
  • How does ADCS coordinate with power during eclipse, when wheel torque and magnetorquer current compete with battery reserves?
  • How does ADCS behave during a robotic service event, when the centre of mass may shift?
  • How are ADCS gains and filter parameters calibrated on orbit?
  • How does the ground operator command attitude and monitor ADCS health?

These will be answered when the operations attachment is defined.

4. Why operations is next

The next attachment to define is the operations architecture: the ground segment, the command and control workflow, the autonomy budget, and the fault response procedures. There are three reasons for this order.

First, operations is the interface between the spacecraft and the people who run it. ADCS can point the desktop, but operations decide when and where to point it, how often to contact ground, and what to do when contact is lost.

Second, the operations model determines how much autonomy the desktop needs. A mission with frequent ground contacts can tolerate simpler onboard decision-making. A mission with sparse contacts needs more autonomy in safe mode, payload scheduling, and anomaly recovery.

Third, operations ties together all the attachments defined so far. Compute, storage, communications, sensor, power, thermal, structural, propulsion, and ADCS all produce telemetry and accept commands. Operations is the pattern that makes them usable as a single spacecraft.

5. The operations questions to answer

The next few entries should answer:

  • What is the ground segment architecture: mission control, ground stations, cloud backhaul?
  • How often does the desktop communicate, and through which links?
  • What autonomy is onboard, and what remains on the ground?
  • How are commands sequenced, verified, and executed?
  • How are anomalies detected, reported, and recovered?
  • How is the mission timeline built from payload requests, orbit constraints, and resource budgets?

These are ordinary operations questions, but they deserve their own arc because they turn a well-designed spacecraft into a service that customers can actually use.

What this changes

  • The ADCS attachment arc is closed with consistent specifications for sensors, actuators, control law, and safe mode.
  • The next arc will define operations: ground segment, autonomy, commanding, and anomaly response.
  • Integration questions about ADCS are held until operations and the overall software architecture are defined.
  • The desktop’s attachment grid now has a sixth proven pattern, following compute, storage, sensor, power, thermal, structural, and propulsion.