|
| 1 | +# LIBERO with Labtasker |
| 2 | + |
| 3 | +This lightweight integration gives you more built-in features with less custom |
| 4 | +orchestration. Labtasker handles task scheduling, retries and progress tracking, |
| 5 | +keeping the evaluation adapter small and the workflow simple: submit Tasks, |
| 6 | +start Workers and inspect results. On a single machine with a local-filesystem |
| 7 | +checkout, you can explicitly authorize its managed local server on first use. |
| 8 | + |
| 9 | +Compared with the traditional launcher, you get: |
| 10 | + |
| 11 | +- **Better load balancing through finer-grained parallelism:** Workers claim |
| 12 | + small trial batches, reducing idle time when some benchmark tasks take longer. |
| 13 | +- **Smaller retry units:** a failed batch is retried independently, limiting |
| 14 | + repeated evaluation to that batch rather than the full benchmark task. |
| 15 | +- **Real-time progress monitoring:** view running, completed and failed batches, |
| 16 | + along with evaluation progress, in one place through the Labtasker CLI or API. |
| 17 | +- **Agent-assisted control:** an agent can inspect Task errors, cancel Tasks |
| 18 | + or requeue failed work via the Labtasker skill and CLI. |
| 19 | + |
| 20 | +After environment setup, choose the path that matches your situation: |
| 21 | + |
| 22 | +- **First evaluation, no manifest cache:** [build the manifest cache](#first-run), then run evaluation. |
| 23 | +- **Subsequent evaluations, cache already built:** [reuse the cache](#run-evaluation) |
| 24 | + and submit evaluation directly, including when testing another checkpoint. |
| 25 | + |
| 26 | +## Setup |
| 27 | + |
| 28 | +Activate your **OpenWAM Python environment** and run commands from the repository |
| 29 | +root. Every `python` command in this guide uses that environment: dependency |
| 30 | +installation, submission, Workers, Labtasker queries and result summaries. The |
| 31 | +policy server also uses this Python by default. |
| 32 | + |
| 33 | +`LIBERO_PYTHON` points to the **separate LIBERO environment's Python**. |
| 34 | +The Worker invokes it automatically to build manifests and run simulator episodes; |
| 35 | +do not switch to that environment to start the Worker. Install the benchmark |
| 36 | +environment first as described in [README.md](README.md). |
| 37 | + |
| 38 | +```bash |
| 39 | +# LIBERO simulator Python, called automatically by the Worker |
| 40 | +export LIBERO_PYTHON=/path/to/libero/bin/python |
| 41 | +export LIBERO_PATH=/path/to/LIBERO |
| 42 | +# OpenWAM Python (active environment) |
| 43 | +python -m pip install -r benchmarks/libero/requirements-labtasker.txt |
| 44 | +``` |
| 45 | + |
| 46 | +**On one machine with the repository on a local disk, you can continue to |
| 47 | +the first-run commands below.** Their `--auto-start-local-server` flag starts |
| 48 | +Labtasker for you; later commands reconnect automatically. No separate server |
| 49 | +command, port or database configuration is needed. The project GPU Docker image |
| 50 | +already includes the full Labtasker package needed for this workflow. |
| 51 | + |
| 52 | +For multiple machines, or a checkout on NFS, WekaFS or Lustre, use the setup |
| 53 | +below first. Use it also if automatic startup reports an unknown filesystem. |
| 54 | + |
| 55 | +<details> |
| 56 | +<summary>Setup for multiple machines or a shared-filesystem checkout</summary> |
| 57 | + |
| 58 | +If your team already runs a Labtasker server, ask for its URL and token and |
| 59 | +skip to the client settings below. Otherwise, run this once on one machine: |
| 60 | + |
| 61 | +```bash |
| 62 | +# Supply your own secret token. |
| 63 | +export LABTASKER_SERVER_TOKEN=... # do not commit the token |
| 64 | +labtasker-server serve --connection http --host 0.0.0.0 |
| 65 | +``` |
| 66 | + |
| 67 | +By default, the server saves its records in `.labtasker/` under the directory |
| 68 | +where you start it. Its automatically created `server.db` stores submitted |
| 69 | +task inputs, task status and reported results. Keep this directory to retain |
| 70 | +your evaluation history. |
| 71 | + |
| 72 | +To choose another location, add just `--labtasker-root /path/to/openwam-eval`; |
| 73 | +`server.db` follows that directory automatically. `--database` only overrides |
| 74 | +the database file's location separately and is unnecessary for this setup. |
| 75 | +Local disks and NFS/shared storage are supported: the server detects the |
| 76 | +filesystem automatically. On shared storage, run only one server for that |
| 77 | +directory/database, even when several machines can access it. The local-disk |
| 78 | +restriction applies to `--auto-start-local-server`, not this manual command. |
| 79 | + |
| 80 | +Workers keep their execution logs and run records under their own |
| 81 | +`.labtasker/runs/`; setting the server's `--labtasker-root` does not move remote |
| 82 | +Worker logs. Benchmark logs, videos and detailed evaluation results still go |
| 83 | +to the output directories described below. |
| 84 | + |
| 85 | +The server listens on port **8000** by default. Keep this command running in |
| 86 | +its terminal or under your process supervisor. |
| 87 | + |
| 88 | +In each shell that submits tasks, runs Workers or reads results, set: |
| 89 | + |
| 90 | +```bash |
| 91 | +export LABTASKER_URL=http://SERVER_HOST:8000 |
| 92 | +export LABTASKER_TOKEN=... # same token as the server |
| 93 | +``` |
| 94 | + |
| 95 | +Replace `SERVER_HOST` with the server machine's reachable hostname or IP. |
| 96 | +Then follow the evaluation steps below, omitting `--auto-start-local-server`. |
| 97 | +All Workers must be able to access the submitted checkpoint and manifest paths. |
| 98 | + |
| 99 | +</details> |
| 100 | + |
| 101 | +For background, see the optional |
| 102 | +[Labtasker guide and demo video](https://luocfprime.github.io/labtasker/latest/). |
| 103 | + |
| 104 | +> [!TIP] |
| 105 | +> To let your coding agent help with Labtasker setup, task submission, progress |
| 106 | +> monitoring, troubleshooting and result summaries, install the **Labtasker skill**. |
| 107 | +> See the [Agent Skill guide](https://github.com/luocfprime/labtasker/blob/main/docs/guides/agent-skill.md) |
| 108 | +> for installation instructions. Describe the evaluation you want to run; the |
| 109 | +> agent can help translate it into the required Labtasker commands and settings. |
| 110 | +
|
| 111 | +<a id="first-run"></a> |
| 112 | + |
| 113 | +## First run: Build the manifest cache |
| 114 | + |
| 115 | +> [!TIP] |
| 116 | +> **Build once per evaluation setup; reuse for every checkpoint.** |
| 117 | +> The manifest keeps evaluation inputs fixed across parallel batches and retries. [Learn more](#manifest-details). |
| 118 | +
|
| 119 | +### 1. Submit manifest-building Tasks |
| 120 | + |
| 121 | +```bash |
| 122 | +python benchmarks/libero/labtasker_submit.py --auto-start-local-server \ |
| 123 | + --operation build_manifest |
| 124 | +``` |
| 125 | + |
| 126 | +Save the submission ID printed by this command. |
| 127 | + |
| 128 | +### 2. Start Workers on four GPUs |
| 129 | + |
| 130 | +Run these four lines in the same terminal, using OpenWAM's `python`. The trailing |
| 131 | +`&` starts each Worker in the background so all four run concurrently. Each Worker |
| 132 | +uses the configured `LIBERO_PYTHON` for the simulator. For a single GPU, |
| 133 | +run only the first line. |
| 134 | + |
| 135 | +```bash |
| 136 | +python benchmarks/libero/labtasker_worker.py --operation build_manifest --gpu 0 & |
| 137 | +python benchmarks/libero/labtasker_worker.py --operation build_manifest --gpu 1 & |
| 138 | +python benchmarks/libero/labtasker_worker.py --operation build_manifest --gpu 2 & |
| 139 | +python benchmarks/libero/labtasker_worker.py --operation build_manifest --gpu 3 & |
| 140 | +``` |
| 141 | + |
| 142 | +### 3. Check completion before evaluating |
| 143 | + |
| 144 | +Check the submission with: |
| 145 | + |
| 146 | +```bash |
| 147 | +python -m labtasker task count --filter 'metadata.submission_id == "SUBMISSION_ID" and status != "succeeded"' |
| 148 | +``` |
| 149 | + |
| 150 | +Replace `SUBMISSION_ID` with the printed ID. Continue when the count reaches zero. |
| 151 | + |
| 152 | +<a id="run-evaluation"></a> |
| 153 | + |
| 154 | +## Evaluate |
| 155 | + |
| 156 | +### 1. Submit evaluation Tasks |
| 157 | + |
| 158 | +Once the cache is ready: |
| 159 | + |
| 160 | +```bash |
| 161 | +python benchmarks/libero/labtasker_submit.py --auto-start-local-server \ |
| 162 | + -- --ckpt-dir /path/to/checkpoint |
| 163 | +``` |
| 164 | + |
| 165 | +Save this new submission ID for progress checks and result summaries. |
| 166 | + |
| 167 | +This uses all four suites, 50 trials per task and batches of 5. |
| 168 | +The latest checkpoint is selected at submission time. Everything after `--` uses |
| 169 | +OpenWAM's native deployment arguments; add overrides there only when needed. |
| 170 | + |
| 171 | +### 2. Start evaluation Workers on four GPUs |
| 172 | + |
| 173 | +Use OpenWAM's `python` again. `run_eval` is the default operation: |
| 174 | +Ports default to `8920 + GPU ID`, so these four Workers use ports 8920–8923. |
| 175 | + |
| 176 | +```bash |
| 177 | +python benchmarks/libero/labtasker_worker.py --gpu 0 & |
| 178 | +python benchmarks/libero/labtasker_worker.py --gpu 1 & |
| 179 | +python benchmarks/libero/labtasker_worker.py --gpu 2 & |
| 180 | +python benchmarks/libero/labtasker_worker.py --gpu 3 & |
| 181 | +``` |
| 182 | + |
| 183 | +Workers load models automatically and reuse them across batches. For a single |
| 184 | +GPU, run only the first line. Start these after manifest construction is complete. |
| 185 | + |
| 186 | +**For another checkpoint, submit evaluation again. No cache rebuild is needed.** |
| 187 | +If evaluation Workers are still running, they will claim the new Tasks; otherwise, |
| 188 | +start them again with the commands above. |
| 189 | + |
| 190 | +## Results |
| 191 | + |
| 192 | +> [!TIP] |
| 193 | +> **For routine operations, use the Labtasker Web UI or ask an agent with the Labtasker skill.** |
| 194 | +> Monitor progress, inspect errors and manage Tasks without writing commands yourself. |
| 195 | +
|
| 196 | +Use the ID printed by the **eval submission**: |
| 197 | + |
| 198 | +```bash |
| 199 | +python -m labtasker task list --filter 'metadata.submission_id == "SUBMISSION_ID"' |
| 200 | +python benchmarks/libero/labtasker_summarize.py \ |
| 201 | + SUBMISSION_ID --output-dir outputs/libero/summary |
| 202 | +``` |
| 203 | + |
| 204 | +The summary reads Labtasker Task records only and writes `task_summary.csv` and |
| 205 | +`suite_summary.csv`. Check the task counts before using a success rate as a final |
| 206 | +score: incomplete runs report partial results. Each successful eval Task also |
| 207 | +returns an `artifact_dir` for its detailed files. |
| 208 | + |
| 209 | +## Optional settings |
| 210 | + |
| 211 | +The defaults cover the normal workflow. Use `--help` for the full CLI. |
| 212 | + |
| 213 | +<details> |
| 214 | +<summary>Cache, evaluation settings and model options</summary> |
| 215 | + |
| 216 | +The cache defaults to `outputs/manifest-cache/libero`. Override it with |
| 217 | +`--manifest-dir PATH` on both build and eval submissions only if needed. Workers |
| 218 | +receive the selected paths from their Tasks. To rebuild, submit `build_manifest` |
| 219 | +with `--rebuild`; otherwise a matching cache with enough entries is reused. |
| 220 | +A 50-entry cache can serve a shorter `--num-trials` prefix. A missing cache is |
| 221 | +built normally by `build_manifest`; an existing invalid or too-short cache |
| 222 | +requires `--rebuild`. |
| 223 | + |
| 224 | +For a smoke run, add `--smoke` to both build and eval submissions. |
| 225 | +Use `--task-ids all|0,1` to select tasks, `--num-trials N` to request an |
| 226 | +ordered prefix, and `--note TEXT` to append a display-name suffix. The official |
| 227 | +default remains all four suites, all ten tasks per suite, and 50 trials per |
| 228 | +task; smaller values are for debug or small-scale evaluation. |
| 229 | + |
| 230 | +Changing a checkpoint or minibatch size does not require rebuilding the cache. |
| 231 | +To select a checkpoint explicitly, put `--ckpt-name FILE` after `--`; native |
| 232 | +`--config` and dotlist overrides also go there. Submission options go before `--`. |
| 233 | + |
| 234 | +Keep code, environments and checkpoint files fixed for reproducibility. Use |
| 235 | +versioned checkpoint paths; restart Workers if you overwrite model files in place. |
| 236 | + |
| 237 | +</details> |
| 238 | + |
| 239 | +<details> |
| 240 | +<summary>Multiple machines and Worker resources</summary> |
| 241 | + |
| 242 | +Configure the same `LABTASKER_URL` (and `LABTASKER_TOKEN` if required) on every |
| 243 | +machine, with a shared Labtasker server you operate. Manifest and checkpoint paths |
| 244 | +must be accessible at the submitted locations on every Worker. Use |
| 245 | +`--manifest-dir` when the default repository-local cache is not shared. |
| 246 | + |
| 247 | +The Worker uses `--port` exactly when supplied; it does not probe or silently |
| 248 | +switch ports. If a port is occupied, server startup fails. For multiple Workers |
| 249 | +on the same GPU, or another service using the default port, choose distinct |
| 250 | +ports explicitly with `--port`. |
| 251 | + |
| 252 | +Routes match automatically between submit and Worker for each operation. A |
| 253 | +custom `--route NAME` changes Worker compatibility; `--queue NAME` selects a |
| 254 | +Labtasker Queue. Pass matching values to the submitter and Worker. Each Worker |
| 255 | +owns its policy endpoint; model arguments belong on submission. |
| 256 | + |
| 257 | +Workers exit after 300 seconds idle by default; start them again for later work. |
| 258 | +Logs, videos and results default to `outputs/libero/<route>`; override with |
| 259 | +Worker `--output-dir`. Use `--server-python` only if the policy server needs a |
| 260 | +different interpreter from the active OpenWAM environment. |
| 261 | + |
| 262 | +</details> |
| 263 | + |
| 264 | +<details> |
| 265 | +<summary>Retries and interrupted submissions</summary> |
| 266 | + |
| 267 | +Failed Tasks retry up to 3 attempts by default. An eval retry repeats only its |
| 268 | +whole minibatch; a build retry repeats its benchmark task. After fixing an |
| 269 | +exhausted failure, use `python -m labtasker task requeue TASK_ID` and start a Worker. |
| 270 | + |
| 271 | +If submission is interrupted, repeat the same command with |
| 272 | +`--submission-id PRINTED_ID` before `--`. Existing Tasks are reused and missing |
| 273 | +ones submitted. Reusing that ID with changed parameters is unsupported. For a |
| 274 | +fresh evaluation, omit this option to generate a new ID. Native `task list` is paginated; follow |
| 275 | +`next_cursor` with `--cursor` when inspecting large submissions. |
| 276 | + |
| 277 | +</details> |
| 278 | + |
| 279 | +<a id="manifest-details"></a> |
| 280 | + |
| 281 | +<details> |
| 282 | +<summary>Why build an eval manifest first?</summary> |
| 283 | + |
| 284 | +An `eval_manifest` fixes the ordered evaluation instances and their reproduction |
| 285 | +information: accepted seeds and instructions for RoboTwin, or initial-state |
| 286 | +indices and reset RNG states for LIBERO. It describes what to evaluate, not |
| 287 | +motion planning or Worker scheduling. |
| 288 | + |
| 289 | +`build_manifest` prepares a complete benchmark task without policy inference. |
| 290 | +`run_eval` distributes its small batches across Workers, reducing idle time at |
| 291 | +the end of evaluation while preserving instance identity across retries and |
| 292 | +checkpoint comparisons. The stages are started separately by the user. |
| 293 | + |
| 294 | +`manifest_hash` identifies the concrete instances. Rebuilding the cache does not |
| 295 | +modify manifests already referenced by submitted Tasks. |
| 296 | + |
| 297 | +</details> |
0 commit comments