SERA: Hướng dẫn VLA π0.5 có trí nhớ trên RoboMME

Robot được yêu cầu gắp một vật ba lần. Sau lần thử thứ hai, camera vẫn thấy vật nằm trên bàn. Robot đã hoàn thành hai lần, hay một lần gắp bị trượt? Một ảnh hiện tại không đủ để quyết định. Robot cần giữ tiến độ và đối chiếu nó với bằng chứng thực thi.

SERA — Self-Evolving Robotic Agent đặt một lớp harness có thể chỉnh sửa quanh VLM planner và VLA executor. Harness là phần mềm chuẩn bị đầu vào, giữ ngữ cảnh, kiểm tra lệnh và đưa phản hồi trở lại vòng quyết định. Điều cần hiểu ngay: SERA giữ nguyên trọng số π0.5; thành phần tự cải thiện là harness điều phối tác vụ.

Bài hướng dẫn dựa trên paper SERA của Tingwen Du và cộng sự, preprint 2026, repository chính thức và mã nguồn liên kết trong từng phần, được kiểm tra ngày 25/10/2026. Các lệnh dưới đây là hướng dẫn đối chiếu với source release, chưa được chúng tôi chạy benchmark lại. Mục tiêu thực hành là dựng base agent, chạy một episode, rồi hiểu điều kiện cần để phát triển harness.

1. SERA giải quyết vấn đề gì?

VLA, viết tắt của Vision-Language-Action, biến ảnh, chỉ dẫn và trạng thái robot thành hành động. VLM tập trung hiểu ảnh và ngôn ngữ; trong hệ phân cấp, nó có thể chọn subgoal cho VLA thực hiện. Ví dụ, planner quyết định “gắp khối xanh”, còn executor tạo chuyển động tay và gripper.

Trong tác vụ cần history, cùng một ảnh có thể ứng với nhiều trạng thái tiến độ. Hãy hình dung một đèn báo xuất hiện ở đầu episode rồi biến mất. Đến lúc chọn đích đặt vật, robot phải dùng thông tin đã thấy trước đó. Hoặc robot phải nhớ thứ tự một chuỗi thao tác, đồng thời nhận ra bước vừa làm có thực sự thành công.

RoboMME cung cấp 16 tác vụ chia thành bốn nhóm. Counting kiểm tra thông tin theo thời gian; Permanence liên quan thông tin không gian khi tín hiệu không còn trực tiếp hiện diện; Reference yêu cầu giữ thông tin đối tượng; Imitation đòi hỏi nhớ quy trình. Benchmark tách train, validation và test với episode cố định để so sánh.

SERA cung cấp một cách thử nghiệm memory ở tầng điều phối. Nếu muốn đối chiếu với cách đưa memory vào policy, bạn có thể đọc REKI và register memory trong VLA. Hai hướng can thiệp vào những vị trí khác nhau của hệ thống.

Nguồn: Figure 1, paper SERA. Hình giải thích vì sao quan sát tương tự có thể cần quyết định khác nhau.

2. Kiến trúc: giữ mục tiêu, cập nhật bằng chứng

Trong source release, luồng chạy đi qua ba phần: simulator RoboMME, planner service và policy service. Tài liệu planner chỉ rõ entry point của từng phần, thuận tiện khi cần tìm lỗi.

Nên phân biệt episode guidance với runtime context. Guidance giữ mục tiêu được suy ra lúc khởi tạo; runtime context theo dõi diễn biến đang xảy ra. Trong ví dụ gắp vật, mục tiêu có thể giữ nguyên suốt episode nhưng trạng thái “đã nắm chắc” cần cập nhật sau chuyển động.

Planner lấy một command từ vocabulary mà executor đã biết. Một command có thể yêu cầu grounding point: vị trí chỉ rõ đối tượng hoặc đích trong ảnh. Harness kiểm tra cấu trúc trước khi truyền xuống executor. Một câu mô tả tự do nghe hợp lý chưa chắc phù hợp với giao diện policy đã học.

Bạn có thể hình dung vòng chạy như sau; đây là sơ đồ khái niệm, không phải API Python:

Instruction + demonstration
          |
          v
Episode guidance + runtime context
          |
Recent images + supported commands
          |
          v
VLM planner -> checked grounded command
          |
          v
Frozen pi0.5 -> action chunk -> RoboMME
          |                       |
          +---- execution feedback+

Điểm dễ nhầm là “đã phát lệnh” không đồng nghĩa “đã làm xong”. Khi debug, hãy tìm quan sát sau hành động. Nếu gripper đóng nhưng vật vẫn nằm trên bàn, tăng bộ đếm thành công ngay sẽ làm sai mọi quyết định sau đó. Đây là bài học thiết kế có thể áp dụng cả khi bạn chưa dùng SERA.

Nguồn: Figure 2, paper SERA. Harness được chọn trước test; context vẫn cập nhật trong episode.

3. Chuẩn bị máy và hai môi trường Python

Theo hướng dẫn upstream, bạn cần Linux, Python 3.11, GPU NVIDIA hỗ trợ CUDA và Vulkan renderer hoạt động cho RoboMME. Policy và simulator dùng hai môi trường Python riêng. Có hai GPU sẽ giúp tránh tranh chấp bộ nhớ; repo cũng cho phép cùng dùng GPU 0 nếu bộ nhớ đủ. Không có cấu hình VRAM tối thiểu được bảo đảm trong README, vì vậy đừng coi một con số tự ước lượng là yêu cầu chính thức.

Các lệnh từ đây dành cho máy thực hành riêng của bạn, chạy tại thư mục gốc SERA sau khi tải source. Nếu tải ZIP thay vì clone, cần lưu ý nội dung Git submodule không tự đi kèm ZIP.

git clone https://github.com/StevenKKXS/SERA.git
cd SERA
git submodule update --init --recursive
python3.11 -m pip install uv

uv venv --python 3.11 .venv-policy
UV_PROJECT_ENVIRONMENT=.venv-policy uv sync --python 3.11 --no-dev

uv venv --python 3.11 .venv-sim
uv pip install --python .venv-sim/bin/python \
  -r examples/robomme/requirements.txt
uv pip install --python .venv-sim/bin/python \
  -e third_party/robomme_benchmark -e packages/openpi-client

Đừng gộp hai environment để tiết kiệm vài dòng lệnh: simulator và model server có thể kéo các dependency khác nhau. Khi gặp ModuleNotFoundError, trước tiên kiểm tra executable nào đang chạy, thay vì cài package vào Python mặc định rồi thử lại.

Planner adapter còn cần codex CLI được cài và xác thực trên máy chạy. Nó sử dụng JSON event output và schema-constrained response; một CLI không tương thích có thể làm adapter lỗi dù tài khoản vẫn hoạt động. Chọn PLANNER_MODEL mà tài khoản của bạn truy cập được. Việc thay planner làm thay đổi cấu hình thí nghiệm, nên phải ghi lại khi báo cáo kết quả.

4. Tải đúng checkpoint và kiểm tra simulator

SERA dùng bản symbolic-grounded-subgoal từ MME-VLA model repository. Đây là checkpoint π0.5 đã được chuẩn bị cho giao diện grounded subgoal. Không thay tùy ý bằng một checkpoint π0.5 khác rồi kỳ vọng cùng kết quả.

uv pip install --python .venv-sim/bin/python huggingface_hub
.venv-sim/bin/hf download Yinpei/mme_vla_suite \
  symbolic-grounded-subgoal/79999.zip \
  symbolic-grounded-subgoal/history_config.txt \
  --revision 5db4d53ddb98c7f80cab08792dd53d985d712ab1 \
  --local-dir models/mme_vla_suite

(cd models/mme_vla_suite/symbolic-grounded-subgoal && \
  sha256sum -c ../../../configs/checkpoint.sha256)

.venv-sim/bin/python scripts/unzip_ckpt.py models/mme_vla_suite
export CHECKPOINT="$PWD/models/mme_vla_suite/symbolic-grounded-subgoal/79999"
export OPENPI_DATA_HOME="$PWD/models/openpi_cache"

Giữ history_config.txt cạnh thư mục 79999; loader dùng file này để cấu hình visual history. Checksum kiểm tra đúng artifact tải về, còn đường dẫn CHECKPOINT phải trỏ tới thư mục đã giải nén. Hai việc giải quyết hai loại lỗi khác nhau.

Tiếp theo làm theo hướng dẫn benchmark RoboMME để chuẩn bị simulator assets. Cài package thành công chưa chứng minh scene có đủ tài nguyên hoặc Vulkan hoạt động. Sau khi hoàn thành bước assets, chạy:

.venv-sim/bin/python examples/robomme/simple_test.py

Nếu bước này thất bại, dừng tại simulator. Chưa cần khởi động planner hoặc trả phí cho model call. Với lỗi renderer, đọc troubleshooting của benchmark và kiểm tra driver, Vulkan cùng cấu hình display trên máy. Evaluation dùng checkpoint có sẵn không yêu cầu tải toàn bộ policy-training dataset.

5. Inference đầu tiên: một task, một episode

Launcher chính thức nhận cấu hình qua environment variables. Mở ba terminal tại cùng thư mục repo. Trong cả ba terminal, đặt cùng các biến sau. Thay giá trị model bằng model bạn thực sự có quyền dùng:

export PLANNER_MODEL="YOUR_AVAILABLE_PLANNER_MODEL"
export CHECKPOINT="$PWD/models/mme_vla_suite/symbolic-grounded-subgoal/79999"
export OPENPI_DATA_HOME="$PWD/models/openpi_cache"
export RUN_ROOT="$PWD/outputs/robomme_base_smoke"
export TASKS="MoveCube"
export NUM_EPISODES=1
export POLICY_GPU=0
export SIM_GPU=1
unset INTERVENTION_BUNDLE

Nếu chỉ có một GPU, đổi SIM_GPU=0 trong các terminal và theo dõi memory. Terminal 1 chạy policy server, giữ nó hoạt động:

bash scripts/run_robomme.sh policy

Terminal 3 chuẩn bị episode context. capture lấy demonstration từ quan sát reset; init diễn giải đầu vào để tạo hướng dẫn:

bash scripts/run_robomme.sh capture
bash scripts/run_robomme.sh init

Terminal 2 khởi động planner:

bash scripts/run_robomme.sh planner

Khi cả hai service đã sẵn sàng, quay lại terminal 3:

bash scripts/run_robomme.sh eval
bash scripts/run_robomme.sh summary

Kết quả từng episode nằm dưới RUN_ROOT/evaluation/<Task>/episode_XX/summary.json. Hãy mở summary và đối chiếu request/response của planner trước khi chạy nhiều task. Một episode thành công chỉ xác nhận một đường chạy nhỏ; nó chưa đủ đại diện benchmark.

Launcher mặc định dùng planner memory dạng text progress, observation horizon 16 và frame stride 2. Các giá trị này là cấu hình của script hiện tại, không phải quy tắc chung cho mọi VLA. Chạy lại eval có thể tiếp tục từ summary đã hoàn thành. Khi thay model, checkpoint hoặc tập episode, dùng RUN_ROOT mới để tránh trộn kết quả cũ.

6. Training trong SERA thực sự có nghĩa gì?

Ở đây có hai công việc cần phân biệt. Policy training thay đổi trọng số mô hình điều khiển, thuộc pipeline MME-VLA upstream. Self-evolution của SERA dùng trải nghiệm thực thi để sửa harness trong khi giữ executor cố định. Những thí nghiệm như EXPO-FT fine-tuning π0.5 bằng online RL tác động vào một phần khác của hệ thống.

Trước khi nghĩ đến tối ưu, hãy lưu base rollout và xác định lỗi đầu tiên. Ví dụ minh họa: nếu robot chọn sai hướng, xem lỗi nằm ở diễn giải hướng, lệnh ứng viên hay chuyển động thực tế. Sửa câu hướng dẫn sẽ không tự tạo ra một skill vận động mà executor chưa học.

Cấu hình self-evolution thể hiện các ràng buộc hữu ích để tổ chức thí nghiệm: train pool 30, validation pool 20, tối đa 5 evolution rounds và paired episode lists bắt buộc. Đây là giá trị trong config phát hành, không phải cam kết rằng mọi task sẽ hoàn thành sau một lệnh.

Để bắt đầu với một task có trong task_order, khởi tạo controller:

.venv-sim/bin/python scripts/codex_rollout/self_evolve_v5.py init \
  --repo-root "$PWD" \
  --config configs/self_evolution.json \
  --run-root outputs/evolution/MoveCube \
  --task MoveCube

.venv-sim/bin/python scripts/codex_rollout/self_evolve_v5.py --help
.venv-sim/bin/python scripts/codex_rollout/self_evolve_v5.py status \
  --run-root outputs/evolution/MoveCube

init chỉ khởi tạo controller, chưa chạy toàn bộ vòng evolution. Mã controller có các subcommand như record-rollout, record-analysis, register-panel, start-candidate, record-verifier và record-retrospective. Mỗi bước cần artifact đầu vào và provenance tương ứng. Không nên ghép một chuỗi lệnh giả với những JSON chưa tồn tại rồi gọi đó là tutorial tái lập hoàn chỉnh.

Quy trình thực hành là thu train/validation rollouts, ghi nhận thất bại, đề xuất candidate bundle, chạy verifier trên các episode đã đăng ký, xem regression và chọn phiên bản. Một panel chỉ gồm episode base thất bại không kiểm tra được khả năng giữ các thành công cũ. Hãy có cả success counterexamples và tập validation chưa dùng để viết bản sửa.

Tách biệt test ngay từ đầu. Không đọc kết quả test rồi đổi bundle cho từng task để lấy điểm cao nhất. Nếu cần tiếp tục phát triển sau khi xem test, báo cáo đó là một chu kỳ nghiên cứu mới, không còn là đánh giá held-out của cấu hình ban đầu.

7. Inference với experience đã chọn

Repo không kèm runtime bundle cuối cùng và toàn bộ rollout output. Bạn cần tạo, kiểm chứng và chọn bundle của chính mình; các file ví dụ hoặc schema không thay thế artifact đã được lựa chọn.

Khi đã có bundle hợp lệ, dừng planner base ở terminal 2. Trong terminal 2 và 3, giữ cấu hình checkpoint/model như trước nhưng đổi:

export RUN_ROOT="$PWD/outputs/robomme_evolved_movecube"
export TASKS="MoveCube"
export INTERVENTION_BUNDLE="/absolute/path/to/selected-runtime-bundle.json"

Đường dẫn trên là chỗ bạn điền artifact thật. Giữ các file bundle tham chiếu ở vị trí tương ứng. Terminal 3 chạy lại capture và init; terminal 2 khởi động lại planner; terminal 3 chạy eval rồi summary. Policy server có thể tiếp tục hoạt động vì trọng số không đổi.

Khi mở rộng đánh giá, dùng task đúng phạm vi bundle. Benchmark đầy đủ có 16 task, mỗi task 50 test episodes; smoke test một task ở trên không tương đương giao thức đó. Lưu riêng base và evolved để so sánh được bằng chứng, thay vì ghi đè một thư mục kết quả.

8. Đọc kết quả và giới hạn

Các số dưới đây do tác giả công bố trong bảng kết quả SERA, không phải phép đo của bài hướng dẫn:

Đó là 56 episode thành công thêm trong tổng 800. Cách viết “tăng 7%” dễ gây hiểu sai: mức tăng tuyệt đối là 7 điểm phần trăm. Con số trung bình cũng không chứng minh từng task đều tốt hơn.

Để sử dụng kết quả trong dự án, hãy kiểm tra ba câu hỏi: task của bạn có phụ thuộc lịch sử tương tự không; executor có sẵn command phù hợp không; thời gian phản hồi planner có đáp ứng yêu cầu không? Một hệ giỏi ghi nhớ mục tiêu vẫn có thể thất bại ở tiếp xúc vật lý hoặc thao tác chính xác.

Bạn cũng cần phân biệt lỗi hạ tầng với thất bại tác vụ. Không kết nối được service, model timeout hay thiếu scene asset không phải cùng loại lỗi với gắp trượt trong simulation. Ghi riêng hai nhóm giúp bạn không đánh giá sai chất lượng policy hoặc vô tình chọn lại episode thuận lợi.

9. Lộ trình thực hành cho người mới

Buổi đầu, hoàn thành simulator smoke test và một base episode. Buổi tiếp theo, đọc trace: mục tiêu ban đầu là gì, planner đã chọn lệnh nào, ảnh sau lệnh xác nhận điều gì? Chỉ khi bạn giải thích được một thất bại bằng bằng chứng, hãy thử evolution trên train/validation.

Khi chuẩn bị báo cáo, giữ checkpoint revision, checksum, model planner, cấu hình và danh sách episode cùng kết quả. Dùng cùng episode để so base với candidate. Báo cáo cả regression và thời gian chạy; một cải thiện nhỏ có thể không đáng chi phí model call trong ứng dụng thực tế.

Nếu muốn mở rộng tư duy về memory, SimpleMem-VLA và native video memory là hướng đọc bổ sung. Với SERA, bài học dễ đưa vào hệ thống hiện có nhất là giữ mục tiêu bền vững, cập nhật tiến độ theo bằng chứng và kiểm chứng bản sửa trước khi sử dụng.

Bài viết liên quan

• REKI: Register memory trong VLA với LeRobot
• EXPO-FT: Online RL cho π0.5
• SimpleMem-VLA: Video memory cho tác vụ dài