One Year Researching Microrobots

The Miskin lab was a big part of my first two semesters and my freshman year summer at Penn. The lab works on robots 1/2 of the width of a human hair, at a level where the physics governing larger robots break down.

Coming to Penn, I majored in Physics due to an interest in a strong theoretical and first-principles background. The lab had novel applications of weird phenomena not yet exploited in established engineering fields (Van der Waals forces, etc.).

I had a lot of incredible mentorship from my super cool PhD mentor, Lucas Hanson, and our PI, Professor Marc Miskin!

Working with Unknown Unknowns

The part of the research I learned the most about was understanding how to work with unknown unknowns. I can have a technical understanding of something (e.g., a robot can walk due to magnetic fields), but in reality, the application can be much more complex. In the Miskin lab, the mechanism that causes the robot to walk also causes it to grow aluminum on itself. Introducing two independent variables made the experiment more complex.

Over longer time horizons, the robots also emitted an unknown purple fluid, an additional variable that caused ripples that messed with the data. Smaller unknown unknowns seemed trivial to me at first, but quickly became more significant as I found that a single misaligned component on the microscope's axis could cause significant parts of the final image to be completely misaligned.

Solvency with Physics

A physics background was helpful to work with unknown unknowns. Each relationship required an understanding of the fundamental relationships between them. Here, I was grateful to be pursuing a physics undergraduate degree, as it’s common to note that two variables are related without going into the specifics of unrelated noise at very low or very high levels. For example, in physics labs, we have noticed that the luminosity of an LED scales linearly with current; some current is required while the LED is off, which is more about semiconductor physics, heat, and human perception than about light. With a physics background, it was much easier to navigate experiment design in the lab.

Solvency with Experience

A skill I realized was important in research was to have a good instinct for where something was likely to go. For example, in designing an experiment, if we felt a robot was likely to grow metal in one solution but not the other, we were more likely to choose the solution with no potential to grow metal. To make that decision many times within a single experiment, we had to have a very wide range of knowledge about variables and what was likely to happen.

It's much easier to identify subtle traits of the material like that over longer periods of focus in the lab, since I had more time between experiments to dwell, rewatch experiment recordings, and notice more granular events.

Scrappy Building

In the above image, you can see that the LED backlight is literally a simple semisphere-headed circuit board LED jammed into the middle of a component for something else, soldered with two copper wires that were alligator-clipped to an outlet, with a glass slide sat on top. This, again, required quite a bit of first principles understanding of backlit microscopes and optics, which I enjoyed.

We built some more complex things, too! The following is a 3D Helmholtz coil we fit around the LED setup, and a macro-level imaging setup using the same backlight concept as the microscope.

Prove the Mechanism Existence before Anything Else

One mental model I keep coming back to from my time in the Miskin Lab is that when working in a hazy system, the first step isn’t optimization, it’s existence. A lot of the uncertainty isn’t in the parameters, it’s in whether the mechanism even works at all. Instead of trying to fully understand or refine something upfront, I tried to collapse the unknown unknowns by forcing a simple proof: can this thing happen, even once, under controlled conditions?

In my lab work, this often looked like getting a single clean reaction or motion to occur, just enough to say this is real. Once that threshold is crossed, the best questions to ask shift to mapping behavior and failure modes, constraints, and so on. It’s a small sequencing decision, but it turns a vague space into something you can actually build on.

After getting proofs of concept, we used

The left plot moved our work from “does it move?” to “how does it move?” The roughly linear relationship between time and vertical displacement suggests that the robot’s motion can be approximated with a stable velocity through the fluid.

The right plot shows that the coil temperature asymptotically approaches a steady-state well below the temperature limits of the 3D-printed structure. Knowing that the system won’t fail under continuous actuation lets us treat temperature as a bounded variable rather than an unknown risk.

The problem becomes less about whether the system works and more about how far it can be pushed, how it breaks, and which parameters are high priority.

Slow Coding for Science Deployment

# Data
time_minutes = list(range(18))
temperature_c = [19.3, 20.7, 21.1, 21.8, 22.2, 22.6, 22.9, 23.0,
                 23.1, 23.3, 23.2, 23.3, 23.5, 23.4, 23.4, 23.2, 23.1, 23.1]

# Plot
plt.figure(figsize=(10, 6))
plt.plot(time_minutes, temperature_c, marker='o', linestyle='-', color='blue')

# Labels and Title
plt.xlabel("Time (Minutes)")
plt.ylabel("Temp (°C)")
plt.title("Z Axis Coils' Temperature with Cooling")
plt.grid(True)

# Show plot
plt.show()```

One thing I had to correct pretty quickly was the instinct to treat code as something to “get working” rather than something to understand. It was tempting to stitch together vibe-coded plotting functions, tweak parameters, and move on once an output looked reasonable. However, in science, the issue isn't functionality bugs in the usual sense—it was that I didn’t actually know what each part of the code was doing well enough to trust the result.

So I started holding myself to a stricter standard: every line needed to be understandable from first principles. I treated that as a gap rather than something to ignore. In practice, this meant keeping the code extremely simple by using explicit lists, direct plotting, and minimal abstraction, so that the mapping from raw data to output remained transparent. The goal wasn’t elegance or efficiency; it was to make the computation traceable.

This slowed things down and, at times, felt unnecessarily rigid, but it forced a tighter coupling between the code and the system it represented. Instead of producing outputs I hoped were correct, I could reason about where they came from and where they might fail. Keeping the code simple wasn’t a way to make sure I wasn’t hiding my own lack of understanding behind working syntax. Simple code wasn't the fastest way to get something running, but it reduces the risk of building on assumptions that were never verified.

This mindset was reiterated in our hardware: we used electromechanical relays (which use physical metal contacts to turn a current flow on and off as opposed to an Arduino, which is computer controlled) to control the on/off state of each axis in our Helmholz coil.

Learning to Live

A major improvement throughout my freshman academic year that affected my work was learning to live properly. That sounds basic, but it had real downstream effects on my work. I had to figure out how not to let food go bad, how to rest in a way that actually restores energy, how to navigate renting and logistics, and how to carry myself in the workplace. Those weren’t separate from the work—they were part of whether I could show up consistently and do it well.

Looking back on my living habits through this internship, I should have 1) been biased towards communication with mentors more, 2) lived closer to the lab, and 3) told myself that effort made into an experiment was also progress to produce a dopamine-reward cycle consistent with an ambiguous problem space, instead of that a failed experiment was wasted time and pavloving myself into working less and 4) closed open paperwork logistical loops that were requiring mental energy

After my time at Miskin Lab, treating those as things to actively pay attention to rather than background conditions has made the rest of my work more stable and consistent.

Thank you to Nevan Sujit and Amaris Chen for edits.