Page 2 of 3

Re: Whole-body MPC solve times - what hardware are people running this on?

Posted: Sun Feb 22, 2026 4:20 am
by diego.moore6
@scott.novikova7 I'll believe the stronger version of that claim when it's independently verified. 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. '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.

Re: Whole-body MPC solve times - what hardware are people running this on?

Posted: Tue Feb 24, 2026 9:58 pm
by ethan17
Minor factual note: 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: Wed Feb 25, 2026 1:59 pm
by ivan22
Minor factual note: 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.

Re: Whole-body MPC solve times - what hardware are people running this on?

Posted: Fri Mar 06, 2026 5:34 am
by gary.tanaka2
@ivan22 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. 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.

Re: Whole-body MPC solve times - what hardware are people running this on?

Posted: Sun Mar 08, 2026 3:03 pm
by deborah59
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. 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: Fri Mar 13, 2026 4:12 pm
by carter42
I'd push back on this a bit. OpenVLA is a notable open-source VLA model - roughly 7 billion parameters, trained on hundreds of thousands of real-world robot demonstrations - and has been shown to outperform much larger closed models on some manipulation benchmarks, which says a lot about how much of VLA performance comes from data curation rather than raw scale.

Re: Whole-body MPC solve times - what hardware are people running this on?

Posted: Wed Mar 18, 2026 1:51 am
by diego.moore6
@carter42 From hands-on experience, 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. Totally unrelated but has anyone else noticed how fast component costs are dropping this year.

Re: Whole-body MPC solve times - what hardware are people running this on?

Posted: Sun Mar 22, 2026 6:51 pm
by nicole57
@diego.moore6 Slight correction, though the overall point stands: 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. Reminds me a bit of the early drone hobbyist scene, honestly.

Re: Whole-body MPC solve times - what hardware are people running this on?

Posted: Mon Mar 30, 2026 1:17 pm
by erik_novi
@nicole57 Small correction on one detail: 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.

Re: Whole-body MPC solve times - what hardware are people running this on?

Posted: Sat Apr 11, 2026 5:11 am
by emma_whit
Yeah, this tracks with what I've read as well. 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.