界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
数据与研究 · SKILL.md

embodied-workflows

embodied-workflows

【数据与研究】Guides RLinf embodied training, simulator, real-robot, reward-data, offline-RL, SFT, model, environment, Hydra configuration, and static preflight workflows.

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

name: embodied-workflows description: "Guides RLinf embodied training, simulator, real-robot, reward-data, offline-RL, SFT, model, environment, Hydra configuration, and static preflight workflows." disable-model-invocation: true metadata: disco-role: operating license: Apache 2.0

RLinf embodied workflows

Use this sub-skill when a task asks about RLinf embodied training setup, simulator or real-world robot recipes, VLA/VLM model and environment YAML choices, reward-model data collection, offline-RL/SFT intersections, or static preflight review before an expensive run.

Do not launch training, evaluation, robot motion, asset downloads, or hardware probes just because this skill is loaded. First identify the target environment family, model family, algorithm, assets, cluster topology, and whether the user wants planning only or an actual run.

Start here

  1. Classify existing YAMLs with scripts/list_embodied_configs.py when the user gives a config directory or repo root.
  2. Statically inspect a candidate YAML with scripts/check_embodied_config.py before proposing a launch.
  3. Use the recipe and configuration references below to reason about required paths, optional assets, overrides, log paths, video/data-collection settings, and safety constraints.

References

Routing boundaries

  • Ray startup, multi-node environment variables, and placement syntax details belong to setup-and-cluster; this skill only says which embodied components must be placed and what assumptions to check.
  • Standalone evaluation, checkpoint resume/inspection, TensorBoard/W&B/SwanLab operations, and debug-log interpretation belong to operations-evaluation-debugging.
  • Adding new environment/model source code, registries, workers, tests, Docker, or CI belongs to extension-development.

Safety defaults

  • Prefer static checks and small YAML reviews over real launches.
  • Treat real robot movement as a high-risk operation requiring an operator, workspace clearance, e-stop readiness, calibrated cameras/grippers, correct robot IP/serials, and explicit user approval.
  • Do not suggest ad-hoc hardware checks on a live robot; use dummy/simulation configs or read-only topology review unless the user explicitly asks for a controlled hardware validation.
我的收藏