Research-collab proposal: URML (substrate-neutral robot intent) for Maytronics Dolphin via dolphin-robot

[idoco2003]

Hi sh00t2kill + dolphin-robot community,

Posting this as a collaboration proposal to the dolphin-robot maintainer. I'm Ido Yahalomi, maintainer of URML, an Apache 2.0 specification for substrate-neutral robot intent. URML's Layer-2 primitive vocabulary sits one layer above ROS 2 / PX4 / vendor APIs / Home Assistant integrations.

URML's value proposition for Maytronics Dolphin via dolphin-robot: a homeowner writes "clean the pool floor and walls, then idle" in URML's natural-language layer; URML compiles to move_to(pool_floor) + move_to(pool_walls) + wait_for(cycle_complete) + report(idle); a MaytronicsDolphinAdapter dispatches via the dolphin-robot integration's WiFi-API surface. The substrate-neutral story is exactly URML's value proposition: the same URML program retargets across indoor floor (Roomba) + outdoor lawn (Automower) + aquatic pool (Dolphin) by manifest swap. Pool cleaning broadens URML's substrate-neutral claim across operating environments.

URML proposes the MaytronicsDolphinAdapter in a new reference/home-runtime/ package as the third adapter (after RoombaAdapter and HusqvarnaAutomowerAdapter).

License note: GitHub's API does not surface an SPDX license identifier on the dolphin-robot repo at verification time. URML's RFC asks the maintainer to clarify the license posture before any adapter code reuse.

Full RFC: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0103-maytronics-dolphin-outreach.md

This is proposal-only, part of URML's Move #8 outreach (home-assistance robotics + parts). Eight targets in this wave. URML has sent ~100 RFCs across eight outreach moves to date; single-digit substantive responses.

Feedback we'd value

1. License posture. Could you clarify the license on the dolphin-robot integration? GitHub's API did not surface an SPDX identifier at verification time.
2. Adapter home. URML repo (reference/home-runtime/src/home_runtime/maytronics/), dolphin-robot contributed example, both?
3. Authoritative manifest values. Model-specific mass, dimensions, sensor inventory (M700 / M600 / M400 / Premier).
4. Region-based mobility encoding. Is region_based the right manifest term, or should URML extend its schema to model the Dolphin's floor / walls / waterline / steps semantics directly?
5. Maytronics developer-relations channel. Known contact for a courtesy notification, or is the community surface the canonical engagement path?
6. Home-profile co-design. Future spec/profiles/home/ Layer-3 vocabulary interest?
7. Conformance lane. Open to a URML conformance line on the dolphin-robot README?
8. Anything else.

Thanks for the dolphin-robot project; pool cleaning is the smallest-installed-base niche in URML's Move #8 wave but the substrate-neutral story benefits from explicit aquatic-subsystem coverage.

— Ido Yahalomi (URML maintainer, urml.dev)

[elad-bar]

Hi Ido, it seems you need to contact Maytronics,
I will share the idea with their r&d but it seems based on what I know as not that feasible with the data the robot produces today.
For newer products of Maytronics it is coming out of the box as far as I know.
If you have any additional questions, you can direct email me at elad.bar@hotmail.com

[idoco2003]

Thank you, Elad. Substantive reply, and the offer to relay to Maytronics R&D is appreciated. Replying inline.

R&D relay. Yes, please. That's a much warmer channel than a cold Maytronics marketing-inbox email. To make the relay easier, here's a 2-paragraph R&D-readable distillation; use, edit, or discard as you see fit:

URML (Universal Robot Language, urml.dev, Apache-2.0) is an open specification for describing robot intent in a substrate-neutral way: one English sentence compiles to a verified program that runs on whatever robot operating system or vendor SDK the target supports. URML sits one layer above ROS 2, MAVLink, vendor SDKs, and consumer cloud APIs.

For Maytronics: URML proposes a MaytronicsDolphinAdapter wrapping the community dolphin-robot integration as a URML substrate, so end-users could write things like "clean the waterline and report when done" in natural language and have it execute on a Dolphin via dolphin-robot today. URML's value to Maytronics is reach (every URML-targeting LLM and orchestration tool would speak to Dolphin out-of-box) at zero engineering cost (URML's adapter wraps the existing API). If newer Maytronics products expose a richer data envelope, URML can target those next-gen products in a revised mapping. Full RFC: docs/rfcs/0103-maytronics-dolphin-outreach.md.

Feasibility caveat. URML's manifest schema is honest about substrate limits: capabilities a robot can't actually perform return an unsuccessful result rather than crashing or silently no-op'ing (normative in RFC-0014). MaytronicsDolphinAdapter would expose only what dolphin-robot reliably surfaces today: region-based mobility (floor / walls / waterline / steps), cycle status, scheduled-start trigger, error reporting via measure and report. Higher-fidelity primitives (precise pose, richer environmental sensors) return not_supported_on_consumer_pool_robot. Worth checking whether that lower-bound mapping is closer to feasible than the high-fidelity read might suggest.

Newer Maytronics products. If you can share even a high-level signal of which newer Dolphin products expose richer data envelopes, or which capability categories they unlock, URML can target those next-gen products specifically in a revised RFC. URML is happy to treat the current dolphin-robot API as the v0.1 floor and revise upward as newer products ship.

Email channel. Appreciate the offer at elad.bar@hotmail.com. I'll keep substantive discussion on this thread for the public record and use the email for side topics that don't belong here.

Thanks again for the time.

Ido