Basics
- Introduction
- Vocabulary
- Core Concepts
- Getting Started
- FAQ
Agent / SDK
FAQ
Answers to common questions from Miru users.
If you need clarification or have any further questions, please contact the founders.
The Miru agent is installed as a systemd service on the robot. During activation, it is authenticated using a token retrieved from the Miru UI. Once activated, the agent becomes tied to a specific device ID.
To install the agent, follow the instructions in the Install the Agent guide. The page includes the install script, activation steps, and supported platforms.
After installing, you’ll need to retrieve the activation token for the desired device from the Devices page in the dashboard. Paste the token into the activation prompt in your terminal to complete setup.
Once activated, the agent is ready to serve configs to the robot’s application via a UNIX socket located at /run/miru/miru.sock.
Your application uses the Miru SDK and provides the path to the config schema file (e.g. motion-planner.schema.yaml).
The Miru agent:
- Grabs the hash of the schema file, which is provided by the SDK and acts as a unique version identifier.
- Combines this schema hash with the device ID to identify which config instance to fetch from the cloud.
- Uses the
$miru_config_slugfield inside the schema to determine the config slug.
Once the agent sends a request with the schema hash and device ID:
- The Miru cloud matches the request to the correct version of the config schema.
- It evaluates any overrides defined for that config.
- The robot’s tags (like
region,hardware, orrobot_model) are used to resolve values from tag metadata into a final rendered config.
The resulting config instance is then pulled to the device by the agent.
This allows each robot to receive a config tailored to its tags, even if the schema is the same across the fleet.
The SDK connects to the agent over the UNIX socket and passes it the path to the schema file. The agent then returns the config instance associated with that schema and client.
The SDK returns this config as:
- A structured, typed object (e.g., in C++), and/or
- A raw JSON blob, depending on the SDK/language used.
This lets your application consume configs in a strongly typed way, aligned with the schema definition you provided.
The Miru agent caches the rendered config locally on disk. If the robot restarts or loses network connectivity, the agent will continue to serve the last known-good config to the SDK.
This ensures robustness in the field where network drops or power cycles are common.
You can ping the agent’s test endpoint using:
sudo curl --unix-socket /run/miru/miru.sock http://localhost/v1/testIf successful, you’ll see a JSON response like:
{"server":"miru-config-agent","status":"ok"}This confirms the Miru agent is installed, activated, and running.
The agent always serves the latest rendered config instance it received from the cloud. You can inspect this using the Miru SDK on the device.
To do this, use the from_agent() method and provide the path to your config schema:
auto config_instance = miru::configs::ConfigInstance::from_agent("/path/to/schema.yaml");You can then retrieve individual parameters or iterate over all parameters in the config instance.
Note: if the device is offline, the agent serves the last known-good config instance from its local cache.
Yes. The Miru SDK supports a development mode using from_file() to load config instances from disk.
This is useful for iterating quickly on schemas and config instances without needing to install or activate the agent. Most teams use this feature in their development environment.
Yes. The Miru agent uses the hash of the schema file to identify which schema version to render from. That schema must already be uploaded to the cloud using miru schema push.
If the agent sees a schema hash it doesn’t recognize, config rendering will fail.
- A tag type is an attribute of a device (like
region,robot_model, orhardware). - A tag is an instantiation of that tag type (like
Amazon,v4, orJetson Orin Nano).
Each device can have one tag per tag type. These tags are used to resolve overrides and render the correct config instance for each device.
The schema file defines the structure and constraints of your config: field names, types, default values, and limits.
The config slug, declared at the top of the schema as $miru_config_type_slug, identifies which config type the schema belongs to (e.g. mobility, motion-planner).
Miru uses the slug to:
- Group all schema versions and config instances under a single config type.
- Resolve overrides and render the correct config instance for each device.
In other words, the slug links your schema to the broader lifecycle of that config type, while the schema defines what’s valid.
Was this page helpful?