Robot Harness documentation¶
For a visual introduction and recorded simulation, visit the project website.
Choose a path based on what you want to do. Current capabilities are summarized in the project README; the documents below retain the detailed contracts and evidence.
Run your first example¶
- Build the project and run normal execution.
- Follow local compute and two-step tasks to run a real worker process and a dependent task.
- Explore cancellation and deadlines, then replacement and rebinding.
These software paths need no model or robot. For a failed command, start with example troubleshooting.
For signatures and the installed/source-tree boundary, use the API entry points.
Understand the architecture¶
Read the design in this order:
- Product boundary: responsibilities of callers, Harness, ROS and native control.
- Execution ownership: who retains work and observes its completion.
- Commands, evidence and receipts: distinguish intent, native facts, result delivery and settlement.
- Source modules and public headers: find the implementation after understanding the boundary.
Results and recovery and the Linux recovery example explain the limited surviving-Owner prototype. Recovery does not restore a missing result or survive Owner/machine restart.
Connect a backend¶
Use the installed Core consumer for a standalone CMake application. Installation exposes Core only; the integrations below retain their own deployment requirements.
Start with the existing local compute integration contract and its usage and verification. Use it to identify a backend's submission, result and cleanup boundaries, rather than assuming native completion alone permits another task.
For ROS 2, read the navigation integration scope, then the optional Humble example. Its two binaries have different settlement contracts. Use the container simulation tutorial to build and run the settlement scenarios from source. No general ROS adapter SDK or physical-robot integration guide is available yet. Discuss a concrete backend through an integration proposal.
Verify or contribute a change¶
- Contributing: participation, licensing status and patch workflow.
- Testing: tested revisions, environments, manual observations and CI scope.
- C++ style: names, headers and formatting.
- PR review and evidence: record what was checked and which findings remain.
- Integrity standard: proportional evidence checks and preservation of historical results.
AGENTS.md contains the agent-specific project entry. It complements the contributor documents; personal agent tools are not required to participate.
Source map¶
| Location | Contents |
|---|---|
| include/robot_harness | Current caller-facing headers |
| src/core | ROS- and payload-independent Core |
| src/compute, src/sample | Native process adapter and deterministic fixture |
| examples | Runnable callers, task controller and recovery demonstrations |
| integrations/ros2 | Optional navigation builds and experimental fixture messages |
| tests | Software regressions registered with CTest |
For planned behavior, use the implementation sequence and M4 delivery increments. A planned check or interface is not evidence that it has been implemented.
Project website¶
The presentation homepage and searchable guides are published together. Guides are generated from the Markdown you are reading; there is no second maintained copy. See documentation development for building, previewing, link checks and publishing. The recording notes identify the demo's scope and provenance.