MicroDuck can learn new behaviors. But that doesn't mean it learns like a pet, or like ChatGPT.
“Ready to learn.”
That is one of the phrases Pollen Robotics uses to describe MicroDuck.
The company says MicroDuck is a small biped robot that you can train yourself with reinforcement learning, and its website explicitly presents the process as:
train in simulation → deploy on the robot → refine → publish the policy.
That sounds exciting.
But it also creates an easy misunderstanding.
When most people hear:
“The robot learns.”
they imagine something like a dog.
You show it something.
It gets better.
It remembers what happened.
It adapts to you.
It gradually develops new habits.
That is not what MicroDuck is promising.
What MicroDuck currently gives you is something more specific:
You can train new physical behaviors and put those trained behaviors onto the robot.
That distinction may sound technical.
For a buyer, it actually matters quite a lot.
MicroDuck doesn't learn simply by spending time with you
Let's start with the most important point.
MicroDuck isn't presented as a robot that continuously watches you, learns from everyday conversations, and develops its own abilities while sitting on your desk.
The current system is built around policies.
Pollen's official site says every behavior is a policy that can be retrained. The robot ships with seven trained moves, while the training workflow happens in a physics simulation before the resulting policy is deployed to the real robot.
The GitHub repository describes the same architecture more directly: MicroDuck's robot software runs the policies, while a separate microduck_rl project contains the MuJoCo-based training environments, PPO training setup, and export process used to create those policies.
So think less:
“My robot is learning from me every day.”
and more:
“Someone trains a neural policy to perform a behavior, then the robot runs that policy.”
That is a much better mental model.
So what is a policy?
You don't need to understand the math to understand the idea.
A policy is essentially a learned strategy for controlling the robot.
For example:
walk
The policy has learned how to produce the motor actions needed to maintain a walking gait.
Or:
stand up after falling
The policy has learned a sequence of movements that can take the robot from lying on the ground back to standing.
Or:
grab something
The robot uses a trained behavior for the movement of lowering its body, closing its beak and returning upright with the object. Pollen currently lists walking, sitting and standing, kicking, grabbing, roller skating and recovery from falls among the trained behaviors shipped with MicroDuck — the same set we broke down in what MicroDuck can actually do.
The important thing is that these aren't traditional hand-coded action sequences in the simple sense.
They are learned neural policies.
That's why reinforcement learning matters.
Reinforcement learning is not the same thing as everyday learning
This distinction is where I think a lot of confusion comes from.
Reinforcement learning is the method used to train the behavior.
The robot is given a task in simulation.
It tries actions.
The training system evaluates those actions using a reward function.
Over many iterations, the policy becomes better at the task.
The resulting model can then be exported and deployed to the physical robot.
MicroDuck's public RL repository uses PPO on MuJoCo Warp, trains policies at a 50 Hz control rate, exports them to ONNX, and deploys them through the MicroDuck runtime. The repository even gives a concrete example: a usable walking gait can be trained in roughly 1–2 hours under its stated 4096-environment setup, assuming a suitable CUDA GPU.
That is real learning.
But the learning happens during training.
It isn't the same thing as saying the robot is continuously learning new skills while you use it — a distinction that also sits at the heart of whether MicroDuck can actually be an AI companion.
This is why the simulator matters so much
One of the most important parts of the MicroDuck idea is something that most ordinary buyers might completely overlook:
the robot doesn't have to learn on the physical hardware.
Pollen trains behaviors in simulation first.
The company's website describes the workflow as:
train in simulation;
deploy on the robot;
refine the simulation;
train again;
deploy again;
publish the behavior.
The MicroDuck simulation documentation goes even further.
It says the simulated duck uses the same robotd, the same policies, the same 50 Hz loop, the same robotctl, and the same high-level software interfaces as the physical robot. The main difference is the body: simulation provides the sensors and physics instead of the real hardware.
That's a clever design choice.
And it changes who can experiment with the robot — which is exactly why how open MicroDuck really is matters so much here.
Why train in simulation?
Imagine you want to teach MicroDuck a completely new movement.
You could try doing that directly on a $399 physical robot.
That would be slow.
And expensive.
And probably a lot of falling.
Instead, you can run thousands of virtual versions of the robot at once.
The current RL repository describes training with up to 4096 environments and includes the simulator, actuator modeling, domain randomization and sim-to-real tooling used to transfer learned policies to the real robot.
That means the virtual robot can make mistakes over and over again.
Fall.
Try again.
Fall differently.
Try again.
Eventually, the training process finds a behavior that works well enough.
Only then do you put it on the real machine.
This is what makes MicroDuck's “learn new tricks” idea more interesting than a simple programming interface.
But there is still a human behind the learning
This is another detail worth understanding.
MicroDuck doesn't sit there and independently decide:
“Today I think I will learn how to dance.”
Someone has to define the behavior and the training problem.
Someone has to choose the environment.
Someone has to design the reward.
Someone has to run training.
Someone has to evaluate the result.
Someone has to deploy it.
And someone may need to refine the simulation when the real robot doesn't behave like the virtual one.
Pollen's public RL repository makes that process visible rather than hiding it behind a magical “train” button. It includes the training environments and scripts, the PPO configuration, export tooling, and the sim-to-real recipe used by the project.
That's not a weakness.
It's just what “teaching the robot” actually means in this context — and if you're wondering whether that means you'll need to code, does MicroDuck need coding is the place to start.
So is MicroDuck being programmed?
In a sense, yes.
But saying:
“It's just programmed.”
also misses something important.
Traditional programming often means explicitly specifying what should happen.
For example:
move this motor to this angle;
wait;
move that motor;
repeat.
A learned policy is different.
You define the task and the training environment, and the model learns a strategy from the training process.
You aren't necessarily specifying every motor movement by hand.
That is one reason reinforcement learning is useful for movement.
Walking is an excellent example.
It's hard to write a beautiful hand-coded description of every tiny motor adjustment needed to keep a biped upright while moving.
It's much more natural to let a learning algorithm discover a workable control strategy.
So I wouldn't call MicroDuck “just programmed.”
I'd say:
its behaviors are learned during training, then executed on the robot.
That's a more accurate description.
And the really interesting part is that you can retrain them
This is where MicroDuck starts becoming unusual for a consumer robot.
Pollen says that every behavior is a policy you can retrain on your own machine. The official site explicitly invites users to train new tricks, deploy them to the robot and publish them for the community.
The current GitHub tooling goes further than the launch messaging might suggest.
The policy system supports replacing a behavior policy without needing a whole robot software release. Users can load a local policy, try community-published policies, reset to the official policy, and publish new policies for other MicroDucks to use.
That is significant.
Because now the robot isn't just learning your behavior.
The community can create behaviors that everyone else can use.
This is where “learning” becomes an ecosystem
Imagine one person trains a weird walking style.
Another person trains a new trick.
Someone else improves recovery.
Someone else creates a completely different behavior.
The result is not four robots that each had a different private learning experience.
The results can potentially become shareable policies.
Pollen's current policy system explicitly supports community policy sources, and the project documentation says an officially published policy can reach every robot through the policy update mechanism.
This is a much more interesting model than:
buy robot → use built-in behaviors.
It becomes:
buy robot → join a pool of behaviors created by other people.
And this is one of the strongest reasons I think the software ecosystem could eventually matter more than the hardware.
We are already seeing the beginnings of this
MicroDuck has only just launched, but the developer community is already experimenting with new policies.
In a recent reinforcement-learning discussion, the Pollen team said the project had already attracted people training new, sometimes unusual policies only days after launch. The same discussion confirmed that the training uses PPO with MuJoCo Warp and that the training environments and export scripts are publicly available.
That's exactly what I would want to see at this stage.
Not hundreds of polished consumer features.
That would be unrealistic.
What matters right now is whether people are actually using the platform to create things that weren't there on day one.
But there's a big limitation
A trained walking policy doesn't automatically make MicroDuck intelligent.
A trained grabbing policy doesn't automatically make it understand what an object is.
A trained recovery policy doesn't give it a personality.
A learned movement doesn't equal general-purpose reasoning.
This matters because “AI robot” can make everything sound much more capable than it really is.
MicroDuck's learned behaviors are still specific behaviors.
The robot can run the policy.
But the policy doesn't magically generalize to every physical task.
A robot that knows how to walk is not necessarily a robot that knows where it should walk.
A robot that knows how to grab isn't necessarily a robot that understands what you want it to grab.
And a robot that can learn to skate isn't necessarily a robot that can decide when skating would be useful.
That's the boundary between learned skills and general intelligence.
That's also why the LLM discussion matters
We've already looked at what happens when you connect a large language model to MicroDuck.
An LLM can potentially provide higher-level reasoning, language understanding or tool selection.
The learned policies provide the physical behaviors.
Put those together and you get something more interesting.
The LLM might decide:
“Go over there.”
The navigation system figures out the route.
A walking policy controls the body.
A grasping policy handles the object.
That's a stack of different systems.
No single component has to be “the intelligence.”
And I think that's a much more realistic way to think about the future of MicroDuck.
The word “learn” still has another meaning
There is one version of learning I think would change MicroDuck much more dramatically:
personal learning.
Imagine the robot gradually learning:
where you usually put things;
how you like it to behave;
which commands you use most;
what your routines look like;
what kinds of interactions you enjoy.
That's much closer to what people mean when they imagine an AI companion that “learns you.”
I don't think we should assume MicroDuck does this simply because its movement policies are trained with reinforcement learning.
Those are different problems.
One is:
learning how to perform a behavior.
The other is:
learning about a person and adapting to them over time.
The second is much closer to the companion-robot experience — and it's also why what to look for in an AI companion robot is a different question entirely.
So what does MicroDuck actually learn today?
I would break it down like this.
It can learn physical behaviors.
That's the core promise of the current system.
You can retrain those behaviors.
The public training stack is designed specifically for that.
The learned policies can be shared.
The current policy infrastructure supports community policies alongside official ones.
It does not automatically become a self-learning companion.
Nothing about the current reinforcement-learning workflow should be interpreted as the robot continuously learning your personality, preferences and daily life.
That would be a different layer of intelligence.
Why I actually like this approach
I think there is something refreshing about MicroDuck not hiding the process.
The company basically says:
Here's the simulator.
Here's the training stack.
Here's the runtime.
Here's how the policy gets onto the robot.
Now go build something.
That is very different from a consumer robot that says:
“Our AI learns over time!”
but gives you no idea what that actually means.
MicroDuck's version is much more concrete.
You can point at a policy and say:
This is the behavior the robot learned.
And you can retrain it.
That makes the concept tangible.
But it also changes who gets the most value from MicroDuck
This is where my earlier conclusion about waiting comes back.
For a developer, the ability to train policies is a major part of the product.
For an ordinary user, it may not be.
If you don't want to run a simulator, install dependencies or train a neural policy, you probably won't care about PPO or MuJoCo.
And that's completely fine.
The real question for you becomes:
Can I benefit from what other people train?
That's why the community matters so much.
A non-technical owner doesn't need to become an RL engineer.
They need developers to turn that open platform into things they actually want to use.
And that is exactly the ecosystem I would watch over the next few months — which is also why before you buy your first AI desktop robot is worth reading before you decide.
My take
When Pollen says MicroDuck can “learn,” I think the statement is legitimate — but it needs a little translation.
MicroDuck can learn behaviors through reinforcement learning.
It can take a behavior trained in simulation and run it on the real robot.
Those policies can be retrained, refined and shared.
That's genuinely interesting.
But I would not confuse that with a robot that continuously learns from its owner in the way a human, pet or future AI companion might.
For me, the real promise isn't:
“My MicroDuck will learn.”
It's:
“People can keep teaching the MicroDuck ecosystem new things.”
That's a much bigger idea.
Because if thousands of developers experiment with the same robot, the robot you buy six months from now could have capabilities that nobody had written on launch day.
And that brings us back to the question I keep asking about MicroDuck:
Is the long-term value in the hardware, or in everything people build on top of it?
The hardware gets the robot onto your desk.
The learned policies may be what keep it interesting.
