영희·철수의
다음 한 걸음을 학습합니다.

# 영희·철수 로봇 축구 판단학습 계획 검토

## 판정

**조건부 타당. 다만 순서를 크게 바꿔야 합니다.**

방향 자체는 타당합니다. 보행 제어가 아니라 기존 동작 명령 위에서 판단만 학습하는 구조, shadow 검증, 성능 과장 금지 원칙이 그렇습니다.

문제는 PPO 설계가 아직 정의되지 않은 기반 위에 놓여 있다는 점입니다.

- 행동 집합이 미확인입니다. 우회전·정지·완료 응답을 확인하지 못했습니다.
- 관측 계약이 미확인입니다. 카메라 JSON·timestamp·신뢰도가 아직 없습니다.
- 동작 모델이 미측정입니다. 5.5cm·0.30rad·3초는 가정값입니다.

이 상태에서 PPO를 먼저 만들면 실패 원인을 분리할 수 없습니다. 따라서 **"측정 → 단일 시뮬레이터 → 규칙 기준선 → 학습 필요성 판정 → PPO"** 순서가 맞습니다.

## 우선 수정 (영향도순)

**1. 하드웨어 행동 지원 미확인 → MDP의 행동공간이 정의되지 않음**

- 우회전이 없으면 좌회전 반복으로 대체해야 하고, 이는 시간 비용과 오차 누적을 바꿉니다.
- 완료 응답이 없으면 "행동 종료 시점"을 정의할 수 없습니다.
- stop이 없으면 안전 설계가 달라집니다.
- 이 항목은 다른 모든 작업의 선행 게이트입니다.

**2. 비동기·가변 시간 동작과 PPO의 MDP 불일치**

- 고정 주기 step에 busy 플래그를 넣는 방식은 대부분의 step을 무의미한 결정으로 채웁니다. 신용할당도 왜곡됩니다.
- **사건 기반 결정(semi-MDP)**으로 바꿔야 합니다.
  - 로봇이 idle이 되고 재관측이 끝났을 때만 정책을 호출합니다.
  - 할인은 γ^τ(τ=실제 소요시간)로 적용합니다.
- 1v1에서는 상대가 내 동작 중에도 움직입니다. 그래서 두 로봇의 결정 시점이 어긋나는 상황을 시뮬레이터가 재현해야 합니다. 실측 시간 분포로 이벤트 큐를 구성하는 방식이 적합합니다.

**3. 관측가능성 과대평가**

- "공 속도"는 동작 완료 후의 스냅샷만으로는 사실상 측정할 수 없습니다. 대부분 0이거나 노이즈입니다.
- 정적 위치와 직전 변위로 대체하는 편이 현실적입니다.
- 다음 상황을 시뮬레이터 관측에 반영해야 합니다.
  - 로봇·공 가림
  - 마커 heading 오차
  - 프레임 지연
  - 검출 실패(신뢰도 낮음 / 결측)
- 반영하지 않으면 실기에서 정책 입력 분포가 달라집니다.

**4. 두 시뮬레이터(JS·Python) 불일치**

- 상태·충돌·득점의 진실원천은 **Python 하나**로 둡니다.
- Three.js는 렌더러 역할만 합니다.
- 동일 seed·동일 행동열을 넣었을 때 같은 궤적이 나오는지 golden replay 테스트로 고정해야 합니다.

**5. 공 접촉 모델의 근거 부재**

- 이족 보행 로봇의 공 밀기는 매우 확률적입니다. 접촉 여부, 밀림 방향, 거리가 모두 흩어집니다.
- 현재의 "단순 밀기" 모델로 학습한 정책은 존재하지 않는 정밀성을 이용할 위험이 큽니다.
- 실측한 분포(방향 오차, 거리, 미접촉 확률)로 대체해야 합니다.

**6. 학습 필요성 미검증**

- Q-learning 0점 대 규칙 32점이라는 결과는 학습이 불필요하다는 뜻일 수도 있고, 이산화·보상·에피소드 길이에 버그가 있다는 뜻일 수도 있습니다.
- 진단 없이 PPO로 넘어가면 같은 문제가 반복될 수 있습니다.
- 공 뒤로 가서 미는 규칙·플래너는 이 문제에서 강력한 기준선입니다.

**7. "실제 학습"의 기대치와 컴퓨트·시간**

- 실기 1동작은 약 3초이고, reset을 사람이 해야 합니다. 대략 계산하면 시간당 수백 결정 수준입니다(추정).
- 따라서 실기 RL은 비현실적이고, **시뮬레이터 학습 + 실기 보정·평가**가 현실적인 범위입니다.
- 반면 2D 이벤트 시뮬레이터와 소형 MLP라면 CPU로 충분할 가능성이 큽니다. 이 역시 미측정이므로 benchmark로 확인해야 합니다.
- 사용자와 "실제 학습"의 의미를 합의해야 합니다.

**8. 1v1인지 협동인지 미정**

- 이 결정에 따라 보상(제로섬인지 공동 보상인지), 관측(팀원 의도 포함 여부), self-play 필요 여부가 모두 달라집니다.
- 로봇 간 충돌 안전 정책도 달라집니다.
- 커리큘럼 4단계 이후의 설계는 이 결정 전까지 보류해야 합니다.

## 수정 계획

**보상** (숫자는 모두 제안값이며 튜닝 대상입니다)

- 기본 보상: 득점 +1, 실점·자책골 −1
- 보조 보상은 **potential 기반 shaping**만 허용합니다. 정책 최적성을 보존하기 위해서입니다.
  - Φ = −a·(공–골 거리) − b·(로봇이 공 뒤 정렬에서 벗어난 정도)
- 시간 패널티: 소폭(예: 결정당 −0.001~−0.01)
- 추가 패널티: 경계 이탈, 충돌
- 보상 편법 탐지를 자동화합니다.
  - 득점 없이 shaping 누적만 높은 에피소드를 플래그합니다.
  - 공 주변 진동 행동을 플래그합니다.

**커리큘럼**

- 각 단계마다 승급 기준을 명시합니다.
  - 예: 보류 초기상태에서 성공률이 기준선 대비 일정 수준 이상
- 실패하면 이전 단계로 롤백합니다.
- self-play는 상대 형태(1v1 여부)가 결정되고 단일 에이전트 단계를 통과한 뒤에만 진행합니다.

**평가**

- 고정된 보류 초기상태 집합을 사용합니다. 예: 200개 이상, 훈련 분포 밖의 조건 포함.
- seed는 5개 이상 사용합니다.
- 성공률은 Wilson 신뢰구간으로 보고합니다.
- 비교 대상
  - 무작위 정책
  - 규칙 정책
  - 노이즈를 넣은 환경에서의 규칙 정책
  - 행동복제(BC)
  - PPO
- 지표
  - 득점률
  - 득점까지 걸린 결정 수
  - 자책골
  - 충돌
  - 관측 결측 시 행동

## 통과 기준

모든 수치는 제안값이며, 기준을 통과해도 성공을 보증하지 않습니다.

| 단계 | 산출물 | 통과 기준(제안) |
|---|---|---|
| S0 | 로봇 API 표 | 각 명령 10회 이상 실행. 완료 응답·타임아웃·중복·stop 동작을 문서화. 미지원 항목 명시 |
| S1 | 카메라 계약 | 정지 상태 위치오차 중앙값 약 2~3cm 이내, heading 약 0.1rad 이내, 검출률·지연 기록 |
| S2 | 동작 분포 | 로봇별·동작별 30회 이상 실측. 이동·회전·시간·공 밀림 분포표 |
| S3 | 단일 시뮬레이터 | golden replay 일치. JS는 Python 상태만 표시 |
| S4 | 기준선 | 규칙·플래너·BC를 실측 노이즈 환경에서 평가. Q-learning 0점 원인 진단 |
| S5 | PPO 판정 | 보류 집합·다중 seed에서 규칙 기준선을 CI상 유의하게 넘으면 계속 진행. 아니면 규칙·플래너 채택 |
| S6 | 실기 shadow | 정책 추천만 기록. 시뮬레이터 예측과 실기 결과의 차이(sim-to-real gap)를 측정 |
| S7 | 감독 실행 | 제한 구역에서 사람 reset. 실기 성공률을 시뮬레이터 예측과 비교 |

**가장 작은 유용한 첫 산출물:** S0~S2의 "행동 지원표 + 실측 동작 분포"와, 이를 바탕으로 한 **규칙 정책의 시뮬레이터 대 실기 성공률 비교**입니다. RL 없이도 sim-to-real 간극을 먼저 수치로 확인할 수 있습니다.

**sim-to-real이 실패할 때의 대안**

- 시스템 식별을 재보정하고 도메인 무작위화 범위를 조정합니다.
- 매 결정마다 재관측해 재계획하는 규칙·플래너를 씁니다. 폐루프 구조라 오차에 강건합니다.
- 플래너의 소수 파라미터만 실기에서 베이지안 최적화로 튜닝합니다. 이 방식은 표본 효율이 높습니다.

**Codex 즉시 구현 순서**

1. 상태·관측 JSON 스키마를 정의합니다. 포함 항목: pose, timestamp, confidence, 결측 표기.
2. Python 단일 시뮬레이터로 리팩터링합니다. 사건 기반 이벤트 큐를 쓰고 동작 분포를 파라미터화합니다.
3. Three.js를 상태 구독 렌더러로 전환하고 golden replay 테스트를 만듭니다.
4. 규칙·플래너 기준선과 평가 하네스를 구현하고, Q-learning 결과를 진단합니다.
5. semi-MDP 방식의 Gymnasium 환경을 만듭니다.
6. PPO를 적용합니다.
7. ROS adapter를 shadow 모드로 연결합니다.

로봇 API probe와 실측은 사용자 승인과 감독 아래에서 별도로 진행합니다.

## 미확인 사항 (실측·사용자 결정 필요)

**실측 필요**

- 우회전·정지·취소·완료 응답 지원 여부
- 명령 중복 수신 시 동작
- 카메라 설치 위치·calibration·지연·가림 패턴
- 실제 동작량·시간·공 밀림 분포
- 넘어짐 빈도

**사용자 결정 필요**

- 1v1인지 같은 팀 협동인지
- "실제 학습"을 시뮬레이터 학습 + 실기 평가로 수용할지
- 학습용 PC 사용 가능 여부
- 실기 감독자와 reset 운영 방식
- 비상 정지 수단(전원 차단 등)

## 검토 한계

- 이 응답은 **제공된 문서·입력에만 기반한 계획 검토**입니다. 코드 실행, 파일 확인, 실기 검증을 하지 않았습니다.
- 위의 수치 기준은 모두 제안값이며 성공을 보증하지 않습니다.
- **학습용 가상 계획에 대한 검토 의견은 실제 로봇 운용 승인이 아닙니다.** 실기 명령 전송, 감독 실행, stop 미검증 상태의 동작 시험은 각각 별도로 사용자의 명시적 승인과 현장 안전 확인이 필요합니다.
- HTML 검토 문서는 요청에 따라 만들지 않았습니다. 필요하면 이 구조를 그대로 옮기면 됩니다.

사용자가 "영희·철수 로봇 학습 구현 계획을 Claude에게 먼저 진단받고, 그 결과를 반영한 HTML로 검토하고 싶다"고 명시적으로 요청했습니다. 아래 계획을 독립적인 로봇/RL 엔지니어 관점에서 비판적으로 검토해주세요. 도구 실행, 파일 열기/수정, 설치, 다른 서비스 접속은 하지 말고 이 입력만 검토하세요. 사실로 주어진 것과 미측정 가정을 구분하며 성공을 보증하지 마세요. 한국어로 답해주세요.

[확인된 현재 상태]
- 실제 두 로봇은 자료상 Aeko ESP32-S3 / XiaoZhi 펌웨어이며 기존 동작 도구를 호출하는 구조. 전진·좌회전 표기는 있으나 우회전·취소·정지·정확한 완료 응답은 실제 API에서 아직 검증하지 못함.
- 카메라로 필드의 영희/철수/공 위치와 로봇 방향을 측정하려는 계획. 기존 필드 1.2×0.9m, 마커 ID 10/20, 중앙 원점, +x 철수 골, +y 위, ROS 내부 단위 m/rad. 실제 카메라 JSON·calibration·capture timestamp·가림·신뢰도는 연결 전임.
- 라즈베리파이급 호스트 Debian 13 arm64, RAM 약16GB, 디스크 여유 약5GB. Docker의 Ubuntu24.04/ROS2 Jazzy 설치 완료. DDS 예제와 가상 ROS 동작/정지 통합 검사 통과. 실제 로봇 transport는 미구현.
- Django에 Three.js 목업을 올림. 현재 브라우저의 자체 JS 모델이 움직이고 ROS와 연결되지 않음. Python의 별도 2D 축구 모델 존재. 동작 1회 전진5.5cm, 회전0.30rad, 시간3초는 미측정 가정값. 충돌/단순 공 밀기/골 판정만 있고 실제 보행·넘어짐·공 관성 없음.
- 초기 Q-learning 3000episode, 정지 상대 조건의 별도100회 평가: 학습정책 득점0, 규칙정책 득점32. 이것을 성공한 정책이나 1대1 승률로 주장하지 않음.
- 사용자는 두 로봇의 실제 학습을 원함. 보행 자체의 서보/RL 제어가 아니라 기존 보행 명령을 활용한 축구 판단 학습을 우선 제안한 상태. 영희/철수의 상대팀1v1은 아직 제안상 가정이며 같은 팀 협동인지 사용자 확인이 필요함.

[원래 제안]
1. 실제 동작 측정: 로봇별 전진/좌·우회전/동작 완료시간/오차/공 밀림을 카메라로 기록.
2. Python에서 경기상태와 충돌·득점 계산을 단일화하고, Three.js는 그 상태를 표시. ROS/실기와 가상 입력 계약을 맞춤.
3. Gymnasium 환경, PPO 신경망정책. 관측은 자기위치·방향, 공 상대위치/속도, 상대위치, 골방향, busy/관측시각. 행동은 실제 지원 확인 후 전진1회·좌/우회전1회·대기만 허용.
4. 목표점도달→공접근→공뒤로가기→골방향공밀기→정지상대→규칙상대→과거정책 상대 self-play. 영희와 철수는 하나씩 고정상대를 상대로 학습하며 정규화된 상대좌표/골방향을 이용한 정책공유 여부 검토.
5. 득점/실점 중심 reward, 접근·골방향진행 보조 reward. 보상편법을 로그 검사. PPO가 적합하지 않으면 모방학습 warmstart/대체법 검토.
6. 실제 이동오차·시간지연·관측오차를 실측 분포로 모델링/도메인무작위화. 훈련에서 제외한 초기상태/조건·여러학습seed로 규칙기준선과 비교. 물리모델 미검증이면 실제 성능 주장 금지.
7. 웹은 훈련 시작/중단·실제진행률·성공률·모델버전/저장선택·경기기록/replay를 제공. 학습 compute는 CPU/GPU PC를 우선 검토하고 Pi는 관측/추론/ROS 제어 중심. 처리량/디스크 예산부터 benchmark.
8. 실기에 적용할 때 camera→policy→ROS adapter→기존 robot_hub/MCP→명령 완료→완료 후 재관측. 한로봇 한동작, 타임아웃·중복·stale관측 차단, 실제stop지원이 없으면 ROS취소가 즉시정지라고 주장하지 않음. 먼저 shadow추천과 감독 하의 제한된 동작검증. 실기는 자동 reset이 안되므로 사람 reset/episode운영 고려.

[검토 요청]
A. 종합 판단: 타당/조건부타당/주요수정필요 및 이유.
B. 가장 큰 기술적 결함/누락 5~8개를 영향도순으로 제시. 특히 관측가능성·busy/서로 다른 실제동작시간의 비동기 제어와 PPO MDP 설계, 두 시뮬레이터 불일치, 하드웨어 동작지원 미확인, 공접촉 모델, 훈련 컴퓨트/시간, 1v1/협동 미정 문제를 진단.
C. 보상·커리큘럼·평가설계의 수정 제안. 숫자기준은 제안임을 명시하고 보장과 구분.
D. 가장 작은 유용한 첫 산출물과 단계별 통과기준. 학습 자체의 필요성 검증(규칙/MPC/행동복제 기준선)과 sim-to-real 실패 시 대안 포함.
E. Codex에게 권고하는 즉시 구현 순서, 미리 실측/사용자 결정을 받아야 할 사항.
F. 승인 범위: 학습용 가상계획 검토와 실제로봇 운용승인을 혼동하지 말 것. 이 응답은 문서/입력에 기반한 계획검토이며 코드/실기검증이 아님을 명시.

답변은 '판정', '우선 수정', '수정 계획', '통과 기준', '미확인 사항', '검토 한계' 순으로 명료하게 구성해주세요. 2000~3500자 정도를 목표로 하되 기술적으로 필요한 내용은 충분히 포함하세요.