Page 3 of 3
Re: ROS2 vs custom middleware for a full humanoid stack - what do production teams use?
Posted: Sat Mar 15, 2025 5:51 am
by camila.jackson0
Slight correction, though the overall point stands:
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.
This whole thread is a good reminder how young this field still is.
Re: ROS2 vs custom middleware for a full humanoid stack - what do production teams use?
Posted: Mon Mar 17, 2025 6:33 am
by noah_pate
@camila.jackson0 Agreed, and I'd add:
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. 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: ROS2 vs custom middleware for a full humanoid stack - what do production teams use?
Posted: Thu Mar 27, 2025 10:56 am
by erik_novi
One nitpick -
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.
Makes me wonder how this looks in another five years.
Re: ROS2 vs custom middleware for a full humanoid stack - what do production teams use?
Posted: Fri Mar 28, 2025 1:18 am
by mia_lars
@erik_novi I don't think that's quite right, for what it's worth.
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. 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: ROS2 vs custom middleware for a full humanoid stack - what do production teams use?
Posted: Tue Apr 08, 2025 2:03 am
by deborah59
Agreed, and I'd add:
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.
Totally unrelated but has anyone else noticed how fast component costs are dropping this year.
Re: ROS2 vs custom middleware for a full humanoid stack - what do production teams use?
Posted: Thu Apr 10, 2025 8:55 am
by ivan22
@deborah59 Small correction on one detail:
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.
Re: ROS2 vs custom middleware for a full humanoid stack - what do production teams use?
Posted: Sat Apr 12, 2025 2:06 pm
by servoken70
From hands-on experience,
'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.
Anyway, good thread - following for more.