Validation in brief
Design validation is the set of checks that show a design will meet its goals before it is built. For a quadruped the goals are usually a target weight, a walking speed, a few tricks such as a jump, and parts that survive falls.
The tests run in stages, from cheap to expensive. A CAD clash check takes seconds. A trained walking policy takes an hour on a gaming GPU. A motor heat test needs a real motor on a bench. Each stage ends in a gate, a pass rule that decides whether the design moves to the next stage. A failed gate sends the design back to CAD, and every test that depends on the changed part runs again.
Buying follows the same order. One or two motors are bought early for the bench tests, and the rest are ordered only after the heat test passes. One leg is printed and tested before the other three.
No single stage is enough. Each one catches problems the others miss. A simulation can show a robot jumping 30 cm while hiding a motor that would overheat in a few minutes of trotting. A stress check can pass a part that the robot then slams into the floor on every landing. The sections below follow the stages in order.
All tests at a glance
Times are for a robot dog of 7–11 kg with 12 motors and printed nylon-carbon parts. Laptop means an Apple M3 laptop and desktop GPU means an NVIDIA RTX 3060. Required tests are the ones that have caught real problems in designs of this kind. Optional ones add confidence but rarely change a design.
| Test | Stage | Needed | Tools | Computer and time | Output |
|---|---|---|---|---|---|
| Goals and similar builds | 0 | Required | Papers, build logs, motor manuals | None, a few days of reading | Target weight, speed and tricks, plus known failure points |
| Bus load and power path | 0 | Required | Spreadsheet | Laptop, minutes | Control rate per CAN bus, list of fuse, relay and soft-start parts |
| Collision check | 1 | Required | Parametric CAD such as CadQuery | Laptop, seconds to minutes | List of parts that overlap |
| Joint travel sweep | 1 | Required | Same CAD model, stepped through each joint range | Laptop, about a minute | Clashes at any joint angle |
| Motor interface check | 1 | Required | The maker's 3D CAD files (STEP), calipers | Laptop, plus measuring a real motor | Screw circles, raised rings and thread depths that match the real part |
| As-printed mass | 1 | Required | CAD with print walls and infill | Laptop, minutes | Mass and inertia of each part for the simulation |
| Full-size fit check in VR | 1 | Optional | WebXR page, VR headset | Headset, minutes | A feel for size and joint limits at real scale |
| Walking policy training | 2 | Required | MuJoCo on a GPU with a PPO trainer such as Brax | Desktop GPU, about 1 hour per 100 M steps | A trained walking policy |
| Simulator parity check | 2 | Required if training on GPU | The CPU simulation and its GPU port side by side | Laptop, minutes | Proof the two simulations match |
| Top speed, startup and gait quality | 2 | Required | CPU simulation running the policy | Laptop, minutes | Top speed, time to reach a commanded speed, stride, foot lift, energy per meter |
| Push recovery | 2 | Required | Same, with side pushes | Laptop, minutes | Largest push survived |
| Tricks | 2 | Optional (required for a jumping or flipping design) | A search over fixed sequences of leg poses | Laptop, about 5 minutes per search | Success rate, jump height, leg strikes on the floor |
| Joint limit margin | 2 | Required | Simulation logs of joint angles | Laptop, minutes | How close each joint gets to its end stop, and the stop load |
| Power and current | 2 | Required | Motor model with battery sag | Laptop, minutes | Peak current, voltage sag, run time |
| Motor heat model | 2 | Required | RMS torque from the simulation, motor ratings | Laptop, minutes | Motor temperature over a walk |
| Load extraction | 3 | Required | Joint and contact forces from the simulation | Laptop, minutes | Worst forces on every part, per move |
| Stress check (FEA) | 3 | Required | gmsh and scikit-fem, or a commercial FEA tool | Laptop, about 30 minutes per round with the default solver; a rented CPU with a faster solver, about 6 minutes | Safety factor of every printed part |
| Print orientation sweep | 3 | Required for weak parts | The same FEA with the layer direction changed | Laptop or cloud, one FEA round per orientation | The strongest way to print each part |
| Hand checks on metal parts and bearings | 3 | Required | Spreadsheet or script | Laptop, seconds | Stress in shafts, pins, tubes and bearing loads |
| Slicing | 4 | Required | Printer slicer, often from the command line | Laptop, minutes | Print time, filament use, bed fit |
| Fit print in PLA | 4 | Optional | 3D printer | Hours of printing | Parts to test-assemble with real motors |
| Motor bench | 5 | Required | Motor stand, lever, scale, controller with CAN | Microcontroller and laptop, several days | Measured torque, friction, CAN timing, heat, braking voltage and battery current |
| Single-leg tests | 5 | Required | One printed leg on a stand | Microcontroller and laptop, days to a week | Drop survival, joint play, backlash after cycling, insert and bolt hold |
Stage 0. Research review
The first check needs no software. It sets the goals in numbers and reads how similar robots were built and where they failed. Useful sources are theses behind research robots such as the MIT Mini Cheetah, Stanford Doggo and StarlETH, open hobby build logs, and the motor maker's manual.
This stage finds problems the later tests are blind to. In the example design every peak-value check passed, including jump height, landing loads and top speed. A review of other builds then showed that comparable dogs put more torque at the knee. Checking the simulation's RMS torque, an average that counts the hard moments more heavily, confirmed it. Trotting would run the knee motors at 1.3–1.5 times their continuous rating. The peak checks never looked at RMS torque, so they missed it.
The review also sets expectations. In a survey of about twenty hobby builds, experienced makers took three to four months to get a dog walking and up to two years to reach a fast trot. Most stalled projects stalled in software. Motor warranties often exclude falls, impacts and exceeding peak torque, which matters for the drop tests later.
Two quick calculations belong here too. The first is bus load. Four motors at 1,000 updates per second fill a 1 Mbps CAN bus to 89–108%, so the example design settled on 500 Hz. The second is the power path. The battery feeds a dozen motor drives with large capacitors, so the design needs a soft-start circuit, a main relay, a fuse and a way to absorb braking energy.
Gate. Goals written as numbers, a control rate that fits the bus, a power-path parts list, and a list of failure points from other builds that the later tests must cover.
Stage 1. CAD and fit
A parametric CAD model is built from a file of numbers, such as link lengths, wall thickness and motor positions. The same numbers generate the simulation model, so the simulated robot and the printed robot always match. Changing one number rebuilds both.
- Collision check. Every pair of parts is checked for overlap, and any overlap over about 1 mm³ is listed. Parts meant to touch, such as a motor and its mount, are skipped.
- Joint travel sweep. Each joint is stepped through its full range, for example every 10°, and the collision check runs at every step. This catches a thigh that hits a screw head only when the knee is fully bent.
- Motor interface check. Mounting faces, screw circles and thread depths come from the maker's STEP model and are then measured on a real motor with calipers. In the example design the real motor's length and mounting face differed from the drawn one, and the hip mount clashed with it.
- As-printed mass. A printed part is a shell of solid walls around a partly hollow infill. Its mass should come from the same model used for printing, walls and infill included.
Gate. No clashes anywhere over the joint ranges, every motor interface checked against a measured part, and masses ready for the simulation. The total mass has to stay inside the heavier variant the walking and trick results were checked on, which is described next. If it grows past that, the walking policy is retrained.
Stage 2. Motion simulation
The simulation stage asks whether the robot can do its job. It uses a physics simulator, most often MuJoCo for robot dogs. The MuJoCo Guide covers the simulator, and Robot Gaits covers gait training.
Realistic motors and variants
A simulated motor with perfect torque makes every design look good. A realistic motor model adds the torque-speed curve, the torque a motor can still give at each speed. It also adds a few milliseconds of command delay, sensor noise and battery sag. Under battery sag the pack voltage drops with load, and the top speed drops with it.
Each result is then checked on several variants, copies of the robot with pessimistic changes. A typical set is nominal, a slippery floor, a lighter battery, and a robot 10% heavier with 10% weaker motors. A harsh variant stacks milder versions of several of these with a longer command delay. A design that only works on the nominal model is not ready. This is the same idea as domain randomization in training.
Walking tests
A walking policy is trained with reinforcement learning, then judged in the CPU simulation on every variant.
- Top speed. The fastest speed held without falling.
- Startup. Time from standing to a commanded speed. The example design reached 1.0 m/s in about half a second.
- Gait quality. Stride length, foot lift and energy per meter. Energy is often given as cost of transport, the energy used per meter divided by weight. In the example design a taller stance raised top speed from 1.35 to about 1.5 m/s and cut cost of transport by about 15%.
- Push recovery. Sideways shoves while walking, given as the sudden change in body speed the robot survives.
Training on a GPU needs one extra check. The GPU version of the simulation is a separate program, so a parity check runs the same commands through both and compares the results. In the example, joint angles matched to the last digit of double precision. A deliberate 1 ms error in the motor command delay of the GPU copy showed up as a 1.1° and 32 mm difference, which proves the check catches real mistakes.
Trick tests
Jumps, flips and hind-leg stands are usually tuned as fixed sequences of leg poses by a search program. Each trick is scored over every variant and several random seeds. The outputs are the success rate, the jump height and every time a thigh or shin hits the floor.
Several lessons came out of the example design. A fixed backflip rotated far enough on all five variants but landed on only one. More motor torque did not help, since the landing has to react to how the body is actually turning. The search also landed jumps on the thighs, with up to about 1,100 N on a printed part. The trick score needs a penalty for floor strikes. Otherwise the parts end up sized for landings the robot should never make.
A learned trick is no automatic fix. In the example a learned jump landed 68% of the time against 100% for the hand-tuned one, and its worst leg strike was three times higher. Landing posture matters as well. ETH Zurich's StarlETH work showed impact losses under 15% when the shin lands near horizontal and over 25% with straight legs, so a crouched landing is easier on the parts.
Failed tricks need a crash check too. Sensors and the head are compared against where a short flip or a missed jump comes down. A lidar on the rear deck is exactly where a short backflip lands.
Joint limits, power and heat
- Joint limit margin. The logs show how close each joint gets to its end stop, the physical block at the end of its travel. In the example the knee stayed 26° from its stop when walking, and only tricks touched it, at 13–15 N·m. Without a drawn end stop, push-off ran the knee past its limit.
- Power and current. The motor model gives the current drawn from the battery. A backflip on the example design pulled about 145 A and sagged the pack to about 37 V, which set the fuse and wire sizes.
- Motor heat. Heat in a motor grows with the square of its torque, so RMS torque over a walk matters more than the peak. A simple heat model turns the simulated torque into a temperature over time. In the example the knee motor settled at 94 °C at 1.0 m/s with walking airflow, under its 145 °C limit. In still air it passed that limit after 8 minutes. The model is only an estimate until the bench test.
Gate. Walking works on every variant at the target speed. Required tricks succeed on most variants. Joints stay clear of their stops when walking. Peak current fits the wiring. No motor is predicted to overheat in a few minutes of normal walking.
Stage 3. Strength
The simulation records the worst forces on each leg part during every move, including walking, trotting, jumps, flips and a drop. The example design used 41 of these load cases, with a 0.5 m drop among them. Even a gentle trot loads the knee hard, since the touchdown torque peak can reach the motor's full rating for an instant.
A finite element analysis (FEA) then splits each printed part into small pieces and solves for the stress in each one under every load case. The result is a safety factor, the material's strength divided by the highest stress. A target of 2 is common for printed robot parts.
- Layer direction. A printed part is weaker across its layers than along them. For the nylon-carbon used in the example, the allowable stress was 60 MPa along the layers and 25 MPa across them. The FEA has to check both.
- Print orientation. For one hip mount the safety factor moved from 1.13 to 1.49 when the layer direction was turned 90°. After the part was thickened, the same turn moved it the other way, from 2.05 down to 1.46. Orientation is part of the design and belongs in the stress check.
- Material choice. PLA reached only about 0.55–0.6 of the nylon-carbon safety factors in the example. PLA parts suit fit checks and gentle walking. Jumps need the stronger material. Nylon-carbon also absorbs water, so spools are dried before printing and the strength numbers assume dry filament.
- Metal parts and bearings. Shafts, pins, tubes and motor output bearings are checked by hand calculation against the same loads. A knee motor that carries the shin directly needs its output bearing's side-load rating, which often has to be asked from the maker.
A perfectly sharp inside corner has no finite stress in the model, so the peak there grows as the mesh gets finer. Averaging the stress over a millimeter or two gives a fairer number, and a real fillet removes the problem. Each fix tends to move the peak to the next joint, so several rounds are normal.
Gate. Every printed part reaches the target safety factor on every load case, in the orientation it will be printed. Metal parts and bearings pass their hand checks.
Stage 4. Print checks
Each final part goes through the printer's slicer. The slicer reports print time and filament use, and shows whether the part fits the bed in its chosen orientation. Long parts such as thighs often only fit diagonally. A cheap PLA fit print of the leg then confirms that screws reach, heat-set inserts seat fully and real motors drop in.
Gate. All parts fit the bed in their tested orientation. If a fit print was made, it assembles with real motors and hardware.
Stage 5. Motor bench and first leg
The bench replaces guesses in the simulation with measurements. A motor is bolted to a stand with a lever arm, and a microcontroller drives it over CAN. The first two tests are safety checks. The watchdog is the motor's own timer that cuts torque when commands stop arriving, and it is proven before any load goes on.
| Bench test | Method | Pass rule |
|---|---|---|
| Watchdog and emergency stop | Commands stopped, then the stop button pressed, with no load | Motor goes limp both times |
| Torque accuracy | Lever pulls a cord on a hanging scale at set torques | Within ±10% of the command |
| Friction and inertia | Slow pulls and torque steps, with and without the lever | Values go into the simulation |
| CAN timing | Commands at the planned rate for 10 minutes | No missed replies, nearly all round trips under 1 ms |
| Zero repeatability | Power-cycled 20 times with a paint mark on the output | Same position within ±0.5° |
| Heat | Torque profile from the simulation, held until the temperature levels off, once on a metal plate and once in the printed mount | Settles below a chosen ceiling such as 100 °C, well under the maker's cut-off |
| Torque-speed curve | Two motors coupled, one driving and one braking | Matches the curve used in the simulation |
| Braking voltage | Motor braked hard, and power cut while it is moving | Bus voltage stays under the drives' limit, or a clamp circuit is added |
| Battery current | A jump-like torque step on two motors, read on a clamp meter | Within 30% of the simulation's figure, or the wiring is re-sized |
The heat test carries the most weight. A motor held still against a stop heats one winding about 1.4 times harder, so the test keeps the output moving a little. Stanford Doggo's team used a simple version, raising current on a lever until the motor settled at 125 °C in a 22 °C room. The run in the printed mount matters because a maker's rating assumes a large metal heat sink, and a motor inside a printed thigh sheds far less heat.
From the heat logs a two-value thermal model is fitted, one for how fast the motor heats and one for how fast it cools. That model goes back into the simulation so the walking checks run against real heating. It also sizes the cheap fix. The Mini Cheetah team found that a small fan cut the thermal resistance of their actuator about four times, which roughly doubled its continuous torque.
After the motor bench comes one printed leg. The StarlETH team ran a single test leg, ScarlETH, for three years before and alongside the full robot, and nothing in the motors, gearboxes or structure failed. Tests on the single leg include the following.
- Drops from about one leg length, as with StarlETH. StarlETH's joints had springs that took the shock. A leg without them needs its motors set to give way under current limits before the drop, and the torque spike logged.
- Joint play and backlash with a dial gauge, measured new and again after about 10,000 cycles of walking motion.
- Insert pull-out and bolt creep. Heat-set inserts are pulled to their rated load, and bolted joints are re-checked after a week to see whether the plastic has relaxed.
- Bearing side load on a motor that carries the shin directly, at the expected foot load.
Gate. Measured torque within 10% of the model, friction and inertia near the estimates, and the bus clean at the planned rate. The heat test passed in the printed mount, and the leg survived its drops and cycles. Then the remaining motors are ordered and the other legs printed.
Redesign decisions
A failed gate sends the design back to CAD with a specific change. A change then reruns every test that depends on what changed. The table lists the usual cases.
| Result | Usual fix | Tests to rerun |
|---|---|---|
| Part clash | Move or reshape the part | Collision check, joint sweep, mass |
| Part below its safety factor | Thicker walls, ribs, fillets, a new print orientation | FEA, mass, then a quick walking check at the new mass |
| Robot heavier than planned | Slimmer parts, lighter battery | Walking, tricks, loads, FEA |
| Motor too hot | Vent holes or a fan first, then a gear stage or a bigger motor | Everything after CAD |
| Trick fails on most variants | Feedback on body rotation during the move, or a learned policy for the trick | Tricks, loads |
| Legs hit the floor on landing | Penalize floor strikes in the trick search | Tricks, loads, FEA |
| Bench values far from the model | Update the motor model | All motion tests, then loads |
| Bus voltage spikes when braking | Add a clamp circuit sized from the logged energy | Braking test only |
Changing a motor is the most expensive fix, since it changes the brackets, the mass, the torque limits and the heat. Cheap fixes come first, such as airflow for heat, or ribs and orientation for strength.
Compute requirements
| Computer | Good for | Notes |
|---|---|---|
| Laptop CPU | CAD, clash checks, trick searches, judging policies, FEA, slicing | A trick search in about 5 minutes. Policy training at about 2,800 steps per second, so 5–20 hours per policy, which is too slow for routine design checks. |
| Desktop GPU | Policy training with MJX | About 30,000 steps per second on an RTX 3060, or about an hour per 100 M-step policy |
| Rented cloud machine | Big training runs, many FEA rounds at once | About $3 per training run and under $1 per FEA round (October 2026) |
| Microcontroller | Bench tests over CAN | A Teensy or similar board with a CAN transceiver |
The FEA solver choice sets most of the gap between the laptop and cloud times above. A sparse direct solver such as CHOLMOD ran about three times faster than the default SciPy solver on the same parts, with identical results.
Other robots and machines
Most of these stages carry over to robot arms, rovers and any 3D-printed mechanism. CAD clash checks, as-printed mass, loads, FEA with layer direction, print orientation, slicing and a motor bench apply to all of them. The walking tests, trick searches, push recovery and variant checks are specific to legged robots, and so are the large impact loads that drive their strength stage.
Sources
The example numbers come from the design checks of one printed robot dog, described in the note below. The outside facts come from the publications and pages listed here. The FEA, safety factor and print-orientation methods are standard mechanical engineering practice and are not tied to one source.
- Mini Cheetah actuator. Benjamin Katz, A Low Cost Modular Actuator for Dynamic Robots ↗, MIT master's thesis, 2018. Dynamometer limits, measured friction, thermal resistance and the fan result (pages 49–54).
- StarlETH and ScarlETH. Marco Hutter, StarlETH & Co. – Design and Control of Legged Robots with Compliant Actuation ↗, ETH Zurich doctoral thesis, 2013. Single-leg bench, landing posture and impact losses (chapter 7), the 0.4 m drop test and trot loads (chapter 8), reliability (chapter 9).
- Stanford Doggo. Nathan Kau, Aaron Schultz, Natalie Ferrante and Patrick Slade, Stanford Doggo: An Open-Source, Quasi-Direct-Drive Quadruped ↗, ICRA 2019. The lever-and-scale continuous-torque test (page 3).
- Motor ratings and stall heating. RobStride's motor manuals in its product information repository ↗. The rated torque assumes a 260 × 280 mm heat sink, and a stalled motor heats one phase about 1.41 times harder.
- Hobby build survey. About twenty open quadruped builds read in October 2026, among them openDog ↗, TOPS ↗, rolandfiksdal's quadruped ↗, ElectroPup ↗ and the MEVIUS ↗ paper. These gave the knee-torque comparison, the CAN rate limits seen in practice, the power-path failures and the time-to-walk expectations.
- Tools. CadQuery ↗ for parametric CAD, gmsh ↗ and scikit-fem ↗ for FEA, CHOLMOD ↗ from SuiteSparse as the fast solver, and Brax ↗ with MuJoCo's MJX for GPU training. See the MuJoCo Guide for the simulator itself.