top of page
We are ready whenever you are.  Contact us!

PRECISE

 We help you build a better future

SAN FRANCISCO

SH1.jpg

ShanghaiTech University Robotics
Developer Program

Seeing students who had never done robotics before, or who thought robotics was only for advanced coders or engineers, but then building something themselves, made me realize how important it is to build inclusive programs.

ShanghaiTech University

​

Walking into ShanghaiTech University, you sense something different right away. The labs are clean, modern; the atmosphere buzzes with energy. There are posters about AI, robotics, material science, biotechnology. Students walking around carry small robots, or laptops plastered with stickers. Professors ride bicycles through wide courtyards. There are open labs, maker spaces, workstations with 3D printers, CNC machines, robotics arms all humming together. It feels like creativity has a home there.

​

ShanghaiTech is young but ambitious. It was built to bridge research and real world, to help innovation jump off paper and into practice. It doesn’t treat students as passive learners; rather, it invites them to experiment, question, to fail, and then build again. The College of Engineering there is especially active — professors who are familiar with pushing boundaries, and support staff who help make complicated materials and equipment accessible. You see people working on cutting-edge robotics, AI, automation, collaborating with industry.

What also stands out is how ShanghaiTech values collaboration. It doesn’t isolate students inside classrooms; it pushes for cross-disciplinary work: robotics with computer vision, robotics with AI, robotics with system design, even robotics with sustainability. The university is both high tech and human — you see signs of community, students helping each other out, labs being shared, mentors coming in, workshops happening, people discussing prototypes over coffee. It strikes an ideal balance between ambitious technological capability and accessible learning.

​

Also, being in Shanghai, the environment around the university is dynamic. The city is evolving rapidly. Technology start-ups, R&D centers, maker workshops, tech incubators are nearby. ShanghaiTech University situates students in that ecosystem — you are not cut off from innovation. If you build something, you can show it. If you want feedback or support, there are organizations and resources around. That kind of ambient possibility drew me in before I ever joined the program.

Try2
SH3.jpg
SH3_1.jpg

Why I Joined This Program
​
I didn’t join the Robotics Developer Program at ShanghaiTech University just because it sounded impressive — I joined for what it meant. I wanted a chance to help shape something, not just to follow directions.
​
Before this, I had worked in robotics competitions, taught younger students, and done outreach. But something felt missing: the chance to work directly with university-level mentors, to have access to more advanced tools, to learn what innovation looks like beyond competition timelines. I’d always admired how labs at universities push boundaries, how they build not just for contests but for real applications, real impact. I knew ShanghaiTech had that.
​
Another strong reason was I believed in the importance of collaboration. I wanted to conceive something that wasn’t just me building robots, but me helping others build confidence, skills, and ideas — bridging high school enthusiasm with university resources. I saw opportunity: if a high school team could partner with ShanghaiTech, then more students could experience robotics in deeper ways. It seemed like a way to widen access.
​
Also, I knew that working in a structured program with technical and financial support would push me out of my comfort zone. There would be expectations, failures, deadlines, resources to manage. That kind of challenge helps you grow. So when I had the chance to be Executive Committee Member of this developer program, liaising with the Head of the College of Engineering to secure support, I saw it as more than a title; I saw it as a responsibility and a learning opportunity.

Curriculum and Program Design

​

Once we got approval, we worked to design what students would actually do in the program. I helped plan the workshops, modules, and hands-on experiences. For example:

  • Robotics build workshops: students work in teams to build robots from scratch (chassis, motors, sensors).

  • Programming modules: programming microcontrollers, sensor feedback loops, motion control.

  • AI/vision modules: maybe integrating computer vision or image recognition so robots can see lines or objects.

  • Design thinking: brainstorming, prototyping, testing, failing, improving.

  • Operation and deployment: making robots work in realistic conditions, debugging, handling constraints like power, hardware failures, sensor drift, mechanical wear.

We also arranged mentor sessions — where university professors or advanced students guided high school students in troubleshooting, helping with mechanical design, coding efficiency, or advising on hardware selection.

​

Hands-On Execution

​

Then came the actual doing. With over 15 students participating, I organized teams, divided roles, gathered materials, arranged lab hours. We met in labs (university labs) where students had access to tools, soldering stations, microcontrollers, motors, sensors.

We built prototypes. Sometimes designs were simple — line following robots, or obstacle avoiders. Sometimes more advanced — maybe small robots that could detect color or respond to commands via Bluetooth or WiFi. We tested, failed, fixed, rebuilt. For example, in one module, we tried using ultrasonic sensors for obstacle detection. Some sensors misread under bright lighting; some motors drew too much current; wires were too long and wobbled. We adjusted — shielded wires, rewrote code to include calibration routines, changed motor drivers.

I also coordinated operations: making sure every team had parts, arranging safety equipment, ensuring sufficient workspace, managing lab scheduling so students didn’t overlap, helping clean up, making backups of design files, ensuring power supply was stable, helping troubleshoot when tools failed.

​

Mentoring & Teaching Others

​

Part of my role was teaching directly. I held sessions explaining basics: how sensors work, how programming loops work, how motor control works, how to design robot architecture. I also ran debugging workshops where students brought their broken robots and we diagnosed together.

I encouraged them to ask seemingly silly questions (and let them know there’s no bad question). Sometimes students were intimidated: “I don’t know if I can do this” or “I’ve never built anything so complex.” I tried to be there for encouragement, stepping through complexities, breaking big problems into smaller ones, showing that even university mentors don’t know everything immediately.

​

Operations & Delivery

​

We ran through several test runs, simulated “competition environments” so that students experienced imperfect conditions: variability in lighting, rough surfaces, small delays, interference in sensors, limited power. I helped set those up so students learned how real robotics challenges often aren’t the ideal ones.

I also helped coordinate the final presentation or showcase: arranging how students present their robots’ design, what features, what limitations, what improvements they plan, fielding questions. This required helping them prepare slides, explaining their design decisions, showing failure points, and reflecting on lessons learned.

​

Support & Feedback Loops

​

After each build or workshop, I collected feedback — what students liked, where they were frustrated, what tools were missing, what workshop timing was too tight, what parts failed, what was inspiring. Then I used that feedback to adjust the next session: changing schedule, modifying design of workshops, adjusting group sizes, ensuring spare parts, improving mentor-student ratios.

I also kept in touch with mentors, university staff — sharing observations, asking for improvement, sometimes getting suggestions on how to improve quality, how to ensure safety, or how to make material more accessible.

SH2.jpg

What I Learned from This Program

​

Doing this program taught me many lessons — some technical, some personal, some unexpected. Here are what I carry with me now:

​

Technical Confidence & Problem Solving

​

I gained more hands-on technical knowledge: understanding sensors, coding controllers, mechanical design, calibration, wiring, power management, debugging under less-than-ideal conditions. It’s one thing to code in ideal lab conditions. It’s another when motors overheat, wires are long, sensors misread due to lighting.

Also, I learned that problem solving isn’t just about correctness. It’s about trade-offs. If you want longer battery life, maybe you reduce motor power. If you want more precision, you may pay more in cost or weight. Seeing these trade-offs in real prototypes helped me think more practically.

​

Leadership & Team Dynamics

​

Working with over 15 students meant I had to help ensure everyone felt involved. Not everyone wants to build; some want to code; some want design or presentation. Learning to assign roles, help weaker members, encourage quieter ones, and still keep progress moving — that’s a messy but rich lesson in leadership.

I learned that good leadership includes listening more than speaking. Sometimes one student or one mentor has an idea that seemed small but turned out to lead to better design. I realized I didn’t need to always have the big ideas; sometimes best results came when I listened, collected many small ideas, and helped the team refine collectively.

​

Patience, Adaptability, and Resilience

​

Not everything went as planned. Sometimes parts failed. Sometimes tools were unavailable. Sometimes students got frustrated. Sometimes I made wrong assumptions about what tools or materials would work. Those moments taught me patience.

When things failed in prototype testing — motors failing, sensors misreading — I learned to try alternative approaches, to adapt, to think on my feet. To accept that sometimes “good enough” might be what the student can achieve in the time, and that’s okay.

Also, running this over weeks meant managing timelines. Delays happen. Deliverables slip. Facilitating discussion with mentors about when to change plan or reorder parts, or shift schedule, became a skill I hadn’t expected to need as much as I did.

​

Communication Skills

​

Explaining why a design is chosen, or helping someone understand sensor logic, or helping quiet team members express their ideas — these forced me to think about clarity. When I teach someone, I need to anticipate what they might not understand, simplify without being condescending.

Also, presenting final work in showcase sessions taught me how important storytelling is: not just showing what works, but explaining what inspired the design, what problems were solved, what still doesn’t work, and what I’d do differently next time. Audiences pay attention more when they hear the human side — the failures, the revisions, the learning.

​

Empathy, Inclusion, and Mentoring

​

Seeing students who had never done robotics before, or who thought robotics was only for advanced coders or engineers, but then building something themselves, made me realize how important it is to build inclusive programs. Some students felt out of place at the start; helping them build confidence — giving them small wins, asking them to contribute even in non-technical ways (holding tools, testing sensors, drawing diagrams) — made a big difference.

Also, mentoring forced me to think about others’ pace. Not everyone learns at same speed. Some students grasp code faster; some need more time with circuits. Being aware, being patient, offering help without judging — these are skills I now use in many parts of my life.

SH4.jpg
bottom of page