Proposal: URML (substrate-neutral robot intent) capability-manifest mapping for u-blox ZED-F9P / NEO-M9N / LEA-F9R GNSS / RTK

[idoco2003]

Hi @KumarRobotics maintainers (and a parallel post on @u-blox/ubxlib),

Proposing a URML v0.1 capability-manifest mapping for the u-blox ZED-F9P / NEO-M9N / LEA-F9R / MAX GNSS / RTK family over ubxlib (vendor) and KumarRobotics/ublox (community ROS driver). URML (Apache-2.0) is a substrate-neutral spec for robot intent.

Dual-surface engagement is the design point. u-blox/ubxlib is the vendor-direct embedded UBX-protocol library; KumarRobotics/ublox is the de facto ROS-side community driver. URML benefits from engaging both surfaces; the RFC asks how vendor and community see the boundary.

Shared GNSS-class Spec-RFC gap with RFC-0119 / RFC-0120 / RFC-0134.

This is proposal-only, part of URML's Move #10 outreach (perception-vendor wave, 29 engageable RFCs).

Full RFC: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0133-ublox-gnss-outreach.md

Questions worth maintainer input on (for u-blox):

1. Vendor-vs-community engagement boundary. Is ubxlib the canonical vendor surface with KumarRobotics/ublox as community add-on, or both first-class?
2. GNSS-class measurement_type shape (datum, fix-type granularity, constellation/frequency declaration).
3. RTK correction-source declaration. Should URML's manifest declare the RTCM correction-source pattern (NTRIP, base-station, SBAS, PPP)?

For KumarRobotics:

4. Driver maintenance posture. Long-term ROS 2 support, or research-fork only?
5. Cross-citation vs co-maintenance. Contributed URML-bridge example in the repo, or cross-citation the right shape?
6. Anything else.

Ido Yahalomi (URML maintainer, urml.dev, 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.