What I actually did — co-founding, chief design, and everything in between

​

Saying “I co-founded and was chief designer” is the short version. The long version is a sequence of messy, fun problems that had to be solved. Below I lay out how my role unfolded from day zero to the final match.

​

1. Building the team & the vision

​

Co-founding started with people — getting the right group together. I reached out to classmates, friends from other schools, and a couple of university mentors I’d met at workshops. We had a mix of coders, fabricators, mechanics, and one person who had a knack for finding weird parts online.

We wrote a simple team mission on the first weekend: “Design robots that solve clearly defined tasks reliably, and teach every member to understand not only ‘what’ we build but ‘why’ we built it that way.” That mission shaped the decisions that followed: we wanted documentation, repeatable builds, and design reviews.

​

2. The core vision & system architecture

​

As chief designer, my first job was to pick the system architecture. That meant choosing drivetrain layout, actuator types, control electronics, sensor suites, and mechanical modularity. For a contest like Beijing, you need to balance speed, torque, precision, and reliability.

We prioritized modularity. I pushed for a chassis that could accept different tool-heads (e.g., a gripper, a disc handler, or a lift) because mid-season rule tweaks and match strategies at these big contests often require quick reconfiguration. That decision paid off during testing: swapping heads without de-soldering saved hours.

On the electronics front we standardized on a main controller with redundant motor drivers (so a single motor driver failure wouldn’t stop the whole robot), hot-swapable batteries, and a simple sensor bus using easy-to-replace connectors. Simple choices like standardized connectors made our pit repairs much faster under pressure.

​

3. Design-to-competition workflow (my baby)

​

I established a repeatable workflow so our builds wouldn’t be one-off miracles but reproducible outcomes:

• Concept stage: sketch multiple small ideas and pick the simplest with the highest chance of working.

• Prototype stage: build a basic proof-of-concept in one weekend (3–4 hours/day).

• Test & iterate: run at least five targeted tests for each module (drive, manipulator, sensor), note failures, fix small items, then repeat.

• Integration: combine modules and run end-to-end tests on a scaled field.

• Stress testing: simulate messy conditions — uneven floors, low light, noise — and run endurance cycles (20–30 minutes) to find heat or battery issues.

• Documentation: every change goes into a team notebook (who changed what, why) so we could revert or replicate.

• ​

This workflow made repairs and improvements much faster. If something failed during inspection, we could look at the log, see who last changed that part, and roll back or patch.

​

4. Prototyping & fabrication

​

I co-led the fabrication sessions. We used CNC-cut aluminum for the chassis, 3D-printed fixtures for custom fittings, and high-torque motors for the drivetrain. I taught teammates how to use CAD for fast part revisions and set up basic machining safety rules.

We learned several painful but useful lessons: don’t trust a 3D-printed part for high-stress joints unless it’s reinforced; belt drives can slip under heat; and wire routing matters — rat’s nest wiring kills a good robot more than any design flaw.

 

5. Software & control

​

I wasn’t the lead programmer, but as chief designer I defined control interfaces and basic PID loops for steering and manipulation. We implemented simple vision routines (color/shape detection) for autonomous sequences and used sensor fusion to stabilize motion in the noisy arena environment.

Observing the codebase integrity was important. I insisted on branch workflows (so testing code never wrecked the main release), and required nightly basic integration tests before we packed the robot for travel.

​

6. Pit strategy & on-site management

​

At big events like Beijing, pit work is crucial. I ran the pit station during matches: quick repairs, battery swaps, and last-minute calibration. I set up a “hot swap” table with spare controllers, a soldering kit, and documented quick-fix procedures laminated on the table.

We practiced pit drills: if a wheel motor died, who pulls it? If a sensor fails, do we replace or bypass? Practice made these responses second nature and reduced panicked tinkering.

​

7. Leading by doing (and failing publicly)

​

We had a few embarrassing failures — a connector unscrewed and we lost a match, a gear stripped mid-play, a vision routine misdetected under bright lights. Each time, my role was to be in the pit, pick tools, and coordinate the fix. I also coached members on how to present failure honestly during debriefs so the team learned faster.

​

8. The showcase & finals

​

By the time finals rolled around, we had a robot that was refined, repaired, and resilient. The team presented its design, answered judges’ questions, and demonstrated robustness in multiple rounds. Our final placement wasn’t the only thing that mattered — the experience of iterating under pressure, repairing quickly, and conducting coherent post-match analysis was the real win.