A Day in the Life of a Mechanical Engineering Researcher

Credit: Jeremy Gasowski
This summer, I got to do something super exciting: build a flying spacecraft simulator.
My project, Reaction Wheel Actuated UAV Platform for Spacecraft Attitude Control Testing, combines elements of aerospace engineering, robotics, and experimental design. The goal was to take a quadcopter and turn it into a testbed that mimics how real satellites adjust their orientation in space, using momentum wheels to control roll, pitch, and yaw (orientation). It’s a scaled-down version of how real spacecraft change orientation but tested here on Earth, in the lab, and at a fraction of the cost. The motivation behind this project was to create an affordable and flexible platform for testing attitude control algorithms before committing to the extremely expensive and irreversible process of launching an actual spacecraft. With funding from a Summer Undergraduate Research Fellowship (SURF), over the course of the last ten weeks I managed to build a prototype, prove the concept, and demonstrate the feasibility of this alternative approach to spacecraft attitude control testing.
To give a better idea of what that process looked like, here’s what a typical day of research looked like for me:
6:45 a.m. – I wake up early and start the day the same way I always do: coffee first. Always.
7:00 a.m. – After getting ready, I take my dog for a long walk around the neighborhood. It is my favorite part of the morning. She always brings so much positive energy and joy, setting the tone for a motivated and focused day ahead.
8:00 a.m. – I arrive at lab S215 in Kingsbury Hall and go through my notes from the previous day. Sometimes I pick up where I left off on a tricky issue; other times I start working on a new part of the platform.
8:30 a.m. – I resume writing code for testing the XBee wireless communication modules. XBee lets me send data between the testbed and my laptop. It is a crucial part for feedback control and monitoring.
For this SURF project, I spend about 60% of my time coding, and the rest building and testing the system itself. Over the course of the summer, I built the entire platform from scratch—designing and 3D printing the base, machining custom aluminum momentum wheels, soldering the electronics, and assembling the full control circuit.
9:30 a.m. – Once the communication is working, I turn to calibrating the IMU (Inertial Measurement Unit). It is sometimes a tricky process, but vital for reading orientation data that drive the controller logic for the motors.
10:45 a.m. – I meet with my advisor, Professor May-Win Thein. We go over the progress I made, the problems I ran into, and brainstorm ways to improve control stability and wiring reliability. Prof. Thein always provides me with useful insights and helps guide the direction of my work.
12:00 p.m. – Time for a quick lunch. I FaceTime my family back home in Czechia—it is nice to catch up and get a mental reset before diving back in.

Credit: Jeremy Gasowski
1:00 p.m. – After some frustration with loose pins and inconsistent signals, I decide to rewire and resolder part of my circuit. It isn’t the most glamorous part of the job, but solid hardware connections are just as critical as clean, elegant code.
Fortunately, I am not always working alone—I have support from Shahab Shokouhi, a brilliant PhD student, and Aidan Boucher, a very talented Computer Science major. Our conversations often spark new ideas, lead to unexpected solutions, or help me see problems from a different angle.
3:00 p.m. – Back at the laptop for more debugging. The reaction wheel logic depends on precise timing and smooth motor control, so getting the PID tuning just right is a real challenge. The math behind momentum-based control is nonlinear and gets messy fast. Writing stable code for an inherently unstable system was an ongoing challenge during my summer research. Every time I solved one issue, another emerged—whether it was electrical noise, a poor connection, or a weird data spike. But those ups and downs were also what made it so exciting. There is a particular kind of joy in solving a problem that has been bothering me for days.
4:00 p.m. – With the new wiring and fresh code in place, I run a series of tests on yaw control. Watching the platform respond to my commands and getting closer to my goal feels incredibly rewarding. It is a small win that makes the last few hours of troubleshooting worth it.
5:30 p.m. – I wrap up for the day and clean my workspace. Time to head home.
6:00 p.m. – I spend the rest of the day unwinding in nature with my dog and my boyfriend. We go to the lake for a swim, which is the perfect way to end a hot summer Monday.
This SURF experience has been a turning point for me. I learned how to solder under pressure, write modular C++ code, debug complex communication protocols, and even fly a quadcopter. I also earned my drone license last month. But more than any technical skill, I learned how to adapt, iterate, and stay patient through the inevitable chaos of building something new. This project didn’t just teach me how to build a prototype, it helped me build confidence in my abilities and sparked genuine excitement for pursuing grad school.