Hi - I answer from the OpenSmartRoute documentation: routing, the API, plans and quotas, self-hosting. Ask away, or open a support ticket if you need a person.
Grounded in the docs - follow a source before acting on it.
sim2real-transfer - Skill - OpenSmartRoute
Skillv1.0.0
sim2real-transfer
Use when a policy or controller trained/tuned in simulation must run on the real robot — close the gap with domain randomization for what you can't measure and system identification for what you can.
Imported from diytechy/ai-template (project-trajectory/skills/sim2real-transfer/SKILL.md). Install upstream with npx skills add diytechy/ai-template --skill sim2real-transfer. Copyright stays with the author.
When to use. Before any sim-trained behavior touches hardware. Why: the sim-to-real gap fails
policies silently; randomize what you can't identify, identify what you can.
Procedure.
System-ID measurable params (joint friction, rotor inertia, actuator delay) against real logs so the nominal sim is correct.
Domain-randomize the rest (mass, friction, latency, lighting, textures) — tune ranges (too wide is unlearnable, too narrow overfits).
Validate across engines (dual-sim) before hardware.
Done when: the policy holds up in a held-out randomized sim and a supervised real-robot trial, with the gap quantified.
Knowledge: KNOWLEDGE-LIBRARY.md §B3.
Use it
Copy one of these into your project. Installing also returns the manifest and these snippets.
# after Install: the listing is in your workspace's routing pool - a plan picks it for its slot
curl -s -X POST https://api.opensmartroute.ai/api/v1/route -H 'Authorization: Bearer $OSR_API_KEY' -H 'Content-Type: application/json' -d '{"text": "...", "plan": true}'
Manifest
An Open Capability Manifest: the router reads it to know what this does, what it costs and when to pick it.
{
"ocm": "1",
"id": "diytechy-ai-template-sim2real-transfer",
"kind": "skill",
"name": "sim2real-transfer",
"description": "Use when a policy or controller trained/tuned in simulation must run on the real robot — close the gap with domain randomization for what you can't measure and system identification for what you can.",
"publisher": "diytechy",
"version": "1.0.0",
"capabilities": {
"domains": [
"observability"
],
"tags": [
"skill-md",
"sim-to-real",
"domain-randomization",
"system-identification",
"rl",
"robustness",
"github"
],
"languages": [
"en"
]
},
"quality_prior": 0.6,
"examples": [
"Use when a policy or controller trained/tuned in simulation must run on the real robot — close the gap with domain randomization for what you can't measure and system identification for what you can."
],
"primary": false,
"metadata": {
"source": {
"provider": "github",
"repository": "https://github.com/diytechy/ai-template",
"path": "project-trajectory/skills/sim2real-transfer/SKILL.md",
"ref": "3abeb636fd109988da0aa2028bcc9055f2dc4065",
"url": "https://github.com/diytechy/ai-template/blob/3abeb636fd109988da0aa2028bcc9055f2dc4065/project-trajectory/skills/sim2real-transfer/SKILL.md",
"key": "diytechy/ai-template/project-trajectory/skills/sim2real-transfer/SKILL.md"
}
},
"instructions": "**When to use.** Before any sim-trained behavior touches hardware. *Why:* the sim-to-real gap fails\npolicies silently; randomize what you can't identify, identify what you can.\n\n**Procedure.**\n1. System-ID measurable params (joint friction, rotor inertia, actuator delay) against real logs so the nominal sim is correct.\n2. Domain-randomize the rest (mass, friction, latency, lighting, textures) — tune ranges (too wide is unlearnable, too narrow overfits).\n3. Validate across engines (dual-sim) before hardware.\n4. **Done when:** the policy holds up in a held-out randomized sim *and* a supervised r",
"cost": {
"context_tokens": 170
}
}
Fetch it by URL: GET /api/v1/registry/diytechy-ai-template-sim2real-transfer/manifest?version=1.0.0
Reviews
Star ratings from people who tried it. One review per account; edit yours any time.
No reviews yet. Install it, try it, and be the first to rate it.
