microduck_rl
microduck_rl Deployment: Reproducible Simulation Workers and Hardware Gates
Deploy training and evaluation workers with pinned simulators, GPU isolation, artifact storage, and a guarded hardware handoff.
What you will learn
- Map environment, simulator, and runner
- Run a reproducible simulation
- Identify sim-to-real gates
Before you start
- Basic Git and command-line usage
- Comfort reading a project README
You can explain the project, run its documented first step, and decide what to verify before adopting it.
Key takeaways
- Workers need simulator and asset pinning.
- Checkpoints require telemetry and config provenance.
- Hardware is a separate, safety-critical deployment.
Simulation worker
Use an isolated GPU worker with pinned mjlab, Python, CUDA/PyTorch, environment assets, seeds, and checkpoint storage. Keep training and evaluation images distinct when possible.
Use the pinned source evidence, record versions and assumptions, and ask a qualified reviewer to validate the result before adopting it.
Artifact contract
Persist config, reward/termination definitions, code revision, checkpoints, telemetry, videos, and evaluation summaries. Make reruns possible without mutable latest tags.
Hardware boundary
Policy export, control frequency, actuator limits, sensor dropout, watchdogs, emergency stop, and operator approval are deployment gates, not afterthoughts.
Use the pinned source evidence, record versions and assumptions, and ask a qualified reviewer to validate the result before adopting it.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Build a pinned simulation image.
- 2
Run smoke/evaluation workers.
- 3
Store immutable artifacts and logs.
- 4
Complete hardware gate tests before transfer.
Copy-ready example
pinned image -> simulator worker -> checkpoint/telemetry
export -> timing/limits/watchdog tests
operator approval -> guarded hardware trialFrequently asked questions
Can training and serving use the same image?
They can, but separate images often make dependencies and safety boundaries easier to audit.
What is the emergency-stop requirement?
Use the qualified robot platform's independent stop path; do not rely on a policy process alone.
Sources
- microduck_rl repositorySource checked 2026-08-31