Skip to main content
Framed content
This page is a brief overview of important concepts in Miru. Use it to familiarize yourself with Miru’s design and refer back to it as needed.

Config instances

A config instance, also known as a config or an instance, is a set of parameters used to modify the behavior of code. Config instances are stored as JSON files, which applications parse into a structured format for consumption. The following YAML file defines a config instance used to control 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 structure, types, and constraints of a config instance. It serves as a contract between code and configuration, ensuring that config instances are valid before being deployment to devices. Below are some example schema definitions in the JSON Schema and CUE schema languages.
x-miru-config-type: "mobility"
$schema: "https://json-schema.org/draft/2020-12/schema"
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

Config types

A config type represents a logical grouping of parameters used by your robot’s software. It consists of
  1. The config instances in its domain (the actual parameters deployed to devices)
  2. A versioned config schema, which defines the structure and constraints for those instances
For example, a Mobility config type houses configs related to the robot’s motion while a Perception config type houses configs related to the robot’s perception. Each config type has its own versioned schema, which its config instances must adhere to depending on the release they are deployed under.

Devices

A device is a machine to which config instances are deployed. This could be an NVIDIA Jetson, Raspberry Pi, industrial PC, or any other computer running your robot’s application.

Releases

A release is a version of software and its compatible config schemas. Within a fleet of robots, multiple software versions may be deployed — each release defines which config schemas are valid for that version. For example, software release v1.7.0 might specify the following schemas:
Config TypeSchema Version
MobilitySCH-FmoDN
PerceptionSCH-3JcLq
ManipulationSCH-HHDRn
Before deploying config instances to a device, the deployment’s release (v1.7.0) is used to verify that all required config instances are present and that each instance complies with the release’s schemas.

Deployments

A deployment is a set of config instances delivered to a device for consumption by your software. Deployments tie together config instances, releases, and devices to simplify configuration management and delivery.