ATLAS, a Robot for Sumo Competitions

Atlas is an autonomous sumo robot built for the VI Venezuelan National Robotics Competition (USB BOTS 2016), where it took 2nd place in the Sumo category. It was developed by the FutBot – Future Robotics team at the Universidad Simón Bolívar (USB).

Step 1Define

Atlas is a two‑wheeled, differential‑drive robot. Its job is to find the opposing robot inside the ring, drive into it and push it out — without driving itself out in the process. It runs on an Arduino Nano, with a closed‑loop speed controller on each wheel and a sensor‑driven state machine that decides how to move.

The Arena

A sumo match is fought inside a circular ring (the dohyō): 150 cm in diameter, with a 5 cm border marking the edge and two short starting lines at the centre. The two robots start back‑to‑back and, after a mandatory delay following the start signal, must push the opponent out of the ring or immobilise it. Leaving the ring on your own means losing the round, so edge awareness matters as much as attacking.

Competition arena — 150 cm ring, 5 cm edge border, central start lines.

What It Had to Do

Within the ring rules above, Atlas had to:

• FindLocate the opponent anywhere around the robot: front, sides and rear
• PushGet under the opponent, lift its wheels and drive it out of the ring
• EdgeNever leave the ring on its own
• StartHold still for the mandatory delay after the start signal
• ProtectSurvive a stalled push without burning out the salvaged motor drivers
• AutonomyNo operator input once the match has started

Step 2Simulate

Kinematics Model

Atlas is commanded like a unicycle — a forward speed V and a turn rate ω — and each command has to become a target speed for each of its two wheels (the full chain is under Control System).

Before writing the Arduino code, the kinematics were modelled and plotted in MATLAB (matlab/Sumo Atlas/) — sweeping V and ω to check the resulting wheel velocities and RPM — and then ported to C.

The script main.m uses Atlas's own dimensions (0.25 m track, 0.08 m wheel radius) and runs two sweeps: ω from 0 to 10 rad/s with V = 0 (spinning in place), then V from 0 to 10 m/s with ω = 0 (driving straight), plotting the target RPM and the speed of each wheel for both.

Step 3Build

System Overview

Mechanical Design

The chassis is 3D‑printed and was designed in SolidWorks; it went through three iterations before the competition version. A curved aluminium scoop blade across the front is the offensive tool — angled to slip under the opposing robot and lift its wheels off the ground so it loses traction. A roller‑ball caster at the rear keeps the robot level while the two driven wheels do the work, each turned through a small gear train from its motor.

CAD model of Atlas, showing the drive wheels and the front scoop blade.

The full part files and 2D manufacturing drawings for every version are in the repository.

Drivetrain & Motors

Atlas is driven by two brushless DC motors salvaged from office equipment. There was no datasheet or wiring diagram for them, so we reverse‑engineered the driver board to work out how to command it from the Arduino. The board is built around two ICs:

• SLA6023 — 3‑phase brushless motor driver (60 V, 6 A, 25 W).
• LB1823 — 3‑phase brushless pre‑driver, originally made for office‑automation motors.

Once mapped out, the board takes a simple logic interface from the Nano — a PWM speed input, a direction bit, a brake line and an enable line — and returns a single‑channel tachometer pulse that the firmware counts to measure wheel speed.

Sensing

Atlas locates its opponent with distance sensors covering the front, sides and rear of the chassis:

• Infrared — a Sharp GP2Y0A21YK analog IR distance sensor.
• Ultrasonic — an HC‑SR04 ultrasonic ranging module.

The firmware turns each into a distance reading and the strategy code compares it against a per‑sensor threshold, backed by measured ADC‑vs‑distance calibration tables (see Sensor Calibration). A TLC2543 — an 11‑channel, 12‑bit SPI ADC — adds the extra analog inputs the Nano runs out of: two forward‑facing proximity sensors, four downward reflectance sensors for the ring edge, and a 3‑axis accelerometer. The competition firmware acts on the proximity channels; the edge and accelerometer channels are read but were not yet wired into the behaviour.

The KiCad electronics design in the repository documents a fuller sensor ring — four Sharp analog IR sensors, one per side — from a later revision of the same layout.

Control System

Motion commands are given in unicycle form — a forward speed V and a turn rate ω. A differential‑drive kinematics step converts (V, ω) into a target speed for each wheel, which becomes a target RPM. Two independent PID loops then track those targets: each loop compares the commanded RPM against the RPM measured from the tacho pulses (counted over 100 ms windows) and adjusts the motor PWM.

Each motor also has an ACS711 current sensor. If a motor draws more than its current limit — typically during a sustained push against the opponent — a fold‑back limiter lowers that wheel's PID output ceiling until the current comes back down, protecting the driver board from a stalled push.

The hand‑wired control board: Arduino Nano, sensor conditioning and the connectors to the motor drivers.

Match Strategy

Tactics are a small state machine. Every loop, estrategia() looks at the sensors and picks a target state; a dispatcher then runs the matching behaviour:

• Start delay — hold still for the mandatory count after the start signal.
• Opening move — one open‑loop ~90° turn to get off the start line.
• Search — spin in place, sweeping the Sharp sensors across the ring.
• Attack — when a sensor sees the opponent, drive at it: straight ahead if it is dead centre, or on a curve if it is off to one side.
• Re‑acquire — if the target is lost, drop back to Search.

The sensors are checked in priority order — front‑centre first, then the front‑left and front‑right proximity channels, then the side Sharps — so the robot always commits to the most head‑on contact available. For example, a front‑centre reading past its ~80 cm threshold triggers a straight charge at full commanded speed.

Step 4Test

Sensor Calibration

Each Sharp sensor was calibrated on its own. The tables kept at the top of Sharps.ino give the raw ADC reading every 10 cm from 10 to 150 cm for the front, right and left sensors, plus two points (40 and 80 cm) for each front proximity channel, in volts. A selection:

The three sensors don't read alike — at 80 cm the right one gives 184 counts and the left one 165 — so each gets its own threshold, and every threshold the strategy acts on is that sensor's own 80 cm reading: 173 front, 184 right, 165 left, and 0.78 V and 0.30 V on the front‑right and front‑left proximity channels.

Competition Result

2nd place, Sumo category — VI Competencia Nacional de Robótica (USB BOTS 2016), Centro Ítalo Venezolano, Caracas, 7–9 November 2016. Built with Javier Inojosa for FutBot – Future Robotics.

Atlas next to the USB BOTS 2016 second‑place certificate.

Step 5Refine

What I'd Change

Going back through the firmware later, I found bugs. These are the fixes I’d make first:

• Ring‑edge escape — the four edge reflectance channels are sampled, but nothing reacts to them. A back‑up‑and‑turn reaction to any edge reading comes first.
• Kinematics units — the wheel‑speed step already returns rad/s, and the RPM conversion divides by the wheel radius a second time, so target RPM comes out about 12.5× too high. The MATLAB model has the same extra division, so its plots didn't catch it.
• Command types — Vc and Wc are declared int, so a turn rate such as 1.1π rad/s truncates to 3.
• Non‑blocking ADC reads — each TLC2543 read waits about 10 ms, which throttles the whole control loop.
• Re‑calibration — the current conversion uses ACS712 scaling while the schematic shows ACS711 sensors, so the 3.5 A limit needs checking on the real board, along with the Sharp tables.

Repository

The GitHub repository holds the complete project: the Arduino firmware (11 modules — motor driver, kinematics, PID, state machine, sensor drivers), the KiCad electronics design, the SolidWorks CAD and drawings for all three chassis versions, and the MATLAB kinematics scripts. The README documents the full hardware and firmware architecture, plus a look back at the bugs and the changes I would make revisiting it today.