Senior design · 2026–2027
Small Debris Detection Satellite
A spacecraft and constellation concept for detecting sub-centimetre orbital debris in situ, using an event-based optical payload. Two semesters, a 23-person team, ending in an integrated flatsat demonstration.
In progress · advisors Prof. Marcus Holzinger and Prof. Tomoko Matsuo
The gap
Debris smaller than about three centimetres is effectively invisible. It is too small for ground-based radar and optical assets to track, and there is far too much of it for that to be comfortable: at orbital velocity a fragment of that size is a mission-ending impact. The population between 600 and 1,000 km, the most heavily used band in low Earth orbit, is characterised largely by inference rather than by measurement.
NASA’s Office of Inspector General has identified filling that measurement gap as an agency priority, and national orbital debris research and implementation plans carry the same direction. There is a second motivation from an unexpected direction: NASA’s Heliophysics Division treats the small debris population as a sensitive statistical tracer of space weather, because thermospheric drag acts hardest on the smallest objects. Measure the small debris population well enough and you are also measuring the upper atmosphere.
The only way to see these objects is to go and sit among them. That is the mission: a spacecraft-hosted sensor making direct, in-situ optical measurements of debris that no ground asset can resolve, returning size, signature and relative motion to feed the debris environment models everyone else’s risk assessment depends on.
Why an event camera
The payload is an event-based, or neuromorphic, sensor. Rather than reading out full frames at a fixed rate, each pixel reports independently and asynchronously when its brightness changes. For this problem that is close to ideal. A debris fragment crossing the field of view at kilometres per second is a moving brightness change against a static star field, which is exactly what the sensor is built to report, and the data volume scales with what is actually happening rather than with the frame rate. A conventional imager would spend nearly all of its downlink budget on empty sky.
The two semesters
| Fall | Requirements flowdown from the mission objective, trade studies on sensor field of view against range and search volume, constellation design and observation scheduling, subsystem design, and two formal design reviews. |
|---|---|
| Spring | Prototype build, subsystem and system testing, culminating in an integrated flatsat. |
| Final deliverable | A flatsat carrying the event-camera payload, demonstrating autonomous detection, tracking and characterisation of debris surrogates across a multi-day ground test, transmitting science and telemetry data over an RF link to a ground station. |
| Modelled, not tested | Orbit geometry, encounter velocities, lighting and thermal environment. Testing happens at room temperature on wall power, so the space environment is carried entirely in analysis. |
The split between what gets tested and what gets modelled is the interesting engineering constraint here. Encounter velocities cannot be reproduced on a lawn in Boulder, so the ballistic surrogate tests have to be designed such that the simulation scaling to representative orbital encounters is defensible. The test does not prove the system works in orbit; it anchors the model that does.
My part: electronics
I am the Electronics Lead, which on this team means owning the power subsystem: the power budget, power routing and PCB design, harnessing and cabling shared with Structures, and wall-power distribution for the prototype. As subsystem lead I also own the design and its requirement verification, the subsystem’s budget, and the job of tracking how it integrates with everything else.
Power is easy to mistake for a support function that simply sizes itself to whatever the other subsystems ask for. On this mission it is not, because of one requirement: the system schedules its observations subject to power and data budget constraints. That makes the power budget an input to the autonomy rather than a consequence of it. What the spacecraft is allowed to look at, and for how long, falls out of what the power system can sustain, so the budget has to be credible early enough for Payload and CDH to design the scheduler against it.
The event camera complicates the estimate in an interesting way. Because its pixels report asynchronously when brightness changes, its data rate, and the downstream processing load that follows it, depends on how much is happening in the scene rather than on a fixed frame rate. The load is driven by the debris flux, which is the very quantity the mission exists to measure and therefore the quantity we know least well. Budgeting against a demand that is itself uncertain is the part of the job I expect to be hardest to do honestly.
There is also a split running through the whole subsystem. The flight power architecture, solar generation, storage and margin across the orbit, is analysis only. The prototype runs on wall power through a multi-day autonomous test. So one half of the work is a design nobody will plug in, and the other is distribution hardware that has to survive several days of unattended operation without a person nearby to reset it.
Structurally, Power is also the most distributed subsystem on the team. Its three engineers are split one each across the sensor, comms and flatsat test teams rather than sitting together on a test team of their own, which means the subsystem sees three different test campaigns first-hand and has to carry what it learns between them.
Team
The section runs as two teams of 23, drawn from Payload, Structures, Comms, Power, GNC and CDH, with every engineer also serving on one of four test teams. Subsystem membership and test-team membership are two views of the same people rather than two separate jobs, which is a deliberate structure: the person who designs a subsystem is in the room when it is tested.