La interfaz está localizada; las descripciones y documentos de las Skills se traducen automáticamente con IA a su idioma. El código, los comandos, rutas y términos técnicos se mantienen en el original, y prevalece el documento del autor.
Explorar Skills
Despliegue y operaciones · SKILL.md

star-vla

star-vla

Operate StarVLA for vision-language-action model development, training plans, LeRobot data integration, benchmark evaluation, and policy deployment.

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentación de la Skill

GitHub

name: star-vla description: "Operate StarVLA for vision-language-action model development, training plans, LeRobot data integration, benchmark evaluation, and policy deployment." disable-model-invocation: true metadata: disco-role: operating license: NOASSERTION

StarVLA repo skill

Use this repo skill when the task involves StarVLA, a Lego-like vision-language-action (VLA) research codebase for robot policies. It routes model-family selection, dataset/robot integration, training launch planning, simulation benchmark evaluation, and policy-server deployment without requiring the original repository docs to be reopened.

Before acting

  1. Confirm the user has a StarVLA checkout or installed package for code execution. This skill is self-contained as guidance, but StarVLA workflows still require the package, model checkpoints, datasets, and benchmark or robot environments.
  2. Read references/repo-provenance.md if the current checkout may differ from the skill snapshot.
  3. Read references/installation-and-environment.md before installing dependencies or choosing CPU/GPU/ROCm/NPU paths.
  4. Run scripts/check_starvla_install.py for a safe import/backend diagnostic. It does not download weights, start servers, or run training.
  5. Use scripts/inspect_starvla_config.py to summarize a training/eval YAML before deciding which sub-skill owns the next step.

Route by task

User requestRead next
Choose QwenOFT, QwenFAST, QwenPI_v3, QwenGR00T, ACT, DiffusionPolicy, CosmoPredict2*, or Wan*; debug Framework ... is not implemented; inspect baseframework APIsmodel-frameworks
Build or modify a training command, explain YAML/CLI overrides, plan Accelerate/DeepSpeed launches, freeze modules, set LR groups, resume/checkpoint layouttraining-config
Add a LeRobot dataset, write modality.json, add a DataConfig, register data_mix, fix embodiment_tag or statistics/cache issuesdata-integration
Plan LIBERO, SimplerEnv, RoboCasa, RoboTwin, DOMINO, BEHAVIOR, VLA-Arena, Calvin, RoboDojo, or similar simulation benchmark evaluationbenchmark-evaluation
Serve a checkpoint, debug websocket/ZMQ clients, unnorm_key, server metadata, server-side unnormalization, real-robot bridge contractspolicy-deployment
Cross-cutting install/import/backend/data/config errorsreferences/troubleshooting.md, then the nearest sub-skill troubleshooting file

Core operating facts

  • StarVLA selects models with framework.name; the framework registry is populated by importing framework modules and maps string keys to classes.
  • All main policy frameworks follow the baseframework contract: forward(examples) for training, predict_action(examples) for inference, and compute_loss(tag, batch) for trainer routing.
  • StarVLA training scripts use YAML plus OmegaConf dotlist overrides. CLI override values have higher precedence than checkpoint or YAML defaults, and malformed overrides should be rejected early.
  • VLA datasets are LeRobot-format datasets with meta/modality.json, a robot DataConfig, and DATASET_NAMED_MIXTURES entries. Registry files are auto-discovered from benchmark or robot train_files/data_registry locations in a StarVLA checkout.
  • Current policy serving performs server-side action unnormalization and returns actions, not the older client-side normalized_actions contract still present in some example prose.
  • Full training, checkpoint inference, simulator evaluation, and real-robot deployment usually require GPU/accelerator resources, pretrained weights, datasets, simulator packages, robot SDKs, or credentials. Treat CPU import checks as preparation only, not as proof of those workflows.

Shared references

Safety and validation

  • Do not run network download scripts, benchmark-scale evaluation, physical robot control, or destructive data conversion without explicit user approval and the right environment.
  • Prefer dry-run planners and validators first: root install/config scripts, data-integration modality validator, training-config command planner, benchmark-evaluation checklist planner, and policy-deployment contract checker.
  • For final verification or repo maintenance tasks, use safe native tests that mock heavy dependencies before any GPU/simulator/robot run.
Skills guardadas