How do you keep a whole-body controller stable when adding a new tool/payload?
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
@harmonicjen60 I can speak to this a bit.
Cross-embodiment training (training one policy across data from multiple different robot bodies) has shown some real transfer benefits for high-level behaviors, but low-level control (exact joint torques, timing) still tends to need embodiment-specific fine-tuning. Sim-to-real transfer still commonly breaks on contact dynamics - friction, restitution, and deformable/compliant surfaces are the hardest things to model accurately in simulation, so policies trained purely in sim often need real-world fine-tuning specifically around contact-rich tasks.
"The best actuator is the one that doesn't overheat."
-
ananya.novak
- Posts: 69
- Joined: Tue Jan 13, 2026 9:07 pm
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
@rossi30 I'd push back on this a bit.
Model predictive control (MPC) is still very much alive in production humanoids, often working alongside or underneath learned policies - MPC handles short-horizon dynamically-consistent trajectory optimization while learned components handle perception, task-level decisions, or recovery behaviors that are hard to hand-model.
Currently: 3D printing my way to bankruptcy.
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
Still learning the space, so correct me if wrong -
ROS2 remains common in research and early-stage products for its tooling and ecosystem, but a number of production humanoid companies run custom, more tightly-optimized middleware for their real-time control loops, using ROS2-like tooling mainly for development, visualization, and non-real-time subsystems. Diffusion policies model the distribution of possible actions and sample from it, which handles multimodal manipulation tasks (multiple valid ways to grasp something) more naturally than a single deterministic action output, at the cost of slower inference.
Reminds me a bit of the early drone hobbyist scene, honestly.
-
arjunsanchez
- Posts: 74
- Joined: Sun Nov 23, 2025 3:20 am
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
@jhansen I see it a little differently.
Cross-embodiment training (training one policy across data from multiple different robot bodies) has shown some real transfer benefits for high-level behaviors, but low-level control (exact joint torques, timing) still tends to need embodiment-specific fine-tuning. ROS2 remains common in research and early-stage products for its tooling and ecosystem, but a number of production humanoid companies run custom, more tightly-optimized middleware for their real-time control loops, using ROS2-like tooling mainly for development, visualization, and non-real-time subsystems.
Totally unrelated but has anyone else noticed how fast component costs are dropping this year.
he/him | robotics hobbyist since the DARPA Grand Challenge days
-
forgesve15
- Posts: 29
- Joined: Wed Jul 15, 2026 4:32 am
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
Still learning the space, so correct me if wrong -
Domain randomization - varying friction, mass, sensor noise, and even visual textures during training - is one of the more reliable tricks for improving sim-to-real transfer, but overdoing it can make training slower to converge and produce overly conservative policies. Zero Moment Point (ZMP) control keeps the robot's center of pressure within its support polygon and has been the classical backbone of bipedal walking for two decades - it's robust and well-understood, but tends to produce a somewhat conservative, flat-footed gait compared to more dynamic approaches.
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
@forgesve15 Respectfully, I think this undersells it a bit.
Isaac Lab (the successor to Isaac Gym) is widely used for large-scale parallel RL training thanks to GPU-accelerated physics, while MuJoCo is often used as a secondary 'sim-to-sim' validation step because its contact dynamics are generally considered more realistic than Isaac's, even though it trains slower at scale.
she/her
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
This lines up with my experience.
ROS2 remains common in research and early-stage products for its tooling and ecosystem, but a number of production humanoid companies run custom, more tightly-optimized middleware for their real-time control loops, using ROS2-like tooling mainly for development, visualization, and non-real-time subsystems.
-
arjunsanchez
- Posts: 74
- Joined: Sun Nov 23, 2025 3:20 am
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
@novak49 Slight correction, though the overall point stands:
Physical Intelligence's pi0 pairs a smaller pretrained vision-language backbone with a separate flow-matching 'action expert' module, which is one way to get fast, high-frequency action output without needing the whole giant language model to run at control-loop speed. Model predictive control (MPC) is still very much alive in production humanoids, often working alongside or underneath learned policies - MPC handles short-horizon dynamically-consistent trajectory optimization while learned components handle perception, task-level decisions, or recovery behaviors that are hard to hand-model.
he/him | robotics hobbyist since the DARPA Grand Challenge days
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
@arjunsanchez I can speak to this a bit.
'Zero-shot sim-to-real' rarely means literally zero real-world tuning in practice - it usually means the policy transfers well enough to be usable with only calibration and minor safety-limit adjustments, rather than needing a full additional training phase on hardware.
he/him
Re: How do you keep a whole-body controller stable when adding a new tool/payload?
@kwilliams Here's what I know on this:
Balance-recovery controllers are usually evaluated with push-recovery tests (a known, repeatable lateral push) in demos, but real-world robustness also depends on recovering from unstructured events like uneven flooring, unexpected contact, or a dropped payload shifting the center of mass mid-stride - which is a much harder, less demo-friendly test.
"Torque is a lifestyle."