Open Source RoboticsRobots, software & learning

OM1

Software

Go-based modular robot-facing multimodal agent runtime with hardware action plugins and external-model/service routes. [1] [3]

Installation & first result →Official websiteGetting started

For
Robotics developers integrating high-level agent pipelines with hardware interfaces [1]
Source rights
Named licenses are documented by part. Review licenses
Unknowns
operating system, compute requirements not fully established. Review gaps

Source researched · Not tested by us
Sources checked · Research details

Licenses & related hardware

Requirements · Research details and dates

On this page

Overview

OM1 is a modular runtime for multimodal agents with robot-facing action plugins. The selected README describes a newer Go implementation and a deprecated Python branch, while warning that Go does not yet reproduce every Python capability. Choose the runtime and a specific input/action route before treating a list of supported robot families as a working integration. [1]

Is this for you?

Known limitations
  • Selected README says Go core pipeline has incomplete parity with deprecated Python runtime.
  • A model/service credential and account are distinct from source availability; no service price or free tier verified.
  • Robot SDK/HAL and exact connector setup remain separate; no physical action or network recovery test.
  • Source-inspected move connector can return without constructor error after Zenoh-open failure, retains a nil publisher after declaration failure, skips publication when not standing or publisher absent, and logs Put failure. Construction does not establish delivery/actuation; no runtime reproduction.

Editorial scope assessment from the cited implementation/documentation; no execution or compatibility test.

[1] [2] [3] [4] [5] [6] · Editorial assessment

What you need

Dependencies
  • Go>=1.25.0 and make for source build
  • Platform audio dependencies include PortAudio and ffmpeg; Zenoh C dependency setup via make deps
  • Documented service route needs an OM_API_KEY; external service usage/costs not established

[1] [2] [3] [4] [5] [6]

Installation & first result

Open the upstream getting-started guide [1]

  • Choose a prebuilt release or source route; for source inspect system dependencies, run the documented make deps then make build, and select configuration/credentials for a bounded non-motion example.
  • Preserve exact source/dependency/model versions and evaluate the selected workflow before connecting physical hardware or reusing data.

Editorial scope assessment from the cited implementation/documentation; no execution or compatibility test.

[1] [2] [3] [4] [5] [6] · Editorial assessment

Installation

Choose a prebuilt release or source route; for source inspect system dependencies, run the documented make deps then make build, and select configuration/credentials for a bounded non-motion example.

Editorial scope assessment from the cited implementation/documentation; no execution or compatibility test.

[1] [2] [3] [4] [5] [6] · Editorial assessment

Hardware, models & data

Inputs and outputs

Configured multimodal inputs and agent decisions to plugin actions and robot-interface messages.

Editorial scope assessment from the cited implementation/documentation; no execution or compatibility test.

[1] [3] · Editorial assessment

Project notes

Separate the build from service access

The source route requires Go 1.25.0 or later and make. The README lists PortAudio and ffmpeg system dependencies, then make deps and make build; go.mod confirms Go 1.25.0 and includes Zenoh and other dependencies. It also offers prebuilt releases. These are distinct routes, neither of which was built or installed here. [1] [6]

The documented conversation/service route uses OM_API_KEY. Having source does not supply an account, credential, service budget or a locally running model. Select the intended configuration and check its external services before attempting even a non-motion example. No service pricing, free tier, request or credential was verified by this review. [1]

For the documented non-motion conversation example, inspect config/conversation.json5 and its ASR/TTS configuration, then the upstream source-run command CONFIG=conversation make run. The pinned README describes a free-plan allowance of 50 OMCU renewed monthly. That is an attributed allowance in this source snapshot, not a fresh availability or usage-cost check; no service request was made. [1]

A plugin still needs the robot's interface

The README assumes the robot provides a high-level SDK or hardware abstraction layer. The inspected Unitree Go2 autonomy connector contains a cmd_vel topic configuration and Zenoh-related implementation. That is a concrete source path to inspect, not evidence that an arbitrary Go2 or humanoid can safely accept its commands without the matching SDK, middleware and configuration. [1] [5]

The registered connector is unitree_go2_autonomy/move, implemented in plugins/actions/unitree/go2/autonomy/move.go. Its configurable cmd_vel_topic defaults to cmd_vel, and the source publishes Twist messages while depending on odometry and path providers. Inspect those providers and topic configuration alongside the robot interface; none was connected or exercised here. [5]

Successful connector construction is not proof of command delivery. At this revision, a Zenoh-open failure is logged and can still return a connector without a constructor error; a failed publisher declaration leaves the command publisher unset. The moveRobot method returns without publishing when the reported robot state is not standing or the publisher is absent, and a failed Put is logged. These are source-inspected error paths, not failures reproduced on a robot. Check actual connection, publisher and device feedback rather than treating construction as actuation. [5]

The root software license is MIT. Robot firmware, purchased hardware, model APIs and other components have separate terms. No source build, network connection, simulator, robot movement, recovery behavior or latency claim was tested. [2]

What we checked

Source research only. Selected implementation/model text, repository tree and license declarations were inspected. No upstream compilation, dependency installation, simulator, network/USB/device integration, data collection, benchmark or physical robot test was performed. Source files are linked rather than redistributed; external services and paid products are not endorsed.

Not yet established

  • Requirements: operating system, host computer
  • Version-specific hardware compatibility (ecosystem tags alone do not establish it)

Updates

Upstream last updated
Not established
Latest release
Not established
Profile updated
Nov 1, 2026
Sources last checked
Nov 1, 2026
Next review
Dec 1, 2026
Reviewed revision
3589af1

Source files and licenses

Distinct robot-facing framework contribution with actual implementation/model content and a bounded documented next step. Review covers source artifacts, not operational performance or a complete tested deployment.

LayerAvailability / license
softwareavailable · MIT
Declaration for the scoped source implementation/documentation; dependencies, external services, model/data assets and inherited file-specific terms require separate checks. No blanket redistribution or operational clearance. [1] [2] [3]
documentationavailable · MIT
Declaration for the scoped source implementation/documentation; dependencies, external services, model/data assets and inherited file-specific terms require separate checks. No blanket redistribution or operational clearance. [1] [2] [3]

This profile is scoped to source implementation/model descriptions and an initial inspection workflow; no physical manufacturing design, pretrained checkpoint or dataset is selected for redistribution or tested deployment.

References

Each source links to the exact revision we read. “Used for” shows where this page relies on it.

Correction guidance · Discussion is not enabled · Profile format 0.7.0-draft.5

Change history