2026년 7월 19일 현재 G1 작업은 M160a 오른팔 독립 excitation의 CPU 계약 7/7 통과까지 진행됐습니다. Isaac runtime capture, PPO, actor 선택, checkpoint 승격, router/WBC 연결은 아직 승인되지 않았습니다.
이 프로젝트를 처음 보면 폴더와 글이 많아서 어디서부터 봐야 할지 헷갈릴 수 있습니다. 하지만 실제 작업 순서는 단순합니다. 논문에서 질문을 만들고, 그 질문을 시뮬레이터 환경으로 옮기고, 데이터와 정책을 만들고, 평가에서 다시 질문을 고칩니다. 이 글은 각 글의 요약이 아니라 현재 워크스페이스를 따라 들어가기 위한 읽는 순서입니다.
1. 먼저 전체 흐름과 현재 위치를 봅니다
논문에서 정책까지의 워크플로는 연구 노트, 시뮬레이터, 학습, 데이터·모델 메타데이터, 실행 라우터가 어떻게 이어지는지 보여 줍니다. 이어서 현재 워크스페이스 구성도를 보면 각 폴더가 무엇을 책임지는지와 H1·G1·라우터가 어느 단계까지 왔는지를 확인할 수 있습니다.
여기서 먼저 알아둘 것은 ‘구현됨’과 ‘검증됨’이 다르다는 점입니다. H1 글은 초기 기준선이고, 현재 G1은 v585–v600 비교와 M160a CPU 계약까지 진행됐습니다. 라우터 코드의 존재와 현재 후보의 실행 승인은 여전히 구분해야 합니다. 이 상태를 알고 읽어야 로드맵을 이미 끝난 결과처럼 보지 않게 됩니다.
글 안에서 사용하는 상태 표현도 이 순서를 따릅니다. 문서와 인터페이스가 있으면 설계됨, 실행 가능한 코드 경로가 있으면 구현됨, 특정 조건에서 실제로 돌았으면 실행됨, 출력이 기록됐으면 관측됨, 미리 정한 관문을 통과했을 때만 승인됨이라고 씁니다. 예를 들어 M160a는 CPU에서 실행되고 관측됐지만 Isaac Sim 실행은 승인되지 않았습니다. 이 어휘를 건너뛰지 않고 읽으면 한 문장의 ‘통과’가 허용하는 범위를 찾기 쉬워집니다.
2. 다음은 실행 환경과 변경 지도입니다
Isaac Sim·Isaac Lab 실행 환경 기록은 5.1/2.x 조합과 RTX 5070 Ti에서 발생한 GUI 드라이버 문제, H1/G1의 현재 준비 상태를 다룹니다. 시뮬레이션의 숫자와 결과는 이 환경 조건에서만 읽어야 합니다.
Theory.md를 구현 지도로 쓰는 방식은 새 논문, 새 실험, reward 변경이 생겼을 때 어떤 문서를 같이 갱신하는지 보여 줍니다. 논문 노트는 근거를 담고, Theory.md는 그것이 프로젝트 흐름의 어디에 붙는지 표시합니다. 두 문서를 같이 읽어야 ‘왜 이 보상을 바꿨는가’와 ‘그 변경이 어느 계층을 건드렸는가’를 모두 따라갈 수 있습니다.
3. 그 다음에 보행 평가를 읽습니다
현재 H1 보행은 학습 iteration이나 episode length 하나로 통과시키지 않습니다. 보행 평가 기준은 정지·전진·회전 시나리오에서 낙상률, 이동 거리, 속도 추종 오차, CoM 높이 변동을 어떻게 분리하는지 설명합니다. 학습을 멈추는 기준은 3,000 iteration 체크포인트가 왜 자연스러운 보행의 증거가 아니었는지와 reward v2 비교를 왜 다시 해야 하는지를 기록합니다.
WBC와 RL도 같은 결과로 묶지 않습니다. WBC 컴포넌트 평가의 28/28 통과는 scheduler·CoM planner·QP·state estimator·발 궤적 생성의 검사 결과입니다. 이는 RL 정책이 실제로 자연스럽게 걷는다는 결론이 아니라, RL 평가 전에 확인해야 할 제어 모듈의 경계를 알려 줍니다.
5. 한 결과가 다음 질문을 어떻게 바꿨는지 따라갑니다
이 워크스페이스를 가장 정확하게 읽는 방법은 파일 목록이 아니라 한 번의 판정 경로를 따라가는 것입니다. M158d에서는 접촉 횟수가 87회에서 71회로 줄고 충격량도 9.8347 N·s에서 7.6006 N·s로 낮아졌습니다. 여기까지만 읽으면 개선으로 보입니다. 그러나 최소 clearance는 -0.151 mm에서 -0.826 mm로 나빠졌고 washout gate도 실패했습니다. 그래서 후보를 승격하지 않고 teacher-overlay 입력이 실제로 식별 가능한지 묻는 쪽으로 다음 질문이 이동했습니다.
이어지는 M159에서 독립 onset은 17개, 설계 행렬은 rank 27/44, 조건수는 8.72×1017이었습니다. 이 결과 때문에 실행을 더 반복하는 대신 teacher-overlay 분기를 중단했습니다. M160a는 학습을 빼고 오른팔 관절을 독립적으로 자극하는 128 reset pair·44열 CPU 설계로 범위를 줄였고, 테스트 7/7과 조건수 기준을 통과했습니다. 읽기의 핵심은 숫자를 외우는 것이 아니라, 앞의 관측이 왜 뒤의 실험 설계를 바꿨는지 확인하는 데 있습니다.
각 글을 읽을 때도 같은 질문을 던지면 됩니다. 무엇을 바꿨는가, 어떤 조건에서 실행했는가, 통과하지 못한 관문은 무엇인가, 그 결과 다음에 열거나 닫은 경로는 무엇인가. 답이 없다면 그 글은 현재 프로젝트의 증거가 아니라 배경 설명으로 읽어야 합니다.
4. 마지막으로 데이터와 모델의 계보를 확인합니다
Git·데이터·모델 관리 규칙은 왜 코드와 설정은 Git에 남기고, 대용량 에피소드와 가중치는 별도 관리하는지 설명합니다. 새 체크포인트가 생기면 config, metrics, Git SHA가 함께 있어야 합니다. 이 연결이 없으면 같은 모델 이름을 봐도 어느 환경·어느 reward·어느 데이터에서 나온 결과인지 알 수 없습니다.
이 순서로 보면 글을 개별 요약으로 읽지 않고, 한 논문의 아이디어가 어떤 환경·학습·평가·다음 변경으로 이어졌는지 따라갈 수 있습니다. 다음 작업은 M160a runtime-capture 제안을 별도로 작성하고 적대검토를 통과시키는 일입니다. 그 결과가 생기면 이 안내도 새 글을 추가하는 대신, 기존 흐름의 빈 연결을 채우는 방식으로 갱신할 예정입니다.