Frictionless

Aurora needed an repeatable in-house testing process for their plasma brake product, which is a tether-based device that deorbits satellites at the end of their mission.


Role: Designer / Engineer (as part of group of 11)
Course: Product Design Project
Tools: Raspberry Pi, micro-controllers, etc.
Duration: 9 months

Frictionless

Plasma brake deployment test rig

product design, hardware & software prototyping

Simulating space-like condition on Earth
Understanding the requirements

We began by understanding the problem. Through research and interviews, we compiled a requirements sheet capturing every parameter.

e.g. the mass and moment of inertia of the tested hardware; the size and range of motion the engineers expect; how controllable and operable the system needs to be …

Plasma Brake Test Bench requirements spreadsheet
My contributions, highlighted, in the "Frictionless" system
Sketches of the 'EMMA' end-mass motion analogue, the satellite mock-up, and the graphical user interface
My contributions: Control system

I implemented 3 control flows, all initiated from the main controller (Raspberry Pi):

  1. Controller → Solenoid activated release (via GPIO pin voltage control)
  2. Controller → EMMA's microblower (via bluetooth)
  3. Controller → Spin-up controller (via USB to the microcontroller)

For each of these flows, I used software-based simulators to mock the response behaviors as the receiving counterpart was still under development (by other team members).

Caveat: The integration still took longer than expected. This was mainly due to confusion about differences in microcontroller models and their mappings, lack of communication that caused mismatch in code, and accidental damages (e.g. me frying a connected raspberry PI on a steel plate).

Learnings: Start integration early. Theoretical readiness is reassuring, but still be prepared with added buffers in the schedule. Document the setup steps as there may be a need to redo.

My contributions: Graphical User Interface

I presented a sketch of my vision for the GUI to the client: the interface is not only a monitoring tool (as they had suggested), but it's also a controller.

“That would be very useful,” the client said. “But it sounds hard to implement.”

With the naive confidence of someone who hadn't yet tried to implement it, I reassured them: we could make it work.

Hand-drawn sketch of the GUI from the client meeting
Sketch from the meeting

I designed the graphic processing pipeline so that the system never had to put raw frames into storage. Instead, the visuals are reconstructed on the fly from numerical position data.

A much more lightweight system overall.

Diagram of the graphics processing pipeline from camera module to hosted GUI
The Game at the final exhibition: Minigolf with the mini "Frictionless"

To make our product easier to understand at the final exhibition, I designed an interactive game that turned our technology into something visitors could experience firsthand.

The concept was simple: mini-golf played on a miniature version of our system. By putting the air-bearing puck in their own hands, visitors could physically experience what Frictionless movement feels like.

The game became an effective conversation starter. It drew people in, gave us a natural way to introduce the technology, and sparked questions about how the air bearing works, how we track motion, and what makes the system reliable.

Visitors playing the Frictionless minigolf game at the gala

Takeaways

In this project, defining the problem was part of the work itself. We spent a good two months going through meetings and discussions, gradually building a shared understanding of the problem before we could even began to think about how to implement the solution.

The ambiguity is challenging, but it also made the project really interesting to me. As I had no perior experience in this extremely complex field, I had to become comfortable with not having the answers upfront. I learned that before I could formulate the right solution, I first need to learn enough about the domain to ask the right questions and uncover the real problem. That is an approach I can carry into future projects.