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

Whole-body control, RL policies, VLA models, sim-to-real, ROS2, and the software stack that makes a humanoid actually walk and act.
jlefebvre
Posts: 59
Joined: Wed Jan 14, 2026 3:07 pm

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

Post by jlefebvre »

Been lurking on this one for a while, finally decided to ask. 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. 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. Happy to be told I'm wrong on any of this.
Ex-automotive, now full-time robots.
scott.andersson5
Posts: 172
Joined: Sat Nov 02, 2024 8:39 pm

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

Post by scott.andersson5 »

Small correction on one detail: 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.
cynthia.muller
Posts: 135
Joined: Sun Feb 16, 2025 8:23 pm

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

Post by cynthia.muller »

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. 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. Totally unrelated but has anyone else noticed how fast component costs are dropping this year.
Opinions my own, not my employer's.
olga_lind
Posts: 170
Joined: Tue Dec 24, 2024 12:11 pm

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

Post by olga_lind »

@cynthia.muller 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.
matthew.yamamoto0
Posts: 66
Joined: Sun Dec 14, 2025 8:43 pm

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

Post by matthew.yamamoto0 »

@olga_lind I see it a little differently. 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."
tariqlarsen
Posts: 83
Joined: Sun Jun 15, 2025 4:28 pm

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

Post by tariqlarsen »

@matthew.yamamoto0 From what I've seen: 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.
"Torque is a lifestyle."
ethan_fisc
Posts: 198
Joined: Wed Dec 04, 2024 1:36 am

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

Post by ethan_fisc »

@tariqlarsen This is exactly the kind of context I was looking for. 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.
deborah59
Posts: 227
Joined: Mon Nov 18, 2024 9:37 am

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

Post by deborah59 »

I dealt with almost this exact situation. 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.
Ex-automotive, now full-time robots.
matthew.yamamoto0
Posts: 66
Joined: Sun Dec 14, 2025 8:43 pm

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

Post by matthew.yamamoto0 »

@deborah59 Here's what I know on this: '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.
"Torque is a lifestyle."
deborahperez
Posts: 279
Joined: Sat Aug 31, 2024 4:22 am

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

Post by deborahperez »

@matthew.yamamoto0 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. 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.
Post Reply