Robosapien

This final post discusses testing outcomes, weight verification, and the servo lever torque calculation for the planned enhancement. With the chassis built, electronics wired, and firmware uploaded, the first full integrated test was the moment of truth. The robot connected to the phone over WiFi immediately — the web interface loaded, and the first tap of the forward button drove all four wheels in unison. That moment felt genuinely satisfying after weeks of work. All five movement commands were verified: forward, backward, left turn, right turn, and stop. The turning radius was tight enough for the 1.5-metre arena — the robot could pivot on the spot by driving the left and right wheel pairs in opposite directions. One issue appeared: after fitting the top chassis cover, the robot wouldn't move from standstill without a small initial push. Root cause: battery voltage had depleted slightly during development, and the added weight of the cover increased static friction. Charging the...

This post discusses WiFi vs Bluetooth decision, how the ESP32 web server works, GPIO logic table, and the GitHub link. Two connectivity options were evaluated for remote control: Bluetooth and WiFi. Both are supported natively by the ESP32, so the hardware decision didn't constrain the choice. This was purely a software and operational decision. Bluetooth: Simple pairing, no network infrastructure needed, slightly lower latency for short-range communication. But: can suffer interference in competition environments where multiple devices are broadcasting, and requires a dedicated app or BLE serial terminal on the controller device. WiFi (selected): The ESP32 creates its own WiFi access point — no router needed. The controller connects to this network and opens a browser to the robot's IP address. The web interface runs in the browser itself. No app installation required, works on any smartphone, and the connection is point-to-point (no other devices on the network). A browser-ba...

This post tells the story of the BTS7960 failure, root-cause diagnosis, and the cleaner L298N redesign. The first circuit design paired a BTS7960 43A H-Bridge motor driver with a separate step-down transformer to provide regulated 5V to the ESP32. But this didn't work as expected. The step-down transformer produced an unstable, fluctuating voltage output — sometimes exceeding the ESP32's safe operating voltage of 5V. Two ESP32 microcontrollers were destroyed by overvoltage before the cause was identified. Each failure set the project back by days. The symptoms were clear: the ESP32 would start up, sometimes partially function, then stop responding permanently. Initial suspicion was firmware — maybe a software crash loop. But the second ESP32 failed within minutes of first power-on with no code uploaded at all. That ruled out software and pointed directly at the power supply. Measuring the step-down transformer output under load revealed voltage spikes significantly above the ra...

This post discusses chassis material comparison, the welding decision, and the staged mechanical assembly with all six build stages. The chassis is the spine of a combat robot. Three materials were on the table: 3D-printed plastic, aluminium extrusion framing, and laser-cut metal sheet. The decision came down to three things — rigidity under impact, mass contribution, and cost of fabrication. Plastic: Cheap and customisable but cracks under sustained impact force. Also too light — in sumo, mass is a weapon. Aluminium extrusion: Lightweight and modular but more expensive and less rigid than a solid sheet. Laser-cut metal sheet: High rigidity, contributes meaningful mass, and custom geometry is achievable through laser cutting services. Metal won easily. A fabricator used laser cutting to produce both the base plate and the top cover from a single sheet design. The custom geometry included slots for cable routing, mounting hole patterns, and angled corners to reduce weight without sacrif...

This post talks about torque, friction, 4WD rationale, and the static vs kinetic friction lesson from testing.  We first needed to understand what physics actually governs combat robot performance. Two concepts dominate: torque and friction. Getting these right is the difference between a robot that wins and one that gets pushed around. Friction The maximum force your robot can exert on the ground before its wheels slip is given by the formula   f = μ × N = μ × mg Where μ is the coefficient of friction between tyre and floor, m is the robot's mass, and g is gravitational acceleration. This means there are exactly two ways to increase traction: add mass, or increase the friction coefficient of your tyres. We did both. The metal chassis adds mass naturally — steel is dense. And high-tread rubber tyres are useful specifically for their high coefficient of friction on arena floor surfaces. Robot mass - 2.35 kg Weight limit - 3.00 kg Drive wheels - 4 (4WD) Tyre type - High-tread ru...

Every engineering project begins with a problem. For us, it arrived as a competition brief of an inter-school design-and-technology robotics challenge. The brief was simple - build a robot that pushes the opposing robot out of a circular arena, 1 to 1.5 metres in diameter. Weight limit: 3 kg. That open-ended constraint is both exciting and terrifying. There are a hundred ways to build a combat robot. What we needed was a principled approach to making decisions — not just one that worked, but one that worked best within the constraints. Before touching any hardware, we spent time thinking about what "winning" actually requires. To push an opponent out of the arena, the robot must: Generate enough pushing force to overcome the opponent's resistance. Maintain enough traction to not spin its own wheels while doing so. Be controllable precisely enough to manoeuvre in a 1.5-metre ring. Survive mechanical impacts without falling apart. Do all of this within a 3 kg budget. Each o...

I, along with my teammates, Amartya Jha, Annem Saad, Krishna Mittal, and Siddhant Singh, participated in the AI Buildathon by the Masters Union.  The objective of the Buildathon was to create a real AI product solving a real-world problem. And in 2 days, we went from an idea to a working prototype called “Fraudly”, an AI-powered app designed to fight digital fraud among teenagers. Teenagers are among the most vulnerable to digital fraud — yet almost no engaging solutions exist for them. With UPI fraud rising sharply and millions of teens coming online every year, the gap was obvious. What if we could teach fraud awareness by letting users experience scams safely? Thus, “Fraudly” was born. The App simulates real-world scam scenarios (UPI, WhatsApp, SMS), lets users swipe to decide: scam or legit, uses AI to explain red flags instantly, and adapts difficulty based on user behavior. Using tools like Replit and Claude, creating a functional app was possible in no time. The Buildathon f...

Personal Takeaways My personal takeaways from the workshop “How to Build an Autonomous Robot” at IIT Delhi: 1. I Underestimated Myself I initially thought I wouldn’t fit into such a high-level environment. But engineering doesn’t care about labels—it rewards curiosity and effort. 2. Learning Happens Fastest When It’s Hands-On You can watch 10 tutorials on robotics. Or spend 2 days building one—and learn more. 3. Collaboration is Everything Working with experienced students accelerated my learning curve massively. 4. Engineering is Iteration Nothing worked perfectly the first time—and that’s the point. 5. Skills I gained Improved CAD modeling Stronger electronics fundamentals Practical understanding of robot architecture Exposure to ROS and automation systems Real-world problem-solving under constraints Final Thoughts This workshop was intense, messy, and incredibly exciting. It wasn’t about building a perfect robot—it was about understanding the process behind building any robot. And t...