Motor mounting height
The caster made the front sit too high, so the bot wanted to tip backward when it tried to climb the ramp.
ROBOTICS · EMBEDDED · FABRICATION
Autonomous Battlebot
Mechatronics project
This came out of the MEAM510 mechatronics course at Penn which I audited, where the final project was a battlebot competition on a game arena. The bot had to navigate autonomously and semi-autonomously, capture towers, score points, and survive against other teams’ robots.
- Electronics
- ESP32 · motor encoders · ToF sensors · whisker switch · Top Hat
- Role
- Software integration
- Fabrication
- 3D print · laser cut · wiring
ROBA Gameplay
The Robot Battle Arena game is inspired by Multiplayer Online Battle Arena games. The goal is to destroy the opposing team’s nexus while defending your own.
For the first 30 seconds, robots navigate autonomously using wall-following and localization through the HTC Vive Lighthouse system. After that, teams can send Wi-Fi packets to their bot, but every command costs robot health.
01 · V1
Starting with the simplest thing that could drive
The game mechanics and terrain constraints such as ramp, wall heights to work around, and home base size limit is what drove our design decisions. Our first pass was about making something that moved reliably withing these constraints before getting clever.
First test platform
We chose differential drive over skid steer because it was easier to implement quickly and matched what had worked in previous year's successful builds. We used a front caster for steering.
I programmed a basic ESP32 remote-control setup first. It let us confirm the motor drivers, wiring, and drive controls before added any sensors and autonomy.
At this stage we were using Adafruit TT gearbox motors with external TT encoders from the lab. I also started tuning a PID closed-loop for dead reckoning.
Caster behavior
Wheel caster was hard to maneuver and sometimes locked up at the wrong angle blocking the movement.
Wheel skids
The external encoders were inconsistent across surfaces. Wheel skidding made the PID loop much less useful than expected.
02 · V2
Follow the wall, avoid the obstacles
Wall following was one of the subtasks in the game, so we added a side-facing time-of-flight sensor for that, and tuned the PID loop to keep the bot moving straight.
Sensing
We added two VL53L1X ToF sensors: one side-facing for wall following, one forward-facing for obstacle avoidance. I wired both into the ESP32 over I2C.
Drive
The front caster became a ball caster, and we replaced motors with integrated encoders. The base was easier to turn and the feedback was cleaner.
What testing showed
A single side sensor was not enough for reliable wall following as the bot veered off course struggling to maintain straight-line motion. Dead reckoning with PID also drifted when the wheels slipped on the ramp - we tried adding rubber bands to the wheels to increase traction.
03 · V3
Final competition build
The final version moved from proving pieces in isolation to making the bot work inside the actual competition rules.
Final integration
- Used two side-facing ToF sensors to get accurate heading by measuring the difference in readings for more stable wall following, plus one front sensor for obstacle avoidance.
- Integrated the provided Top Hat circuit with the ESP32 so game commands, scoring, and bot health stayed in sync.
- Added the required whisker switch, which let other bots physically register hits and deplete our health during the match.
- We ended up leaving out the servo based attack mechanism becuase of time constraints.
Video
Final match
After all the iteration, our bot ended up winning the final competition against 11 other bots.