URML (open robot intent language): a declared, validated mission intent above INAV (request for comment)

[idoco2003]

Hi INAV maintainers,

INAV is navigation-first, which is what brought me here rather than to a stabilization-focused firmware. A waypoint mission with a geofence, altitude bounds, and a return-to-home condition is, in language terms, a goal plus constraints. That is exactly the shape URML (urml.dev, a small Apache-2.0 robot-intent language) is built to declare and check. This is a request for comment (cross-citation only, since INAV is GPL-3.0).

The mapping is direct: URML declares the mission as intent plus bounds, validates it against the craft's declared capabilities and a safety envelope, then hands it to INAV to fly. INAV keeps full ownership of navigation and control; URML is the checkable statement of what the mission is and whether the craft may do it. The geofence and failsafe conditions INAV already enforces are, in URML terms, a safety envelope, so an inadmissible mission could be rejected before upload rather than discovered in the air.

Two questions: does a declared, validated mission intent fit how INAV missions are actually defined and uploaded? And do INAV's existing geofence and failsafe bounds correspond closely enough to a written-down safety envelope that a shared representation would be worth anything?

Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0577-inav-outreach.md

Thanks for INAV; autonomous missions are where a declared, checkable intent earns its keep, and INAV is the clearest place in this firmware family to ask.

Ido Yahalomi (URML, greenvh@gmail.com)

AI-assisted prose, maintainer-reviewed before posting (see https://github.com/URML-MARS/URML/blob/main/VIBE.md). Human-only correspondence available on request.

[sensei-hacker]

This sounds to me like it may be a good fit. To check my understanding, please let me know if this is accurate:

URML is a bridge language and tooling that allows a human or LLM to state their goal for what the robot (vehicle in our case) should do, and any constraints it must obey, such as geofencing and other limits.

Such as "fly over to the water tower, then come back and land". Don't go past the road."

It's universal in the sense that it's not limited to INAV or any particular system -- it could interface with any autonomous system.

The tooling then checks whether the "robot" has the necessary capabilities to complete the stated mission within the stated constraints. If so, the tooling would the URML into an INAV mission.

That might be a good fit. It occurs to me that along with limits such as the geofencing, there are physical limits such as minimum turn radius, which are defined as INAV settings. INAV also has capabilities such as a sophisticated "return to home" mode which allows it to return to the starting point and land effectively, with some obstacle avoidance built-in. Such a system would probably want to leverage knowledge of such capabilities.

[idoco2003]

Thanks, and yes, you've understood it exactly right on all four points: you (or an LLM) state the goal and the constraints, URML checks the aircraft can do it within them, and compiles to an INAV mission.

I built a small worked example of that flow against an INAV-class aircraft: state "fly to the water tower and back, don't cross the road", validate it (the "don't cross the road" part is a geofence the check enforces), and compile the admissible mission to an INAV waypoint list (move_to -> WAYPOINT, return-to-home -> RTH, land -> LAND). A leg that crosses the road is rejected before anything compiles:
https://github.com/URML-MARS/URML/tree/main/examples/inav-mission

On your two points:

• Return-to-home: exactly the kind of capability URML should lean on rather than reimplement. It maps to a return_to_home primitive, so the mission just says "come back" and INAV's RTH (with its obstacle avoidance) does the work.
• Minimum turn radius: this is the part URML doesn't model yet, and I think you've found the right next field. The manifest declares max velocity and ceiling but no turn radius; it belongs as an aerial-kinodynamic limit, after which the check could reject a mission whose leg geometry is tighter than the aircraft can fly. I'd rather design that against a real INAV setup than guess: what does INAV expose for turn radius, and is the waypoint-mission format (the .mission / CLI wp list) the right compile target?

[b14ckyy]

I can help here I guess.

With the RTH you have properly described what happens. I assume the LLM is dependent on good documentation but the way how waypoints work and geozones with RTH route planning already is well documented.

The turn radius is a different story. At the moment it fully depends on wind conditions and some tuned settings like navigation bank angle, speed etc. That is hard to tell as it is not actively controlled. It just turns as much as it turns with the bank and speed. I am currently working on entirely controlled and precalculated turn system for waypoints that is that does precalculated turns based on the navigation bank angle and tries to fly exact precalculated turns with active bank adjustment. So turns get much more deterministic within certain limits (speed and wind can overwhelm it and then the turn can become bigger). But this will be a thing for INAV 10.

What we do NOT have is geozone avoidance for missions. The operator needs to be aware of geozones, hence we auto download them from the FC on connect in INAV configurator and other GCS do the same (MWPTools, my upcoming KiteGCS).

[idoco2003]

Thanks, this is exactly the grounding I needed.

On turn radius, agreed, let's drop it for now.
If it isn't actively controlled today there's no honest number to declare, and forcing one would just be fiction.
Worth revisiting once your precalculated turn system lands in INAV 10 and a real bound exists.

The line that jumped out at me was the other one.
You don't have geozone avoidance for missions.
That's the real fit.
The zones already exist and already get pulled down to the ground station, but nothing checks that a planned mission stays out of them before it flies. The operator has to.

That check is the whole point of the example.
URML takes the mission plus the zones and refuses any leg that enters one, before a single waypoint goes out.
It isn't adding a new constraint system, it's checking the mission against the zones you already define.

Since the ground station is where those zones land anyway, that's the natural home for it.
Which makes KiteGCS an interesting place for it to live.

If that's worth exploring I'd be glad to sketch how a mission and a set of zones flow through it, and come out either cleared or rejected with the offending leg.

[b14ckyy]

but nothing checks that a planned mission stays out of them before it flies

There is in fact a check and warning within INAV configurator that warns about a Geozone validation by the mission path.
Nevermind... its a general warning and not an active check.

[idoco2003]

That screenshot is the whole case in one image.

"Mission valid ❌" with "please ensure the mission does not violate the geozone" is the manual step. The tool knows there's a mission and a geozone, but it leaves the actual checking to the operator's eyes.

That's the exact thing URML computes. Same inputs you already have, the mission and the zones, but the answer comes out as a real pass or fail, with the offending leg named, not a reminder to look.

If it's useful I'll put together a small sketch against a real airspace kml and an INAV mission, showing it come out cleared or rejected. That's the piece that would slot into KiteGCS.

[b14ckyy]

just so you know, for the initial release I have not planned external APIs. But I am not opposed to look into that possibility later down the road.

Do you have Discord by chance to stay in touch directly for questions?

[idoco2003]

Makes sense, and no pressure on the API for the first release. A geozone check that lives inside the GCS is a fine place for it to start anyway.

Let's keep it here on the issue for now. Easy to pick back up when KiteGCS is further along and the API question is actually live.

Thanks for taking the time to dig into it, and good luck with the release.