When I started my internship, my work looked very different from where it ended.
In the first few weeks, I focused on firmware automation, power supplies, and voltage regulator testing. I wrote scripts to remotely control lab power supplies, debug .NET automation issues, and worked through a long list of small but critical setup problems: driver mismatches, framework versions, incorrect solution files, and hardware quirks. On the hardware side, I tested and depanelized PCBs, learned surface-mount soldering, and became more comfortable working with schematics and lab equipment.
At that stage, the hardest part was not the technical content. It was communication.
When something broke, my instinct was to struggle quietly and try to brute-force my way through it. I was hesitant to ask questions, worried they might be obvious or poorly formed. In practice, that hesitation cost time. I would lose hours debugging issues that could have been resolved in minutes by asking the right person the right question.
That changed as the internship progressed.
As I became more comfortable, I started looking for higher-impact problems to work on. One system stood out: a robotic motor handling and identification pipeline built around a Dobot arm and a proprietary vision system. It worked, but it was expensive, rigid, and difficult to extend.
I asked to get involved.
This marked a turning point. Instead of waiting for tasks, I took ownership of a full automation problem: how to build a low-cost, accurate, and extensible robotic vision system that could train itself.
This project required much more than coding.
On the mechanical side, I designed and 3D printed a custom rotation slide that would rotate motors by exactly 90 degrees after each pickup. This ensured consistent orientation for reading printed IDs and collecting training data. Designing it efficiently required iteration in CAD, tuning tolerances, reducing filament use, and balancing rigidity with print time.
This experience reinforced that effective automation systems are rarely purely software problems. Mechanical design decisions directly shaped data quality and system reliability.