In many autonomous spacecraft and robots, two groups of engineers share one problem without working from the same state. Power and thermal engineers keep batteries charged and components inside their temperature limits. Autonomy engineers decide what the system does next. Fixed budgets and design margins carry the coupling because the plannerThe software that decides what a robot or spacecraft does next, and in what order. It is separate from the control loop, which carries out each action once it has been chosen. may not see how battery and thermal state change as it moves work through time.
This initiative examines what changes when the planner can see those states directly, through physics models fast enough to run inside the planning loopThe repeating cycle in which a planner reads the current state, chooses the next actions, then revises as the state changes. For a physics model to sit inside this loop rather than beside it, it has to run fast enough to be consulted on every pass.. The objective is not to remove prudent marginExtra capacity added to a design to cover what engineers cannot predict: a larger battery, a bigger radiator, or thicker insulation. Margin has a mass cost, which is often a limiting resource in space-system design.. It is to measure when margin is being consumed, when some of it can be allocated to useful work, and when the system must preserve it.
One primary proof, followed by transfer tests
The primary proof is Reference Mission 01A bounded, published mission scenario used to test one research claim. It fixes the assumptions, initial conditions, limits, metrics and comparison method so that another team can run the same study.: lunar-night survival for a representative small rover. Before sunset, the rover must decide how much useful work to complete, how much energy to store, and how to schedule heater loads as illumination falls. The planner succeeds only if it keeps battery state and modeled node temperatures inside their declared limits across the full uncertainty set.
In-orbit servicingRepairing, refueling, inspecting or moving a satellite while it is still in orbit, instead of replacing it., power beamingSending energy as a beam, by laser or microwave, rather than through a cable. It would let a satellite draw power from elsewhere instead of carrying an array large enough for its own peak demand., and a high-power spacecraft payload remain transfer cases. They share the coupling between scheduled work, stored energy, and heat rejectionGetting waste heat out of a vehicle. In space, a radiator panel emits that heat as radiation. Heat rejection can constrain high-power spacecraft before available electrical power does., but they introduce different time scales and operating limits. We will test them after the lunar reference result establishes which parts of the model and planner contract are general.
This sequence matters. One reference mission can produce a result that is clear enough to challenge, reproduce, or reject; four simultaneous demonstrations cannot.
The research question
On a small-rover reference mission built from published parameters, does a planner using coupled battery and thermal state complete more useful work than a fixed-budget schedulerThe existing or simpler method against which a new result is compared. Both methods must receive the same hardware assumptions, starting conditions and environment for the comparison to mean anything. without violating temperature, state-of-charge, runtime, or uncertainty limits?
That question separates into four claims.
Feasibility
A coupled planner can keep the modeled rover within its battery and thermal limits through the mission horizon.
Operational value
Under the same hardware, initial state, and environment, it can complete more useful activity or preserve a higher probability of survival than the fixed-budget baseline.
Planning performance
The physics model and solverThe code that computes the answer to a physics problem, such as a temperature field or a power flow. Distinct from the model, which describes the problem. can return a decision within the declared planning deadline, with deadline misses reported rather than hidden.
Transfer
The model and planner contracts can be reused for later servicing and high-power cases, although the policy, parameters, and validation evidence will change.
We will report survival to the target time, useful activity completed, minimum state of chargeHow much energy is left in a battery, given as a fraction of its full capacity., minimum and maximum node temperature, solver runtime, deadline misses, and the count and magnitude of constraint violationsAn occasion when a planned or simulated state crosses a declared limit, such as a battery falling below its minimum charge or a component exceeding its allowed temperature. Reporting both the count and size of these events prevents useful-work metrics from hiding an unsafe plan.. Results will include sensitivity across the published uncertainty range.
What we are building
The initiative is organized as a five-module reference architecture, planned for release under Apache-2.0A permissive open-source license. It allows commercial use, modification and redistribution, and it carries an explicit patent grant..
Models
Solar generation, battery state, bus losses, component heat loads, and a lumped thermal networkA model that treats a vehicle as a handful of connected blocks, each held at a single temperature, instead of solving the full temperature field. At a suitable size and fidelity, it can run fast enough for a planning loop, and it remains an approximation. with conduction, radiation, and radiatorThe panel that sheds a spacecraft's waste heat by radiating it into space. Its size is one major factor in the vehicle's heat-rejection capacity. rejection. Each model will have a plain reference implementationA plain version of a model, written for clarity rather than speed and checked against reference cases. Faster versions are compared with it against stated tolerances. and, where speed matters, an optimized fast path tested against it.
Environment
Orbit and eclipseThe stretch of an orbit spent inside a body's shadow, where no sunlight reaches the solar arrays. The vehicle runs on battery, and its thermal balance inverts from shedding heat to holding it., sun vectorThe direction to the Sun from the vehicle. It sets how much power the arrays make and which surfaces are being heated., lunar surface illumination and thermal boundary. An analytic backend will come first, and an interface to established dynamics simulators such as BasiliskAn open-source simulation framework for spacecraft dynamics, attitude and orbital motion. is planned behind it.
Planners
A duty-cycle scheduler will be formulated as a mixed-integer programAn optimization problem in which some of the decisions are whole numbers or on/off switches rather than continuous quantities. Choosing which heater runs in which time slot is naturally this shape, and it is expensive to solve., followed by a receding-horizonPlanning over a short window ahead, executing the first step, then planning again from the new state. It can respond to changing conditions more often than one long fixed schedule. controller with constraint tighteningPlanning against limits deliberately stricter than the real ones, so that model error or an unexpected disturbance does not push the actual system past the actual limit. and a learned policy as a baseline for comparison.
Simulator
A closed-loop scenario runner will couple the three modules above and be reproducible from a single file and a seed.
Benchmark
Reference Mission 01, its metrics, uncertainty set, and fixed-budget baseline will come first. In-orbit servicing under eclipse, laser duty cyclingThe fraction of time a component spends switched on. Once hardware is built, cycling a heater or laser can be one available way to manage its energy use and heat load. against a radiator limit, and a small satellite with a high-power payload will follow as transfer cases.
Five modules connect models, environment, and planners to a closed-loop simulator and benchmark. Solvers feed the models and planners, while the simulator returns state to the planners.
Scroll horizontally to inspect the full diagram.
Evidence gates
| Gate | Evidence required |
|---|---|
| Reference definition | Published mission assumptions, parameter sources, uncertainty ranges, metrics, and fixed-budget baseline |
| Analytical result | Model checks against reference cases, comparison with the baseline, and reported constraint or deadline violations |
| Independent reproduction | A clean run by a team outside Mindpool using the published scenario and release |
| Relevant-environment test | The same claims tested on a battery, heater, and radiator breadboard at a partner facility |
Reference definition
Evidence required
Analytical result
Evidence required
Independent reproduction
Evidence required
Relevant-environment test
Evidence required
The specifications will record public interfaces and assumptions while the model and baseline develop. A survey paper will establish the vocabulary; the lunar reference result will test the first claim. Later papers address transfer to servicing, faster thermal surrogatesA fast stand-in for a slow physics solver, usually machine-learned from that solver's own output. Physics-informed means the approximation is held to known physical laws instead of only fitting the data., independent benchmarkA fixed set of scenarios, metrics and baseline methods that anyone can run, so that results from different groups can be compared honestly. runs, and hardware-in-the-loopA test in which real hardware runs inside the simulation, so the software drives actual batteries, heaters and radiators rather than modeled ones. validation. Each paper is planned to include the code and inputs required to reproduce its result. Review the research program
Research software boundary
The benchmark will record units, model fidelity, agreement tolerances, solver deadlines, and every observed constraint violation. These planned releases will support research and design studies. They will not be flight-qualified control software; a vehicle program would require independent qualification, vehicle-specific verification, and its own safety review.
Status
| Item | Badge |
|---|---|
| Specifications (RFC-001 to RFC-006) | In progress |
| Survey paper | In progress |
| Reference Mission 01 definition | In progress |
| Fixed-budget baseline | Planned |
| Analytical benchmark | Planned |
| External benchmark runs | Planned |
| Transfer cases | Planned |
| Hardware-in-the-loop validation | Planned |
Specifications (RFC-001 to RFC-006)
Badge
Survey paper
Badge
Reference Mission 01 definition
Badge
Fixed-budget baseline
Badge
Analytical benchmark
Badge
External benchmark runs
Badge
Transfer cases
Badge
Hardware-in-the-loop validation
Badge
Who we are looking for
We are looking for thermal engineers who can challenge the rover model, autonomy researchers who can challenge the baseline, and organizations that can review a realistic surface scenario before the reference mission is fixed. Servicing and high-power scenarios remain welcome as transfer cases. View open roles · Propose a scenario
The initiative brings energy and heat into the decision without pretending uncertainty has disappeared. If the result holds, a small mission gains greater latitude to use its available hardware while preserving the limits that keep it alive.