Overview

CubeSat missions face a persistent challenge: failures happen. Often. From 2000 to 2015, over two-thirds of CubeSat missions that made it to orbit experienced some kind of failure. The reasons are varied—limited development budgets, ambitious designs, and a lack of robust testing procedures. Interestingly, most failures don't happen right out of the gate. They occur in-flight, when the CubeSat works fine one moment, and fails the next. For teams like ours, where resources are tight, this raises an important question: how do we build fault recovery systems that are autonomous, adaptable, and reusable across missions?

This framework is our answer. It's designed to take the burden off CubeSat developers by automating fault recovery and mission replanning. At its core, it uses reinforcement learning (RL)—a way for the CubeSat to "learn" how to adapt on its own when things go wrong.

The Problem We Set Out to Solve

The status quo for fault recovery systems isn’t great. Existing approaches either rely on human intervention (like manually rescheduling the mission plan after detecting a fault) or use redundant hardware to patch over issues. Both have their limits. Human intervention is slow and often impractical during orbit. Redundancy helps only if small-scale faults occur, and even then, it’s costly and resource-intensive. These solutions also focus too narrowly—fixing the fault itself without considering how it impacts the broader mission.

Our goal was to create a system that didn’t just react to faults but planned for them. We wanted something that could:

• Automatically reschedule tasks based on available resources post-fault.
• Optimize task selection to prioritize the most critical mission objectives.
• Run on low-power CubeSat hardware, which meant it needed to be lightweight and efficient.

Our Approach: Two Reinforcement Learning Models

To solve this, we built a framework around two reinforcement learning models that work together:

1. Task Subset Selection This model decides which tasks from the original mission plan should still be attempted after a fault. It takes into account:

   • How much resources (like power or computation time) are available after the fault.
   • The priority of each task, which we rank on a scale of 1–10.
   • The time required to complete the task.

   We used a Deep Q-Network (DQN) for this. DQNs are particularly good at making decisions in structured environments, and they're computationally efficient—perfect for CubeSats with limited onboard processing power.

2. Task Scheduling Once the first model picks the tasks to focus on, the second model schedules them. This involves:

   • Placing time-critical tasks as close as possible to their required execution window (e.g., pointing a camera nadir-facing during periapsis).
   • Filling in gaps with flexible tasks that don’t depend on specific times or locations.
   • Avoiding conflicts or overlaps between tasks.

   This second model also uses a DQN, but with a more complex observation space that includes proximity to target times and available resources.

To make the whole system efficient, we use model caching. Instead of recalculating everything from scratch during a fault, the models pre-train on simulated faults before launch. This way, in-orbit calculations are limited to applying what the model already "knows," saving time and energy.

What We Achieved

We tested the framework using simulated CubeSat missions. Each simulation introduced random faults—like losing half the power capacity or part of the ADCS (Attitude Determination and Control System). Here's how the framework performed:

• Accuracy in Task Selection: The first model was incredibly consistent, selecting an optimal subset of tasks with a 96.46% mean accuracy. This was a huge win, as it shows the model could reliably prioritize tasks even with minimal training.