Skip to main content
This quick-start guide walks through deploying your first configuration with Miru. Here’s what we’ll cover.
1

Defining a config schema

We’ll create the Mobility config type, install the Miru CLI, and push a schema to Miru.
2

Installing the agent

Next, we’ll install the Miru Agent on your target device and activate it.
3

Deploying config instances

Finally, we’ll deploy config instances and make some edits.

​
Create an account

If you don’t already have an account, navigate to the sign up page and follow the instructions.

​
Concepts

Before we begin, let’s define the key configuration concepts in Miru.

​
Config instances

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 schemas

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:
While schemas are recommended, you can use Miru schemaless.

​
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. The Mobility config type is useful for managing a subset of parameters for your robots, which may be updated independently of other parameters.

​
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 machine powering a robot.

​
Releases

A release is a version of software. Amongst a fleet of robots, several software versions may deployed at any given time. This makes managing configurations, which the software relies on, a critical challenge. Releases are used to manage this complexity. A release contains a set of config schemas that define the valid config instances for a given version of software. Say our software application v1.7.0 requires a config instance for three different config types:
  1. Mobility
  2. Perception
  3. Manipulation
Release v1.7.0 in Miru would then define a config schema for each of the required config types:
  1. Mobility - schema v1.2
  2. Perception - schema v1.3
  3. Manipulation - schema v1.1
Before deploying config instances to a robot, the robot’s current release (v1.7.0) is used to validate all config instances are present and satisfy the release’s config schemas.

​
Deployments

A deployment is a set of one or more 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 serve as the “glue” that ties together config instances, releases, and devices, providing a structured way to manage configurations. As such, 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.
If these concepts are a bit fuzzy at the moment, don’t worry! Seeing these concepts in action will solidify their meaning.
With these concepts in mind, let’s begin!