Page 4 of 6

Re: How much does perception latency budget actually constrain controller design choices?

Posted: Thu Jun 11, 2026 10:07 am
by robertmiller
Here's what I know on this: 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.

Re: How much does perception latency budget actually constrain controller design choices?

Posted: Sat Jun 20, 2026 4:59 am
by lbianchi
@robertmiller That's the official framing, at least - reality tends to lag 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. Whole-body control (WBC) formulates locomotion and manipulation as a single optimization problem across all joints simultaneously, respecting contact constraints and task priorities - it's more general than ZMP-only approaches but is computationally heavier and harder to tune.

Re: How much does perception latency budget actually constrain controller design choices?

Posted: Sun Jun 28, 2026 3:26 am
by freya.smith
@lbianchi 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. This whole thread is a good reminder how young this field still is.

Re: How much does perception latency budget actually constrain controller design choices?

Posted: Sun Jun 28, 2026 12:35 pm
by benjaminsanchez
From hands-on experience, 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. 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: How much does perception latency budget actually constrain controller design choices?

Posted: Thu Jul 09, 2026 11:47 pm
by kim37
@benjaminsanchez Tangent, but worth mentioning: 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.

Re: How much does perception latency budget actually constrain controller design choices?

Posted: Thu Jul 16, 2026 11:29 pm
by mohammed.rossi
@kim37 Slightly off-topic, but related: '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. Whole-body control (WBC) formulates locomotion and manipulation as a single optimization problem across all joints simultaneously, respecting contact constraints and task priorities - it's more general than ZMP-only approaches but is computationally heavier and harder to tune.

Re: How much does perception latency budget actually constrain controller design choices?

Posted: Tue Jul 21, 2026 10:21 am
by joseph31
@mohammed.rossi This raises a question for me - 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 much does perception latency budget actually constrain controller design choices?

Posted: Sun Jul 26, 2026 10:07 am
by diego.moore6
@joseph31 I see it a little differently. 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: How much does perception latency budget actually constrain controller design choices?

Posted: Wed Jul 29, 2026 6:50 am
by samuel.adams
@diego.moore6 Minor factual note: 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. 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: How much does perception latency budget actually constrain controller design choices?

Posted: Sun Aug 09, 2026 1:21 am
by nicole57
Agreed, and I'd add: 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. 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.