vs Professor Wasp
The drivetrain pulleys were not strong enough (they needed epoxy), and the weapon rods failed.
Shear Force
30lb Combat Robot
- Competed at Open Sauce 2026
- Current weight: 29 lb 14 oz
- Next competition: December 12, 2026 at SCAR HQ, Walnut, CA
Specifications
Weight class30 lbWeapon typeAngular drisk
Drive top speed predicted15.51 mphTime to 15 mph1.08 s
Weapon max tip speed predicted244.67 mphTime to 90 % of max (220.20 mph)2.56 s
Drive values are predicted from my drivetrain model below.
Objective & Role
What combat robotics is
Combat robotics (think BattleBots) puts two remote-controlled robots in an arena, and the goal is to destroy the other robot. Robots compete in weight classes: 1 lb, 3 lb, 12 lb, 30 lb, 250 lb and others. If both robots survive the match, judges decide it, usually on damage (3 points), aggression (2) and control (2). The exact points change between competitions, but that split is typical.
How Shear Force started
Shear Force is a 30 lb robot built by Anteater Combat Engineering (ACE) Robotics at UCI. We started at the beginning of the Winter 2026 quarter, on January 12, and aimed at SCAR's "Carnage at the Cube" on April 24 to 26, 2026: sixteen weeks for UCI's first 30 lb robot, with a new weapon design, an angular drisk.
An eight-person team got the robot to a competition-ready state, with a large share of the work from me. At 2 am on the day we were due to compete, during a final test, the weapon ESC caught fire, and we did not compete. The root cause analysis is further down.
For the summer the team shrank to three: Jake, Matthew and me. I took over most of the work, debugging, fixing and improving the robot so it could compete at Open Sauce 2026, while working a full-time internship.
My role
Shear Force was my first combat robot, and my role changed more than I expected: I went from chassis support to mechanical systems engineer to team lead. I designed chassis parts, wrote the drivetrain model, ran the weapon CFD and FEA, helped manufacture and test, built the telemetry app, took over electrical after the fire and ran the timeline and sourcing for Open Sauce. The steps are below.
How my role changed
Winter 2026
Chassis support
Designed the first fork design and parts of the armor and chassis, working with Jake.
Winter 2026
Drivetrain calcs & spec
Derived the 4WD model from first principles and built the simulator that set wheel sizes and pulley ratios.
Winter 2026
Weapon CFD & FEA
Ansys CFD to check the weapon could reach about 240 mph under the 250 mph limit; FEA to check it would stay retained axially.
Winter to Spring 2026
Sourcing, manufacturing, testing
Helped source parts, plasma-cut the titanium, assemble and test the robot.
Spring 2026
Telemetry developer
Streamed ESC telemetry over an ESP32 to check the drivetrain predictions.
April 2026
The fire
The weapon ESC caught fire on the day of SCAR. We did not compete.
Summer 2026
Electrical lead
Root cause analysis, wiring diagram, soldering and packaging; replaced the third-party telemetry program with SF_Telem.
Summer 2026 on
Team lead
Timeline and sourcing to get the robot to Open Sauce, and the fixes after it.
- All electrical
- Weight optimization
- Mechanical optimization & packaging
- Sourcing & timeline
Timeline
Kickoff
Start of the Winter quarter, eight-person team
- Jan to Apr 2026
3D-printed prototype
Fit, drive and inversion tests
- Jan to Apr 2026
Titanium plasma cutting
Side armor supports made in-house
- Jan to Apr 2026
Desert testing
First weapon ESC stops working, no fire
- Apr 2026, day of SCAR
ESC fire at 2 am
Did not compete at Carnage at the Cube
- May to Jul 2026
Summer rebuild
Team of three; new electronics
- Jun 28 and Jul 11, 2026
SF_Telem weapon tests
Third ESC fails in the second session
- Jul 17 to 19, 2026
Open Sauce 2026
San Francisco, two matches
- Aug to Sep 2026
Post-Open Sauce fixes
Rods, hubs, molds, red blades, weight check
Next competition
SCAR HQ, Walnut, California
Requirements
| Requirement | Target | Where it landed |
|---|---|---|
| Competition | ||
| Weight | ≤ 30 lb | The most important requirement. 29 lb 14 oz, under the 30 lb limit. |
| Weapon tip speed | < 250 mph | 244.67 mph predicted maximum |
| Safety inspection | Pass | Passed safety checks at Open Sauce 2026 (videos below) |
| Self-imposed | ||
| Drive top speed | 15+ mph | 15.51 mph predicted, 15 mph in 1.08 s |
| Torque curve | Reasonable | Traction-limited up to 9.65 mph on purpose, for pushing |
| Weapon tip speed | ~240 mph | 244.67 mph predicted |
Overview & Tradeoffs
A combat robot's drivetrain is a set of tradeoffs, and two of them shaped this one.
Torque vs. Top Speed: A higher pulley reduction gives more torque for pushing matches and a lower top speed. Less reduction gives a faster, more maneuverable robot that pushes with less force.
Wheel Size vs. Positioning: The weapon shifts the weight forward, and the front also has to leave room for the armor and forks, so wheel size and placement trade against each other. A smaller front wheel lets the front axle sit farther forward, which helps turning, but on its own it limits top speed. We used larger rear wheels so the robot is invertible and still drives when it is flipped.
We built a 4WD drivetrain whose front and rear pulley ratios keep the smaller front wheel and the larger rear wheel at the same surface speed. The robot gets the top speed of the larger rear wheels and keeps all four wheels driving, so the torque reaches the ground wherever the weight shifts.
Drivetrain System Prelim CADDrivetrain Derivations
Computational Modeling & Simulation
Because the front and rear wheels differ in size and pulley ratio, I derived this drivetrain's dynamics from first principles to check the motor curve against it. The full derivations are in the PDF, typeset from my handwritten notes (the handwritten original (PDF, opens in a new tab) is still available).
I turned these derivations into a standalone .exe tool. It reads its inputs from a .txt file, simulates the drivetrain and exports the results to a .csv file for Excel. It warns when the input ratios would give the front and rear wheels different speeds, which would make them slip.
Analysis and Results
I iterated with the tool, and we settled on a 2.5 in front wheel and a 3.5 in rear wheel. Both motor pulleys have 30 teeth to keep the parts simple; the front wheel pulley has 20 teeth and the rear 28, which puts both wheels at the same surface speed.
The model predicts a top speed of 15.51 mph, with 15 mph reached in 1.08 s. Up to 9.65 mph the wheels are traction-limited, on purpose, so the robot has its full pushing force at low speed. We also cap the ESC current so a full-throttle input does not spin the wheels.
Simulation V2, inside SF_Telem
V1 answers one question: which wheel sizes and pulley ratios give the front and rear wheels the same surface speed. V2 is updated logic I built into SF_Telem, my telemetry app on Cosmic (my AI-assisted engine), to answer a harder one.
I wanted to try other pulley ratios for more torque or more speed. The parts I have fix the axle heights, and I cannot mount the wheels differently on the chassis. So a new ratio also needs new wheel diameters that keep both wheels at the same tangential speed and lift the chassis the same distance off the ground. Only discrete combinations satisfy both, and they are rarely round numbers. V2 searches for them: a lift planner lists the whole-tooth pulley swaps that keep both wheels in sync for the same lift, next to a feasibility check and a wheel-diameter sweep.
I never built a V2 configuration, for cost reasons. The solutions exist, and I can use them if the drivetrain changes.
Takeaway With fixed axle heights, a gearing change is a constrained search over wheel diameters, not a single calculation.
Objective
Few combat robots use an angular drisk as their weapon. We set the weapon’s top tip speed at approximately 240 mph, under the 250 mph SCAR limit. A shape like this is hard to model at that speed, because of the vortices it sheds and the uncommon drisk shape.
I ran the CFD to find the parasitic aerodynamic torque on the weapon across a range of RPMs. With that torque, the pulley ratio and the motor curve, I could calculate the top tip speed the weapon actually reaches and the time to reach 90 % of max tip speed.
Weapon System Overview
Explanation of CFD Approach
I ran the CFD in Ansys Fluent with a Rotating Reference Frame (RRF). I used the SST k-omega turbulence model because it handles boundary-layer separation and the wake at high rotational speed. While the analysis ran, I monitored the residuals to make sure they stayed small, typically less than 10⁻³.
Simulating a range of RPMs gave me a drag torque vs. angular velocity curve. It is the aerodynamic "air braking" torque the motor has to overcome.
Results and Analysis
As with the drivetrain, I can analyze the weapon to find its RPM and tip speed. The difference is that for the weapon, the aerodynamic effects of rotation are significant.
A drivetrain reaches top speed near the motor's no-load speed. The weapon reaches top speed where the torque the motor produces equals the aerodynamic parasitic torque at that RPM.
I calculated the weapon axle’s τ-ω curve (the motor curve multiplied by the reduction and a loss factor). Subtracting the parasitic torque gives the net torque, and dividing that by the weapon's inertia gives its angular acceleration.
As expected, the angular velocity and tip speed behave like a first-order system:V(t) = C₁ (1 - e-C₂t)To check the simulation, I plotted torque against ω for the weapon system and for the absolute value of the parasitic torque; top speed is where the two curves cross. The model does not account for voltage sag or friction.
Manufacturing
3D-printed prototype
Before cutting metal we printed the whole robot. The prototype let us check that the CAD fit in real life, run early drive tests with telemetry, confirm the robot drives when inverted, and sanity-check the electronics and my drivetrain calculations.
Plasma cutting titanium
Outsourcing the titanium side armor supports was too expensive, so we made them ourselves: plasma-cut from Ti-6Al-4V plate, then ground to remove the embrittled edge the plasma cut leaves, because the parts had to be bent.
Machined and cut parts
The 7075-T6 aluminum parts were laser cut, and a vendor CNC-machined the weapon hubs.
What went wrong in the build
- Tapping titanium was harder than planned and forced a last-minute change of weapon screws.
- The weapon was unbalanced when first assembled; I balanced it by adjusting and re-tightening, by trial and error.
- The idler and tensioning pulleys melted.
Takeaway Making the titanium supports ourselves replaced a quote we could not afford, and printing the whole robot first let us test fit and driving before any metal was cut.
SF_Telem
Why I built it
I started SF_Telem to check my drivetrain calculations against real data. The ESCs run AM32 firmware and send a telemetry frame from a serial TX pin: voltage, current, eRPM and temperature. From eRPM I get motor rpm, and from the ratios and geometry, wheel speed and weapon tip speed.
My first setup streamed the ESP32 output to the Arduino serial monitor, where I copied numbers by hand. A third-party app (Serial Studio) was the next step, and it was buggy. So I wrote my own.
How it works
- ESC TX pin
- UART
- ESP32
- Bluetooth SPP
- PC COM port
- SF_Telem on Cosmic
The ESP32 reads each ESC's UART frames, checks their CRC, decodes the fields and sends them over Bluetooth as tagged text lines with a checksum. Pairing with it opens a COM port on my PC; SF_Telem reads the lines from that port, converts them to volts, amps, rpm and speed, and plots them with ImPlot, which I added to Cosmic for this telemetry work and have used for other Cosmic work since.
What it does
- Live, zoomable plots for the weapon and each drive side, so I can find a current spike and zoom into it.
- Recording and instant replay: each session saves to CSV and a binary file and can be replayed right away.
- Built-in ESP32 firmware: I set the pin in the app, it updates the Arduino code, and one button copies it. The ESP32 pin layout is shown next to it.
- UART re-alignment: the ESP32 firmware checks each 10-byte ESC frame's CRC. If the first frame arrives misaligned, or bytes are lost and frames shift, it steps through the stream one byte at a time until the CRC passes and frames line up again. On the PC, SF_Telem discards any line whose checksum fails.
Debugging suite
I can load scripts that make the ESP32 send dummy data, read the raw hex packets in a sniffer to see whether anything is arriving, and debug the weapon or the drive on its own.
What it enabled
The videos are no-load motor tests I ran before installing the motors, some on older versions of the app with fewer plots. The same app recorded the weapon ESC data that the root cause analysis below depends on.
Takeaway Owning the whole path, from ESP32 firmware to plots, turned an unreliable serial stream into data I could use to diagnose a failure.
ESC Root Cause Analysis
What prompted it
At 2 am on the day of SCAR, during a final test, the weapon ESC caught fire. Our first diagnosis: the weapon bearings had gone in without grease, flattened and marked the shaft. The weapon stalled, the motor kept demanding current, and the ESC had no protection fast enough to stop it. Problem solved, or so it looked.
Flattened, ungreased bearings, the marked shaft and the burnt ESC
It was not the whole story. In desert testing, earlier in the spring, the same model of ESC had stopped working after about five runs, with no fire and no stall. It still connected to the AM32 configurator but would not take new settings. We put it down to dust or a cold joint and had no time to look further.
In summer testing, with new electronics, new greased bearings and a weapon balanced on a jig, a third ESC failed the same way: no stall, no fire, it stopped and would not take settings. This time I had SF_Telem on the weapon ESC, so I ran a proper root cause analysis.
Three failures
| ESC | What happened | Settings | Data |
|---|---|---|---|
| Desert ESC | Desert testing, spring 2026. Stopped after about 5 runs; no fire. Connects to AM32 but cannot be flashed. | Stall protection off | No telemetry |
| Fire ESC | Final test, day of SCAR. Weapon stalled on flat bearings; fire. | Current limit 100 A; stall protection probably off | No telemetry |
| Jake ESC | Second SF_Telem session, July 2026. Failed without a stall; the 200 A fuse did not trip; its telemetry stopped mid spin-up. | Stall protection on; startup power 110 %; current limit 160 A; temp limit 120 °C | Last readings 52 to 57 °C, 59 A, voltage reading bogus |
Before the Jake ESC failed, SF_Telem logged: first session (June 28), 39.6 A peak, 21 to 39 °C; second session, first run, 131.6 A; a quick spin-up, 188.3 A, 30 to 42 °C. Tip speed in the plots is calculated from eRPM and the geometry; there is no sensor on the blade.
Second run (sudden stop, then quick spin-up) · weapon current
Peak 188.3 A at 48.5 s, log time 11.7 to 57.7 s. Use the arrow keys to read values.
Second run · tip speed (from eRPM)
Peak 182.7 mph at 46.8 s, log time 11.7 to 57.7 s. Use the arrow keys to read values.
Failure run · weapon current
Peak 142.1 A at 38.2 s, log time 11.7 to 78.0 s. Use the arrow keys to read values.
Failure run · ESC temperature
Peak 57 °C at 47.0 s, log time 11.7 to 78.0 s. Use the arrow keys to read values.
Failure run · voltage
Minimum 34.3 V at 37.7 s, log time 11.7 to 78.0 s. Use the arrow keys to read values.
SF_Telem CSV, 60 Hz, resampled to 10 Hz for the web, with corrupted packets (impossible voltage or rpm) and the ESC's start-up frames removed. Peak figures in the text are the largest recorded samples.
Why a stall destroys an ESC
I = (V − Eback) / R, and Eback is proportional to motor speed.
At a stall, ω = 0, so Eback = 0 and I = V / R = 50.4 V / 0.0049 Ω ≈ 10,286 A
At a stall, ω = 0, so Eback = 0 and I = V / R = 50.4 V / 0.0049 Ω ≈ 10,286 A
The numbers are for the weapon motor, a TP-5660 at 950 KV (212 A maximum, 0.0049 Ω winding resistance), on 12S (50.4 V fully charged). Nothing actually reaches 10 kA; the MOSFETs fail first. The number shows that in a stall the only thing limiting current is the motor's winding resistance.
Start-up has the same ω = 0 condition, but the ESC ramps the duty cycle (effective voltage = duty × 50.4 V, switched at about 48 kHz) so back-EMF builds before current runs away. Software current limiting measures current through shunt resistors, compares it with the limit and lowers the duty cycle, in a loop. Stall protection waits for a de-sync. Both respond in milliseconds; stall current rises in microseconds. A normal stop is safe because the throttle is already at 0 %.
Fixes I considered
- Avoid the stall: greased bearings and proper belt tensioning. Necessary, probably not sufficient.
- Decouple the motor from the weapon: a shear pin or slip clutch, so the motor can keep turning when the weapon stops. Conceptually the real fix; I have not worked out whether it is feasible here.
- Hardware over-current protection: a gate-driver cutoff acts in microseconds, the only electronics fast enough.
- Fuses: they will not stop a stall, but they can keep a failure from spreading to the batteries.
Teardown and decision
I opened all three ESCs. The two that stopped working are each missing a resistor, which may never have been fitted; I found no debris or other damage. My theory for those two is a temperature-related failure around 50 °C, which would be low for this ESC. Every failure came after several runs in a session, never on the first.
I stopped trying to explain the Sequre ESC (SQESC 12200, rated 200 A continuous and 250 A peak) and replaced it with a Hobbywing ESC. It weighs about 0.5 lb against about 0.2 lb, so I repackaged the electronics to fit it within weight. Its own telemetry read around 350 A on hits at Open Sauce, above the Sequre's peak rating. I have had no ESC failures since.
The data points to an ESC that is under-rated for this weapon's current spikes, at start-up and possibly under braking, but I cannot say exactly why two of them died without a stall, and that still bothers me.
Takeaway Firmware current limiting cannot protect against a stall; the protection has to be mechanical or in hardware, and logging the weapon ESC is what turned guesses into an analysis.
Taking over electrical
By this point I had taken over all of the robot's electrical work.
- Wiring diagram: the original electrical team never made one, so I did. It is generated from a Python script I wrote and covers the drive, the weapon and the ESP32 telemetry on one sheet.
- Soldering: I cleaned up and redid the soldering.
- Packaging: I repackaged the electronics, including fitting the larger Hobbywing ESC.
- Telemetry: I built SF_Telem's ESP32 link into the robot.
Takeaway Generating the diagram from code means it changes when the wiring does, and the next person can wire the robot without me.
Open Sauce 2026
July 17 to 19, San Francisco
Getting to Open Sauce took the whole summer: three of us rebuilt the electronics, replaced the weapon ESC and fixed what testing broke, and I did my part around a full-time internship.
Safety checks
vs Winning Ticket
LossShear Force lost; the battery was punctured.
Takeaway The replacement weapon ESC held through both matches; what failed this time was mechanical (weapon rods, drive pulleys) and a punctured battery.
Post-Open Sauce improvements
Weight and cleanup
- Titanium screws to save weight
- New electronics sourcing
- Angle grinding and polishing parts
- TPU buffers in the electronics packaging
- Debugged a switch that was failing silently
Drivetrain
- Epoxy in the drivetrain
- Wheel hubs redesigned for more tread
- VytaFlex wheel molds with a draft angle and a pour funnel
Weapon
- The weapon rods failed even though we did not expect them to
- Approach 1: threaded rods; the ones that failed had a grade issue
- Approach 2: custom titanium threaded rods
- New red blades
Takeaway Open Sauce showed where the robot breaks; this list is the response, and the September weigh-in is where it stands.
Status and next steps
- Next competition
- December 12, 2026 at SCAR HQ, Walnut, California. The plan is simple: compete.
- Current weight
- 29 lb 14 oz
Extras
Weapon FEA (axial retention)
I ran a static structural FEA in Ansys to check that the weapon would stay retained axially.