Skip to content

URML (open robot intent language): consuming the estimate a SymForce-powered estimator produces (request for comment) #464

@idoco2003

Description

@idoco2003

Hi SymForce community,

URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: an intent becomes a typed primitive, validated against the robot's declared capabilities and a safety envelope, then dispatched. SymForce is the factor-graph / optimization engine behind state estimators and SLAM back-ends, and URML consumes the estimate such an engine produces -- it does not estimate.

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

The layering: SymForce optimizes the factor graph that yields a robot's state estimate. URML resolves its frames and validates intent against the active safety envelope using that estimate. URML is the declarative intent + envelope layer above the estimator; SymForce is the optimization that produces the estimate.

Two real questions: (1) is "a SymForce-powered estimator produces the state estimate, URML consumes it" a sensible layering? (2) Is an optimization library the right altitude to engage, or is the seam better at a SLAM / estimator that wraps SymForce?

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

Thanks for SymForce; the codegen-plus-optimization approach is the engine under a lot of the estimates a declared-world intent layer consumes.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions