Repository navigation
feat(sim): dimsim as connection - #1735
Conversation
Greptile SummaryThis PR introduces DimSim as a second simulation backend (alongside MuJoCo), adds a Python SDK (
Confidence Score: 2/5The DimSim backend is not functional as written: the robot cannot move, odometry is never forwarded to consumers, and the test assertions against robot position will always fail. The core connection class (DimSimConnection) has multiple unresolved gaps from previous review rounds: move() returns True without publishing to /cmd_vel, odom_stream()/lidar_stream()/video_stream() are permanently silent Subject instances that no code ever pushes to, and _handle_odom only publishes TF without notifying the odom Subject. Together these make every e2e test that asserts on robot position structurally unable to pass. The scene client has an unresolved JS injection path and a recv-thread crash race. DimSimClient.stop() still unconditionally creates and connects a fresh SceneClient during teardown, and the client always binds to hard-coded port 8090. dimos/robot/unitree/dimsim_connection.py needs the most attention — move(), odom_stream(), lidar_stream(), and video_stream() all need real implementations before any e2e test can pass. dimos/e2e_tests/dim_sim_client.py needs the lazy-init guard in stop() and the configurable port. dimos/simulation/dimsim/scene_client.py needs the JS injection fix in add_collider/remove_collider and the recv-thread KeyError guard. Important Files Changed
Reviews (22): Last reviewed commit: "feat(sim): add dimsim" | Re-trigger Greptile |
9d01ca0 to
d26e60d
Compare
6e02118 to
1aec40d
Compare
7851b03 to
139e176
Compare
c1fa423 to
054c9ec
Compare
054c9ec to
55afcff
Compare
55afcff to
e3baf66
Compare
e3baf66 to
3f5a71e
Compare
2f00cad to
96d8638
Compare
96d8638 to
36391fb
Compare
36391fb to
377385b
Compare
377385b to
2dde795
Compare
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
2dde795 to
e3adc99
Compare
leshy
left a comment
There was a problem hiding this comment.
I have no notes on this apart from LCM, can fix in the followup, amazing!
e3adc99 to
b722d89
Compare
b722d89 to
47ef883
Compare
47ef883 to
0815c18
Compare
878f15e to
7f058fc
Compare
Co-authored-by: Viswajit Nair <viswajitnair@gmail.com>
2045f24 to
369d90a
Compare
Root cause of the "robot never spawns" report: paul/feat/dimsim (#1735) landed DimSimConnection as the dimos↔DimSim transport, but that connection only shuttles cmd_vel and odom over LCM — it never sends an `embodimentConfig` WS message. The visibility/avatar setup therefore falls through to whatever engine.js does at boot. What engine.js did: if the scene returned `embodiment: null` (apartment, warehouse, empty all do — they don't want to dictate the model), the agent was created with `avatarUrl: []` and `agent.group.visible = false`. The fallback was that an explicit SceneClient.set_embodiment() call would later send embodimentConfig and re-show the agent (a feature my previous commit already wired up). But the default Connection-based agentic blueprint never calls SceneClient, so the agent stayed hidden forever even though server physics + sensors were running fine. Fix: in dimos mode, drop the empty-avatar / hide-group path. Let createAiAgent use its default avatarUrl (the dimsim_unitree_stub.glb we just renamed), and leave the group visible. An external SceneClient call to set_embodiment still works — it swaps the GLB and re-asserts visibility via the embodimentConfig handler.
Co-authored-by: Viswajit Nair <viswajitnair@gmail.com>
Problem
We need a light-er weight simulator.
Closes DIM-xxx
Solution
Breaking Changes
The
--simulationflag now takes a parameter: eithermujocoordimsim.How to Test
Run the apt scene:
Run the empty scene:
Run the dimsim tests:
Contributor License Agreement