Skip to main content
This page is a reference of key concepts in Miru. Use it to familiarize yourself with Miru’s terminology and refer back to it as needed.

​
Config Instance

A config instance is a set of parameters used to alter the behavior of code. Config instances are typically stored as JSON or YAML files (or potentially in a database somewhere), 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 Schema

A config schema defines the constraints for a config instance. Miru uses JSON Schema, a popular open-source configuration language, for defining the valid fields, types, and values in a config instance. 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
While Miru only supports JSON Schema at the moment, other configuration languages are coming soon. Here are some popular ones:

​
Config Type

A config type represents the parameters that configure an aspect of a robot’s software, regardless of the version of that software. For instance, a robot may have a Mobility config type that configures its motion. The Mobility config type goes through many iterations—parameters are added or deprecated (creating new config schemas) and given different values (creating new config instances). The Mobility config type is not a particular config instance nor a particular config schema. It simply refers to the motion-related parameters for the robot in general.

​
Device

A device is the machine to which config instances are deployed. This could be an NVIDIA Jetson, Raspberry Pi, industrial PC, or any other machine powering a robot.

​
Release

A release represents the version of robot software. In Miru, a release defines a set of config schemas used to validate configurations for a given software version. So, a config schema defines the configuration constraints for an aspect of the robot’s software. A release then uses a set of config schemas to define the configuration constraints for all of the robot’s software.

​
Deployment

A deployment is a set of config instances made available on a device for some interval of time. A deployment adheres to a release and must satisfy that release’s constraints: it must have a valid config instance for each config schema in the release. So, a config instance contains parameters for part of the robot’s software. A deployment then uses a set of config instances to define the parameters for all of the robot’s software.

​
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.
⌘I