Page 2 of 2
Re: What's your onboard compute stack look like - Jetson, custom silicon, something else?
Posted: Sun Aug 30, 2026 11:59 am
by deborahperez
Still learning the space, so correct me if wrong -
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: What's your onboard compute stack look like - Jetson, custom silicon, something else?
Posted: Sun Aug 30, 2026 11:59 am
by scott.andersson5
Speaking from personal experience here,
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: What's your onboard compute stack look like - Jetson, custom silicon, something else?
Posted: Sun Aug 30, 2026 11:59 am
by camila.jackson0
@scott.andersson5 I see it a little differently.
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.
Kind of makes me think about how different this all looked even three years ago.
Re: What's your onboard compute stack look like - Jetson, custom silicon, something else?
Posted: Sun Aug 30, 2026 11:59 am
by niklassantos
I can speak to this a bit.
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: What's your onboard compute stack look like - Jetson, custom silicon, something else?
Posted: Sun Aug 30, 2026 11:59 am
by greta.carter
Can I ask a dumb follow-up -
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: What's your onboard compute stack look like - Jetson, custom silicon, something else?
Posted: Sun Aug 30, 2026 11:59 am
by nicole57
@greta.carter Thanks for laying this out, genuinely useful.
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: What's your onboard compute stack look like - Jetson, custom silicon, something else?
Posted: Sun Aug 30, 2026 11:59 am
by ananya.novak
I'll believe the stronger version of that claim when it's independently verified.
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: What's your onboard compute stack look like - Jetson, custom silicon, something else?
Posted: Sun Aug 30, 2026 11:59 am
by emilyperez
@ananya.novak Minor factual note:
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. 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.
Reminds me a bit of the early drone hobbyist scene, honestly.
Anyway, good thread - following for more.