URML (open robot intent language): declaring a fuse state-estimation source, request for comment

[idoco2003]

Hi fuse maintainers,

URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: English sentence -> typed primitive -> static validation against a capability manifest and a safety envelope -> dispatch. URML declares frames and named locations and consumes a fused state estimate to ground them, it does not estimate state itself. fuse is exactly that: a graph-based, plugin-extensible state estimator.

A scope note: I separately reached Locus Robotics on the warehouse side a while back (a different conversation). This is specifically about the open-source fuse framework, not a re-pitch of that.

Two real questions. First, for a URML manifest to declare its localization source, how would you want fuse referenced relative to robot_localization, since fuse is in many ways its successor, just the published state and frame, or something that captures the graph structure? Second, would a fuse estimate's covariance be a reasonable input to a URML safety envelope?

Full write-up, with the manifest mapping table: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0339-fuse-outreach.md

One small thing: the GitHub API did not surface an SPDX license id at our verification time. Is fuse BSD-3-Clause?

Thanks for fuse, and for keeping a modern fusion framework open.

Ido Yahalomi (URML, greenvh@gmail.com)

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

[svwilliams]

how would you want fuse referenced relative to robot_localization

To get a better sense of what this question is asking, I'm referencing the following line from RFC-0339:

Position relative to robot_localization. For a URML localization / pose- source declaration, how should fuse be named and positioned next to robot_localization, given fuse is the graph-based alternative? Is a single pose-source enum with both as values the right shape?

Things get fuzzy here because fuse was designed to be extensible.

• Can fuse output the most recent pose estimate and covariance? Yes. This is functionality that exists within the open-source package.
• Do you have to configure fuse to publish the most recent pose and covariance? No. If your application does not need the current robot pose, fuse does not require you to configure that publisher.
• Can fuse output the last N poses and covariances from the graph? Also yes. I think this is also included within the open-source package.
• Can fuse output the best estimate and covariance of RF beacons placed in the world? Also yes. There is a toy example in the tutorials that creates a custom sensor and custom publisher. This functionality is not included in the open-source repo, but someone could implement those plugins and add them into the fuse configuration.

Unlike robot_localization, the output of fuse is highly configurable. That makes it a bit difficult to declare that fuse always does X, or only does Y.

But based on the components that are included in the open-source repo, estimating the pose and covariance of a single robot from multiple sensor inputs is the most likely configuration you will see in the world. And in that regard, it should mimic the robot_localization interfaces very closely.

would a fuse estimate's covariance be a reasonable input to a URML safety envelope

I want to be very careful about the word "safety" here. Nothing in fuse should be considered safety-rated in any way. The fuse covariance is the state estimator's best guess at the robot's pose uncertainty. But that is based on the input measurement covariance values from the sensor models (which may not be accurate), some sort of hand-tuned uncertainty propagation for the motion model (which may not be accurate), and an implicit assumption that all errors are Gaussian in nature (which is definitely inaccurate). fuse can be tuned to return a conservative estimate of the robot's pose uncertainty (larger than the true distribution of robot poses) or to return an optimistic estimate of the robot's pose uncertainty (smaller than the true distribution of robot poses). All of these statements are equally true for the EKF in the robot_localization package as well. Whether the pose covariance is useful in your context, I will defer to you to make that judgement.

Is fuse BSD-3-Clause?

Yes, fuse is using the BSD-3-Clause license
https://github.com/locusrobotics/fuse/blob/devel/LICENSE

[idoco2003]

Thanks @svwilliams, this is really helpful, and the configurability point lands.

For the language's purposes I'll model the common open-source configuration you describe (single-robot pose + covariance from multiple sensors, mimicking the robot_localization interface) as the default, and treat fuse and robot_localization as two values of one pose-source declaration, with an explicit note that fuse's output is configuration-dependent rather than fixed.

On "safety": point taken, and I want to be equally careful. The language does its checking statically against declared capabilities; it would not treat a fuse (or robot_localization) covariance as safety-rated. At most a covariance would be an optional, opt-in advisory a deployment chooses to surface, carrying exactly your caveats (input-covariance quality, a hand-tuned motion model, the Gaussian assumption, and conservative-vs-optimistic tuning). I'll make sure the write-up reflects that it is an estimator's best guess, not a safety guarantee.

Thanks too for confirming BSD-3-Clause.