Pollen Robotics opened pre-orders for Microduck on August 27, 2026. The 25 cm biped is listed at an introductory $399 before taxes and shipping, but the more consequential part for robotics developers is the software boundary behind the product. Pollen has published one repository for the robot runtime and another for training reinforcement-learning policies in simulation.
Both inspected repositories use the Apache 2.0 license. That gives developers source code they can inspect, modify and retrain. It does not establish that every hardware design artifact is open, nor does it turn Pollen's product demonstrations into independent performance evidence.
What Pollen Robotics has released
The official Microduck product page lists 15 motors, a camera, LiDAR, two inertial measurement units and a 50 Hz onboard policy loop. Pollen says seven trained moves are included, with examples such as walking, sitting and standing, kicking, retrieving an object from the ground, roller skating and recovering after a fall.
Those behaviours are documented product capabilities, not independently reproduced test results. The product page also describes the $399 figure as an introductory pre-order price before taxes and shipping. It does not provide a primary-source shipping date, so Microduck should be treated as a pre-order rather than generally available hardware.
Two repositories handle different parts of the system
The microduck runtime repository contains the software that runs on the robot. Its documentation describes a Rockchip RK3566 system running several Rust services, including a 50 Hz control loop that drives 15 servos from neural policies. Other services handle configuration, Bluetooth, gamepad input, camera streaming and software updates.
The separate microduck_rl repository contains the training environment. It is built around mjlab, MuJoCo Warp and proximal policy optimization. Policies are trained at 50 Hz, exported to ONNX and then loaded by the robot runtime. The repository includes tasks for locomotion, standing, fall recovery, ground interaction and several roller-based movements.
This separation is useful because training and deployment have different constraints. Developers can examine the policy-training process without treating the physical robot as the training environment, while the runtime can focus on sensor input, motor control and safe software delivery.
Why the sim-to-real workflow matters
Reinforcement learning often requires a large number of trial-and-error interactions. Running those trials on physical hardware is slow and can wear out motors or damage a robot. Simulation makes parallel experimentation possible, but it introduces a reality gap: a policy that succeeds in a physics model can fail when it encounters real friction, timing, backlash or sensor noise.
Pollen's training repository tries to narrow that gap with domain randomization, actuator modelling and explicit backlash simulation. Domain randomization changes physical parameters during training so the policy does not depend on one perfectly configured model. The repository also models gear play and exports trained policies into the ONNX format used by the runtime.
This is a documented engineering workflow, not proof that transfer is automatic. New behaviours still require reward design, training, validation and safe physical testing. The current training setup also requires Python 3.12, uv and a CUDA-capable GPU for local training. The repository offers Hugging Face Jobs as a remote alternative.
Open software does not mean every part is open
The inspected runtime and training repositories both carry Apache 2.0 licences, and Pollen describes the SDK, simulation and reinforcement-learning stack as open source. The evidence supports describing the software stack in those repositories as open and permissively licensed. It does not establish that the robot's complete mechanical design, electronics, manufacturing files or every firmware component have been published under the same terms.
That distinction matters when evaluating an open robotics platform. Source access can make behaviour, updates and data paths easier to inspect, but it does not guarantee security or privacy. Microduck includes a camera and other sensors. As TechCrunch noted in its launch coverage, third-party applications can still collect or transmit sensor data depending on how they are built. Operators should inspect application code, permissions and network behaviour before using camera-equipped robots in sensitive spaces.
The launch materials leave important questions open
Pollen's videos and documentation show a set of trained movements, but they do not provide an independent benchmark for reliability, terrain tolerance, battery endurance or the repeatability of sim-to-real transfer. Developers should treat the listed moves as shipped policies documented by the vendor, not as a general measure of robot intelligence.
The published repositories make the implementation inspectable, which is more useful than a closed demonstration. They do not remove the work of calibration, physical validation or safety testing. The training repository itself records practical dependency and hardware constraints, reinforcing that retraining is a developer workflow rather than an automatic consumer feature.
Why developers should watch Microduck
Microduck presents a relatively legible path from a public simulation environment to an on-device control runtime. That can make it useful as a reference for developers studying reinforcement learning, robot control and the operational boundary between training and deployment.
The next evidence to watch is practical: stable software releases, reproducible community-trained policies, clearer hardware documentation and results from independent users. Until then, the strongest claim is narrow but meaningful. Pollen has published substantial runtime and training code around a pre-order robot, giving developers more to inspect than a product video alone.
