Szarik
From printing to designing.
A belt tensioner made for this robot. By July, the project was drawing its own parts.
An open quadruped robot
Four paws.
A world of curiosity.
Meet Szarik. A robot to build, understand
and discover the world with.
A hands-on project in development. Build cost and time are still being established.
For curious makers comfortable learning mechanics, electronics and code.
Small robot. Big learning curve.
Made to move.
Built to understand.
If you can write software but have never made a motor move, this is a place to start. Szarik connects printed parts, electronics and code in one project you can take apart.
4legs
12actuated joints
Pi 5onboard computer
3Dprinted structure
The hero is a rendered motion and conversation demo. Physical performance remains work in progress.
From the workbench
Real parts.
Real progress.
Before the renders came copper wire, printed parts and plenty of things that didn’t fit. A few moments from the build diary.
The second actuator.
Consistent resistance readings—and a rotor that still rubbed slightly. The difficult bits are part of the story.
One leg. Three actuators.
On a stand, with the feet clear of the floor. A way to learn one joint at a time.
Inside every joint
A little motor.
A lot to discover.
Twelve actuators make the robot move. Start with one: a magnetic motor, a planetary gearbox and parts you can print yourself.
The Szarik actuator
Built layer by layer.
Printed mechanics. Real metal hardware.
Planetary reduction.
Six motor turns.
One output turn.
42Rotor magnets.
Alternating north and south.
A shared job
Three planets.
One output.
The planet gears travel around the sun gear, inside a fixed ring.
Printed pieces.
For one actuator in the current print release. Purchased hardware is additional.
See the breakdown
Housing, backplate, rotor, output, rotor cap, outer bearing retainer, back cover, planet carrier, stator lock, bearing retaining ring and three planet gears. The optional manual handle is separate.
Purchased hardware includes magnets, bearings, pins and fasteners. A complete hardware-inclusive count for this revision is still being verified.
From filament to parts.
Estimated printing time for one actuator, across four plates.
Printer and settings
Current print release 909: Bambu Lab H2S, 0.4 mm nozzle and saved PETG Basic profiles. Four plates total 14 h 34 min 1 s. Assembly, post-print cooling, support removal and reprints take additional time.
Filament for one.
PETG for the printed parts and supports in the current sliced package.
What this weight includes
The four plates use an estimated 158.46 g, 71.62 g, 23.88 g and 6.21 g: 260.17 g in total. This includes supports and is material consumption, not assembled actuator weight. Complete actuator weight still needs a scale measurement.
From the outside in
Every part has a purpose.
A simplified CAD view of the assembled actuator.
Design facts, not rated performance. Torque, efficiency and thermal limits still need measurement. Explore the leg →
From a joint to a step
One leg.
Three ways to move.
Three actuators work together to place a foot. A toothed belt carries the knee drive down the thigh, keeping its motor close to the hip.
The Szarik leg
Built for the next step.
A CAD view of the complete leg.
Joints. One foot.
Hip roll moves sideways.
Hip pitch swings the thigh.
The knee folds the lower leg.
A little extra leverage.
The belt adds another reduction between the knee actuator and the lower leg.
Schematic · not to scale
A motor at the hip. Motion at the knee.
The belt does the travelling.
The smaller pulley drives the larger one: 28 ÷ 18 = 1.56. The lower leg turns more slowly, with greater ideal turning force. Belt tension, friction and flex affect what reaches the foot.
9.33:1 rotor-to-knee reduction6:1 planetary × 28:18 belt · ideal kinematic ratio
Room to move
Sideways. Forwards. Folded.
Reference software ranges
Physical travel remains unverified.
Hip roll
±46°Side to side.
Hip pitch
±120°Thigh forwards and backwards.
Knee
±149°The model permits bending both ways.
How to read these ranges
Angles are relative to each joint’s model zero and rounded to the nearest degree: hip roll ±0.8 rad, hip pitch ±2.1 rad and knee ±2.6 rad. The tracks compare those configured spans on a common 360° scale. These are software bounds, not measured mechanical stops or a guarantee that every combination is collision-free. Physical clearance, cable routing and usable travel need validation on the assembled robot.
CAD geometry and software configuration. Belt efficiency, usable travel and load capacity still need physical measurements.
Everything comes together
A home for
every moving part.
The body connects four legs, carries the computer and gives the battery its own compartment. Printed parts make the structure something you can build, open and understand.
The Szarik body
Built around what’s inside.
Reference CAD structure. Internal installation evolves as the robot is built.
Legs. One frame.
Mounting plates join the legs to a body built from printed panels and carbon-fibre tubes.
Made to be understood.
Removable covers give access to the hardware. Threaded inserts let printed parts meet metal fasteners.
A place for the essentials
Computer above.
Battery in its compartment.
The documented electronics layout keeps the Raspberry Pi horizontal on its tray, with the power HAT above it. The Bosch pack uses a printed battery box, rails and contact carrier. CAD packaging is a reference; connector mating and final installed clearances still need physical checks.
A face for physical AI
Look. Listen.
Let you know.
Two cameras, a microphone array and a speaker share a head with a little personality. Black and brown printed parts give Szarik his German Shepherd look.
The Szarik head
Curiosity has a face.
Separate brown eyebrows. A narrow halo. A printed home for cameras and audio.
A pair of eyes.
ArduCam B0179 camera modules. Stereo experiments compare their views to estimate distance.
A fixed camera pair.
Nominal camera spacing in the rigid CAD carrier. Accurate depth depends on calibration of the actual camera pair.
Vision · 2 × IMX219
8MPTwo affordable eyes.
Two off-the-shelf camera modules give the computer two views of the same scene. Comparing their images is the starting point for stereo depth.
About $20 per camera
ArduCam lists the B0179 family at US$19.99 per module, checked 6 November 2026, before shipping and tax. This is a reference listing, not our recorded purchase price. The physical boards are UC-609 Rev.E; cable compatibility is revision-specific.
Camera listing ↗Hearing · ReSpeaker XVF3800
4Microphones. One listener.
Four microphones feed the XMOS XVF3800 audio processor. The selected module includes XIAO ESP32S3 and connects to the Raspberry Pi.
More than recording sound
The manufacturer provides beamforming, noise suppression and acoustic echo cancellation. Beamforming combines the microphones to favour a direction. Echo cancellation helps reduce the speaker’s own sound in the microphone signal. Results depend on the room, enclosure and setup.
ReSpeaker hardware ↗Voice · Seeed 114993346
5WA voice in the muzzle.
A separate enclosed speaker plays Szarik’s reply. The selected Seeed unit is rated 5 W with a 4 Ω impedance; that is a component rating, not a measured audio output.
Speaker and microphone are different jobs
ReSpeaker handles the microphone signal and audio interface; the speaker turns the output into sound. This speaker has worked electrically with ReSpeaker. Mounting, enclosure acoustics and vibration still need physical checks. The hero conversation is recorded.
Speaker specification ↗Why two cameras?
Two views.
One sense of depth.
A real stereo experiment
from the Szarik project.
Hold a finger in front of you and close each eye in turn. It seems to move against the background. Stereo vision uses the same effect: find the same feature in both images, measure its shift, then estimate its distance using the camera spacing and calibration.
Camera imageEstimated depth
Red: nearerBlue: fartherBlack: no reliable match
An early experimental result. Gaps and noisy edges show where the estimate is uncertain; black does not mean clear space.
See what the two cameras see
These are the aligned left and right views from the same experiment. Horizontal guide lines help check that corresponding features lie on the same rows. Their horizontal shift is called disparity. Nearer features generally shift more; farther features shift less.
Calibration, lens distortion, scene texture and timing all affect the answer. This image is a development result, not a claim of rated ranging accuracy.
A little attention
The halo gives
interaction a cue.
The selected narrow halo is a visual way to express attention. The rendered demo illustrates this interaction; hardware behaviour is still being developed.
The signal behind the movement
Think together.
Control locally.
A central computer works with a small dispatcher and a driver at every joint. Each board has a clear job.
Raspberry Pi 5
The robot’s computer.
Robot-side software, control calculations, recordings and camera experiments.
Local motor drivers.
One ERAD 2.1 board per joint. Each handles its motor and local rotor-angle sensing.
A sense of rotation.
The AS5048A encoder reports 16,384 positions per rotor turn. Resolution is not a promise of joint accuracy.
Plan.
Raspberry Pi 5
Runs the robot-side application and calculates movement.
USB → spineDispatch.
ESP32-S3 spine
Supervises and distributes joint commands.
ESP-NOW → joint driversDrive.
12 × ERAD 2.1
Turns commands into three-phase motor drive, using local feedback.
One board per actuatorFrom the battery to every joint
One power source.
Many places to go.
A Bosch ProCORE18V pack sits in the printed battery compartment. The power design links that pack to the computer and twelve joint drivers.
mjbots mjpower-ss
Power, shared out.
Pre-charge and six switched outputs. Pre-charge fills the drivers’ input capacitors gradually, reducing the initial current surge.
A familiar battery.
Bosch ProCORE18V 4.0Ah.
The pack shown in the project’s photographs and CAD.
Energy on the label.
18 V nominal × 4 Ah.
Runtime depends on movement, load and the usable battery capacity; it has not been measured.
A familiar pack. A custom home.
Battery out.
Back to building.
The removable tool battery fits into the robot’s printed compartment and adapter system. The pack illustration follows the photographed ProCORE model; rail and contact geometry still need physical verification.
The power path · proposed harness architecture
From a pack to a moving leg.
- Battery interface
Printed compartment and adapter. Protection and service-disconnect details still need qualification.
- Power distribution
The mjpower-ss pre-charges and distributes the motor supply. A separate regulated logic branch is proposed for the Pi.
- Leg harnesses
Proposed grouped power feeds, with local drops to each joint driver. Cable sizes and protection depend on measured demand.
- Motor phases
Each ERAD converts its DC supply into the motor’s U, V and W phase connections. Those are different from the battery pair.
Two jobs, two power levels
Motor power.
Regulated computer power.
The KAmodRPI5 REL+POW HAT supplies the Pi through its header at 5.1 V, with a published 3 A continuous rating. The HAT’s small relays are not the motor power switch. Final fusing, cutoff wiring, current limits and thermal performance remain engineering work to verify.
Make something you can understand
Start with a part.
Think in systems.
A robot brings the whole stack together. Follow one question from the workbench all the way to the code.
Make the mechanics.
Printed housings and gears meet bearings, magnets, copper and fasteners. Learn why a part that looks right in CAD can still need another print.
Explore the actuator →Connect the electronics.
Each joint has its own ERAD 2.1 driver and magnetic encoder. A spine board joins the twelve joints to the Raspberry Pi.
See the architecture →Bring it into software.
Rust handles the core control logic. Python drives experiments and simulation. The operator console makes the state visible.
Meet the software →A few things we know.
- Actuation
- 12 joints · 3 per leg
- Joint drive
- 6:1 planetary · ERAD 2.1
- Rotor sensing
- 14-bit AS5048A encoder
- Computer
- Raspberry Pi 5
- Joint communication
- ESP-NOW via the spine board
- Mass, runtime & rated torque
- Not published as verified measurements
See what the software sees
More than
a moving machine.
The operator console shows the robot’s state, telemetry and configuration. It’s one more way to turn “why did it do that?” into something you can investigate.
Screenshots from the project’s operator console. This website does not connect to or control a robot.
The open toolbox
Made with tools
you can make your own.
From a sketch to a printed part, from a circuit to a line of code. Open source tools make the process something you can inspect, adapt and learn from.
The language
Rust
Core control logic and shared software, with checks that catch many mistakes before the code runs.
The editor
Neovim
A keyboard-driven place to write code, understand changes and keep learning.
The foundation
Arch
The Linux foundation of the development desktop. A system you can understand and shape.
BTW, we use Arch, Neovim, and Rust.
Mechanical design
FreeCAD
Parametric parts and assemblies. Dimensions, interfaces and the geometry behind the printed robot.
Electronic design
KiCad
Schematics, circuit-board layouts and 3D inspection. Follow a signal beyond the software.
Interface design
Penpot
An open design and prototyping tool for exploring interfaces before they become code.
Renders & animation
Blender
Lighting, cameras and explanatory films that help show how the mechanics fit together.
Experiments & vision
Python
Camera experiments, simulation scripts and the glue between an idea and a repeatable experiment.
Physics simulation
MuJoCo
A place to explore robot motion and contact before comparing a model with the physical machine.
The development desktop
Omarchy
An Arch-based Linux desktop for the workbench computer. A considered starting point, with room to make the environment your own.
Linux, at the workbench.Curiosity, encouraged
Learn the why.
Then change the how.
No robotics background required to start reading. Bring your programming experience—and a willingness to meet a few new ideas.
Why a planetary gearbox?
A gearbox trades rotational speed for turning force, called torque. Here, the motor turns six times for one output turn. The three planet gears share the load as they travel around the central sun gear, inside the fixed ring.
What does the encoder measure?
An encoder reads the rotor’s angle. This actuator uses a 14-bit magnetic sensor: 16,384 counts across a full turn. That describes resolution—how finely it reports position—not a guarantee of accuracy under load.
Why begin in simulation?
Simulation lets you try control ideas against a model before working with a physical machine. Szarik uses MuJoCo. A useful simulated motion is a starting point; contact, friction and real mechanical tolerances still have to be checked on hardware.
Work in progress · 5 November 2026
There is still a lot to learn.
The complete build cost and repeatable build time are still open. Actuator performance needs bench measurements. The hero shows a scripted rendered demonstration, not recorded physical walking or live recognition.