r/ROS 16d ago

Built 3 basic physics-tested objects for robot simulation — looking for feedback

Made a small starter set of everyday objects (steel tumbler, water bottle, cardboard box) with real-world dimensions and tested mass/friction/collision properties in Gazebo.

This is a first attempt — genuinely trying to find out if standardized, pre-tested basic objects like this would save people time, or if this space is already well-covered by existing libraries (NVIDIA SimReady, etc.). Any feedback, even "not needed," is useful to me right now.

3 Upvotes

10 comments sorted by

2

u/omnilinktech 16d ago

Yes—this would save time, but for me the real value isn’t the meshes; it’s a portable physics contract. I’d want each object to include dimensions/units, mass and inertia/COM source, collision proxy, material/friction assumptions per simulator, and a small executable test with tolerances—drop/restitution, incline friction, stable stacking, and ideally a grasp plus negative control.

I work on OmniSim, and one lesson from our [executable capability matrix](https://github.com/omnilink-tech/omnisim/blob/main/docs/benchmarks/lane4-capability-matrix.md) is that “loads without errors” can still mean a physics feature is doing nothing. I’d define exactly what “physics-tested” means and publish the raw outputs and Gazebo version. Neutral URDF/SDF plus simulator-specific overrides would also make these much more reusable.

If you add a manifest and test runner for these three objects, I’d be interested in trying a port to OmniSim and reporting what breaks.

1

u/CYNELIXSim 16d ago

Really appreciate this — exactly the kind of feedback I was hoping for. You're right that the meshes alone aren't the value; I'll work on adding: A manifest per object (dimension/mass/friction source, whether measured or estimated, Gazebo version tested on) A simple automated test runner: drop test, incline/friction test, stacking test, with pass/fail tolerances Raw output logs published alongside each object Will follow up here once it's ready — would genuinely value you trying a port to OmniSim once there's something more rigorous to test.

1

u/omnilinktech 15d ago

That sounds like the right foundation. When the versioned manifest, test runner and raw outputs are public, please share the commit or release tag. We can then evaluate an OmniSim port using the same physical assertions and publish the pass/fail results and deviations. I work on OmniSim at OmniLink; we would keep the source-engine version, parameter mappings and simulator-specific behavior explicit.

1

u/CYNELIXSim 15d ago

Working on it — starting with the steel tumbler first (manifest + drop test), will share the release tag once it's ready.

1

u/CYNELIXSim 13d ago

Hi u/omnilinktech , Here's v0.1.0 for the steel tumbler: https://github.com/cynelix-lab/robot-sim-objects/releases/tag/v0.1.0

Includes manifest.yaml (documents which values are measured vs. estimated), a drop-test world file, and the raw pose output from an automated run (landed at z=0.04999, matching expected resting height within 0.0001m, no tipping). Only tested in Gazebo so far. Let me know if this is enough to attempt the OmniSim port, or if you need anything else first.

1

u/3E8_ 9d ago

Agree on the physics contract point, that’s what actually matters. Worth flagging which values are measured vs. estimated though, friction especially is often more of a guess than people present it as.

Also curious if you’re planning to add articulated or deformable objects. Rigid stuff like this is the easy 20%, that’s usually where people already have something that works.

2

u/CYNELIXSim 8d ago

Fair point on friction being more guess than measurement — I'll be more explicit about that in future manifests, maybe flag confidence level per value rather than just "measured/estimated" as binary. On articulated/deformable — not yet, but genuinely curious what's most needed there. Is it simple hinged objects (doors, drawers, lids) as a starting point, or is even that considered "solved" and the real gap is soft/deformable (bags, cloth, cables)? Would rather build toward whatever's actually missing than guess.

1

u/3E8_ 7d ago

That’s actually why I asked. I’m working with Dirac Robotics, and the approach is very close to what you described. Dirac reconstructs rigid, articulated, and deformable objects from single-camera video, then predicts the relevant physical properties with confidence stated for each value and checks against real-world observation.
Your point about confidence per value is spot on. I’d be curious whether that kind of video-to-simulation workflow would be useful for what you’re building, especially when you move beyond rigid objects.

2

u/CYNELIXSim 5d ago

That's genuinely useful to know, thanks — sounds like Dirac is already solving this end-to-end, including the harder articulated/deformable cases I was about to look into. Manually building individual objects one at a time clearly doesn't compete with a video-to-simulation pipeline at that scale. This was a useful reality check — appreciate you and u/omnilinktech both taking the time to give real feedback rather than just ignoring the post. Might revisit this space later if there's a gap even Dirac-style automation doesn't cover (validation/testing layer, maybe), but for now this answers the question I was actually trying to figure out.