mirror of
https://github.com/OPCFoundation/UA-.NETStandard.git
synced 2026-10-29 23:38:39 +08:00
# Description Remove stock phrasing and correct misleading or inconsistent technical documentation. The initial two passes covered 367 Markdown files, followed by an interactive review of 169 editorial flags. The U5 interpretation originally deferred in that review has since received the upstream Mantis answer recorded by #4843; remaining server/spec follow-ups stay explicit in the CTT log. - Correct package responsibilities, migration steps, API names, ownership, protocol descriptions and links. Keep bundled migration guides synchronized. Preserve historical conclusions as historical records with separate re-check notes. - Provide at least two rendered TOC levels throughout `docs/`. Convert appropriate architecture figures to Mermaid without changing code examples, transcripts or historical quotations. - Address the October 19 feedback with concrete setup/migration instructions, corrected certificate paths and PubSub names, shorter repeated caveats, consistent XML comments, and a full review of the Concepts guide. Retain #4839's API corrections. - Integrate #4841's runtime/performance guidance and review incoming/recent prose. Preserve dated measurements rather than claiming new benchmark runs; clarify allocation ratios, startup-only processor settings, JIT warm-up and the benchmark commit's scope. Missing raw measurement artifacts and repeat ranges remain tracked by #4842. - Merge master through `e8c5d800a` in `32c6394b7`. Resolve the CTT log conflict using the updated Mantis states and OPC answers, retaining historical framing and re-checks for C28/C32/C43. - Address the latest naming/index feedback in `adb5bf693`: rename the guides to `docs/WotCon.md` and `docs/WotNodeSetConversion.md`; move the provider and DataType-declaration contracts into the conversion guide and remove `docs/WoT.md`. Rename `samples/DI` to `samples/Di` and `samples/Isa95` to `samples/ISA95`. Add content-index READMEs to Di, FluentApi, ISA95, Lds and PubSub; update solution entries, project references, Docker/CI paths, test fixture paths and documentation links with exact casing. **WoT guide scope.** This branch retains the detailed conversion guide that #4758 had replaced with an anchor stub. Conversion limits, verified document sets, preservation rules and provider ownership now live together in `WotNodeSetConversion.md`; binding/runtime guidance remains in `WotBindings.md` and `WotCon.md`. The design-rationale/test-ledger prose was shortened, the oversized argument-table cell moved into its section, and existing anchors preserved. **SDK policy is a separate, explicit user-directed change.** `global.json` sets a stable minimum of `10.0.400`, `rollForward: latestMajor`, and `allowPrerelease: false`. Newer major SDKs are permitted; CI's explicit SDK pins are unchanged. README, GettingStarted, DeveloperGuide and Recycling instructions reflect the possible analyzer differences. The image-contract regression fix accepts compatible stable SDK images instead of requiring exact equality with the floor. The latest four rename/index threads are resolved after publication. Three older threads remain open: universal obsolete-removal timing, unconditional nonce-strength wording, and a blanket Vision NativeAOT claim. Existing implementation/evidence constraints are explained in their inline replies. The two-level TOCs remain as requested. ## Validation - `git diff --check` and staged diff checks: passed. The untouched upstream AutoID NodeSet retains its provenance bytes, including two existing license-header trailing spaces. - `.\.azurepipelines\validate-migration-plugin.ps1`: passed; 15 bundled migration documents and manifests synchronized. - Documentation/path validation: **101** documents retain two rendered TOC levels (**2,228** entries), with idempotent formatting. **52** new relative links and their anchors passed exact-case checks. No tracked references to the old guide/sample paths remain. Both relocated provider-contract sections are preserved in the destination. - `dotnet sln UA.slnx list`: passed; shows the renamed Di/ISA95 projects and the existing FluentApi/Lds/PubSub projects. Updated solution and pump ProjectReference paths also passed exact-case existence checks. - Latest focused commands, run from the repository root: ```powershell # Passed: 61 channel send-order and reconnect tests. dotnet test tests\Opc.Ua.Core.Tests\Opc.Ua.Core.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~UaSCBinaryChannelSendOrderTests|FullyQualifiedName~TcpReconnectKeyAgreementTests' --verbosity minimal # Passed: 5 pump datasheet tests; builds the renamed pump sample. dotnet test tests\Opc.Ua.Di.Tests\Opc.Ua.Di.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~PumpDatasheetConformanceTests' --verbosity minimal # Passed: 4 repository NodeSet path/round-trip tests, including the moved pump models. dotnet test tests\Opc.Ua.Types.Tests\Opc.Ua.Types.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~RepositorySourceSurvivesSerializedLinkedPartitionsAsync' --verbosity minimal # Passed: build, zero warnings/errors. dotnet build samples\ISA95\MinimalIsa95Server\MinimalIsa95Server.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal # Passed: dependent sample-test project build, zero warnings/errors. dotnet build tests\Opc.Ua.WotCon.Samples.Tests\Opc.Ua.WotCon.Samples.Tests.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal ``` Earlier focused integration checks passed 2,620 tests across AutoID, event queues/scheduling, source generation, MCP/package profiles and WoT. Both reviewed Mermaid diagrams rendered locally without network access. These checks are not a full solution run. The full solution has **not** been rerun for this review. Earlier `dotnet test UA.slnx -p:CustomTestTarget=net10.0 --verbosity quiet` did not pass: three AOT projects rejected VSTest and 20 Vision tests failed during graphics initialization with `OutOfMemoryException`. Remaining long-running tests were stopped at the user's request. A focused Vision rerun passed 558 tests and reproduced those 20 failures. The earlier `dotnet test UA.slnx -p:CustomTestTarget=net48 --verbosity quiet` was blocked by the former SDK pin and was not retried after the policy change. The user approved proceeding with those limitations documented; current remote CI is not claimed green. ## Related Issues - Follow-up #4842 tracks the requested 2.0.2+ benchmark/tuning and diagnostic-tool documentation refresh. #4841 supplies documentation and earlier results, not all newly requested measurements. - #4758 explains the conversion guide's earlier consolidation; the current provider contracts are now consolidated into `WotNodeSetConversion.md`. - #4839 supplies the reviewed API corrections; #4843 supplies the updated CTT issue record. - The original prose cleanup and SDK policy were user-requested without a source issue. No new runtime architecture is introduced by these documentation edits. ## Checklist _Put an `x` in the boxes that apply. You can complete these step by step after opening the PR._ - [ ] I have signed the [CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf) and read the [CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md) doc. - [ ] I have added tests that prove my fix is effective or that my feature works and increased code coverage. - [x] I have added all necessary documentation. - [ ] I have verified that my changes do not introduce (new) build or analyzer warnings. - [ ] I ran **all** tests locally using the **UA.slnx** solution against at least .net **framework** and .net **10**, and all passed. - [ ] I fixed **all** failing and flaky tests in the CI pipelines and **all** CodeQL warnings. - [ ] I have addressed **all** PR feedback received. --------- Co-authored-by: Roman Ettlinger <romanett98@gmail.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
152 lines
8.0 KiB
Markdown
152 lines
8.0 KiB
Markdown
# Robotics samples
|
|
|
|
Three runnable samples covering the two robotics companion models this stack implements: **OPC 40010
|
|
Robotics**, which describes a robot, and the draft **[OPC UA — Robot Intent](../../docs/Robotics.md#robot-intent)**,
|
|
which commands one.
|
|
|
|
| Sample | What it is | What it shows |
|
|
|---|---|---|
|
|
| [`MinimalRobotServer`](MinimalRobotServer) | A server for a two-robot cell | OPC 40010 topology, RSL/GPOS positioning, and an OpenUSD representation of the whole cell |
|
|
| [`IntentEnabledRobot`](IntentEnabledRobot) | A server for one collaborative arm | The Robot Intent command surface end to end, plus an OpenUSD representation you can drive |
|
|
| [`IntentViewerClient`](IntentViewerClient) | A client with a 3-D viewport | Clicking a target in the OpenUSD viewport and watching the arm execute the intent |
|
|
|
|
All three are non-production demonstration code. `--insecure` in the command lines below means an
|
|
unsecured endpoint with blanket certificate acceptance; it exists so the samples start without a PKI
|
|
dance and must never be used anywhere real.
|
|
|
|
## `MinimalRobotServer`
|
|
|
|
A self-contained server exposing a robot **cell**: two KUKA-style six-axis arms on mobile platforms,
|
|
their axes, power trains and safety states modelled per OPC 40010, their positions modelled per
|
|
OPC 10000-210 RSL and OPC 10000-211 GPOS, and the whole thing published as an OpenUSD representation
|
|
whose assets the server serves over the Part 5 `FileType`.
|
|
|
|
```powershell
|
|
dotnet run --project samples/Robotics/MinimalRobotServer -- --host localhost --port 62830
|
|
```
|
|
|
|
Then render it live with the connector tool:
|
|
|
|
```powershell
|
|
dotnet run --project tools/Opc.Ua.OpenUsd.Connector -- `
|
|
--server opc.tcp://localhost:62830/MinimalRobotServer `
|
|
--fetch-assets ./stage --insecure --view
|
|
```
|
|
|
|
See [`MinimalRobotServer/README.md`](MinimalRobotServer/README.md) for the full walkthrough, the
|
|
address-space layout and the USD binding contract.
|
|
|
|
## `IntentEnabledRobot`
|
|
|
|
One stationary UR5e-style collaborative arm with an offset wrist — deliberately a different kinematic
|
|
family from the cell sample's arms — on a workbench with four target locations.
|
|
|
|
Where `MinimalRobotServer` shows you what a robot *is*, this shows you how to *ask it to do something*:
|
|
the server declares an `IntentControllerType` with its capabilities, frames, tool centre point,
|
|
locations, axes, outputs, kinematic description and safety state, and executes submitted intents against
|
|
a simulated motion kernel with real kinematics. Every intent is tracked on a Part 10 program instance, so
|
|
a motion that takes a minute outlives the `Call` that started it.
|
|
|
|
```powershell
|
|
dotnet run --project samples/Robotics/IntentEnabledRobot -- --host localhost --port 62840
|
|
```
|
|
|
|
## `IntentViewerClient`
|
|
|
|
The client connects, discovers
|
|
`Server/RobotIntent/Controllers`, reads the controller's capabilities, opens the OpenUSD viewport on the
|
|
served stage, and streams live joint and tool-centre-point values into the picture. **Click one of the
|
|
four target pucks on the bench** and the client submits a linear-move intent to that location, then
|
|
tracks the resulting `IntentOperation` to a terminal state while the arm animates on screen.
|
|
|
|
Start the server first, then:
|
|
|
|
```powershell
|
|
dotnet run --project samples/Robotics/IntentViewerClient -- `
|
|
--server opc.tcp://localhost:62840/IntentEnabledRobot `
|
|
--insecure --view
|
|
```
|
|
|
|
It also runs **headless**, which is how it is exercised in CI and how it works on a machine without the
|
|
native OpenUSD payload:
|
|
|
|
```powershell
|
|
dotnet run --project samples/Robotics/IntentViewerClient -- `
|
|
--server opc.tcp://localhost:62840/IntentEnabledRobot --insecure
|
|
```
|
|
|
|
In headless mode the four targets are offered as a console menu instead of as prims to click, and
|
|
everything downstream of the pick — submission, tracking, cancellation, command authority — is identical.
|
|
|
|
### Agent-driven pallet stacking
|
|
|
|
`IntentViewerClient --mcp` is the agent entry point for the intent sample. Start `IntentEnabledRobot`,
|
|
then run the viewer with MCP over stdio for a headless agent or over HTTP when the OpenUSD viewport is
|
|
open. The agent and the human viewer share the same OPC UA `SampleSession`, so MCP calls, operation
|
|
monitoring, payload outputs and OpenUSD live bindings all describe the same robot.
|
|
|
|
A well-behaved agent starts with discovery, not motion:
|
|
|
|
1. `robotics_list_controllers`
|
|
2. `robotics_read_controller` to inspect `SupportedIntents`, `SupportedFacets`, frames, tools,
|
|
locations and outputs
|
|
3. `robotics_read_state` to verify `Ready`, mode, safety and current command owner
|
|
4. `robotics_request_control` before any command
|
|
|
|
The pallet demonstration deliberately proves refusal handling before the successful plan. Another
|
|
session holds command authority, the agent submits a move, receives `Accepted=false` with
|
|
`Failure=ControlNotOwned`, reads the enum and message, releases or waits for the owner, requests
|
|
authority itself, and only then replans. It must not retry the refused submission blindly.
|
|
|
|
The stacking plan uses the published model seam. Parts begin under `/World/Payloads/BinParts`, the
|
|
held part is driven by `HeldPartPosition` and `HeldPartVisible`, and completed slots are driven by
|
|
`PayloadSlotNNFilled`. The viewer and connector do not contain pallet logic; they just render the
|
|
server-published bindings. The agent can pick from `Bin`, move the held part to row/layer coordinates
|
|
near `Fixture`, place it, then submit a mission that repeats the sequence for the next slot.
|
|
|
|
Agents must not assume:
|
|
|
|
* command authority is implicit;
|
|
* a supported tool means the controller supports every intent kind;
|
|
* `SupportedIntents`, `SupportedFacets`, safety state or queue depth can be skipped;
|
|
* a refusal should be retried without changing the plan;
|
|
* a submitted operation is done until `robotics_wait_operation` or controller state says so.
|
|
|
|
### How a click becomes an intent
|
|
|
|
The viewport is rendered by the optional [`Opc.Ua.OpenUsd.Connector.Viewer`](../../tools/Opc.Ua.OpenUsd.Connector.Viewer)
|
|
assembly. A pick becomes an intent the same way whichever path resolves it: the viewer raises
|
|
`UsdViewOptions.PrimPicked`, and the client maps that prim path to the `LocationType` node the server
|
|
published under the controller's `Locations` folder, builds an intent naming that location, and submits it.
|
|
|
|
`UsdViewOptions.PickMode` selects how the pick is resolved:
|
|
|
|
| Mode | Behaviour |
|
|
|---|---|
|
|
| `Auto` (default) | Renderer-backed pointer picking first, falling back to the command prim only when renderer picking is unavailable |
|
|
| `Renderer` | Renderer-backed pointer picking only |
|
|
| `CommandPrim` | Watch `UsdViewOptions.CommandPrimPath` (default `/World/IntentCommand`) and raise the callback when its `targetPrim` changes |
|
|
|
|
Renderer-backed picking works: the OpenUSD viewer owns input handling, DPI scaling, physical-pixel
|
|
conversion and stale-revision retry, and reports hits through the host callback. Misses do not submit
|
|
intents. The gaps this used to work around were filed as `marcschier/openusd-dotnet` issues #1, #5, #8,
|
|
#9, #10 and #11, and all are fixed in the package version this sample ships against. The command-prim
|
|
path remains supported and lets picking work headlessly — which is also how an
|
|
[MCP agent](IntentViewerClient/README.md) drives the same robot.
|
|
|
|
## Prerequisites
|
|
|
|
* .NET SDK 10.0.
|
|
* The `--view` option needs the optional viewer assembly and its native OpenUSD payload, which is
|
|
supported on `win-x64`, `linux-x64`, and `osx-arm64`. A RID-less build or publish on a supported host
|
|
uses that host's payload; publish with an explicit RID for another platform. Everything else,
|
|
including both servers and the headless client, runs on every platform the stack supports.
|
|
|
|
## See also
|
|
|
|
* [Robotics developer guide](../../docs/Robotics.md) — the OPC 40010 model these servers expose.
|
|
* [Robot Intent](../../docs/Robotics.md#robot-intent) — the command surface, its lifecycle and its safety boundary.
|
|
* [OpenUSD](../../docs/OpenUsd.md) — the binding, the connector tool and the viewport.
|
|
* [Relative Spatial Location and Global Positioning](../../docs/Positioning.md) — how the cell sample
|
|
places its robots.
|