WBC 모듈 평가에서 28개 점검 항목이 모두 통과했습니다. 처음에는 이 숫자를 그대로 “보행이 된다”는 결과처럼 적고 싶었지만, 그 표현은 정확하지 않았습니다. 이 평가는 Isaac Sim에서 학습 정책이 자연스럽게 걷는지를 확인한 것이 아니라, gait scheduler·CoM planner·WBC QP·state estimator·발 궤적 생성기가 각자 정해 둔 조건을 만족하는지 확인한 컴포넌트 평가입니다. 같은 ‘통과’라도 무엇을 통과했는지부터 나눠야 했습니다.
평가의 질문을 작게 쪼갰습니다
training/eval/eval_wbc.py는 제어기를 한 번에 합격·불합격으로 판정하지 않습니다. 보행 스케줄러는 stand·trot·walk에서 duty cycle과 양발 지지 구간, phase 연속성을 봅니다. CoM planner는 속도 명령을 바꿨을 때 목표 속도에 수렴하는지, 높이를 유지하는지, 감속 뒤 멈추는지를 확인합니다. 이어서 QP 출력의 차원과 토크 제한, state estimator의 자세·접촉 판정, Bezier 발 궤적의 시작·끝·최고점과 Raibert 발 디딤 목표를 따로 검사합니다.
이렇게 나눈 이유는 실패했을 때 원인을 좁히기 위해서입니다. 예를 들어 발이 기대보다 낮게 들린다면 정책 전체를 다시 학습시키기 전에 궤적 생성기의 중간점과 속도 방향부터 확인할 수 있습니다. 반대로 접촉 상태가 잘못 들어오면 gait scheduler가 정상이어도 다음 단계의 판단은 믿기 어렵습니다. 한 번에 ‘보행 실패’라고 쓰는 것보다 훨씬 작은 질문으로 돌아갈 수 있습니다.
이번 결과가 확인한 범위
저장된 결과에서는 walk gait의 양쪽 duty cycle이 각각 0.664와 0.636, double-support fraction은 0.3으로 계산됐습니다. 통합 점검에서는 0.5 m/s 명령에 대해 최종 속도가 약 0.5 m/s에 수렴했고, 평균 air time은 0.28 s, step frequency는 2.4 Hz로 기록됐습니다. H1과 G1에 대해 출력 토크 형상과 제한도 확인했습니다.
이 값들은 서로 다른 모듈의 계약을 확인합니다. duty cycle은 한 주기 동안 각 발이 지면에 있어야 하는 비율이고, double-support fraction은 양발이 동시에 지지하는 구간입니다. 발 궤적의 시작과 끝이 0이고 중간 최고점이 설정 높이에 도달하는지 확인하는 검사는 scheduler가 만든 swing 구간을 실제 발 목표로 바꾸는 연결을 봅니다. QP 검사는 그 목표가 로봇별 관절 수에 맞는 토크 벡터로 나오고 제한을 넘지 않는지를 봅니다.
한 항목이 실패했을 때도 해석 범위가 다릅니다. phase가 불연속이면 scheduler로 돌아가야 하고, swing 최고점이 틀리면 Bezier 궤적 계산을 봅니다. 속도가 목표에 수렴하지 않으면 CoM planner의 응답을, 토크가 제한을 넘으면 QP와 로봇 파라미터를 확인합니다. 28개를 한 숫자로 보고하는 것보다, 어느 계약이 깨졌는지 남기는 편이 다음 수정에 훨씬 유용합니다.
여기까지는 모듈의 입력·출력 관계가 검사 조건 안에서 일관됐다는 뜻입니다. 특히 28/28은 state estimator와 foot trajectory까지 포함한 컴포넌트 점검의 집계입니다. ‘H1과 G1에서 실제로 안정적으로 보행했다’는 증거는 아닙니다. 물리 엔진 접촉, 자산 관성, 관측 지연, 정책의 행동 분포가 함께 들어가는 Isaac Lab 평가에서는 다른 문제가 나타날 수 있습니다.
컴포넌트 테스트와 시뮬레이터 평가 사이의 빈칸
CPU 수준의 입력으로 속도 수렴과 발 궤적을 확인하면 함수가 기대한 계산을 하는지는 알 수 있습니다. 하지만 Isaac Sim에서는 예상보다 이른 접촉, 관성 오차, 센서 지연, PD gains가 같은 목표를 다른 움직임으로 바꿀 수 있습니다. state estimator가 만든 접촉 판정도 실제 contact sensor의 노이즈와 결합됐을 때 같은지를 다시 봐야 합니다. 이 구간을 통과하려면 동일한 명령과 초기 상태에서 계획값·추정값·실제 물리 상태를 함께 기록해야 합니다.
따라서 다음 통합 평가는 ’28/28을 다시 실행’하는 것이 아닙니다. stand에서 속도 명령을 넣고 멈추는 전환, walk의 양발 지지 구간, swing 발의 clearance, 토크 포화와 몸통 자세를 시간축으로 맞춰 보는 일입니다. 모듈별 값이 정상인데 로봇이 무너지면 인터페이스나 물리 파라미터를 의심할 수 있고, 모듈 값부터 깨지면 시뮬레이터보다 앞단으로 돌아갈 수 있습니다.
그래서 RL 정책 결과와 섞지 않습니다
현재 H1Walk-v0에는 3,000 iteration 체크포인트가 있지만, 자연스러운 보행은 아직 수용 기준에 미치지 못했습니다. reward v2에서는 feet_air_time을 포함한 보상 항목을 다시 조정했고, 이를 같은 조건에서 재학습·평가해야 합니다. WBC의 28개 컴포넌트 검사가 통과했다고 해서 RL 정책의 이 문제가 사라지는 것은 아닙니다. 두 결과는 같은 로봇을 다루지만, 서로 다른 질문에 답합니다.
이 구분을 기록으로 남기는 이유는 다음 실행을 단순하게 만들기 위해서입니다. 컴포넌트 검사가 깨지면 WBC 모듈로 돌아가고, 정책의 보행 품질이 부족하면 환경·보상·학습 설정과 시뮬레이터 평가를 다시 봅니다. 현재 G1의 M160a에서는 WBC 연결이 승인되지 않았으므로, CPU 계약과 별도의 runtime-capture 검토를 먼저 끝내야 합니다.