​
Overview

This page is a reference of key terminology used in Miru. If this is your first time using Miru, please read the getting started guide and refer back to this page as needed.

​
Config Instance

A config instance is a particular instantiation 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 on a config instance. Miru uses JSON Schema, a popular open-source configuration language for defining the valid fields, types, and values in a JSON or YAML file. Below is an example of a config schema written in 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, which is widely used and has code generation for many languages. However, support for other configuration languages is coming soon. Here are some popular ones.

​
Config Type

A config type represents the parameters responsible for configuring a particular aspect of an application through time. For instance, an application may have a Mobility config type that controls the motion of a robot. The Mobility config type goes through many iterations—parameters are added or deprecated (creating new config schemas for the config type) and given different values (creating new config instances for the config type). The Mobility config type is not a particular instantiation of parameters or a particular specification of constraints. Instead, it is the parameters responsible for configuring the motion of a robot at any point in an application’s lifecycle.

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

​
Tag Types & Tags

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 based on their hardware:
  • Raspberry Pi 4 Model B
  • NVIDIA Jetson Orin Nano
  • NVIDIA Jetson Orin AGX
An environment tag type could group devices based on their stage of development:
  • Dev
  • QA
  • Beta
  • Stable
An accelerometer tag type could define a tag for each accelerometer:
  • Accelerometer 1
  • Accelerometer 2
  • Accelerometer 3
  • Accelerometer 4
A device’s accelerometer tag reflects the specific accelerometer in use by the device, which may change as accelerometers are replaced or upgraded.
Devices may be “tagged” with any number of tags as long as they are from unique tag types.