Building, Testing and Safety

From requirements to a first robot

• Write the requirements as numbers: payload, speed, runtime, floor and slope, minimum doorway, how it is charged, how it is stopped, what it must never do. Each one drives a choice below.
• Build the smallest robot that tests the riskiest assumption first: a drive base before the arm, a lidar on a stick before the mount.
• Make everything accessible and labeled: a robot is rebuilt many times, so connectors, fuses and test points should be reachable.
• Mount sensors rigidly and record their positions for the URDF (see Frames, Transforms and Arm Kinematics and Perception: Cameras, Lidar and IMUs).
• Keep a bill of materials and a wiring diagram under version control with the code.
• Separate the high-power and low-power sides physically and electrically, with a single, clearly marked main switch.

Power: budget, battery and wiring

• Battery chemistry: Li-ion and LiPo (high energy, need a protection board and a proper charger, never over-discharge), LiFePO₄ (safer, flatter voltage, heavier), lead-acid (cheap, heavy, forgiving). See Batteries and Power Supplies and the Battery Runtime and Pack Calculator.
• Measure the battery voltage and warn well above the cut-off; stop the motors at the low-voltage threshold rather than let the pack collapse.
• Charging: use the charger made for the chemistry, in a safe place, never unattended, with a balance lead for multi-cell packs.
• Brown-outs reset the computer: give the computer its own regulated, filtered supply, with a capacitor for ride-through, so motor surges do not restart it.

Motors and drivers

Motor	Driver	Good for	Watch out for
Brushed DC	H-bridge (PWM and direction)	Cheap drive wheels, small arms	Brush wear and noise; stall current
Brushless DC (BLDC) with Hall sensors or FOC	ESC or field-oriented controller	Efficient wheels and arm joints, high power density	Needs commutation; controller tuning
Stepper	Step/direction driver	Precise open-loop positioning at low speed, 3D printers	Loses steps if overloaded; resonances; hot
Servo (hobby)	Built in; 50 Hz pulse	Light joints, grippers, steering	Limited torque and life; no feedback
Smart servo (Dynamixel and similar)	Serial bus	Arms and legged robots: position, speed, torque and temperature feedback in one	Cost; power per bus

• Choose the driver for the stall current, not the running current, or limit the current in firmware; add a flyback path for inductive loads.
• Separate the motor supply from the logic and join the grounds at one point (see below).
• A brake or a holding torque for joints under gravity, and a defined state when power is lost.
• Thermal limits: sense motor temperature or estimate it from current, and derate before it burns (see Motor Control, PID and Trajectories for sizing).
• Encoders and cables: keep the encoder wiring away from the motor power lines, with shielded twisted pairs for long runs.

Grounding, noise and cables

• One ground reference: a single star point where the motor ground, the logic ground and the battery meet; do not let motor current flow through the logic ground wires.
• Separate motor power cables from signals and cross them at right angles; twist the supply and return wires.
• Decouple: a large capacitor at each motor driver and 100 nF ceramics across each motor’s terminals and to the case.
• Ferrites and filters on USB and sensor cables that run beside motors; shielded cable for encoders, with the shield grounded at one end.
• Strain relief and connectors: a vibrating robot loosens every connector. Use latching, locking or screw connectors, and secure cables so that they cannot be caught by the moving parts or pulled out (a 10 kg robot dropped by its cable is a 10 kg pull on a 1.5 mm² wire).
• Intermittent faults (random resets, lost serial links) are usually power or connector problems, not software: measure the supply with a scope while the motors move (see Embedded Systems: Debugging).

The emergency stop and safe design

An emergency stop must remove motor power by hard-wired means that do not depend on software, the computer or the network: a mushroom button wired through a contactor (or the driver’s safe-torque-off input) that cuts power to the drives, latching until reset by hand. A “stop” message or a software disable is a convenience, not a safety function.

• Wire the emergency stop to cut power to the motor drivers, not just to signal the computer; test it at every start-up and after every change.
• Brakes fail safe: a spring-applied brake that releases only when powered, so that losing power holds a load.
• Limit speed, force and workspace in the firmware where no upper software layer can raise the limits (see Robot Software Architecture).
• Use a heartbeat or watchdog so that lost commands stop the robot.
• A safety-rated sensor and controller (a safety lidar, a safety PLC) for anything near people, instead of the general-purpose navigation sensors.
• Signs, lights and sounds show that the robot is on and moving; a visible “running” light is a cheap, effective safeguard.

Safety standards

Standard	Covers	Notes
ISO 10218-1 / -2	Industrial robots and robot systems	Requirements for the robot and for the cell and integration (see Industrial Robotics)
ISO/TS 15066	Collaborative robots	Allowed contact force and pressure by body region; power and force limiting, speed and separation monitoring
ISO 13482	Personal care robots (mobile servants, physical assistants)	Service robots in homes and public places
ANSI/RIA R15.08	Industrial mobile robots	AMRs and AGVs: speed, stopping, sensing
ISO 13849-1, IEC 62061	Safety-related control systems	Performance level (PL) and safety integrity level (SIL) of the safety functions
ISO 13850, ISO 13855	Emergency stop; positioning of safeguards and approach speeds	Where the protective field must start
IEC 60204-1	Electrical equipment of machines	Wiring, stop categories, protective earth
Machinery Directive / Machinery Regulation (EU), OSHA (US)	Legal duty to make machinery safe; CE marking	A risk assessment is required for a product placed on the market

A hobby or research robot is not covered unless it is sold or used at work, but the methods are worth borrowing: list the hazards, estimate the severity and likelihood, reduce them by design, then by safeguards, then by warnings, and record what you did. A robot for sale or for use among the public needs a formal risk assessment, certified safety components and a competent person.

Testing: from unit tests to the field

Level	How many	Cadence
Unit tests (kinematics, filters, parsers)	1 000s	Seconds, on every commit
Software in the loop (simulation, headless)	100s of scenarios	Minutes, on every merge
Hardware in the loop (real controller, simulated world)	10s	Hours, nightly
Bench tests (real robot, wheels off the ground)	A checklist	Before every first run
Field tests (real robot, real place)	Planned runs	Days, with safety measures

• Test the math first (kinematics, filters, planners) with unit tests against hand-calculated answers (see Software Practice).
• Simulate before you drive: the same launch files in simulation, with noise and delay added (see Simulation and Digital Twins).
• Bench-test every new function with the wheels or the arm off the ground, a person at the emergency stop and the speed limited.
• Increase speed, load and complexity in steps, with a written test plan: what you will do, what you expect, what “pass” means.
• Test failures on purpose: pull the lidar cable, kill the computer, fill the battery warning, block the path, and check that the robot stops or recovers safely.
• Repeat tests many times: a robot that works nine times out of ten fails every day in the field. At a mean time between failures of 200 h, an 8 hour day has a 3.9 % chance of at least one failure: find them before the customer does.
• Keep a test log with the software version, the settings, the conditions and the outcome.

Logging, replay and monitoring

• Record every run with ros2 bag record (sensor data, commands, transforms, diagnostics), and keep the bags with the software version (see ROS 2 in Practice).
• Replay to debug: run the perception or navigation code on the recorded data, change one thing, and compare.
• Publish diagnostics: battery voltage, motor temperatures and currents, loop timing, sensor rates, localization uncertainty; diagnostic_updater and a dashboard (Foxglove, rqt, Grafana) show them live.
• Set alerts on the things that go wrong before failure: low battery, hot motor, falling frame rate, growing localization uncertainty.
• Time-sync every machine and every log so that events can be lined up.
• Keep logs off the robot too, and watch the disk: a full disk is a common cause of a robot that stops recording.

Deployment, updates and maintenance

• Start the software as services (systemd units, or containers with restart policies) so that the robot comes up by itself after a power cycle, and use a watchdog to restart a hung process.
• Reproducible builds: a container image or a locked set of packages, built by a pipeline from Git, with the version shown on the robot.
• Update safely: test the new version in simulation and on a bench robot, update one robot first, keep the previous version to roll back, and never update a robot that is moving.
• Firmware updates need the same care as software updates (see Embedded Systems: Updates).
• Network and security: a robot has its own network, strong passwords, no default accounts, and the ROS 2 security options if it is exposed (see ROS 2 in Practice).
• Maintenance schedule: check wheels, belts and cables, tighten fasteners, clean the lidar window and camera lenses, test the emergency stop and the bumpers, inspect the battery for swelling or damage, and recalibrate the sensors and odometry (see Mobile Robot Kinematics and Odometry).
• Keep spares and documentation: a spare of anything that wears, and a log of what was changed and when.

Troubleshooting

Symptom	Likely cause	Try
The robot will not start or resets under load	Battery voltage sag, loose connector, a brown-out of the computer	Measure the supply under load; check connectors and fuses; give the computer a separate regulated supply with a capacitor
Motors run the wrong way or one wheel only	Swapped motor or encoder wires; sign error in the driver	Test each motor alone, wheels off the ground; check signs and units (see Motor Control, PID and Trajectories)
Drives in a curve instead of straight	Unequal wheels, calibration, a motor difference	Calibrate (see Mobile Robot Kinematics and Odometry); closed-loop speed control
The lidar shows ghost obstacles	Reflections, the robot’s own body in the scan, a wrong mounting transform, sunlight	Filter the robot’s footprint; check the lidar frame; mask or shade the sensor
Localization jumps or is lost	A changed environment, a featureless corridor, wrong initial pose, a bad transform or clock	A new map; a better initial pose; check time stamps and the lidar mounting (see Localization, Mapping and Navigation)
It stops and says “no path”	Inflation too large for a doorway; a wrongly placed obstacle; a stale costmap	Check the costmap in RViz; reduce the inflation; clear the costmap
Overheating motors or drivers	Too much stall or low-speed torque; no cooling; wrong current limit	Reduce the load or gear down; add heatsinks; set the current limit
Works on the bench, fails in the building	Wi-Fi, floor material, lighting, people	Test where it will work; log the network and the sensors
Everything works, then degrades over days	Disk full, memory leak, loosening hardware, battery aging	Monitor disk and memory; tighten; replace the battery; recalibrate
Random faults that nobody can reproduce	Power noise, connectors, thermal effects, race conditions	Log everything; swap parts one at a time; measure the supply (see Embedded Systems)

Pre-run checklist

Check	Why
Battery charged and undamaged; fuses fitted; connectors seated	No surprises in the first minute
Emergency stop tested: pressed, power drops, reset needed	The one safety function that must always work
Wheels, belts and cables free; nothing loose; no pinch points	Mechanical faults cause most injuries
Sensors clean and clear; lenses and windows wiped	Perception depends on them
Software version and parameters as expected; clocks synchronized	Know what you are running
Speed limits set for the test; area clear; a person at the stop	Fail small
Recording started (bag) and diagnostics visible	So that you can learn from the run
Test plan written: what, where, expected result	A test without a plan is a demonstration

Related

• Robotics Tools: the overview of this guide.
• Robot Software Architecture: where safety and timing live in the software.
• Simulation and Digital Twins: testing before the real robot.
• Industrial Robotics: cells, guarding and collaborative robots.
• Workshop Safety and Batteries and Power Supplies: shop practice and battery safety.

FAQ

What is the minimum safety equipment for a hobby robot?

A hard-wired emergency stop that cuts motor power, a fuse at the battery, speed limits in the firmware, a heartbeat timeout, and testing with the wheels off the ground first. Never test unattended.

Can I use a software stop as an emergency stop?

No. A software stop depends on the computer, the network and the program all working; an emergency stop must work when they do not, by cutting power with wiring and a contactor.

How long should a robot run on a battery?

Work it out from the power budget with 80 % of the capacity, as in the worked example, and test it: heavy loads, cold and aging reduce it. Add a margin, and return to charge at a threshold above empty.

When do I need a formal risk assessment?

When the robot is sold, supplied to others, or used at work, and in any place where it can hurt people. Even for a hobby robot, listing the hazards and what you did about them is good practice.

References

• ISO 10218-1 and -2, ISO/TS 15066, ISO 13482, ANSI/RIA R15.08, ISO 13849-1, ISO 13850 and ISO 13855 (safety of robots, collaborative operation, emergency stop and safeguards).
• Murphy, R., Introduction to AI Robotics; Siciliano, B. and Khatib, O. (eds.), Springer Handbook of Robotics (design and safety chapters).
• Battery makers’ datasheets and handling guides; ROS 2 documentation on logging, diagnostics and security (SROS2).

Last reviewed: October 2026. This is general guidance, not a safety certification: a robot that can injure people needs a proper risk assessment and the standards that apply to it.