DESMAS - Deep Space Management System

When help is light-minutes away, survival can't wait. DESMAS autonomously protects critical systems and helps crews understand emergencies - from lunar bases to remote clinics on Earth.

Comment

Inspiration

On Earth, when something goes wrong, we call for help. On Mars, a message to Earth takes between 3 and 22 minutes to arrive, depending on where the two planets are in their orbits, and a reply takes just as long. What happens in between?

Future space habitats will need to survive power shortages, environmental hazards, and equipment failures without waiting for instructions from mission control. But this challenge isn't limited to space. Remote medical clinics and disaster-stricken communities face a similar question: when resources are scarce and outside help is delayed, what must keep running?

We built DESMAS around a simple principle: the systems that keep people alive should never have to wait for the cloud.

What it does

DESMAS (Deep Space Management System) is a hardware-connected prototype for autonomous infrastructure management across three environments: a lunar habitat, a future Mars base, and an off-grid medical clinic on Earth.

Its core is a priority-based controller that responds to changing environmental conditions. As available light decreases, the system sheds comfort first, then science, and only in near-total darkness drops communications to a low-power state. Life support is never shed.

An Arduino monitors light, temperature, and humidity, controls four LEDs representing infrastructure loads, and sounds an alarm when humidity rises past a calibrated threshold. The board runs these rules on its own, so the hardware keeps protecting essential loads even with the laptop disconnected.

The same four loads mean different things in each environment. On the Moon they are life support, communications, science, and comfort. In the off-grid clinic they become the vaccine fridge, the radio, the exam-room lights, and the fan, so when the sun goes down the clinic turns off the fan and lights first and keeps the vaccines cold through the night on battery.

A web dashboard turns these physical events into an interactive mission-control experience, showing live sensor readings, system status, and alerts across three 3D environments.

The crew-facing interface uses Grok Voice. When an alert fires, DESMAS announces it out loud with Grok text-to-speech, and crew members can type questions about live sensor conditions and recent incidents. Safety-critical load control stays on the Arduino and does not depend on Grok or an internet connection.

To explore what autonomy means in deep space, DESMAS uses real Earth–Mars communication-delay data from NASA JPL Horizons. The Mars interface separates urgent situations that need immediate local action from noncritical decisions where consulting Earth is still practical.

We also built historical scenario replays from real NASA observations. Earth scenarios use NASA POWER solar irradiance data, and Mars scenarios use Curiosity Mastcam atmospheric optical-depth measurements. These observations drive a mathematical model of the controller, so users can explore how different environmental conditions would affect infrastructure priorities without interfering with the live hardware.

The result is a system with two distinct responsibilities: autonomous control to protect essential functions, and human-facing intelligence to explain what is happening.

How we built it

We started with an Arduino Mega, a photoresistor, a DHT11 temperature-and-humidity sensor, four LEDs, and a buzzer.

The controller uses four priority levels:

  • P1: Life support — always protected
  • P2: Communications — enters a blinking low-power warning state at 85% darkness
  • P3: Science — shed when darkness reaches 55%
  • P4: Comfort — shed when darkness reaches 30%

On startup, the board records the room's normal light level and humidity, and every threshold is measured relative to that baseline. "Darkness" is how far the light reading has moved from normal toward fully covered. This lets the same hardware work in any room, and the board can recalibrate on command when conditions change. Darkness stands in for reduced solar input; a real habitat would shed loads based on battery state of charge, which is our next step.

We implemented hysteresis around these thresholds to prevent rapid switching caused by small fluctuations in sensor readings. A humidity increase of 10 percentage points above the startup baseline triggers a separate alarm.

The Arduino streams structured JSON readings over USB every 500 milliseconds. Our web application reads these events and translates them into a live visual representation of each environment. We also built a simulator so the interface can be tested without physical hardware.

For the crew interface, we implemented Grok text-to-speech for spoken alerts, with server-side API-key handling. We also built the realtime voice connection, but API-access restrictions kept it from working reliably during the event. The assistant retrieves current sensor readings and incident history rather than relying on hardcoded information.

Mathematical model validation. We independently implemented the Arduino's priority and hysteresis rules in software, then compared the model's predicted LED states with the actual states reported by the Arduino. This lets us test whether the simulated controller behaves consistently with the physical hardware. We verified the model during live sensor changes, including transitions into load-shedding states.

NASA historical scenario replay. We extended this model to explore environmental conditions beyond our tabletop hardware.

For Earth, we retrieved hourly surface solar irradiance observations from NASA POWER for June 21, 2025, at 38°N, 77°W. We converted the observed irradiance (I(t)) into a modeled darkness index:

$$ D_{\mathrm{Earth}}(t) = \operatorname{clip}\left(100\left(1-\frac{I(t)}{I_{\mathrm{ref}}}\right),0,100\right) $$

Here, I_ref = 903.47 Wh/m² is the maximum observed hourly value in the selected day. Users can scrub through the 24-hour dataset and see how the modeled load priorities respond.

For Mars, we used Curiosity Mastcam observations of atmospheric optical depth at 880 nm from Gale crater. These measurements capture changes in atmospheric opacity, including the rapid increase associated with the 2018 global dust storm. We converted the observed optical depth　(\tau(t)) into a modeled environmental-stress index:

$$ D_{\mathrm{Mars}}(t) = \operatorname{clip}\left(100\frac{\tau(t)}{\tau_{\mathrm{ref}}},0,100\right) $$

Here, τ_ref = 8.589 is the maximum optical depth in the selected replay window. The scenario shows how increasing atmospheric opacity can trigger progressively stricter load-shedding decisions in our model.

These indices are modeling assumptions, not direct measurements of battery charge or available electrical power. Historical NASA observations are replayed separately from the live Arduino sensor stream, preserving the distinction between observed data, simulated responses, and physical control.

We used Cursor throughout development to build, debug, test, and integrate the application.

We also used Grok Bot to plan the project and divide work across the team.

Challenges we ran into

One challenge was connecting physical hardware to an interactive web experience while keeping the same underlying control logic across different environments.

Another was deciding which decisions should depend on AI. We deliberately kept critical load-control rules on the Arduino rather than relying on a remote model.

We also ran into API-access restrictions early in testing Grok Voice. Working through them pushed us to separate voice-based assistance from the controller's essential functions, so the hardware keeps operating even when the AI service is unavailable.

A further challenge was translating real environmental observations into meaningful simulations. NASA POWER irradiance and Mars atmospheric optical depth measure different physical quantities. Rather than treating either as a direct measurement of electrical power, we defined transparent normalization rules and kept historical scenario predictions separate from live hardware readings.

Accomplishments that we're proud of

We're proud that DESMAS connects a tangible hardware demonstration to a larger problem: autonomous decision-making when infrastructure is isolated.

Our prototype makes priority-based load shedding visible through physical LEDs and software events. We integrated Grok Voice with live operational data and built communication-aware decision support using real Earth–Mars signal-delay information.

We are particularly proud of validating our mathematical model against physical hardware. Instead of relying solely on a simulated demonstration, we compared predicted LED states with the Arduino's actual outputs and tested the model during changing light conditions.

We also integrated two real NASA datasets into interactive historical replays, allowing users to explore how solar irradiance on Earth and atmospheric opacity on Mars affect modeled infrastructure priorities.

Our automated test suite passed 29 tests covering the hardware interface, simulation logic, NASA data processing, and application state.

Most importantly, we built around graceful degradation: losing access to a remote AI service does not stop the core controller.

What we learned

Building DESMAS taught us that autonomy is not simply about adding intelligence. It is about deciding which actions must remain reliable when communication, power, or external services fail.

We also learned how challenging it is to translate noisy physical sensor readings into meaningful operational information, and how much a good interface matters when humans need to understand a system under pressure.

Working with NASA data reinforced another lesson: a useful simulation must be explicit about the difference between what is measured and what is modeled. A real atmospheric observation can help us investigate possible system responses, but it is not itself a measurement of a habitat's electrical power supply.

What's next for DESMAS

Our prototype uses darkness as a proxy for reduced solar-power availability. A future version would incorporate actual voltage, current, battery state of charge, and power-generation forecasts, so loads are shed based on how much energy is actually left rather than on light alone.

We also want to develop predictive resource allocation, test fault-tolerant operation under more realistic failures, and extend our historical NASA simulations to additional locations and environmental conditions. Another direction is to formally specify and verify the safety properties of the controller, including guarantees that essential services remain protected under defined failures.

Ultimately, we envision DESMAS as a modular system that can help manage critical infrastructure wherever timely human intervention cannot be guaranteed.

Share this project:

Updates

Submission history