Robot Hands, Quadrupeds, and Home Robots: A Survey from Toy Prototypes to Integrated Systems | Private AI Cluster Log, Day 7

This AI-assisted survey synthesizes public primary sources; it does not report a robot hand, quadruped, or care robot built by the author. As of October 3, 2026, the platforms discussed here have not been purchased, wired, integrated, tested, or safety-certified for this article. The gates are comparative examples, not validated schedules, product specifications, or purchasing guarantees.

For readers with software and AI experience but little electromechanical practice, a low-energy two-finger gripper mounted on a desk is one comparable starting point: it separates sourcing, assembly, feedback, networking, and fault testing. After that, dexterous-hand research leads to multiple fingers, while household work leads more directly to an arm and wheeled base. A quadruped is a branch for terrain or gait research, not a prerequisite for chores. Household and elder-care uses come later: they require reliable handling in homes and, for care, human safety, privacy, and accountability.

For readers outside robotics, start with the five layers, complete hand workflow, and the later household and care stages. Practitioners can inspect the interfaces and exit criteria. Here, proficient means being able to specify a task, integrate layers, measure failures, revise the design, and state which safety work remains. It does not mean knowing one framework.

What the layers actually mean

A robot is a sense, decide, act, verify loop. A camera sees a cup, software estimates its pose, a controller asks joints to move, motors act, and encoders report what happened. When reality differs from the plan, the machine must stop or recover rather than trust the original image.

An arm positions a tool; a gripper is a simple grasping tool at its end; a dexterous hand coordinates several contacts. A wheeled mobile robot focuses on localization and obstacle avoidance; a quadruped must also balance while contacts change. The mathematics overlap, but the risks differ. The authors' Modern Robotics textbook resources separate kinematics, dynamics, planning, and control.

Comparing starting points and branches

For a solo software developer without an electromechanical lab, a desk-mounted two-finger gripper is a manageable shared starting point; a multi-finger hand fits dexterity research, while an arm better supports desk-based pick and place and later household work. The gripper exposes motors, feedback, force, and slip; the multi-finger hand adds contact and synchronization; the arm adds spatial positioning and collision. Building a custom motor driver, battery pack, dexterous hand, and quadruped together makes faults nearly impossible to isolate.

Reference platforms can reduce unknowns: LEAP Hand V2 for a multi-finger hand, OpenMANIPULATOR-X for an arm and gripper, TurtleBot3 for wheels, and the Unitree ROS 2 project for certain quadrupeds. These are research examples, not purchasing recommendations; verify model-specific support, licenses, repairability, and compatible software before buying.

Solo robotics learning sequence

Finger and gripper

Source, assemble, control one axis, observe, stop

Start on a desk

Multi-finger hand

Calibrate, synchronize, collect grasps, low-voltage adapter PCB

Test each finger

Arm and system

Frames, vision, control, networking, reliability

One task

Mobility

Quadruped or wheeled base, navigation and falls

Choose one

Home and care

Real sites, privacy, safety, human takeover

Use defines standard

The first deliverable for a robot hand

Specify a task before buying parts: place an empty box of known weight and fixed shape in a desk fixture, then have a fixed two-finger gripper repeatedly close on and release it, with nobody reaching into the operating area. Gate B tests grasping, not transport. At gate D, add an arm and only then test lifting the box, moving it a short distance, and putting it down. Independent finger articulation calls for a multi-finger hand. The hand can grasp, but cannot position itself in space. This survey uses four example maturity gates: A, one finger on a fixture; B, two-finger gripper; C, desk-mounted multi-finger hand; D, arm plus hand. Establish a fixed-rule and human-operated baseline before adding AI at each gate.

Sourcing parts and deciding what to buy

Initially choose mature drivers and smart servos, rather than undocumented loose motors and a custom power stage. A bill of materials should state specification, source, and substitutes for each item. Use the LeRobot SO-101 assembly guide for an arm-plus-gripper reference, or the LEAP Hand V2 creators' assembly guide for a multi-finger hand. They are different systems; do not combine their BOMs as if interchangeable.

Create a selection sheet with manufacturer specifications, quote date, lead time, substitutes, warranty, and document quality. A motor's stall figure is not sustained grip force; verify leverage, drivetrain loss, and measured grasping. Estimate simultaneous peak current, wiring, and heat before purchase. Do not pass a live shop price off as a stable project budget. ROBOTIS actuator documentation illustrates modes and feedback; the exact model controls the actual limits.

For Taiwan procurement, an inquiry sheet can copy part numbers and specifications from the creators' SO-101 open BOM or LEAP V2 assembly material, not treat overseas shop links as local stock. Seek itemized quotes from suppliers with warranty terms, 3D-printing services, and power-supply vendors. Record currency, shipping, import charges, delivery time, and returns; maintain a second source for critical servos and connectors. The SO-101 creators distinguish motor-voltage variants and their matching supplies, illustrating why look-alike kits may not share a power setup. This survey obtained no Taiwan quotes and does not invent a total budget.

Choose one build path before ordering

For a desk gripper that may later become an arm, one revision of the SO-101 follower creators' BOM can anchor a quote; verify the complete parts list and power variant first. If components can be ordered separately, buy its specified gripper motor, matching bus adapter and supply, gripper prints and fasteners, plus an additional desk fixture; buy the remaining arm parts only after gates A/B pass. If only a full kit is available, test the gripper portion first. The standalone desk fixture is this survey's proposed adaptation, not a manufacturer assembly step: independently verify travel, tip-over resistance, and harness clearance. Gate C instead gets its own LEAP V2 BOM; assume no parts compatibility. This is a quoteable example; this survey has not verified Taiwan stock or compatible bundles.

The SO-101 follower has five arm joints plus one gripper actuator, six motors in total, appropriate for gate D pick-and-place; it is not a standalone dexterous hand. The current LeRobot SO-101 guide separates follower and leader, motor IDs, bus wiring, and calibration. Lock one revision of the BOM, print files, and guide. New bus servos often share a default ID, so configure them one at a time rather than daisy-chaining all of them first. For LEAP V2, verify the creators' API and licensing notes: OS, supply, serial port, calibration file, and CAD licensing. Permission to use the software does not by itself license commercial use of the CAD.

Each procurement-sheet row should contain purpose, manufacturer part number or CAD revision, quantity, voltage, protocol and connector pinout, dimensions, dated Taiwan quote, lead time, alternative, return and warranty terms, and received serial number. Include a meter, current-limited test supply, calipers, fixture, simple weighing tool, and eye protection. Ask a supplier to confirm that the exact motor, bus adapter, and power supply work together, then check that answer against manufacturer documentation. If the specifications disagree, do not power the assembly.

Estimate the load before trusting a torque advertisement

Specify object dimensions and mass, pad contact area, closing travel, grasp direction, cycles per minute, allowable surface temperature, and where the object goes after loss of power. For an object lifted by friction between two pads, an elementary lower bound on normal force per pad is mass × 9.81 ÷ (2 × friction coefficient). With an illustrative 0.2 kg object and assumed coefficient 0.5, that is about 1.96 N per pad before margin. Actual friction changes with material, dust, and pose; verify it experimentally. Gate B's fixed gripper does not lift the object. Convert required fingertip force to joint torque using lever length, linkage or tendon mechanical advantage, and losses. Stall torque is not continuous torque. Separately budget simultaneous motor peaks, standby draw, wiring, and heat from the exact datasheets. Missing continuous-duty data is a reason to narrow the task or choose a better documented actuator.

Assembly and calibration

Arrange assembly so each error can be reversed: inspect parts → dry fit without power → check free joint motion → assign and record unique actuator IDs one by one → verify zero and direction → route cables away from pinches → power with current limiting → move one finger at a time → finish hand assembly → recalibrate the full hand. Photograph each step and record revisions or abnormal travel instead of discovering duplicate addresses and mirrored joints after final assembly.

A tendon hand additionally needs checks for line wear, slack, pulley jams, and soft-print deformation. The LEAP Hand V2 assembly page documents printed parts, tendons, pulleys, motor IDs, and wiring; its API guide requires open/closed calibration. Manufacturer calibration establishes an initial setup, not safety with every object. Recalibrate after replacing a motor, finger, or tendon, and save the calibration file with the hardware identity.

Use six bring-up records, and do not proceed after a failed gate: (1) count and identify received parts, measure supply-connector polarity; (2) dry-fit, check every joint for jams and trapped wire, photograph zero; (3) connect just one servo, assign an ID and baud rate, label it, reconnect and confirm its identity; (4) command a small unloaded motion and log target versus actual position, current, temperature, and noise; (5) attach a finger, traverse the allowed range slowly and inspect end stops; (6) only then grasp test objects on a fixture where a person can stop the machine immediately. The SO-101 guide likewise configures servos individually before assembly and calibration.

The calibration record needs model, hardware serial, motor IDs, mechanical zero, direction, allowed range, firmware revision, operator, and date. If reported position changes for the same physical pose, inspect mounting, encoder, and calibration revision. If the fingertip reaches the target but cannot hold an object, inspect pad material, tendon tension, and contact geometry instead. The LEAP V2 API stores automatic calibration in CSV and distinguishes lateral-joint from curl commands. Do not raise its protective current cap merely to get a tighter grasp.

The practical first PCB for a hand

Use the manufacturer's servo bus board and standard power hardware for the first revision. The first useful custom PCB is a low-voltage connector or sensor adapter: it fixes connector orientation, polarity, fingertip sensing, test points, and board revision so technicians cannot easily miswire the hand. Do not combine first-time battery protection, power driving, and emergency stop on this board. Start with requirements, block diagram, pin and connector table, and power budget; then make the schematic and layout. KiCad's official guide walks through schematic, ERC, layout, DRC, and fabrication outputs.

Before ordering, manually review connector orientation and pinout, voltage and current ratings, return current and sensing paths, and clearance to moving fingers and enclosure. Inspect the returned boards, test continuity, bring each rail and communication path up under current limiting, verify sensors, and only then attach actuators. ERC and DRC cannot catch wrong parts, solder faults, heat, or mechanical collision. Keep each revision's BOM, fabrication outputs, assembly photos, test report, and known issues.

For a fingertip-sensor and connector adapter, first document which verified module supplies power, the sensor's voltage and analogue/digital/bus interface, anti-misconnection features, and mounting points inside the palm. A pin table must list signal name, direction, voltage range, maximum current, wire color, other endpoint, and consequence of reversed wiring. Expose power, ground, and important signal test points and a visible board revision. Keep servo-power routing distinct from sensitive sensor signals; have a competent electrical reviewer check power and protection. Bring up unattached board and continuity → current-limited rail measurements → dummy load and simulated signal → one sensor → whole hand → extended heat and dropout test. Record board identity and measured failures before respinning; a patched prototype is not a validated production design. KiCad's guide is the workflow, while ERC/DRC are checks rather than system-safety proof.

Firmware and the control contract

With smart servos that already contain controllers, the first revision does not require rewriting motor firmware. Start by specifying the host-to-servo command contract. Add your own MCU firmware later if you need a sensing gateway, local limits, or telemetry. Design a testable state machine: no motion before initialization; enable only after calibration; bound every command and its age; enter a controlled safe state on lost link, overcurrent, or abnormal temperature; require explicit recovery. Depending on the mechanism, a safe stop may cut power, hold position, or release slowly. Blindly dropping a held object is not universally safe.

Messages should include joint IDs, units, timestamps, sequence numbers, calibration revision, measured position and current, faults, and timeout behavior. Measure loop period, packet loss, and reboot behavior. Zephyr documentation can guide custom MCU work. Human-risk protection requires an appropriate, risk-assessed hardware layer and cannot depend solely on this application state machine.

Write a one-page testable control contract before burying it in ROS. An illustrative command has joint_id, target_rad, max_speed_rad_s, increasing seq, ttl_ms (remaining lifetime measured at the receiver), and calibration_id. A status message returns measured angle, speed, current, temperature, last command sequence, fault code, and local timestamp. These are proposed fields, not an existing vendor packet. Reject stale, duplicate, out-of-range, or mismatched-calibration commands and log why. After a controller reboot, start disabled and require a person to confirm the pose before enabling. Inject faults: unplug USB/network, kill the host process, obstruct a finger, freeze a sensor reading, restart while holding an object. Record the actual stop behavior and destination of the object. If a smart servo already closes a position loop, do not create a second competing position loop on the host. ros2_control explicitly separates hardware reads, controller updates, and writes when integrating the system.

System operation and networking

The complete loop is human request or teleoperation → camera and encoder measurements → frames and object estimate → bounded motion plan → arm or gripper control → motors and fingers → feedback deciding success, retry, or stop. Without an arm, the task only exists on a fixed desk fixture. Adding an arm brings workspace, collision, load, and moving-harness constraints. MoveIt 2 teaches arm planning, ros2_control structures hardware control interfaces, and LeRobot covers teleoperation and imitation data. They solve different pieces, not an entire household product.

For the first connected system, use a controlled local network. Begin with read-only remote status; make video optional and off by default; require authorization for teleoperation. Remote commands need authentication, roles, expiry, audit logs, and lost-network behavior. They must never bypass local speed or force limits. A firmware updater needs hardware-revision identification, image validation, failed-update tests, and rollback. Zephyr's DFU guide explains one framework, while the product still needs its own transport and management. The NIST IoT capability catalogue lists device identity, configuration, data protection, access, updates, and security-state awareness; these matter especially for cameras and microphones in a home.

Draw the control path as operator interface → task computer → sole command arbiter → local controller and servos → fingers, with status flowing back. A camera or AI suggests objects and actions; the arbiter enforces operating mode, workspace, speed, authority, and expiry. Teleoperation and AI may not command the same joint simultaneously. Losing the network does not always mean "open the hand": that is reasonable for an empty desktop box but dangerous above a person or while holding glass. Risk analysis must choose holding, a safe placement, or human takeover for each application. Network tests must measure time from lost link to local response, rejection of unauthorized or stale actions, behavior after reconnection, and rollback after failed update. Process household images locally when practical and document retention and viewer permissions. NIST's technical catalog gives a concrete security review checklist.

Improving a hand from moving to proficient

Split the task into detect, align, contact, secure, carry, release. Log success, elapsed time, current and temperature, slips, pinches, manual takeovers, and idle power for each part. Fix loose mechanics and calibration drift before tuning rules; compare AI only after that. Hold out objects, lighting, desk positions, operators, and dates when evaluating a dataset. Testing only on the cup used for training inflates the result. LeRobot's real-robot workflow can guide data collection, but deployed policies still need bounded commands, monitoring, and human takeover.

One testable description of a proficient robot hand is that a new object or lighting condition comes with an explained success rate, failure modes, and fallback; a changed motor or PCB can be recalibrated and retested from documentation. This is not a promised numerical success threshold. A hand that still fails frequently in its fixed scene should not be mounted on a quadruped or used beside an older person.

Use a development test plan, not a certification claim: three specified objects (rigid box, a box with a different surface, slippery empty container), first at a fixed pose and then under changed position and lighting. For every attempt, log object ID, starting pose, controller and calibration revisions, grasp, slip, completion time, peak current and temperature, and reason for any intervention. The success-rate denominator is all attempts; do not discard failure videos. Hold out unseen objects rather than testing on the training set. Compare pad material, travel, and rules-based control before adding vision or imitation learning. If AI raises apparent success but also increases intervention time, it may have no operational benefit.

Debug in a fixed order: no movement suggests supply, connector, ID, enable state, or fault; wrong direction or end-stop impact suggests zero, units, sign, or software limit; moves unloaded but fails on contact suggests friction, lever, tendon, or current cap; intermittent dropout suggests cable flex, supply sag, port identity, or command age; degrades with use suggests heat, looseness, wear, or calibration drift. Change one variable at a time and rerun previous tests.

From program to motor and back

The complete machine needs a high-level computer, low-level controller, motor driver, sensors, power, and mechanics. A laptop or single-board computer handles vision, maps, and tasks. A microcontroller handles periodic work near the motors. The high-level system sends goals; the low-level system enforces permitted behavior and enters a designed safe state on communication loss or invalid feedback.

Commands down, evidence up

Task and AI

Select a bounded goal

ROS 2 and control

Frames, plans, state machines, hardware interfaces

Firmware and drivers

Periodic sensing, command limits, fault reports

Mechanism and world

Motors act; sensors report the outcome

ROS 2 documentation introduces nodes, topics, services, actions, and quality-of-service concepts. ros2_control connects controllers to hardware interfaces. Neither automatically makes a motor safe. Speed, torque, joint, collision, and timeout limits require machine-specific design and tests.

Stage one learn on a computer

Learn enough Python, C or C++, Git, Linux, tests, and data logging to reproduce a result. You need not finish an entire graduate mathematics syllabus first, but you should understand vectors, angles, coordinate frames, and error as target minus observation. Forward kinematics computes a hand pose from joint angles; inverse kinematics seeks joint angles for a desired pose; feedback control repeatedly corrects measured error. Use Modern Robotics as a deeper reference.

The first deliverable is a fixed task in a simulator such as the one described in the Gazebo–ROS 2 integration guide: align a gripper with one object on a desk, grasp, and release it, recording frames, contact, slip, and failures. Repeat the same setup at least ten times and report successes and failures. Ten runs are an introductory exercise I propose, not an industry safety threshold. Confirm simulator, ROS, package, and robot-model compatibility first.

Stage two one motor and firmware

The next deliverable is a low-energy finger securely mounted on a test fixture using a mature driver module. Read position and current first, then add bounded position or speed commands. Test communication loss, blocked travel, bad sensor values, and power restart. Record the expected safe state and actual result each time. Do not attach unvalidated control software to a machine that can pinch someone or fall.

Firmware work introduces GPIO, PWM, encoders, ADC, I²C, SPI, and CAN, while distinguishing periodic control from irregular logging or networking. An RTOS is optional at first; use one when concurrency and timing requirements justify it. Zephyr's getting-started guide covers building and flashing samples, and its test framework supports unit and integration tests. Measure actual loop periods, worst observed delays, reboot behavior, and communication timeouts. An RTOS label is not proof of real-time behavior.

Write the cross-layer contract down: command units, direction, limits, timestamp, sequence number, report rate, error codes, and which layer stops motion on a lost link. Undocumented assumptions become integration bugs.

Stage three extend the hand into different robots

For the mobile branch, establish odometry and coordinate frames before mapping, localization, and navigation. The Nav2 first-time setup guide covers TF, URDF, odometry, sensors, footprint, and controller setup. TurtleBot3 simulation provides a reference. Begin with teleoperation and a working stop, then test autonomous commands at low speed.

For the arm and gripper branch, establish joint zero, joint limits, tool frames, collision zones, and slip behavior before adding vision. MoveIt 2 tutorials cover arm planning; OpenMANIPULATOR-X documentation is a simpler hardware reference. Grasping a box with a gripper is not dexterous manipulation of keys or flexible objects.

For the dexterous hand branch, the creators' LEAP Hand V2 API illustrates the assembly, calibration, software, and maintenance involved. Evaluate grasp success, jams, and joint error over changing object sizes, placements, and grasps. This is a sensible later project, after arm, gripper, and single-axis work.

For the quadruped branch, learn center of mass, joints, foot contacts, and gait in simulation. Then use a supported, high-level interface for state monitoring, slow tasks, and safe exit. Compare the Unitree ROS 2 interface with the Open Dynamic Robot Initiative's Solo hardware: one is an interface to specific commercial platforms; the other exposes research-oriented custom hardware. Neither removes mechanical, fall, or power risk. Keep unvalidated AI outputs away from direct joint control until low-level limits and protection are independently verified.

What AI can improve, and what to measure

This survey compares AI in development assistance, perception, task selection, and learned control. An assistant can summarize manuals, draft tests, and inspect logs; a human still checks pins, ratings, and physical behavior. Perception can locate objects or obstacles but needs lighting and occlusion tests. Task selection should issue only bounded goals. Learned gait or grasping may handle complex behavior but introduces a simulation-to-reality gap.

The LeRobot official guide covers teleoperation, demonstration collection, training, and evaluation; Isaac Lab provides robot-learning simulation tools. A model succeeding in training conditions does not establish performance on new objects, floors, or lighting. Compare it with a fixed-rule or human-operated baseline using held-out scenes and different sessions. Report task success, collisions or drops, takeover count, completion time, and energy. A vision-language model should not be the sole time-critical motor feedback controller.

The best solo AI project may be narrow: camera-aided gripper positioning, log analysis of localization drift, simulated failure-case generation, or operator-facing anomaly summaries. Each needs a no-AI baseline, a test set, and a fallback.

System integration requires visible failures

Start with a one-page requirements sheet: task, operating site, people nearby, speed, load, power, endurance, stop mechanism, and who repairs it. Maintain one agreed source of truth for frames, electrical and mechanical interfaces, communication messages, and versions. Every test should record software, firmware, PCB revision, calibration, scene, and outcome.

Before selecting actuators or batteries, estimate continuous and brief loads, required joint torque, startup and stall current, peak power on each rail, usable battery energy, heat, and harness capacity, then revise the estimates with manufacturer specifications and measurements. Electrical watts and mechanical torque are different quantities. A short peak is not the same as sustained thermal performance. ROBOTIS DYNAMIXEL-X documentation shows that even one actuator family has different modes, feedback, and ratings; use the exact model's specification.

The integration ladder is desktop simulation → unit tests → hardware-in-the-loop with no unrestricted motor output → single actuator → speed-limited robot → repeated task → disturbance and fault tests. Hardware-in-the-loop connects a real controller to a simulation or restricted load to examine interface and timing. Unexplained motion, failure to stop on link loss, overheating, or pinch hazards send the design back a stage.

This is not a formal product-safety certification. Industrial or human-shared environments require a qualified risk assessment and applicable standards. ISO 10218-1:2025 addresses industrial robots; the ISO robotics catalogue lists ISO 10218-2:2025 for applications and cells. Service robot classifications differ. A learning project is not evidence of compliance.

When to design a PCB

A printed circuit board makes a verified circuit and its connections repeatable. Begin with manufacturer controllers, development boards, mature motor drivers, and dependable harnesses. A custom board becomes justified when miswiring, loose connectors, size, or repair labor is an observed problem. Do not invent the first motor-drive algorithm and first PCB at the same time.

The full sequence is requirements and power budget → block diagram and interface table → schematic → part and footprint checks → ERC → layout, return-path and thermal review → DRC → manufacturing outputs and bill of materials → board inspection → current-limited power-up → section-by-section test → robot regression test. KiCad's official guide teaches schematic, ERC, layout, DRC, and fabrication in that order. ERC and DRC catch some errors; they cannot prove a circuit works or a robot is safe.

For a first board, choose a low-voltage sensor or connector adapter, intended to reduce wiring mistakes, rather than a high-power motor driver or battery protection board. Mark revision, connector orientation, test points, and polarity. Check shorts, rails, and communication before connecting valuable sensors or actuators. Battery, higher-current, or human-risk designs warrant review by an experienced electrical engineer.

A twelve-week example, not a promise

This is an illustrative schedule for someone who already writes code and can devote several hours a week. Extend any step as needed; evidence matters more than a date.

From there, proficiency branches: mobile robotics deepens localization and navigation; manipulation deepens kinematics, contact, and grasping; quadrupeds deepen state estimation, dynamics, and gait; firmware deepens drivers and fault handling; hardware deepens power, signal integrity, manufacturing, and reliability. One person need not master all five, but must understand adjacent interfaces and know when to request expert review.

Here is a stronger definition of proficiency by deliverable, proposed for learning rather than as a credential or safety standard.

Each gate should leave a minimal reproducible project, a test report, failure video or log, and a list of environments where the machine is not yet ready. Taking one task from specification to repeatable acceptance is more convincing than running ten unrelated demos.

Second destination what a quadruped adds

The hand's challenge is contacting and applying force to an object; a quadruped's is keeping its body stable while feet alternately contact the ground. Hand experience with control, calibration, logging, PCB, and networking transfers, but leg mechanics, dynamics, state estimation, and fall protection are new. A quadruped alone cannot pick things up. Mounting an arm and hand adds mass, shifts the center of gravity, and changes collision risk. Therefore four legs are not a mandatory next step toward household chores. Stairs or uneven terrain may justify them over wheels; that is a use-case inference to test in a real home.

Build a toy dog first: stand, take a few steps, stop

Do not start with an autonomous patrol dog. The minimum artifact starts from a rest pose on a cleared level floor, stands on one command, takes a few slow steps, stops, and returns to rest. Also interrupt the command source once to prove it will not walk indefinitely. A prerecorded gait is acceptable; dynamic balance, stairs, and AI recognition are outside this gate. For a first quadruped, one revision of the Petoi Bittle X V2 construction kit and assembly guide offers a documented kit case. Its official inventory lists body and four legs, 10 servos with different cable lengths, BiBoard V1, battery, USB cable, and fasteners. Do not mix legacy Bittle/NyBoard wiring or firmware with V2. The current OpenCatESP32 repository is for BiBoard-family hardware; verify board and servo revisions before ordering.

The V2 calibration guide warns that servo angles may be unknown before calibration; a construction kit should enter zero before final leg fastening, with center screws installed afterward. The boot guide recommends a calibration stand because automatic righting can move the robot unexpectedly. This is a toy dog assembled from a documented platform, not a new quadruped actuator and gait design. Once it repeats reliably, body-shell experiments must still respect pinout, mass, and center of gravity; changing motor, battery, or controller requires renewed power and calibration tests.

An eight-leg-joint DIY alternative needs four two-joint legs, eight documented low-voltage servos, a compatible controller or PWM board, a separate servo supply, body, harness, switch, and stand. Test one leg, a mirrored pair, all four while suspended, and only then on the floor. Never power eight servos from a microcontroller's 5 V pin. Adafruit's PCA9685 wiring guide separates logic from servo supply and explains the current bursts from multiple servos. Select a complete CAD and pin-map revision and measure current before taking this DIY route; the documented kit is the more reproducible first toy.

The toy-dog finish line is repeatable stand, walk, stop, and recalibration; Q0–Q4 below are not prerequisites. They are the next checklist for studying custom hardware, payload, and gait. Assembling a walking toy does not establish full quadruped engineering competence.

A lower-risk solo research path uses a simulated quadruped and a supported high-level SDK, beginning with telemetry, navigation, or inspection rather than a custom load-bearing motor board. The Unitree ROS 2 interface and SDK2 are commercial-platform references; the Open Dynamic Robot Initiative's Solo hardware exposes research-oriented actuators and mechanics. Hardware versions, control privileges, and safety modes differ. Do not run code across platforms by assumption, and do not let high- and low-level controllers compete without understanding arbitration.

For a custom quadruped, derive the BOM from terrain, total mass, desired runtime, and repair capacity: compatible actuators and gearing, four leg assemblies, foot pads, IMU, encoders, computer, mature drivers and distribution, battery management, harnesses, and guards. Assemble and measure one joint and one leg before measuring the supported machine. Unlike a desk-mounted hand, a quadruped can fall because of center-of-mass error, a reversed joint, or one missing leg message. Start any custom PCB as a low-voltage sensor or connector board; distribution and motor-power boards need separate electrical, thermal, and protection review. Firmware should first record posture and joint state and enter a tested lost-link state before gait work. Start networking with read-only telemetry, then allow bounded remote commands only in a controlled site. Optimize falls, slip, joint temperature, energy, and human intervention across surfaces, not only speed.

If building toward a whole quadruped, use gates

The ODRI Solo12 hardware repository exposes mechanics, electronics, fixtures, and calibration and shows how much work a full quadruped represents. Unitree's MuJoCo project offers an example of sim-to-hardware interfaces. Neither establishes safe floor operation by itself. State estimation must distinguish joint positions, IMU body orientation, and actual foot contact: a foot believed to support weight may instead be slipping. Start with supported high-level standing and walking control. Low-level joint torque and gain experiments need a fall-safe facility and qualified collaborators. If the goal is indoor chores, Q0–Q1 can remain a research branch; a wheeled mobile manipulator is the more direct main path.

Third destination an actually useful robot

For indoor object retrieval and delivery, a slow wheeled base with one arm and gripper is an early testable configuration; two arms, dexterous fingers, and bipedal locomotion require separate task and site justification. The bottleneck is often reach it, see it, grasp it, place it, recover from failure. Wheels still struggle with steps, carpets, and narrow halls. Quadrupeds may handle some terrain but bring payload, runtime, noise, and fall tradeoffs. Humanoids may fit human-height tools while adding biped balance and more complex safety. These are system-engineering inferences, not universal product rankings.

First build a toy wheeled robot: follow a line, detect an obstacle, stop

The easiest mobile robot to verify is a two-wheel differential-drive rover. Its initial job is to follow a black line on a white floor, stop on a front obstacle or lost line, and restart only after a button press. It needs no ROS 2, SLAM, AI, or custom PCB. A reproducible kit path is the slower Pololu 3pi+ 2040 Turtle edition and manufacturer's assembly manual: motor drivers, two motors and encoders, five downward reflectance sensors, front bump sensing, and a controller belong to one supported platform. The manufacturer describes Turtle as easier to control for introductory use. Distinguish the assembled version from the kit, which requires assembly and soldering. The guide also specifies four AAA cells and a USB-C data cable. This is a technical example, not a verified Taiwan price or inventory claim.

The 3pi+ 2040 guide provides motor_test.py, line following, and front-bump examples. Understand one example, slow it down, then add explicit stop conditions before trying new algorithms. If designing from parts, source a two-wheel chassis, matched geared motors and wheels, caster, dual motor driver, MCU, line sensors, bumper, battery holder, switch, and harness; add encoders to compare wheel speeds. A carrier such as the Pololu TB6612FNG board has specific voltage and continuous-current ratings: compare them against the selected motors' running and stall currents. Mechanical fit alone does not establish electrical compatibility. For a first rover, the documented kit makes faults easier to isolate because power, mechanics, and control do not all change at once.

If “robot” means a human-shaped toy

The open Otto DIY design lists an Arduino Nano, four micro servos, ultrasonic sensor, battery holder, and printed body and legs. Its first tasks are calibrated standing, stepping, turning, and obstacle response. This is a four-servo biped toy without grasping hands, not evidence of care-safe human contact. The maker says it no longer produces the original DIY kits; source parts against one revision of the open design instead of assuming a current boxed kit. If the main aim is household work, the two-wheel rover teaches a more directly reusable mobility stack.

An Otto build has a short sequence: choose one STL and wiring revision → center all four servos on the desk before attaching horns and feet → mount Nano, battery, and ultrasonic sensor → run the creators' standing, slow-walk, and turn examples → add a short-range object stop. The official calibration guide stresses centering before fastening the horns. Uneven legs call for checking that step before increasing stride.

Once R4 works, give the toy rover a light tray and deliver an object along a fixed route. Do not mount an SO-101 arm on the tiny 3pi+ base: its payload and tip-over behavior were not designed for that. For autonomous grasping, choose a mobile-manipulator base with documented payload, power, and mounts, then integrate the hand's gate D. AI can help classify line-following failures; camera output may suggest go or stop, but local firmware still enforces an independent stop condition.

The integration sequence is fixed desk hand → fixed arm pick-and-place → mobile base carrying objects → base and arm working together → long multi-room task. Each new capability requires revisiting power, center of mass, stopping distance, sight lines, harness, collision zones, and lost-link behavior. The Nav2 setup guide covers basic wheeled navigation; MoveIt 2 addresses arm planning. Bringing them together also needs consistent frames, scheduling, and a safety state machine. Networking supports human-machine coordination; it does not replace local control.

For a wheeled mobile manipulator, buy a base and arm with obtainable repair documentation, then check mount, gross mass, power, and camera sight lines. Separately accept the base's braking and the arm's fixed-workspace grasp before attaching them. The first PCB can still be a signal or harness adapter. Record base and arm firmware revisions, message units, and timestamps in one interface table. The task state machine must reach a comprehensible, human-recoverable state after localization loss, dropped objects, low battery, or network loss. Move optimization from one successful demo to tasks completed per hour, minutes of human assistance, damage, and repair cost to judge whether it beats manual work or a dedicated appliance.

An integrated mobile manipulator is more than an arm bolted to a base

The LeRobot LeKiwi assembly guide, for example, separates an SO-100/101 arm, three-wheel base, onboard computer, motor IDs, calibration, and teleoperation. It is a research reference, not a home product validated by this survey. Before integration, define ownership: the base controller handles wheel speed and local stop; the arm controller enforces joint limits; the task computer owns maps and grasp sequence; the operator interface provides takeover. Shared power may sag during startup or simultaneous motion; measure the combined peaks and preserve protection by subsystem.

Accept the machine in this order: empty-base teleoperation and stop → odometry and localization → known-obstacle avoidance → parked arm pick-and-place → carrying an object → long-task recovery. Nav2's initial setup guide covers frames, odometry, sensors, footprint, and costmaps. MoveIt Task Constructor decomposes approach, grasp, retreat, and place. At their boundary, object and base poses need consistent frames and time references. If parking error leaves the object beyond reach, relocalize or request takeover rather than stretching the arm blindly.

A plausible route to household chores

Public research shows some household subtasks working under bounded conditions. It does not prove arbitrary chores in arbitrary homes are reliable products. The original Stanford BEHAVIOR-1K paper frames 1,000 everyday activities in simulation and identifies long-horizon, multi-step physical interaction as difficult. The creators' Mobile ALOHA project demonstrates task-specific mobile dual-arm imitation learning. The original Dobb-E research studies short demonstrations for specified tasks in multiple homes. Study sites, task definitions, and human intervention are different from product uptime.

A narrow assistive task is more testable as a prototype or pilot than a general robot butler, which the available evidence does not support. Full cost includes hardware, site mapping, home modification, consumables, cleaning, service visits, remote help, and insurance; inference cost alone is misleading. If a person must reset or reteach the robot constantly, its practical value may be small.

Work through one household job: move a closed empty bottle to a specified tray

The first trial runs only on one flat floor, in daylight, with fixed object and tray locations and no pets in the work zone. Begin with a stationary arm grasping and placing; then get the base to park at the desk; finally link the full state sequence: confirm target → navigate to marked pose → park → observe again → grasp → verify no slip → travel to tray → place and verify visually. At uncertain steps, stop, observe again, or ask a person; do not count an unverified guess as completion. Separate navigation, object identification, grasp, transport drop, placement, and human-help minutes in the log so the next change targets the actual bottleneck.

Expand one difficulty at a time: new object and light → changed room and furniture → thresholds, bystanders, and pets → fragile, wet, or deformable objects. Laundry adds fabric deformation; dishwashing adds water, hygiene, breakage, and electrical separation. Success with an empty bottle cannot support a claim to general housekeeping. BEHAVIOR-1K identifies long-horizon complex manipulation as a research challenge, while Mobile ALOHA reports specified tasks trained with demonstrations. These sources suggest research directions, not a product success rate across homes.

Use each accepted completed task as the cost denominator: include depreciation, consumables, cleaning, electricity, support, visits, remote takeovers, insurance, and site setup. Measure the family's original task time and whether preparing the home for the robot adds work. If a one-minute chore requires five minutes of setup and frequent rescue, change the use case or stop; a larger AI model cannot repair a mismatched need.

A plausible route to elder-care assistance

Care is not merely chores plus reminders. Users may have mobility, sensory, or cognitive limitations, while carers, family, and clinicians share the workflow. The WHO assistive-technology overview frames tools as support for function and independence; a WHO long-term-care report notes limited evidence of robotic-care impact and risks to privacy and autonomy. By contact risk and evidence requirements, the progression examined here is reduce non-contact work for caregivers first, then consent-based retrieval and delivery, and only much later investigate physical assistance to the person.

ISO 13482:2014 covers certain personal-care robots. A declared rehabilitation, assessment, or movement-impairment purpose may enter a different medical-robot domain such as IEC 80601-2-78; applicability depends on intended use and qualified review. In Taiwan, TFDA's medical-device introduction explains why intended purpose matters and offers an attribute-classification inquiry where uncertain. The Ministry of Health and Welfare has a reviewed smart-assistive-device rental mechanism, but a homemade robot is not automatically approved for reimbursement or sale.

A plausible long-term product hypothesis starts with home-care teams, occupational therapists, older users, and families choosing one frequent task without body contact. Compare against human service, measuring caregiver time, mistakes, user acceptance, and repair burden. Only after repeatable benefit should it extend to low-contact retrieval. Fall risk, medication errors, delayed help, and private video demand stronger risk review and human takeover. AI can assist recognition, scheduling, and summaries; it cannot take over care accountability.

Start care research by reducing caregiver travel, not by lifting people or dispensing medication

One candidate task in a fixed space is to place a light, nonmedical, unbreakable object on a reachable table after caregiver confirmation and older-user consent, for the person to pick up. If the path blocks, localization fails, consent is withdrawn, or the object drops, the robot stops and notifies the caregiver. It does not push an object into a hand, deliver medication, substitute for emergency response, or use a camera to declare someone safe. Compare caregiver travel and time saved with cleaning, upkeep, wrong/missed deliveries, and whether the older person can easily refuse or switch it off—not a single successful video.

For each function, write a five-column failure → harm → detection → fallback → reviewer risk record. An assistive walker blocking the route might lead the robot to obstruct a corridor; distance sensing, timeout and stop, caregiver notification, and site testing by care and robot-safety experts are needed. Accidental video sharing calls for minimum access, off-by-default recording, access logs, deletion, and user control. Body support, transfer, rehabilitation, feeding, or medical claims require clinical, occupational-therapy, human-factors, regulatory, and safety review before a deployment plan. In Taiwan, TFDA considers intended purpose and accepts classification inquiries when uncertain. ISO 13482:2014 is a personal-care-robot reference, while ISO had published a final draft of a broader service-robot safety revision in 2026. Check the actually published and applicable edition before product work; a draft is not certification.

Current evidence and unresolved decisions

This survey has no Taiwan quote, tested site, or validated schedule for a specific first-hand BOM, nor measured evidence for any chosen platform's power, version compatibility, parts supply, or site requirements. Household and care functions have not been field-tested for this article. Those choices need model-specific, user, and physical evidence; an AI search alone cannot settle them.

Findings and evidence still needed

Choose one repeatable grasp task; establish a no-AI baseline; prove the single-finger and link-loss stop; treat hands, arms, quadrupeds, household tasks, and care as different milestones; let a PCB solve a measured wiring or manufacturing problem. A reader starting practical work can use a hardware-free hand simulation and BOM quote exercise to obtain repeatable runs, failure analysis, and actual prices before choosing a platform.

Primary references checked for this survey include Modern Robotics, ROS 2, Gazebo, ros2_control, Nav2, MoveIt 2, Zephyr, KiCad, LeRobot, Isaac Lab, and the platform documents linked above. Checked October 3, 2026; recheck package and hardware versions before building.