My Roadmap part 4

Electronics... Yikes!

I told you previously that I have enough curiosity to dive into anything related to programming—guess what, electronics and the world of embedded systems are now among them!

It all started with participating in robotics competitions. The organizers told us that, to make a robot, you need to combine mechanical design with control design, and they gave us sessions on both. I barely cared for those sessions—as you know, I’m driven by a self-learning mindset (“I gotta do it my way!”). My first event was the Under-Construction competition organized by the IEEE Helwan Student Branch. I only had experience in programming and making games, and I was tutoring game-development sessions at the same time. I treated hardware the way I treat software: a try-and-error strategy. Unfortunately, I realized the drawbacks a bit late—after burning countless components and, basically, burning money like crazy. “Let’s hit run and see.” Even when wiring: “Let’s wire and see.” I was hooked.

Anyway, I eventually figured out the right combinations. I discovered that the relays used to control the motors burned out because of the current drawn by the motor. To prevent that, we had to separate the motor’s power source from the power that switches the relay. In the default setup, those power sources are tied together, which sometimes causes the relay to burn. So we fixed it. I built the “perfect” formula: motors controlled by relays, all driven by an Arduino. The Arduino connected to a Bluetooth module, and I paired it with my phone. I even built a custom mobile app—secretly using a drag-and-drop app designer—and it worked like a charm. The Arduino ran off a power bank, so the whole thing was a small, wireless control-unit box. Back in 2015, that was a real wow factor. I didn’t care much for the mechanical part, but my teammates handled it themselves—though, in hindsight, we over-engineered everything.

The day before the competition, after we had wired everything, I had to give a game-development session and couldn’t attend the rehearsals. My teammates couldn’t wait for me to finish; they tried to power the robot themselves, burned some circuits, and by the time I arrived we had no spare parts. We couldn’t test before the actual competition, which led to a horrible performance. I think we finished second-to-last—only beating the team whose robot never started. Our robot could move all the blocks at once (that year’s task) and place them elsewhere, yet we failed because we hadn’t practiced. My teammate tried once but wasn’t used to the phone controls, then I tried—in vain. Amusingly, the team that won had the simplest, most effective design: one block at a time, an easy wired controller, fast and accurate. The biggest takeaway: I learned how to build the whole system from start to finish and what I actually needed.

My second attempt at robotics came about two years later. The task was to follow a track while balancing a ball on a metal plate and staying on a black line automatically. I waited for the mechanical part to finish, and I partnered with someone, but we couldn’t communicate well. She was stubbornly determined to learn on her own, showing the “I can do it myself” attitude. In the end we split tasks: I handled line-tracking and control; she coded the ball-balancing algorithm. The night before the competition we wired everything together, but the balancing code still wasn’t ready. We pulled an all-nighter and got something working—barely.

On competition day, we ended up using manual controls instead of automatic line-tracking, and our attempt to balance the ball without a proper algorithm failed. We did get a chance, near the end, to fire a ball into a box for extra points—but we missed. Still, it was a good experience. After that event, 

I lost interest in robotics competitions: it felt like I wasn’t learning anything new, just repeating what I’d already done. So I decided to move on and try something different, which is going to be building software professionally.