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.

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

speed: 10
features:
	spin: true
	jump: true
	backflip: false
accelerometer:
	id: acc_id_1
	offsets:
		x: 0.1
		y: 0.13
		z: -0.04
	scaling_factor:
		x: 1.0
		y: 1.02
		z: 0.99

​
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"
type: object
properties:
  speed:
    type: integer
    minimum: 1
    default: 10
  features:
    type: object
    properties:
      spin:
        type: boolean
        default: true
      jump:
        type: boolean
        default: false
      backflip:
        type: boolean
        default: false
    required: [spin, jump, backflip]
  accelerometer:
    type: object
    properties:
      id:
        type: string
      offsets:
        type: object
        properties:
          x:
            type: number
          y:
            type: number
          z:
            type: number
        required: [x, y, z]
      scaling_factor:
        type: object
        properties:
          x:
            type: number
          y:
            type: number
          z:
            type: number
        required: [x, y, z]
    required: [id, offsets, scaling_factor]
required: [device_id, speed, features, accelerometer]

​
Configs

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

For instance, your application may have a “motion control” config that controls the motion of your robot. The motion control 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 motion control 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 alongside code and are used to validate concrete configs before deployment. Once ready to deploy a new version of your application, these schemas are uploaded to Miru using the Miru command-line interface or 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 Policies

Policies are created to determine how configuration data is evaluated to produce concrete configs. Like configuration data, policies 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.