Hmm… Physical AI isn’t really my area, but from what I found:
For a custom differential-drive USD in Isaac Sim 6.1, I would start with one short, synchronized observation before changing more friction or solver settings. The key question is whether the problem happens between the controller and the wheel joints, between the spinning wheels and the ground, or between physical simulation and the remote view. Your report says the custom USD loads and the wheel joints can be controlled, but the robot sometimes stops translating while the wheels still rotate. Changing caster collision settings can also cause jumping. The parallel Chore Robotics team report adds that it may move a short distance before stopping, that several articulation, geometry, joint and friction settings have already been checked, and that revised USDA/test files and logs are available. That is more specific than an unconfigured robot, but it still does not establish a single cause.
Place the same robot on a simple static flat floor. Bypass teleop temporarily and hold a modest, constant left/right joint velocity target for a few simulated seconds. Capture the transition from initial movement to the apparent stall, with:
If it is already easy to obtain, caster swivel angle, chassis height/pitch or wheel-joint effort could help too, but I would not require extra instrumentation to begin. A second, slow in-place turn is a useful follow-up. The first decision branches would be:
| Observation during the apparent stall | First place to look |
|---|---|
| Targets persist, measured wheels keep rotating, but live chassis pose barely changes | Wheel/floor traction and load, caster contact/swivel resistance, unexpected contacts or constraints |
| Targets persist, but measured wheel angular speeds drop | Drive force/effort limits, joint axes, competing controllers, mechanical |
| Direct wheel-joint control works, but the normal teleop path fails | Custom prim path, articulation root, left/right DOF mapping and command propagation |
| Live chassis pose changes but WebRTC looks frozen | Simulation/render/stream timing rather than immediately changing contact physics |
Those are diagnostic branches, not diagnoses. More than one issue could be present. The Isaac Sim 6.1 robot troubleshooting guide explicitly covers collision overlap, joint setup, physics stability and differential-drive friction. The 6.1 mobile robot controller guide is useful for checking the wheel-command boundary.
One important caution: disabling the caster collider also removes a potential support point. If the chassis then drops onto another collision shape or changes load distribution, a jump does not by itself prove the original caster collider was wrong. I would compare caster alternatives while preserving approximately the same support height and load.
There are two legitimate development routes: use a deliberately simplified rear sliding support to establish a reliable navigation baseline, or retain physical swivel/roll/contact behavior for caster fidelity. The official Isaac Sim 6.1 DD100 walkthrough illustrates the first route; it is not a universal physical-caster recipe.
Since the team has already done several setup checks, either a few seconds of the four-field trace above or just the wheel/caster joint-and-collider part of the revised USDA would be a good next piece of evidence. The more detailed possibilities and references are below for anyone who wants to pursue a particular branch.
I would start with one short synchronized direct-wheel trace, or the relevant revised wheel/caster USDA excerpt if that is easier to share. Either can tell us which branch deserves the next experiment without changing the robot’s overall goal or committing to a premature explanation.