dsh-nonead-ursim

LIMITATIONS

已知限制

- **Connection persistence** — the worker process lives for the plugin's lifetime and keeps robot connections by IP; after a worker crash or a DSH restart you must `connect` again. - **Remote control mode** — some UR robots must be in "remote control" before they execute motion/program commands, and `ursim_connect` reports that state. **CB3 robots running URSoftware 3.1 through 3.20 already allow remote control by default (nothing to enable at the settings level)**; a `remote_control: false` reading still means the controller is *currently* not in remote mode — in local/teach-pendant mode URScript and motion commands are silently discarded, so switch the pendant to remote control. Other firmware (e-Series, or CB3 outside that range) needs Remote Control enabled in PolyScope first. `ursim_get_status` also reports `remote_control_raw`, and an unreadable state is reported as unknown rather than pretended to be `false`. - **Tool digital I/O** — `ursim_get_digital_in` / `ursim_set_digital_out` with `which="tool"` control the tool-flange digital I/O. Tool digital signals are **not carried by RTDE**, so reading a tool input runs a short URScript program (via `SendProgram`) that may **interrupt a running program**; writing a tool output sends the URScript `write_tool_digital_out` command. Tool digital **output read-back is not supported** (no reliable `read_tool_digital_out` expression). - **Joint current** — the current RTDE recipe does not expose per-joint current directly, so `ursim_get_joint_current` is not provided (the reference implementation's version of this tool has a value bug; this implementation does not carry it over). - **Threading / cancel** — motion commands poll until arrival within `commandTimeoutMs`; for long trajectories, remind the model in the prompt to set a reasonable timeout or split the motion into steps. - **Not a safety boundary** — this plugin is on par with the `bash` tool and can drive physical equipment; test thoroughly on a real robot before production use. - **Package size** — the published package is about **21 MB**, almost entirely the **14 `assets/models/*.glb`** meshes; the plugin's own code adds only a few hundred KB. The meshes are down from the converter's raw 35.11 MB in two reproducible steps (`node scripts/compress-models.mjs`, plus `npm run analyze:models` to see where the bytes go): a **lossless** pass to 28.27 MB (`uint32` → `uint16` indices — the largest index in these models is only 24228 — plus dropping the non-standard `_color` attribute no material reads; vertex positions, UVs, textures and the index sequence stay byte-for-byte/value-for-value identical, and the script proves it before writing), then a **lossy, explicitly decided** pass to 20.86 MB that box-filters the **eight** 2048×2048 base-colour PNGs embedded by the five newer models (ur15 ×1, ur18 ×2, ur20 ×1, ur30 ×2, ur8long ×2) down to 1024×1024 (`--texture-size 1024`). The simulation panel is only a few hundred pixels wide, and a same-region 1:1 comparison shows no visible difference. Geometry precision is untouched (Ruling 24); `test/model-contract.test.mjs` guards the resulting size band. To drop whole models instead, regenerate a subset with `python scripts/convert-meshes.py --only <model…>`. - **Unknown models fall back** — a robot whose model has no bundled mesh (unknown or customized model string) is rendered with **approximate geometry instead of failing**; the simulation never errors out on an unknown model. - **Can the AI drive the simulation without a robot? — Yes, within a boundary that is written in code.** - **The built-in kinematics simulation**: after `ursim_sim_start(model="ur10e")` (or flipping the panel's offline-simulation switch), the motion tools and the pose readback act on a virtual robot at `127.0.0.1` and the simulation follows it. **No real robot and no URSim required.** - **What it can do**: point-to-point and path motion — joint / linear / path / arc / axis-aligned / drawing / **multi-segmen