Preface¶
DeepSeek Harness (dsh) packages models, tools, skills, sessions, and interfaces all as plugins, with the official slogan “Everything is a plugin”. For coding agents, installing a search or vision plugin lets them start working immediately. For robotics and embodied AI, the gaps are more concrete: whether a URDF is correct, whether a simulation runs properly, or whether a grasp failure stems from poor perception or a slipping suction cup—evidence is often scattered across CAD files, MuJoCo logs, and a few charts, making it hard for agents to consolidate them into a single workflow.
dsh-robotic-harness was built for exactly this purpose. It is a community-maintained DSH plugin that integrates robot asset inspection, MuJoCo pick-and-place simulation, fault injection, and hashed evidence packages into the agent loop. This article is collated by cross-referencing the plugin directory page, the GitHub repository README/Chinese documentation, docs/demo.md, docs/safety-boundary.md, and the official DeepSeek Harness repository: covering what it is, what it can do, how to install it, how to run the demo, and what it explicitly cannot do.
Two clarifications are needed first. DeepSeek Harness itself is an open-source agent runtime developed by DeepSeek AI; the plugin introduced in this article comes from a community repository maintained by dingkaihu63, and the license clearly states that it has no affiliation with DeepSeek official. The plugin directory site deepseek-harness-plugin.com is an independent community index, not an official app store for DeepSeek / HoYoverse.
What It Is¶
dsh-robotic-harness (also called Robotic Harness in the repository) is an embodied AI research tool for DeepSeek Harness, categorized under “Tools and Capabilities” and maintained by dingkaihu63. Its installable package name is @robotic-harness/dsh-bundle, current version 0.1.0, licensed under MIT, and primarily written in Python. The directory page summarizes it as: Robot asset inspection and MuJoCo pick-and-place simulation. The GitHub repository currently has 13 stars (12 stars when the directory page was indexed).
Its core problem to solve is straightforward: bring the following tasks into the same agent workflow instead of copying files back and forth between simulators, scripts, and reports:
- Inspect robot assets such as URDF / MJCF / SDF
- Run MuJoCo pick-and-place simulations, with fault injection using fixed seeds
- Use a rule engine to collect facts, rule-based judgments, and candidate root causes
- Export evidence packages with SHA256 manifests, Markdown reports, and offline-viewable timelines
Architecturally, DSH registers a set of rh_* tools and several Skills; the actual work is done by a Python worker distributed with the package (python -m robotic_harness_worker --input -), invoked via a stdio one-shot process. Runs, telemetry, and charts are written to the .rh/ directory in the workspace by default. The purpose of the one-shot process is crash isolation: if the worker crashes, it will not take down the DSH process.
The repository README marks the current state as Demo stage. The author notes: it has only been verified in a limited local environment so far (Windows + Anaconda Python 3.10 + DSH 0.1.0-rc.6); ROS 2, CAD, physical robots, and other operating system/hardware environments have not been fully tested. The badges showing Windows / Linux / macOS are target platform declarations, not confirmation of full coverage.
Core Features¶
The repository README lists approximately 110 rh_* tools covering more than a dozen domains. Below only covers capabilities verified in the README and demo documentation, and does not treat roadmap visions as implemented features.
Asset Inspection¶
For URDF / MJCF / SDF: inspection, inertia and topology validation, mesh statistics, SVG previews, URDF to MJCF conversion, SDF compatible export, and CAD inventory and version comparison. Representative tools include rh_robot_asset_inspect, rh_urdf_validate, rh_urdf_to_mjcf, rh_sdf_validate, rh_mesh_inspect, rh_inertia_validate. SolidWorks files are only logged in the inventory for now and not parsed (due to being commercial software).
MuJoCo Grasp Simulation and Fault Injection¶
The built-in demo scene is a planar 3-DOF robotic arm with a suction cup: pick up a red cube on the table and place it in the target area. The scene is built with geometric primitives and does not rely on external meshes. The simulation side provides rh_sim_run, rh_sim_fault_inject, batch benchmarks, read-only replay, and a simulation vs. real robot gap report (real robot evidence does not currently exist, see limitations below).
Fault injection is deterministic and seed-controllable, with 6 types listed in the documentation:
- perception_offset_px: Perception pixel offset
- gripper_slip: Gripper/suction cup slip
- tf_offset: Coordinate transform offset
- sensor_noise: Sensor noise
- model_timeout_s: Model timeout
- occlusion: Occlusion
The perception routing logic is: first use color segmentation (low latency), fall back to general saliency segmentation on failure or occlusion, and record the routing reason.
Diagnosis, Evidence and Reporting¶
Telemetry includes joint target/actual/error values, suction cup status, object poses, perception estimates and ground truth, as well as scene renderings. Diagnosis uses a deterministic rule engine, with output divided into three layers, and the documentation requires not mixing them:
1. Facts: Timed numerical values, such as the difference between perception estimates and ground truth in millimeters
2. Rule Judgments: Discoveries triggered by thresholds or state machines
3. Candidate Root Causes: Layered by perception/calibration/mechanical/control/system, with probability and missing evidence marked
Final conclusions are left to human users. The evidence package is self-contained: manifest.json (file list + SHA256 + environment snapshot), telemetry, charts, plus Markdown reports and a single-file timeline.html (can be opened directly in a browser without starting a server).
Other Implemented Modules with Potential Backend Gaps¶
The README divides implemented features into two categories:
- Pure Software Modules: Assets, simulation, control, vision, models, diagnosis, telemetry, data, experiments, knowledge, literature, training, etc. The documentation states they are complete and tested (the README badge shows 274 passing tests).
- Backend Dependent Modules: ROS 2 physical robot detection, SolidWorks parsing, physical robot adapters, heavy-duty VLA. When the backend is unavailable, it returns a structured backend: "unavailable" with installation instructions, and does not fake passing tests. rosbag2 inspection and conversion do not require ROS to be installed.
Physical robot-related tools currently include a preflight checklist and an experimental state machine: without a hardware adapter, physical robot items will be marked skip truthfully. docs/safety-boundary.md is more explicit: the current version does not include physical robot hardware adapters, physical robot write tools, or any topic publishing; it also does not provide emergency stop release. Simulation passing cannot be equated to physical robot safety.
Installation and Activation¶
The installation command given on the directory page is as follows, run in the DeepSeek Harness terminal. Follow the original text on the page, do not construct the repository name manually:
dsh plugin add github:dingkaihu63/dsh-robotic-harness
For reproducible installations, pin the commit hash (replace commit with the actual hash):
dsh plugin add github:dingkaihu63/dsh-robotic-harness#commit
The directory page also warns: the plugin runs with the permissions of the current DSH process, and may execute code during installation. You should inspect the source code repository and license before installing.
The repository’s own installation instructions are more detailed, requiring:
- DSH CLI: @deepseek-ai/dsh ≥ 0.1.0-rc.6
- pnpm
- Python 3.10 environment (recommend Anaconda’s python3.10, and install mujoco, numpy, opencv-python, matplotlib, pytest)
The command to install the bundle from a local clone is:
git clone https://github.com/dingkaihu63/dsh-robotic-harness.git
cd dsh-robotic-harness
# Example: Install from local package with specified profile
dsh plugin --profile rh-demo add ./packages/dsh-bundle
The README also requires pointing rh-tools.pythonPath in the profile’s cordis.patch.yml to your Python 3.10 interpreter. It specifically notes: the patch will replace the entire line of configuration, so you need to rewrite other keys on that line as well, and cannot only modify one field. The safety documentation marks pythonPath as a trusted configuration: the worker uses this interpreter to execute the bundled code, and modifying it is equivalent to trusting arbitrary code execution.
A known pitfall when enabling the Web UI is recorded in the repository: the upstream npm package @deepseek-ai/dsh-web-app depends on the private package @deepseek-ai/dsh-frontend, so direct pnpm add will return a 404. The author’s workaround is to edit $DSH_HOME/profiles/rh-demo/package.json and write the built-in bundle to resolve from the DSH installation directory, for example:
dsh.profile.bundles = ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "@robotic-harness/dsh-bundle"]
The file must be saved as UTF-8 without BOM. Then start with an idle port, the README example uses port 3090 to avoid conflicting with DSH’s default port 3080:
dsh --profile rh-demo --port 3090
You can also install from a tarball: dsh plugin add ./robotic-harness-dsh-bundle-0.1.0.tgz. The repository lists the npm post-publishing installation method as “once published”, and the current package.json version is still 0.1.0. Whether it is available on npm depends on the registry at the time, so this article does not state that it can be installed via pnpm add.
Typical Usage¶
The two workflows below are from the repository documentation and can be reproduced as written. One does not require DSH, and the other uses an agent.
1. Run the Python Demo Without Installing DSH¶
Requires Python ≥ 3.10 and the dependencies listed earlier.
git clone https://github.com/dingkaihu63/dsh-robotic-harness.git
cd dsh-robotic-harness
# Test running per-file process isolation to avoid native library conflicts with mujoco / cv2 / pyarrow
cd python && python run_tests.py && cd ..
# End-to-end Demo: Normal Run + Fault Run + Diagnosis + Evidence Package + Report + Timeline
PYTHON=<your python3.10> node scripts/demo.mjs
docs/demo.md specifies that the demo will perform the following steps in order:
1. Normal Run (seed 42, no faults), expecting success: true, with the object landing in the target zone [-0.16, 0, 0.17] ± 0.05
2. Fault Run (seed 43, simultaneously injecting perceptionOffsetPx [18,6], gripperSlip, tfOffset [0.015, 0]), expecting success: false, with anomalies including grasp_missed / gripper_slip
3. Perform rule-based diagnosis, export evidence packages, generate Markdown reports, and timeline.html for each Run
4. Literature retrieval and training flow are offline-safe by default: train-job-prepare is a dry-run that only generates local artifacts; when the network is unavailable, literature retrieval returns backend:"unavailable" and does not fabricate papers
Outputs are saved to examples/demo-output/ by default:
| Artifact | Description |
|------|------|
| report-run-*.md | Experiment report (evidence + hypotheses) |
| timeline-run-*.html | Standalone timeline |
| bundle-run-*/ | Self-contained evidence package |
| dashboard.html | Single-file dashboard |
| .rh/runs/*/artifacts/*.png | Joint, trajectory, error curves, and scene graphs |
A diagnosis example for the fault Run (from docs/demo.md, not the author’s actual test): the perception estimate is approximately [0.354, 0, 0.19], the ground truth is [0.30, 0, 0.19], with an offset of about 54 mm; the rules will flag perception deviation from ground truth and lost objects during transport; the hypothesis layer may suggest “perception error导致 grasp failure” and “gripper surface slip”, and mark missing evidence (such as the segmentation mask at the moment of grasping). The documentation emphasizes: hypotheses are not conclusions, and rerunning with adjusted fault configurations for comparison is needed to quantify the contribution of each factor.
2. Have an Agent Drive the Same Pipeline in DSH¶
After installing the bundle, the entry command given in the README is:
Run the Robotic Harness pick-place demo: inspect the demo robotic arm, run one normal simulation and one faulty simulation, diagnose the failure cause, export the evidence package and generate a report.
docs/demo.md has a more tool-specific description:
Run the rh-pick-place-demo Skill: inspect the demo robotic arm → rh_sim_status → normal sim-run → faulty sim-run → rh_diagnose_run → rh_evidence_export → rh_report_generate, then explain the failure cause and distinguish between facts and hypotheses.
The agent will call the rh_* tools in Skill order, with intermediate results saved to .rh/, which can be opened with regular file tools. For headless Linux off-screen rendering, the documentation requires software GL: sudo apt install libosmesa6 libgl1, and set MUJOCO_GL=osmesa. If the renderer is unavailable, perception will fall back to a simulation of “ground truth + noise”, which will be logged in telemetry instead of crashing the Run.
Applicable Scenarios and Notes¶
The right users are:
- Those already using DeepSeek Harness who want to connect robotics/embodied AI experiments into the agent loop
- Those needing to inspect URDF / MJCF / SDF, or convert assets into a format compatible with MuJoCo
- Those wanting to use fixed seeds for controlled grasp failure experiments and leave hash-verifiable evidence packages
- Those studying perception, calibration, slip, and other issues in simulation, who do not yet have a physical robot adapter
Treat the following items as hard constraints, all from the repository’s own disclosures and not additional requirements:
1. This is a demo, not a production tool. The verified environments are mainly Windows + Anaconda Python 3.10 + DSH 0.1.0-rc.6. ROS 2 physical robots, deep CAD parsing, physical robots, and other operating systems have not been fully tested.
2. The suction cup is a kinematic implementation. After adsorption, the object pose follows the suction cup via code, without simulating real suction force or contact mechanics. This is noted in the run configuration and report.
3. Simulation results are not physical robot evidence. No functional safety certification (IEC 61508 / ISO 10218 / ISO/TS 15066 and others have not been completed). Do not use it to replace emergency stops, safety doors, or limits. In permission hierarchy, pure reading, local derivation, and local MuJoCo simulation are implemented; controlled physical robot actions are not implemented; emergency stop release and similar functions will never be exposed as regular Tools.
4. Missing backends will fail honestly. Without the ros2 CLI, no configured training server, or unreachable literature API, it will return backend: "unavailable". The training module defaults to dry-run; remote submission requires both dryRun:false and confirm:true in the same call, and only runs whitelisted commands. The generated training scripts are deterministic template placeholders, not real model code.
5. MuJoCo results are reproducible on the same machine, but not necessarily across platforms/versions. The documentation uses the default integrator and fixed seed.
6. The plugin runs with the permissions of the current DSH process. Both the directory page and docs/safety-boundary.md require: inspect the source code and license before installing; when installing from git, pnpm may prompt authorization for the prepare script, only authorize packages with trusted source code, and lock the commit. This repository does not upload telemetry or logs, and the worker runs locally.
7. Third-party components have their own licenses. See THIRD_PARTY_NOTICES.md in the repository.
Summary¶
dsh-robotic-harness integrates robot asset inspection, MuJoCo pick-and-place simulation, fault injection, and layered diagnosis into DeepSeek Harness’s plugin ecosystem. For users already using DSH who need to turn simulation failures into verifiable evidence, it provides an agent workflow from rh_sim_run to evidence packages, rather than another isolated simulation script. It is still in demo stage: there is no physical robot capability, some backends rely on “unavailable” diagnostics, and the suction cup does not model contact mechanics. Following the directory page’s installation command, running scripts/demo.mjs locally first, then deciding whether to integrate it into your own profile, will be more prudent than directly testing with physical robots.
Directory page and source links:
- Plugin Directory: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-robotic-harness/
- GitHub Repository: https://github.com/dingkaihu63/dsh-robotic-harness
- DeepSeek Harness: https://github.com/deepseek-ai/deepseek-h