This guide provides a high-level overview of using Miru.

This is NOT a tutorial detailing the installation and usage of Miru in depth. For this, refer to the getting started guide (after reading through these core concepts).

To begin, let’s define Miru’s terminology surrounding configurations.

​
Terminology

​
Concrete Configs

A concrete config is a particular instantiation of parameters used to alter the behavior of your code.

You’re probably storing concrete configs as JSON or YAML files (or potentially in a database somewhere), which your application parses into a structured format for consumption. The following YAML file defines a concrete config 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 constraints on a concrete config.

Miru uses JSON Schema, a popular open-source configuration language for defining the valid fields, types, and values in a JSON or YAML file. Here 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

​
Configs

A config represents the parameters responsible for configuring a particular aspect of your application through time.

For instance, your application may have a Mobility config that controls the motion of your robot. The Mobility config goes through many iterations—parameters are added or deprecated (creating new config schemas for the config) and given different values (creating new concrete configs for the config).

The Mobility config is not a particular instantiation of parameters or a particular specification of constraints. Instead, it is the parameters responsible for configuring the motion of your robot at any point in your application’s lifecycle.

​
Workflow Primer

The Miru workflow has four stages.

1

Define Schemas

Config schemas are defined in a git repository and used to validate concrete configs before deployment. Once ready to deploy a new version of your application, these schemas are uploaded to Miru via the command-line interface or in a continuous integration pipeline.

2

Set Configuration Data

Configuration data used to generate concrete configs is defined and stored in the cloud. Configuration data is edited in the Miru dashboard or programmatically with the Miru REST API.

3

Create Overrides

Overrides are created to determine how configuration data is evaluated to produce concrete configs. Like configuration data, overrides live in the cloud and are edited in the Miru dashboard or programmatically with the Miru REST API.

4

Deploy

Concrete configs are deployed to robots via the Miru SDK. The SDK fetches updated configurations from the cloud, making them readily available to your application.