​
Cloud-Based

Unlike config schemas, configuration data is not stored in a git repository. Instead, configuration data is stored in the cloud and is accessible via the Miru dashboard or programmatically via the Miru REST API.

Miru uses the concepts of devices, tags, and metadata to structure how configuration data is stored and rendered.

Think of tags and metadata as a datastore for configuration data. Overrides reference this data to render config instances in the format of a particular config schema.

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

​
Tags

Groups of devices share configurations based on criteria like hardware, customers, location, etc. Miru uses the concepts of tag types and tags to group devices in a logical way.

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.

​
Metadata

Metadata is data stored about a particular tag.

Suppose a robots support certain features based on their hardware. This information can be stored as metadata for each tag in the hardware tag type.

For example, say robots powered by the NVIDIA Jetson Orin Nano can support the jump and spin features but not the backflip feature. This information can be stored as metadata for the NVIDIA Jetson Orin Nano tag.

A metadata schema defines the constraints on the metadata.

Metadata schemas are written in a configuration language like JSON Schema. The following JSON Schema is a plausible metadata schema for the robot_id metadata we showed above.

Miru requires every tag type to have a metadata schema describing what constitutes valid metadata for any tag of that tag type. For instance, the hardware tag type may have the following metadata schema to specify the features (jump, spin, backflip) supported by a given hardware.

Any tags of the hardware tag type can only store metadata that adheres to the hardware metadata schema.

Metadata schemas look eerily similar to config schemas but serve a different purpose. A metadata schema does not describe or enforce any constraints on the config instances that are deployed to devices. Metadata schemas only describe what constitutes valid metadata, effectively structuring the metadata stored for devices and tags.

​
Customization

Tags are defined by you. We gave examples with the hardware, accelerometer, and environment tag types. However, you can define any tag type you want and create any number of tags for each tag type.

This flexibility allows you to tailor tags to the needs of your application. Maybe your customers don’t have unique configurations. A customer tag type would be unnecessary then. You may have many different sensor types. Defining a tag type for each sensor type would then prove useful.

The metadata stored for devices and tags is also completely defined by you. We showed simple examples of metadata and their schemas: a device storing a robot_id and hardware tags storing supported features like jump, spin, and backflip. However, you can define the metadata custom to your application.