URML capability-manifest draft for Spot: where does the abstraction break?

[idoco2003]

Hi Tiffany (cc @jbarry-bdai, @mhidalgo-rai),

My team and I are working on URML, a small Apache 2.0 spec for describing
robot intent. It sits above ROS 2 / PX4 / vendor SDKs and statically
validates programs before anything actually moves. Project page:
https://urml.dev. Code: https://github.com/URML-MARS/URML.

URML's SpotAdapter is already on main (reference/legged-runtime/src/
urml_legged_runtime/spot.py). It talks bosdyn gRPC directly, no
spot_ros2 dependency, the same shape PX4Adapter uses for MAVLink. That
is URML's substrate-neutrality acid test, and Spot is the second proof.
v0.1 covers the locomotion subset (move_to, hover, dock, wait, measure,
wait_for, report, scan-stub); grasp/release return
not_supported_on_spot until a manipulation extension lands.

I have a draft capability manifest for Spot (the bare quadruped, no Spot
Arm) and the existing SpotAdapter code on main. Before any next step, I
want to know whether the manifest matches what spot_ros2 exposes today,
and whether the bosdyn-direct substrate cut is right for your downstream
users, or whether URML should compose RclpyAdapter over spot_ros2
instead (the way HuskyAdapter and JackalAdapter do for Clearpath bases).
A "this is wrong because X" reply is the most useful response I can
imagine.

Full packet (manifest + adapter pointer + program + reproduce + README):
https://gist.github.com/idoco2003/29d95db3c5138f5cd8ba8a157e607a49

Four questions, roughly in priority order:

1. Substrate cut. SpotAdapter talks bosdyn gRPC directly, not through
   spot_ros2. Is that the right cut, or should URML compose over your
   ROS 2 driver, using spot_driver/config/spot_ros_example.yaml's
   field shape, the way HuskyAdapter composes RclpyAdapter? The
   PX4Adapter parallel argues gRPC-direct is fine, but you own both
   layers and your read changes how the next non-ROS substrate gets cut.

2. Capability vocabulary. Does the manifest's shape match
   spot_ros_example.yaml's fields where they overlap? The ones I'm
   least sure about: frames (URML uses site + body; the driver
   exposes vision/odom/body per preferred_odom_frame),
   perception.cameras (one body_rgb aggregate vs five fisheye + an
   arm cam; spot_ros_example.yaml toggles via rgb_cameras: True|False), and whether mobility.station_keeping: true
   correctly captures Spot's active-balance posture-hold. Where would
   a researcher writing one of these naively get a wrong answer?

3. Spot Arm extension. v0.1 returns not_supported_on_spot for
   grasp/release. RAI shipped non-trivial arm PRs this year ([dependabot] Bump ros_utilities from 8198dee to d907d62 #168,
   Add an action interface for arm surface contact #671, Add Arm velocity commands to the Spot #704, Publish transient local arm availability flag #785). If a deployment has the Spot Arm, what's the
   minimum manifest field set and the minimum SpotAdapter extension
   that would actually matter to your downstream users, a single
   manipulation.grippers entry + bosdyn.client.manipulation_api_client
   calls, or something richer (arm-velocity, surface-contact, grasp
   pre-pose)?

4. Federal-procurement angle. URML ships a bundled US-federal default
   policy (RFC-0004) that statically checks vendor denylists, FCC
   Covered List entries, and country-of-final-assembly against a
   manifest's provenance block. Spot currently passes cleanly under
   that default (US assembly, Hyundai not on any covered list,
   §889-clean in DoD/civilian procurement today). BD is publicly
   lobbying NDAA FY26 / FCC on UGS rules, so this validator might be
   useful to your community, or it might be out of scope for
   spot_ros2 and better left to BD/Hyundai directly. Your read?

On what's working and what isn't yet. URML's ROS 2 reference runtime is
green on recorded gazebo-e2e runs (TurtleBot 4 + Nav2 + Gazebo). Evidence
ledger: https://github.com/URML-MARS/URML/blob/main/docs/launch/claims-audit.md;
the audit's honesty section is the source-of-truth on which workflow
runs are green. SpotAdapter is on main, hermetically unit-tested, and
exercised through the conformance runner on the mobile-patrol fixture
shape against MockROSAdapter. No live Spot hardware run yet; first run
is a calibration run by design.

URML is Phase 0 and there's no commercial program. We'll want maintainer
and governance participation eventually; not today. Today the ask is the
technical critique above.

Thanks,
Ido (greenvh@gmail.com)

[taughz]

The ROS 2 driver is intended to provide the same functionality of Boston Dynamics's Spot SDK, just through a ROS interface. If working with ROS is easier for you, we recommend using our driver. However, if you don't really care about ROS, it would only add another layer of complexity you don't really need. By the way, we are not Boston Dynamics.

[idoco2003]

Thank you, Tim. That answers the most important question cleanly: URML's SpotAdapter stays bosdyn gRPC-direct for v0.1, matching the substrate-neutrality cut PX4Adapter uses for MAVLink. If downstream spot_ros2 users ask for a ROS-composed path later, URML can add a sibling adapter that wraps spot_ros2, but the bosdyn-direct path is the canonical cut.

And thank you for the "not Boston Dynamics" clarification. Q4 had a BD-policy frame that was misdirected at the rai-opensource surface. I'll take BD-policy questions to BD directly and won't press Q4 here.

Two questions from the original post you may or may not have a few minutes for, no pressure either way:

• Q2 (capability vocabulary nits). Where spot_ros_example.yaml and URML's manifest overlap, the corners I'm least sure about are: frames (URML uses site + body; the driver exposes vision / odom / body per preferred_odom_frame), perception.cameras (one body_rgb aggregate vs five fisheye + arm; toggled in your example by rgb_cameras: True|False), and whether mobility.station_keeping: true correctly captures Spot's active-balance posture-hold. A "this is wrong because X" reply is the most useful response I can imagine; happy to inline the manifest YAML if that's easier than the gist.
• Q3 (Spot Arm extension). RAI shipped non-trivial arm PRs this year ([dependabot] Bump ros_utilities from 8198dee to d907d62 #168, Add an action interface for arm surface contact #671, Add Arm velocity commands to the Spot #704, Publish transient local arm availability flag #785). If a deployment has the Spot Arm, what's the minimum manifest field set and the minimum SpotAdapter extension that would actually matter to your downstream users? A single manipulation.grippers entry + bosdyn.client.manipulation_api_client calls, or something richer (arm-velocity, surface-contact, grasp pre-pose)?

Either, both, or none. Useful even at the lowest-touch level.

Thanks again for the substrate-cut answer.

Ido (greenvh@gmail.com)

---

Authoring disclosure: URML is the invention of Ido Yahalomi. The outreach prose is AI-assisted (Claude, under the maintainer's review). See VIBE.md. The maintainer reads and approves every post before it ships. Reviewers who prefer human-only correspondence are welcome to say so.

[idoco2003]

Following up on the Spot Arm extension scope (Q3) you flagged as worth a closer look. Two pieces of the URML spec grew in that direction since this thread, both now on main:

Whole-body / bimanual manipulation (RFC-0010). grasp/release gained an arm selector (left/right/any or a named arm), the manifest gained manipulation.arms (per-arm declaration with its own gripper), and there is a new bimanual primitive for coordinated two-arm intent. For Spot that maps cleanly: a single Spot Arm is one declared arm addressed by name, and the same model scales to a two-arm platform without a vocabulary change.

Legged kinematic structure (RFC-0384). A whole_body manifest block declares the legged kinematic structure plus stability limits (center-of-mass bounds, support polygon). That is the locomotion-side complement: Spot as a quadruped base declares its structure and stability envelope, and the arm rides on top as a declared manipulator.

Together they close most of the Spot-specific gap this thread opened with: the legged base and the optional arm now each have an honest declaration the validator can check, rather than being forced through the wheeled-plus-single-arm shape. The SpotAdapter stays bosdyn-direct as we settled earlier.

No ask here, just closing the loop since you pointed at the arm scope. Happy to hear if the manipulation.arms shape reads right for how the Spot Arm is actually addressed.

(As before: the URML prose is AI-assisted under the maintainer's direction; see VIBE.md. Replies here are checked by a human.)