Proposal: URML integration with the Spot SDK (RFC for maintainer comment)

[idoco2003]

Hello Boston Dynamics SDK maintainers,

URML is an open-source, vendor-neutral language for describing robot intent that compiles down to whatever substrate sits below: ROS 2, PX4, the bosdyn SDK, AUTOSAR, and others. Apache 2.0. Spec, validator, and reference runtimes at https://github.com/URML-MARS/URML.

URML already ships a working SpotAdapter against the bosdyn Python gRPC SDK plus a spot_quadruped capability-manifest fixture. The adapter passes its hermetic unit suite without a bosdyn install (lazy import via the [spot] extra, credentialed by environment-variable name). RFC-0043 documents the URML-to-Spot mapping and asks for your review of the implementation choices.

This is not proposal-only; the adapter is real and merged. Earlier RFCs in our wave (RFC-0040 LeRobot, RFC-0041 ArduPilot, RFC-0042 Waymo) propose future work; RFC-0043 is the "we already ship this; please review the mapping" posture instead.

Full RFC:
https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0043-boston-dynamics-spot-integration.md

Routing note: this Issue is filed on spot-cpp-sdk rather than spot-sdk because the Python SDK repo has Issues disabled. Our first question below asks whether this is the right surface or whether you would prefer a different channel for proposals of this kind.

We are looking for your input on:

1. Outreach routing. Is spot-cpp-sdk the right Issue surface for a Python-SDK proposal, or should we move to forum.bostondynamics.com, a private support ticket cross-linked to a public note, or a different sibling repo?
2. Spot Arm SDK integration. URML returns not_supported_on_spot: arm today. What is the recommended path for wiring bosdyn-arm-* into an adapter that also drives the base via GraphNav?
3. License pinning. What is the current license string we should cite in the RFC and in our [spot] extra's documentation? GitHub's API returns NOASSERTION for spot-cpp-sdk and we want to pin the exact name correctly.
4. Mission / Orbit integration. URML's move_to(location) resolves a manifest-declared location to a GraphNav waypoint id. For deployments that use Mission Editor / Orbit, is there a recommended bridge from URML's named locations to Mission's waypoint identifiers, or should that stay a deployment concern outside URML?
5. SDK cadence. What is the maintainers' guidance on tracking Spot SDK majors, and are there near-term breaking changes that affect the mapped surface (move_to, dock, wait, measure, wait_for, report, scan)?
6. Downstream link. Would Boston Dynamics be open to a downstream link from one of the Spot SDK repositories' READMEs or wiki to URML's conformance run for any URML program validated against a Spot deployment?

URML is independent open-source work; nothing on our side is gated by your response. Happy to break any of these into separate Issues, or to move the conversation to whichever surface you prefer.

Thanks for any time you can spare.

Ido Yahalomi
URML maintainer
greenvh@gmail.com