How much does perception latency budget actually constrain controller design choices?
-
gimbalmar65
- Posts: 86
- Joined: Sun Jul 13, 2025 4:14 am
Re: How much does perception latency budget actually constrain controller design choices?
This matches what I've seen too.
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.
Kind of makes me think about how different this all looked even three years ago.
Currently: 3D printing my way to bankruptcy.
Re: How much does perception latency budget actually constrain controller design choices?
@gimbalmar65 Pretty much this. One thing to add:
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.
Watching this space closely since 2019.
-
mohammed.rossi
- Posts: 88
- Joined: Fri Nov 07, 2025 9:46 pm
Re: How much does perception latency budget actually constrain controller design choices?
Ran into exactly this myself.
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. 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?
To answer this directly:
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.
Ex-automotive, now full-time robots.
Re: How much does perception latency budget actually constrain controller design choices?
@jlefebvre Respectfully, I think this undersells it a bit.
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. 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.
Ex-automotive, now full-time robots.
Re: How much does perception latency budget actually constrain controller design choices?
@deborah59 This matches what I've seen too.
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. 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.
they/them
Re: How much does perception latency budget actually constrain controller design choices?
@ivan22 I can speak to this a bit.
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. 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.
she/her
Re: How much does perception latency budget actually constrain controller design choices?
Worth being a little skeptical of the marketing angle here.
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.
Watching this space closely since 2019.
Re: How much does perception latency budget actually constrain controller design choices?
@mia_lars Short answer:
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. 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.
Kind of makes me think about how different this all looked even three years ago.
-
charlesbianchi
- Posts: 157
- Joined: Fri Apr 18, 2025 2:51 am
Re: How much does perception latency budget actually constrain controller design choices?
Short answer:
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. 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.
she/her