§ 02 - PROBLEM

The problem

Long-duration space missions don't have natural sunlight, and the absence of the sun's daily cycle is a known problem for human crews: circadian rhythms drift, sleep quality drops, cognitive performance suffers. Plants grown on board have their own version of the same problem, with different mechanisms; they need the right amounts of red and blue light at the right times to grow.

So a spacecraft cabin needs lighting that does two things at once: entrain the crew's circadian rhythm, and grow plants on a separate schedule. The constraint for our senior design project was that the controller had to do both in real time, in a physical setup we could ship to a conference. That meant a Raspberry Pi running Python over Open Lighting Architecture, LUX and RGB sensors on the bus, and a closed loop that read the actual delivered light and corrected back to setpoint. We also noticed bulbs and sensors drift over time, so we bolted on compensation logic that did the job, mostly.

§ 03 - APPROACH

Approach

The system runs on a Raspberry Pi 4 in Python, talking to the lighting hardware over Open Lighting Architecture (OLA) on a DMX-512 bus. Two sensor streams come back the other way: LUX sensors measure overall illuminance in the cabin, RGB sensors measure the spectral mix at the canopy. Both feed into a closed loop that compares the delivered light against the schedule's current setpoint and adjusts RGB output until the readings match.

Two schedules run in parallel. The crew schedule is a 24-hour curve that ramps cool-blue light at simulated dawn, holds bright daytime levels through the work hours, warms toward amber in the evening, and cuts to a low-blue night mode. I built the schedule by tracking my own sleep and wake times for two weeks and using the average as a baseline circadian rhythm, so the controller had a real human's rhythm to match instead of a synthetic curve. The plant schedule is simpler: red and blue at the intensities and durations the crops need, on their own clock independent of the crew.

§ 04 - MY ROLE

My role

Three-person team for senior design at UNT, with a faculty advisor at NASA via Texas Space Grant Consortium. I owned the hardware integration end of the project, shared the schedule logic, and handled the team's documentation and external communication.

Specifically:

  • Hardware setup and sensor integration. Specced and procured the Raspberry Pi units, LUX sensors, RGB sensors, and the bus components. Built the physical demo rig, including the breadboard layout, the wiring, and the transport-friendly enclosure.

  • Schedule logic, on the human side. Tracked my own sleep/wake times for two weeks and used the average as the baseline circadian rhythm the controller ran against. Wrote the day-curve schedule that the controller follows.

  • Team documentation. Wrote the project documentation, design records, and final report. Distributed builds and notes via the team's repo.

  • NASA advisor liaison. Primary point of contact with the Texas Space Grant advisor.

The lighting hardware design and the plant schedule were owned by teammates; I supported their integration into the closed-loop controller.

§ 05 - OUTCOME

Outcome

The system was demonstrated at a Texas Space Grant Consortium conference in Houston in Spring 2022. Attendees included NASA representatives, astronauts, research scientists, and teams from other Texas universities showing their own NASA-sponsored projects. We didn't win an award, but the booth saw steady traffic all day and the questions we got suggested the work was being taken seriously. The same setup served as the senior design demo for UNT later that semester.

The detail I remember most is from the morning of the conference. Some of our wiring, sensors, and the plant itself had taken damage in transport. We spent the hour before the doors opened doing repairs in the parking lot of the conference center: re-soldering connections, rewiring sensors, and trying to convince the plant to look alive. The rig worked all day after that.

The lesson I took from that morning is one everyone who ships hardware learns eventually. The system you should optimize for is not the one that arrives intact, it's the one that can be repaired by the people standing next to it. I think about that one a lot when I'm writing software too.