URML (open robot intent language): wrapping a learned drone controller in a validated envelope — request for comment

[idoco2003]

Hi gym-pybullet-drones community,

URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: it validates a request against a capability manifest and a safety envelope, then dispatches. URML has an aerial drive type, and your project — the most-starred open drone-RL sandbox — is an ideal place to show URML wrapping a learned controller in a validated intent layer.

Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.

The idea is the decide-then-do split applied to learning: a URML aerial intent declares the goal and the envelope, a learned policy in a gym-pybullet-drones environment produces the low-level control, and URML validates the request against the declared limits before the policy is allowed to act. The policy is the actuator; URML is the typed, validated intent and the safety envelope around it. The RL sandbox is a clean demonstrator for "a natural-language goal, a learned controller, and a validator that refuses out-of-envelope requests."

Two real questions: (1) Is wrapping a learned drone controller in a validated intent layer + envelope interesting in the RL-sandbox context? (2) What should a URML capability manifest declare to describe a learned-controller drone honestly — drive type, altitude/speed limits, observation/action assumptions — and is the Gymnasium env interface the right seam or a higher-level mission wrapper?

Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0417-gym-pybullet-drones-outreach.md

Thanks for gym-pybullet-drones; a clean, popular open drone-RL suite is a great place to think about safety around learned control.

Ido Yahalomi (URML, greenvh@gmail.com)

AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.

[JacopoPan]

Hello @idoco2003

PRs (whether features, fixes, or 3rd party integrations) are always welcome but the main design driver of this repo is to adhere to the KISS principle (so the implementation should be frugal, an accompanied by a minimum working example).

[idoco2003]

Thanks, and KISS is the right instinct. I would not want URML to add a dependency to this repo.

So let me do it the frugal way round. I will put together a minimum working example on my side first: a URML manifest for a drone, plus a small script that validates a commanded action against the declared envelope (altitude, velocity, the bounds) and only then hands it to the gym-pybullet-drones control interface. Nothing in your repo changes, and nothing new gets imported into it.

If it turns out genuinely useful and stays small, I will bring it to you as a PR and you can judge it against KISS. If it does not, I will not spend your review time on it.

Thanks for the clear steer.

-- Ido

[idoco2003]

Done, and kept small. It is here: https://github.com/URML-MARS/URML/tree/main/examples/gym-pybullet-drones

It is two YAML files and one script, and it imports nothing from gym-pybullet-drones. The script declares a quadcopter and an arena (a 3 by 3 m box with a 2.5 m altitude cap), then validates a take-off, waypoint, land flight against them: the in-arena flight passes, a take-off above the cap is refused, and a waypoint outside the box is refused. Only the admissible flight is then mapped to target positions for a position controller like DSLPIDControl.

If a thin, opt-in wrapper along these lines would be useful in the repo, I am happy to open a PR and you can judge it against KISS. If it is not a fit, no problem, it costs you nothing where it is.

Thanks again for the steer.

-- Ido