FAQ
Answers to common questions from Miru users.
If you need clarification or have any further questions, please contact the founders.
1. How does the Miru agent work and how do I install it?
1. How does the Miru agent work and how do I install it?
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.
2. How does the Miru agent determine which config to fetch?
2. How does the Miru agent determine which config to fetch?
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.
3. What happens in the Miru cloud when a robot asks for a config?
3. What happens in the Miru cloud when a robot asks for a config?
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.
4. How does my application use the config from the agent?
4. How does my application use the config from the agent?
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.
5. What happens if the robot goes offline or restarts?
5. What happens if the robot goes offline or restarts?
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.
6. How can I verify the agent is running correctly?
6. How can I verify the agent is running correctly?
You can ping the agent’s test endpoint using:
If successful, you’ll see a JSON response like:
This confirms the Miru agent is installed, activated, and running.
7. How do I know what config my robot is currently using?
7. How do I know what config my robot is currently using?
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:
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.
8. Can I test configs locally without the agent?
8. Can I test configs locally without the agent?
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.
9. Does my schema need to be uploaded before using it in production?
9. Does my schema need to be uploaded before using it in production?
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.
10. What's the difference between a tag and a tag type?
10. What's the difference between a tag and a tag type?
- 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.
11. Why do I need both a config slug and a schema file?
11. Why do I need both a config slug and a schema file?
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.