Microduck hardware: from body to behavior
What physical systems let this robot sense, compute, and move? Start with the body, then trace how sensing and motor commands connect through the onboard computer.
Introductory reading · no hardware operation or training required · sources reviewed 12 September 2026
1 · Body and joints: what can move?
Microduck is a small biped: two articulated legs support a torso, neck, head, and grasping beak. The official product is about 25 cm tall and under 800 g. A joint is a connection that permits relative motion between two parts.
Why structure matters: rotating a hip moves everything attached below it, while moving the head changes the distribution of weight. A walking controller must coordinate these connected motions; commanding each motor independently is not enough.
In the simulation source, STL meshes describe shapes and MJCF XML files describe the articulated model, including joints and physical properties. These are useful for studying the robot, but are not a released manufacturing bill of materials or complete production CAD package.
From a joint angle to a foot position
A rigid link is a part whose shape is treated as fixed. A joint specifies how one link can move relative to another. A revolute joint permits rotation about an axis. Its angle is meaningful only after specifying that axis, the positive direction, and the pose called zero. A mesh alone supplies none of this movement information.
Consider a deliberately simplified leg: one rigid link, 10 cm long, rotating about a hip. If the link starts vertically downward and rotates forward by 30 degrees, the foot moves 10 × sin(30°) = 5 cm forward. Its vertical distance below the hip becomes 10 × cos(30°), about 8.66 cm. The foot rises about 1.34 cm. These are teaching dimensions, not Microduck measurements. The example shows why rotating a joint changes both forward position and height.
A real leg has several joints, so each rotation changes the coordinate frame used by the next link. Forward kinematics means calculating the resulting foot position from all those joint angles. Dynamics asks a different question: what motion results when gravity, motor forces, inertia, and contact act on those links? A geometrically reachable pose is not automatically a balanced or physically achievable motion.
When standing almost still, the location of the centre of mass—the mass-weighted average position of the body—relative to the supporting feet is important for balance. During walking, momentum and changing contacts also matter. This is why an attractive animation of alternating legs does not demonstrate a successful walking controller.
In a robot XML, inspect body nesting, joint axis, joint range, and inertial properties separately from mesh references. Then open the default joint positions in the runtime model. Do not assume that a visual part corresponds one-to-one with a motor.
Official hardware specifications · Explore robot XML and mesh files · Read joint identities and home positions
Check your understanding
Open a robot XML file. Find a body nested inside another body. Which parts would move if the parent joint rotated?
Read the explanation
The child link and its descendants move with the parent rotation. In a loaded leg, the motor must also resist gravity and accelerate attached mass. Geometry predicts where the foot could be; dynamics and contact determine whether it can get there without falling.
2 · Motors and the shared bus: how does a command become movement?
A servo combines a motor with position feedback and local control. The runtime documents Dynamixel XL330 servos connected through one serial communication bus. The robot controller sends target positions and reads measured motor state through that bus.
The product has 15 motors, but the movement policy outputs 14 joint targets. The mouth is excluded from that policy interface and occupies a separate motor slot in the runtime. Do not confuse the number of learned outputs with the number of physical motors.
Why it matters: a target position is a request, not an instant physical motion. Available torque, friction, load, and communication timing affect the result. The simulator therefore needs an actuator model, not just a moving drawing.
Two control loops, not one
The onboard policy and the servo controller solve different problems. The policy coordinates the body and chooses joint targets. The servo controller compares its requested position with its measured position and drives its motor to reduce that difference. Position feedback closes this faster local loop; it does not remove physical limits.
For a toy proportional controller, suppose the target is 0.20 radians and the measured position is 0.15 radians. The position error is 0.05 radians. A hypothetical gain of 2 newton-metres per radian would request 0.10 newton-metres of torque. This arithmetic explains feedback; it is not the XL330 firmware law or a recommended gain. The actual actuator model includes electrical and friction effects.
A serial bus carries messages sequentially. Each device needs an identity so the controller can associate a reply with the correct joint. Reading many devices together reduces communication overhead, but does not make their physical responses instantaneous. A stale reply, wrong identity, or unexpected delay can corrupt the control loop even if the neural network itself is correct.
More aggressive feedback can reduce position error, but may also increase oscillation, current demand, and sensitivity to delay. More realistic actuator simulation costs implementation effort, but helps prevent a policy from relying on forces the real motors cannot produce. Neither higher gain nor a larger neural network is a universal remedy.
Read the joint names and device identities in duck-control’s model module, then find how bus reads are grouped. Follow the motor-target mapping back to the policy output, paying special attention to the skipped mouth slot.
Read the motor-bus and policy-interface design · Inspect serial-bus implementation · Inspect simulated actuators · Read joint identities and home positions
Check your understanding
Why might two identical position commands produce different motion when one leg is supporting the robot’s weight?
Read the explanation
The supporting leg has a different external load. The same target can require more torque, produce slower movement, or remain unreachable under that load. Measured position and motor condition are therefore necessary evidence, not optional diagnostics.
3 · Sensors: what can the robot observe?
An inertial measurement unit (IMU) measures motion quantities such as angular velocity and acceleration. The product lists two IMUs, a camera, and an 8 × 8 time-of-flight range sensor. Time-of-flight sensing estimates distance from reflected light travel time.
Joint feedback and inertial measurements support balance and movement control. Camera images and range measurements support different perception tasks. Having a camera does not mean every walking policy uses images: the documented movement-policy input contains inertial and joint information plus commands, not camera pixels.
Why it matters: before designing an intelligent behavior, identify which observations actually reach the policy. A sensor elsewhere on the robot cannot help a model unless software supplies its information.
An observation is a measurement with a frame and a time
A gyroscope measures angular velocity: how quickly the sensor rotates about its axes. An accelerometer measures specific force, not a direct angle and not pure linear acceleration with gravity already removed. Estimating orientation from inertial measurements requires conventions and processing. The policy uses a projected-gravity vector: the gravity direction expressed in the robot’s body coordinates.
Imagine tilting the robot forward without moving its joints. Joint encoders would report almost the same angles, but projected gravity would change. Now imagine bending a knee while holding the torso orientation fixed. Joint angles change even when projected gravity hardly does. These two sensor groups answer complementary questions about body orientation and internal configuration.
Suppose a gyroscope reports 1 radian per second for 20 milliseconds. If that rate stays constant, the orientation changes by 1 × 0.020 = 0.020 radians, about 1.15 degrees. This short-interval calculation is useful, but repeatedly integrating a biased measurement accumulates orientation error. A missing or stale measurement can therefore be more consequential than a small amount of random noise.
Frames must also agree. “Forward” may mean forward relative to the robot’s torso or along a fixed direction in the room. After the robot turns, those directions differ. A plot of body-forward speed can look correct while the world trajectory curves; evaluating straight walking requires both kinds of information.
Open obs.rs and identify gyro, projected gravity, joint positions, joint velocities, previous actions, and commands. Read imu.rs for the transformation into the torso frame. Note which sensor streams are absent from that policy input.
Official hardware specifications · Inspect IMU processing · Inspect policy observations · Explore range-sensor software
Check your understanding
Find the observation vector in the source. Can the walking policy see an obstacle just because the robot has a camera?
Read the explanation
No. A camera is useful only if its information reaches a controller that can act on it. The documented locomotion policy is not a general visual navigation model; obstacle avoidance needs additional perception and decision logic.
4 · Onboard computing: where does the policy run?
The official specification lists a Rockchip RK3566 processor, 1 GB of memory, and 32 GB of storage. This onboard computer runs the robot software and evaluates a saved policy during operation.
Training and operation are different jobs. Training repeatedly changes model parameters using simulated experience, typically on a separate GPU machine. Onboard inference uses the resulting parameters to choose an action. The documented control loop targets 50 updates per second—one cycle every 20 milliseconds.
Why it matters: a large training server can make learning faster, but the deployed model must fit the robot’s memory and timing budget.
A twenty-millisecond budget
A 50 Hz loop has 1 ÷ 50 seconds, or 20 milliseconds, between intended updates. That interval must accommodate sensor acquisition, policy computation, safety processing, and output work. Some operations may overlap, but their dependency order and worst delays still matter.
For an illustrative budget, suppose reading sensors takes 5 ms, preparing observations takes 1 ms, model inference takes 4 ms, safety and target processing take 1 ms, and communication takes 3 ms. The total is 14 ms, leaving 6 ms of margin. These are invented teaching numbers, not measured Microduck timings. If a camera operation occasionally adds 15 ms on the same blocking path, that cycle takes 29 ms and misses its intended interval.
Average speed can hide this problem. A loop averaging 14 ms can still produce occasional long pauses. For control, record both normal timing and the slowest or unusually slow cycles. A responsive-looking interface is not a measurement of motor-update timing.
Training throughput asks how much simulated experience a server can process per second. Inference latency asks how long one policy decision takes on the robot. A design that improves one need not improve the other. Keep camera processing, remote communication, and model training conceptually separate from the motor-control deadline.
Follow the timing and control orchestration in robotd, then inspect where the ONNX model is loaded and invoked. Distinguish initialization work from work repeated on every control cycle.
Official hardware specifications · Follow the onboard control loop · See how policy inference is implemented
Check your understanding
If one policy evaluation takes longer than 20 milliseconds, what happens to a loop intended to run 50 times per second?
Read the explanation
The loop cannot maintain 50 timely decisions per second if each decision alone exceeds 20 ms. It must run late, skip work, or use another scheduling strategy. The correct diagnosis comes from measured timing, not processor specifications alone.
5 · Power and interfaces: what supports the rest of the system?
The product specification lists a removable NP-F550 battery, Wi-Fi, Bluetooth, microphones, a speaker, and NFC interfaces. These support power, communication, interaction, and identification; they are not all inputs to locomotion learning.
Battery condition affects motor behavior. The runtime reads voltage and temperature, while the training code models actuator effects including battery-voltage variation. A robot may execute the same policy differently when physical conditions change.
This page is a system overview, not a wiring or repair guide. Follow official operating instructions for the actual hardware revision.
Energy, peak demand, and reproducible motion
Battery capacity describes stored charge; it does not directly specify the peak torque available at every joint. Electrical energy also depends on voltage. Power is the rate of energy use. A controller can demand a brief high-current movement even when the average energy use seems modest.
As a generic example, a battery with 20 watt-hours of usable energy powering a steady 10-watt load would last about 2 hours: 20 ÷ 10 = 2. Neither value is a Microduck measurement. Real runtime depends on usable capacity, conversion losses, compute load, and how much work the motors do. This is why a single advertised runtime is not a guarantee for every behavior.
During a demanding movement, voltage can fall under load. The resulting motor response may differ from a lightly loaded bench test. Domain randomization addresses part of this problem by varying physical parameters during training, so the policy does not see just one idealized condition. It cannot compensate for arbitrary electrical faults or unsafe operation.
Record the operating condition alongside the policy version when investigating inconsistent motion. Distinguish a depleted battery, a hot motor, a communication failure, and an incorrect model input before changing rewards. This chapter intentionally provides no wiring or battery-modification procedure.
Read the runtime safety checks and the actuator configuration’s voltage-related parameters. Compare the purpose of a runtime protection with the purpose of varying a parameter during training.
Official hardware specifications · Inspect control safety checks · Read official operation and health commands
Check your understanding
Why should low battery be considered a physical operating condition rather than automatically diagnosed as a software failure?
Read the explanation
The program may be unchanged while the power available to actuators has changed. A useful diagnosis records voltage and load conditions, then checks whether the software responded appropriately. It does not automatically blame either hardware or software.