Skip to main content
This page is a brief overview of important concepts in Miru. Use it to familiarize yourself with Miru’s design and refer back to it as needed.

​
Config instances

A config instance, also known as a config, is a set of parameters used to modify the behavior of code. Config instances are typically stored as JSON or YAML files (or even in a database), which applications parse into a structured format for consumption. The following YAML file defines a config instance for controlling a robot’s motion. 
max_linear_speed_mps: 1.2
max_angular_speed_radps: 1.0
obstacle_avoidance_enabled: true
navigation_mode: balanced
telemetry:
  upload_interval_sec: 60
  heartbeat_interval_sec: 10

​
Config schemas

A config schema defines the structure, types, and constraints of a config instance. It serves as a contract between code and configuration, ensuring that config instances are valid before being deployed to devices. JSON Schema is a popular open-source configuration language, useful for defining valid fields, types, and values for a config. Below is an example JSON Schema. 
$schema: "https://json-schema.org/draft/2020-12/schema"
title: Mobility
type: object
properties:
  max_linear_speed_mps:
    type: number
    minimum: 0.1
    maximum: 5.0
    default: 1.2
  max_angular_speed_radps:
    type: number
    minimum: 0.1
    maximum: 3.0
    default: 1.0
  obstacle_avoidance_enabled:
    type: boolean
    default: true
  navigation_mode:
    type: string
    enum: [conservative, balanced, aggressive]
    default: balanced
  telemetry:
    type: object
    properties:
      upload_interval_sec:
        type: integer
        minimum: 10
        maximum: 300
        default: 60
      heartbeat_interval_sec:
        type: integer
        minimum: 1
        maximum: 60
        default: 10
    required:
      - upload_interval_sec
      - heartbeat_interval_sec
required:
  - max_linear_speed_mps
  - max_angular_speed_radps
  - obstacle_avoidance_enabled
  - navigation_mode
  - telemetry
Miru only supports JSON Schema at the moment but support for other configuration languages is coming soon. Here are some popular ones:

​
Config types

A config type is a container for all config schemas and config instances that configure an aspect of a robot’s software. For instance, a robot may use a Mobility config type to configure motion parameters. The Mobility config type contains config schemas that undergo frequent updates — new fields are introduced, constraints are modified, and existing fields are deprecated. The Mobility config type also contains config instances, each of which satisfies one of its config schema versions. These config instances have a history for each robot—parameters are added, many are modified, and some are removed. Config types let you isolate and version subsets of parameters so they can be updated and managed separately from the rest of your system.

​
Devices

A device is the machine to which config instances are deployed. This could be an NVIDIA Jetson, Raspberry Pi, industrial PC, or any other computer powering the robot’s application. The Miru agent only supports devices running Linux; MacOS and Windows are not supported. For more more information on specific operating systems supported by Miru, please refer to the agent documentation

​
Releases

A release is a version of software and its compatible config schemas. Amongst a fleet of robots, multiple software versions may be deployed. Each release defines which config schema versions are valid for that software version. For example, software release v1.7.0 might specify the following schema versions.
Config TypeSchema Version
Mobilityv1.2
Perceptionv1.3
Manipulationv1.1
Before deploying config instances, the robot’s current release (v1.7.0) is used to validate that all config instances are present and satisfy the release’s config schemas.

​
Deployments

A deployment is a set of config instances made available on a device. Config instances are deployed by the Miru Agent, which writes the config instances to a subdirectory of the /srv/miru/config_instances directory on the target device. Deployments tie together config instances, releases, and devices, ensuring that every device runs a valid config instance for its software version. The following constraints are useful to understand what a deployment is:
  1. A deployment’s config instances are immutable. Once created, the config instances of a deployment cannot be updated. A new deployment must be created to modify a device’s config instances.
  2. Deployments belong to a single release. Deployments use their release’s config schemas to validate the config instances they contain.
  3. Deployments are associated with a single device. Deploying to two different devices requires a deployment for each device.
  4. Deployments are one-time use. Once removed from a device, a new deployment must be created to restore a device’s previous configurations.

​
Tag types & tags

Tags and tag types are used to group devices by some criteria. Formally, a tag type is a group of related tags, while a tag is an instantiation of a tag type. Examples illustrate this best: A hardware tag type could be used to group devices by their compute type and generation:
  • Raspberry Pi 4 Model B
  • NVIDIA Jetson Orin Nano
  • NVIDIA Jetson Orin AGX
An environment tag type could be used to group devices by their usage in different stages of development:
  • Development
  • QA
  • Beta
  • Stable
A region tag type could be used to group devices by the region they are deployed to:
  • east
  • west
  • central
Tag types and tags are defined by you, allowing you to tailor tags them to your application’s needs. Devices may be “tagged” with any number of tags as long as they are from unique tag types.