Page 3 of 3
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Tue Apr 14, 2026 1:50 am
by sven.smith4
@emma_whit I see it a little differently.
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.
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Fri Apr 17, 2026 7:09 pm
by nicole57
Not sure I fully agree here.
'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. A lot of what reads as 'full autonomy' in public demos is closer to a mix of scripted state machines, teleoperation for the hardest sub-tasks, and autonomous execution for the easier, well-rehearsed parts - transparency about this mix varies a lot between companies.
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Tue Apr 28, 2026 12:40 pm
by ashley_flor
@nicole57 Not to derail, but this reminds me of something adjacent:
Vision-Language-Action (VLA) models like RT-2, OpenVLA, and Physical Intelligence's pi0 unify a vision-language backbone with an action-output head, letting a robot map a camera image and a text instruction directly to motor commands instead of hand-coding separate perception and planning stages.
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Sun May 10, 2026 1:54 am
by cynthia.muller
@ashley_flor This matches something I went through recently.
Vision-Language-Action (VLA) models like RT-2, OpenVLA, and Physical Intelligence's pi0 unify a vision-language backbone with an action-output head, letting a robot map a camera image and a text instruction directly to motor commands instead of hand-coding separate perception and planning stages.
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Wed May 13, 2026 8:53 am
by charlesbianchi
Slight correction, though the overall point stands:
'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. 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.
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Sun May 24, 2026 9:19 pm
by carol38
This is a great summary, thanks.
Vision-Language-Action (VLA) models like RT-2, OpenVLA, and Physical Intelligence's pi0 unify a vision-language backbone with an action-output head, letting a robot map a camera image and a text instruction directly to motor commands instead of hand-coding separate perception and planning stages.
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Thu Jun 04, 2026 1:34 am
by olga_lind
@carol38 Here's what I know on this:
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.
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Sat Jun 13, 2026 7:18 pm
by nschmidt
@olga_lind Pretty much this. One thing to add:
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. 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.
Re: Whole-body MPC solve times - what hardware are people running this on?
Posted: Sat Jun 20, 2026 1:52 am
by george92
@nschmidt Slightly off-topic, but related:
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.