BOTIMUS: 72-Hour Engineering Sprint

Product Strategy: The "Constraint Innovation"

The Challenge: Build a combat-ready robot in 72 hours as a solo engineer, competing against 4-person teams with weeks of lead time.

The Strategy: Simulation-First, Parallel Execution. I couldn't afford the traditional "Design → Build → Test" waterfall. I implemented a Just-In-Time (JIT) workflow:

• Phase 1 (Simulation): used Python to derive torque requirements before opening CAD.
• Phase 2 (Parallel Fab): Designed the electronics housing while the chassis was printing.
• Phase 3 (Edge Logic): Wrote C++ kinematic mixing algorithms that ran locally on the ESP32 to eliminate Wi-Fi latency.

The Problem

I faced a "David vs. Goliath" scenario defined by three hard constraints:

1. The Resource Gap: I was a solo engineer competing against "Standard Competitor Units" (4 engineers).
2. The Physics Constraint: My chassis was PLA (Plastic). Competitors used metal saw blades. I had to design for agility over durability.
3. The Time Limit: A 72-hour hard stop. No extensions. No do-overs.

The Build

I treated this as a 43-hour active engineering sprint, assuming ownership of the full technical stack.

1. Python-Driven Kinematics (The "No-Guessing" Rule) Most students guessed their lever lengths. I calculated mine.

• I wrote a Python Jupyter Notebook to map the "Design Space" of the flipper mechanism.
• The Optimization: The simulation identified that a 4.5cm lever arm provided the local maximum for torque (1.33kg output), ensuring I could lift opponents without stalling the servo.
• Result: I skipped the "trial and error" phase entirely. The first prototype worked.

2. Top-Down CAD Architecture (PTC Creo) To support the JIT manufacturing, I used a "Master Model" methodology.

• I created a "Skeleton Model" defining the bounding box and COTS component locations.
• All structural parts referenced this skeleton. If I moved the battery in the master sketch, the chassis mounts updated automatically, preventing assembly conflicts during the rush.

3. IoT Edge Computing I didn't just remote-control the bot; I programmed it to drive itself.

• Architecture: Used an ESP32 as an intelligent edge node.
• Kinematic Mixing: The differential drive logic (Left = Y + X, Right = Y - X) ran on the chip, not the phone. This meant that even if the Wi-Fi stuttered, the motor control remained smooth.

The Outcome

The Victory: Despite the resource asymmetry, BOTIMUS won the Division Championship.

• Tactical Advantage: The "Combat Cockpit" UX allowed me to maneuver while firing the weapon blindly, a feature competitors lacked.
• Kinematic Superiority: The 4.5cm lever arm (derived from Python) successfully pinned two opponents, validating the math.

The Failure (And the Lesson): In the Grand Finals, reality caught up. A Kinetic Energy Weapon (Rotary Saw) sheared the left motor mount.

• Root Cause: My "Monocoque" printing strategy (Strong Skin / Weak Core) was optimized for blunt force, not shear force. The saw bypassed the skin and tore through the 10% infill.
• The Takeaway: Velocity gets you to the market, but material science keeps you there. I learned that System Threat Assessment is just as important as functional requirements.