Reflections on My Robotics Journey

I came to India to spend my summer break. I was cleaning up my room when I came across some of my early electronics projects. That started a journey of self-reflection on my time in embedded systems and robotics over the years so I began journaling. I thought I’d publish those thoughts here. I used AI to help refine the language and make it more readable.

Sparks

The oldest memory I have is of my 7th grade science fair. I ended up building a runway light — basically soldering a bunch of LEDs in series, connected to a blinker circuit. I’m not sure where I found the blinker circuit; it was either one of my dad’s books or an EFY magazine. Either way, I didn’t understand how it worked. I got some help drawing the circuit diagram, put the components together, and soldered them. It worked, somehow. Felt like magic.

Apart from the exposure to electronics and the joy of seeing physical lights glow, soldering was the only real skill I picked up from that project. But something clicked. Every technical thing I tried after that would somehow end up back at electronics. I subscribed to a bunch of magazines in the mid-2000s and always found myself flipping straight to the electronics articles.

The College Detour

It wasn’t until much later, in my engineering days (late 2000s), that I got to put any of it to use. In the meantime, I got more interested in CS and took it as an elective in both high school and college. Looking back, the curriculum was pretty bad — the only real learning in the syllabus was typing code in Turbo C and Java. There were some logic skills in there, sure, but it was mostly just exposure. The real learning happened fooling around in class: accessing networked machines to find exam papers, remotely controlling another computer in the lab, changing the admin password so the next day’s exam got cancelled. I’m not sure how serious any of it actually was, but being able to do it gave me real confidence with computers. Still, I was done with it — it stopped attracting me. The logical puzzles and solving them with code were fun, but I craved something more hands-on, more low-level.

The Hacker Group

So I took up Electronics for my Bachelor’s. Alongside the formal education, I enrolled in a local hacker group — a place where people without formal education went to learn vocational skills. It was run by an old man teaching people to repair TVs and other household electronics (yes, back then things could still be fixed). It was hands-on study in fixing stuff. Since most of the people who attended weren’t well off, we built our own soldering stations, debugging tools, everything from scratch.

I learned more there in six months than in three years of college. We built our own signal tester — essentially an amplifier connected to a filter, so you could detect signal loss in an old radio or TV circuit. We looked at real TVs, radios, even car ECUs from the early 2000s.

Microcontrollers and AVR

The next thing to catch my attention was microcontrollers. We had it as a subject in second year, and that’s what sparked it. I went mad about AVR controllers. We didn’t have high-speed internet back then, so I slowly downloaded every datasheet I could find, along with material on the different controllers — I even ended up downloading the entire AVR library webpage. Flashing programs onto the AVR wasn’t easy, and a JTAG programmer was expensive, so I found the design for a programmer board and built one myself, just to flash programs.

Arduino and Open Hardware

This was around the time Arduino was introduced. I bought my first Uno, and it felt expensive — the ATmega8 cost about ₹90 (roughly $9 in today’s conversion), and the Uno was almost $100. Things were relatively expensive back then, and relying on my parents’ money felt hard, even though they’d already invested a fair amount in my experiments. Along with some friends, I started making our own boards at home — designing, printing, drilling, the full cycle. We perfected home fabrication with copper sulphate solution, iterating on PCB designs several times a day. The slowest part was always drilling the holes by hand.

This eventually led to my own custom Arduino designs. We teamed up with FSMK, a local grassroots organization promoting free software, and I helped start the Open Hardware chapter in Bangalore. We ran multiple workshops for students and faculty, teaching the basics of Arduino, OpenCV, and embedded hacking in general.

A Detour with ROS

ROS came out in 2007-08; I first tried it in 2011. It looked like a great piece of software for high-level tasks, but I didn’t really follow up on it for the next few years. At the time I didn’t see it having much impact on the kind of low-level robotics I cared about. I brushed it off, thinking it was too heavy to run alongside the electronics I was building. It wasn’t until much later, during my Masters, that I got into ROS properly — introducing it at the department and building my thesis around it, working on questions of distributed systems that borrowed a lot from how ROS handled things.

The Business That Wasn’t

By the end of my engineering days, I was designing PCBs for custom applications, while my friends sourced components and handled the programming. We had a decent little business — except we were terrible businessmen. We were so invested in the technology itself that we couldn’t sustain ourselves.

PEC was officially started in 2012. It was a decent business, but we were way ahead of our market, our timing was wrong, and our business skills were pathetic. I exited early, moving to Sweden in 2013, though I stayed on as an advisor and PCB designer from a distance. The business held on for about five years in total before we finally shut it down.

I took a job at NSN during the same time — pure software, and I hated it to the core. The hardware companies I was actually interested in weren’t offering me positions; there were very few hardware companies in Bangalore in the 2010s, and they rarely hired from my college. And when they did screen candidates, I usually failed the theoretical exams.

Sweden

I moved to Sweden on the first opportunity I got. The course was Systems Control and Mechatronics — a perfect combination, I thought. I was already into systems and mechatronics; controls was something new to explore. Once again, I didn’t enjoy the theoretical courses. I sought out the hands-on ones instead, choosing an experimental course over a theoretical one whenever I had the choice.

The first, CFS, is the one I’m still most proud of — building a race car. All the robotics projects up to that point had been small-scale, where the consequences of anything going wrong were limited. CFS was my first real exposure to interfacing with real-world systems. I designed and built the electronics subsystem for the car: a distributed system with fail-safes, built on the STM32. Architecture, PCB design, software, all of it. It was a 30hp course spread over a year, and we competed with the car at Silverstone and Hockenheim. I’m not much of an F1 fan nor a car enthusiast, but it was an incredible experience.

Next came Carolo-Cup. Less hardware here, more distributed systems — I collaborated with Christian Berger and contributed to OpenDaVinci. I learned a lot more about software, even though I’d never studied it formally; it was good practical exposure, and I found myself looking more at system design and hardware abstraction than at any one piece of code.

I hadn’t planned it, but both of these courses ended up feeding directly into my Master’s thesis.

I signed an NDA for that project, so I’ve never been able to talk about it in detail. Looking back, it’s the thing that changed the direction I took from there on. During the thesis we built a ROS-based orchestration system, using an algorithm from a fellow PhD student to make the orchestration provably correct: no safety spec could ever be broken. That idea fascinated me. I’d always treated backups and safety as an afterthought. This was a different way of designing entirely — safety built into the thing itself, not bolted on after.

None of it was new to the field, but it was new to me. I was lucky enough to get a PhD position continuing that work, and ended up pivoting from hardware to control — mathematical control.

Over the next five years, I worked on manufacturing systems, looking for ways to guarantee their correctness. A side effect was learning a lot more about programming — mainly functional programming in Scala. I contributed to SP first, then built my own tool, MIDES, which was really the output of those five years.

Wanting to stay in research, I took a position at RISE, working across a range of projects — hardware (drones, WayWiseR, small cars) and software testing and verification methods (Synergies).

Looking Back

I wrote this out to reflect on the changes I see across seasons — starting from my Bachelor’s, 2008 onwards, to now, 2026. Roughly eighteen years. Long enough for someone to mature, maybe.

• 08–13 was ground level: low-level PCB and embedded work.
• 13–16 was more system-level work and interfacing.
• 16–21 was high-level control for low-level devices.
• 21–26 has been a mix of things, mostly verification, and at times very abstract.

Mistakes

Some of my most useful learning came from mistakes.

One was about environment. You can test something for months in a closed room and it works every single time, and that means nothing once you take it outside. Took me years to actually get that. It really came together at a robotics fest at IIT Kanpur, a line-follower competition — robot was well built, everything handmade down to the PCB, worked in every condition we threw at it at home. At the venue, it just died. Turned out the stadium lights were sodium vapour lamps, and the heat and light was enough to throw off the IR sensors we were using.

The other lesson was about staying calm, and that one took longer. If something you’ve built and tested before suddenly stops working, it’s almost always something small that got overlooked, and you will not find it while you’re panicking. Two things taught me this. First was a workshop, 30-40 students, all paid up front, and I’d built the AVR programmer myself to keep the cost down — under a thousand rupees, maybe $100-150 today. On the day, my own programmer, the one that had worked every time before, just would not flash. Do we refund everyone? That’s what was going through my head for a couple of hours while we pulled the thing apart. Turned out to be one jumper that needed to be connected for that setup. We’d just missed it.

Second time was during my Masters, Carolo-Cup project. We were demoing a maneuver in front of the sponsors and the car just stopped, mid-demo. A few of my colleagues panicked, because each subsystem checked out fine on its own — so why was the whole thing dead? I was on infrastructure, so I looked closer and found too many phones in the room trying to connect to our cheap little lab router, killing the car’s connection. Locked it onto one channel it could talk to directly. Fixed it, for that day at least.

One thing I seem to have missed, or not carried forward, is that in India I was far more social. I call myself an introvert, but I had many more conversations and open collaborations back then — running two or three workshops a year in different locations, coordinating logistics and curriculum, teaching, finding new collaborators and interesting students in every cohort. That seems to have gone missing in my later years, and I don’t fully know why. Was it a new atmosphere in Sweden? Access to different people? Something shifting in me? I don’t know.

Sometimes, catching up with old friends and the conversation turns to work, it’s genuinely hard to pin down my niche. It happened once with a recruiter, too. I have my hands in different parts of the system, but I’m not really an expert in any one of them — and somehow, I enjoy all of them equally.