A LiDAR and an IMU now run beside physics: the scan sweeps the workcell and the IMU reads gravity on the wrist.
中文版在文末，点开即可阅读。
Before
After
Before: sensor prims are ignored. After: the LiDAR scan is drawn over the arm and table.
Each return carries the semantic label of the surface it hit: table, cube or unlabelled.
Specific force of about 9.8 m/s² against gravity, and MEMS-level gyro noise.
Situation
Turing Sim could simulate robots but not what their sensors see. Isaac Sim's main value for robotics is sensor simulation; Turing Sim had no IMU, no LiDAR and no way to record either. The roadmap made sensors the next stage.
Task
Add IMU and LiDAR sensors that are described in plain USD, work with both physics engines (MuJoCo and Genesis), produce the same kind of data from either, and can be recorded. Discovery must not depend on any particular robot or asset, and adding a sensor must be undoable.
Action
-
Sensors are ordinary USD. A sensor is an
XformwithturingSensor:typeand its parameters in theturingSensor:namespace, mounted on the nearest rigid body or fixed in the world. Reading them needs no schema plugin, so the editor, the MuJoCo host and the separate Genesis runtime see the same sensors. Adding one from a preset is one undoable command. - IMU from each engine's own physics. MuJoCo gets accelerometer, gyro and orientation sensors at a site placed by the MJCF conversion, sampled every substep (400 Hz). Genesis uses its IMU per outer step and says when it cannot reach the requested rate. One shared model then adds white noise and bias drift.
- LiDAR against what is visible. Rays hit the render geometry, not the collision hulls: meshes, primitives and point-instanced copies, grouped by rigid body and moved with each physics frame. MuJoCo's ray caster, which both runtimes ship, does the intersection. Rotating patterns fire column by column through each revolution, so motion distorts a scan the way it does a real spinning sensor. Each return carries intensity, the surface it hit and its semantic label.
- Previews and recordings. The physics host reports previews on request and records IMU CSVs and organised LiDAR frames with a manifest.
Result
Tests check the physics, not just the plumbing. An IMU at rest reads +9.81 m/s² upward, tilted 90° it reads along +Y, in free fall it reads about zero, and on a turntable at 90°/s it reads 1.571 rad/s within 1%. Genesis gives the same readings. LiDAR ranges on a flat wall are exact.
On the workcell the scan costs about 4.7 ms per 10 ms step on MuJoCo, which stays real time. Genesis GPU goes from 10.7 to 18.5 ms per step, so it plays at about half speed.
The captures run the same scene before and after: the old version ignores the sensor prims, the new one draws the scan. Cameras came next and are in the following post.
LiDAR 和 IMU 现在随物理一起运行：激光扫过工作站，手腕上的 IMU 读出重力。 Turing Sim 能仿真机器人，但不能仿真它们的传感器看到了什么。Isaac Sim 对机器人最重要的价值就在传感器仿真，而 Turing Sim 没有 IMU、没有 LiDAR，也没法录制这些数据。路线图把传感器定为下一个阶段。 加入 IMU 和 LiDAR：用普通 USD 描述，两个物理引擎（MuJoCo 和 Genesis）都能用，两边产出同一种数据，并且可以录制。识别传感器不能依赖特定的机器人或资产，添加传感器必须可以撤销。 测试检查的是物理结果，不只是数据通路。静止的 IMU 向上读到 +9.81 m/s²；绕 X 轴倾斜 90° 后读数在 +Y 方向；自由落体时约为零；放在 90°/s 的转台上读到 1.571 rad/s，误差在 1% 以内。Genesis 的读数一致。LiDAR 打在平墙上的距离是精确的。 在工作站场景里，MuJoCo 每个 10 ms 步多花约 4.7 ms，仍然实时。Genesis GPU 从每步 10.7 ms 变成 18.5 ms，大约半速播放。 截图用同一个场景对比：旧版本忽略传感器 prim，新版本画出扫描点云。相机在下一篇。中文版 · Chinese version（点击展开）
背景
目标与难点
解决思路与行动
Xform，带 turingSensor:type 和 turingSensor: 命名空间下的参数，挂在最近的刚体上，或者固定在世界里。读取不需要 schema 插件，所以编辑器、MuJoCo 宿主和独立的 Genesis 运行时看到的是同一组传感器。从预设添加一个传感器是一次可撤销的操作。
结果与下一步
Top comments (0)