SFT 2026-27 - LLASO Project 4 - AI Predictive Maintenance for Lunar Robots
SFT 2026-27 - LLASO Project 4 - AI Predictive Maintenance for Lunar Robots
NASA Reference Name: LLASO-P4-AI-MAINT-2026
Executive Summary
Develop an AI system that reads robot telemetry, predicts failures before they happen, and dispatches at-risk robots to the P5 Repair Garage while rotating a standby unit into service — so the fleet keeps running even when no human technician is immediately available. Deliverable: an AI prototype running on simulated or real robot telemetry, with a dispatch interface that feeds the P5 repair workflow.
Requested By
NASA HUNCH / Kennedy Space Center; NASA AI / Autonomy Programs.
Problem Statement
Lunar robot fleets will operate for 30-60 day crewed missions and then autonomously for months between missions. Without predictive maintenance, undetected failures can ground robots at critical moments when no human technician is immediately available.
Requirements Overview
Collect motor, joint, wheel, battery, and thermal telemetry streams
Detect anomalies and predict failures with configurable thresholds
Generate a work order and route the robot to the P5 Repair Garage
Track a standby fleet and dispatch replacements automatically
Accept a robot self-diagnostic override (the robot can confirm or reject an AI flag)
Operate autonomously during uncrewed mission phases
Major Constraints
Real lunar robot telemetry may not be available — synthetic or scaled data must be used
Communication latency to Earth means the system must make decisions autonomously on-orbit
Multiple robot types (P2 transport, P3 unloading, mining, construction) have different failure modes; some robots are always inside and clean, others are always outside and dirty
Repair Garage (P5) capacity is limited — dispatch must prioritize by criticality
Key Challenges
Generating realistic failure signatures in training data without real hardware
Avoiding false positives that waste P5 garage capacity
Handling simultaneous multi-robot failure events gracefully
Balancing the predictive-maintenance schedule against active mission requirements
Follow the Data Specification for RAW Robot Data. Note: We have asked students in the Robotic Projects for this. ( 3B - General Internal Robot Telemetry and Logging Files ) - https://docs.google.com/presentation/d/1SueAmHwFi-P2x_gbm-ykE9V5AHc2u29cNNU-sN_HJJQ/edit?usp=sharing
Missions
## Basic Operations — Missions 1–6
**Mission 1 — Robot Health Check**
Students feed their system telemetry from a simulated robot, RC robot, Arduino, Raspberry Pi, motor, or other test platform and display basic measurements such as battery level, motor current, temperature, wheel speed, and joint status. The system must clearly identify whether each measurement is **NORMAL, WARNING, or CRITICAL**, establishing the foundation for automated robot health monitoring. ([nasahunch.com][1])
**Mission 2 — Find the Anomaly**
Introduce one abnormal telemetry condition—such as rising motor current, excessive temperature, unusual wheel speed, or rapidly declining battery voltage—into an otherwise healthy data stream. The system must automatically detect the anomaly, identify the affected subsystem, timestamp the event, and alert the operator without requiring someone to continuously watch the data.
**Mission 3 — Catch It Before It Breaks**
Instead of introducing an immediate failure, gradually change telemetry over time to simulate a developing problem such as an overheating motor or degrading battery. The prototype must recognize the trend and issue a predictive warning **before** the simulated component reaches its failure threshold; NASA HUNCH specifically identifies predicting a motor failure 15+ minutes before breakdown as an example of excellence. ([nasahunch.com][1])
**Mission 4 — Diagnose the Robot**
Give the system several different simulated failure signatures—for example, battery degradation, motor overheating, wheel resistance, or abnormal joint current. The prototype must determine which subsystem is most likely responsible, assign a severity level, and display the suspected problem on a fleet-health dashboard.
**Mission 5 — Generate the Work Order**
When the AI determines that a robot requires maintenance, it must automatically create a digital work order containing the robot ID, suspected failure, telemetry evidence, severity, recommended action, and predicted time-to-failure. The system must then change the robot's status from **ACTIVE** to **MAINTENANCE REQUIRED** and place it into the Project 5 Repair Garage maintenance queue. ([nasahunch.com][1])
**Mission 6 — Send in the Backup**
Simulate an active robot developing a serious problem while performing a lunar mission. The system must remove the at-risk robot from service, dispatch it toward the repair garage, select an appropriate standby robot, and place that replacement into service while maintaining a digital record of the entire decision—demonstrating the project's goal of maintaining operations without mission gaps. ([nasahunch.com][1])
# Innovative / Out-of-the-Box Missions — Missions 7–12
**Mission 7 — AI vs. Robot: Who Is Right?**
The AI flags a robot for maintenance, but the robot's onboard self-diagnostic system reports that it is healthy—or the reverse occurs. The student system must compare both assessments, examine the supporting telemetry, calculate confidence in each diagnosis, and autonomously decide whether the robot should **CONTINUE, LIMIT OPERATIONS, or GO TO REPAIR**, demonstrating the project's required self-diagnostic override capability. ([nasahunch.com][1])
**Mission 8 — Lunar Fleet Triage**
Three robots simultaneously report different developing problems, but the Repair Garage has room for only one robot. The AI must consider predicted time-to-failure, mission criticality, available standby robots, repair urgency, and garage capacity to determine the maintenance sequence while keeping as much of the lunar operation running as possible—directly addressing HUNCH's limited-garage-capacity constraint. ([nasahunch.com][1])
**Mission 9 — The Robot That Teaches the Fleet**
One lunar robot discovers a new failure signature that the other robots have never encountered; the system must learn from that event and improve future detection across the fleet. Advanced teams could demonstrate **federated learning**, allowing robots to contribute to a shared failure model without transmitting all of their raw telemetry—an innovation specifically suggested in the HUNCH project. ([nasahunch.com][1])
**Mission 10 — "Why Are You Sending My Robot to the Garage?"**
The AI may no longer simply announce that a robot will fail—it must explain its reasoning in understandable language, such as: *motor temperature has risen while RPM has decreased and current consumption has increased*. Students must create an **Explainable AI (XAI)** interface that shows the evidence behind the prediction, estimated time-to-failure, confidence level, and recommended maintenance action so an astronaut or technician can understand **why** the AI reached its conclusion. ([nasahunch.com][1])
**Mission 11 — Ask the Lunar Fleet**
Students create a natural-language or voice interface that allows an astronaut or Mission Control operator to ask questions such as **"Which robots are at risk?"**, **"Which robot needs maintenance first?"**, or **"Can we complete today's cargo mission?"** The AI must analyze current and historical telemetry and respond with an understandable fleet-health summary supported by the underlying data; a natural-language crew interface is another innovation identified by NASA HUNCH. ([nasahunch.com][1])
**Mission 12 — 30-Day Autonomous Lunar Fleet Challenge**
Run an accelerated simulation representing **30 days of lunar operations** involving multiple robot types, changing mission assignments, component degradation, false alarms, unexpected failures, standby robots, and limited Repair Garage capacity. With no human intervention during the simulation, the AI must continuously predict failures, prioritize maintenance, generate work orders, rotate standby robots, learn from previous failures, and maintain the highest possible fleet availability—then produce an end-of-mission report explaining **what it predicted, what actually failed, which decisions it made, and how accurate those predictions were**. ([nasahunch.com][1])
### A strong progression for judging
These missions naturally move students through **Telemetry → Anomaly Detection → Trend Analysis → Failure Prediction → Work Orders → Autonomous Dispatch → Conflicting Diagnostics → Fleet Triage → Learning → Explainable AI → Human/AI Interaction → Full Autonomous Fleet Management**.
That progression also fits NASA HUNCH's broader Software and Technology program emphasis on delivering **working products**, with students addressing software development, design, quality assurance, and user testing—not merely demonstrating code. ([nasahunch.com][2])
[NASA HUNCH — Project 4: AI Predictive Maintenance for Lunar Robots](https://nasahunch.com/projects/sft-2026-27-llaso-project-4-ai-predictive-maintenance-for-lunar-robots-n77o9n3o27fhozkq28jootsy?utm_source=chatgpt.com)
[1]: https://nasahunch.com/projects/sft-2026-27-llaso-project-4-ai-predictive-maintenance-for-lunar-robots-n77o9n3o27fhozkq28jootsy?utm_source=chatgpt.com "SFT 2026-27 - LLASO Project 4 - AI Predictive Maintenance for Lunar Robots"
[2]: https://nasahunch.com/programs/software?utm_source=chatgpt.com "Software and Technology Hardware Engineering plus Robotics"
Please Click the link here for more robot information
More Info below
Other Suggestions for High School Students
Simulated telemetry from an RC robot or a stepper motor is an acceptable data source
The AI model can be a simple threshold / rule system for beginner teams; use machine learning for advanced teams
The dispatch interface can be a dashboard mockup rather than a live system
A single robot type (for example, the transport robot only) is fine for keeping the scope manageable