← All projects
Personal Project Robotics In Progress

4-Wheel Differential Swerve Robot

A four-wheel robot where every wheel sits in a differential swerve module: two motors per module both steer and drive the wheel, so the robot can move in any direction while rotating. I'm designing the mechanics, electronics and firmware myself.

Hero video or render of the full robot.
4 × 2Swerve modules, each with two N20 motors
∞Steering range, with no wires turning with the wheel
12 MPaPeak gear stress at stall, vs ~50 MPa for PLA
0Design-rule errors on the custom PCB

Skills

Why differential swerve

In a normal swerve drive, one motor steers each wheel and another drives it. In a differential swerve module, two motors work together through a gear differential: turning them the same way drives the wheel, and turning them at different speeds steers it. Because neither motor rotates with the wheel, there are no wires to wind up, so each module can steer endlessly in either direction.

Mechanical design

I modelled the full assembly in Fusion 360 and 3D-printed every structural part in PLA. The robot has four modules on a four-piece printed chassis, with a 35 mm centre cap that houses the Raspberry Pi 5, the motor controller and the LiDAR mount. Each module has a ring gear held down by printed clamps, and a hall sensor that lets it find its home steering position on start-up.

One module: two N20 motors both steer and drive the wheel.
Exploded view of the printed layers.

Stress testing the gears

I ran FEA on the gears and bearing brackets at motor stall load, the worst case they will see. The peak stress came out at 12 MPa, comfortably below the roughly 50 MPa that PLA can take. I then refined the pinion bores, ring hold-downs and centre cap through several print-and-fit cycles until everything meshed cleanly.

FEA stress plot of the swerve module gears at motor stall load, peaking at 12 MPa
Gear FEA at motor stall: peak 12 MPa, against roughly 50 MPa for PLA.

Electronics and a custom PCB

The robot's work is split between two computers. A Raspberry Pi 5 handles LiDAR mapping and path planning, and sends commands over USB to an ESP32 that runs the eight motors and four hall sensors in real time. I wrote the ESP32 firmware, which drives the motors with 20 kHz PWM, homes each module using its hall sensor and saves calibration to flash.

My first plan used two hand-wired perfboards with dozens of solder links. Instead, I designed a single two-layer controller PCB in KiCad, autorouted it with Freerouting, checked every net against the firmware's pin map and sent it to PCBWay for assembly.

Board88 × 33 mm, 2-layer
Drivers4× TB6612FNG, running 8 motors
Sockets8 motor + 4 hall sensor, JST-PH
Checks0 design-rule errors, 0 unconnected nets
Controller PCB, front and back.
Centre bay: the Raspberry Pi 5 beside the ESP32 controller.
System diagram: LiDAR → Raspberry Pi 5 → ESP32 controller → motors and hall sensors.

Where it stands

What I learned

Write a few sentences here in your own words: the hardest part of the design, what the print-and-fit cycles taught you, and what you would do differently next time.

What's next