1. 들어가기 전에…#

이전 단계에서는 PPOTrainer를 Learning Agents 학습 루프에 연결하고, Policy에서 출력된 Action이 실제 거미 로봇의 관절 제어까지 전달되는 것을 확인하였다.

즉, PPO가 출력한 24개의 연속 Action 값이 SpiderJointControllerComponent를 거쳐 Physics Constraint 기반 관절 제어로 이어지는 흐름은 동작하였다.

하지만 실제 결과를 보면, 로봇의 다리는 움직였지만 기대했던 것처럼 앞으로 안정적으로 걷지는 못했다. 단순히 학습 시간을 더 늘리면 언젠가 걷게 될 수도 있겠지만, 현재 상태에서는 문제가 학습 부족인지, 물리 구조 문제인지, 보상 설계 문제인지 구분하기 어려웠다.

그래서 관련 논문과 사례를 찾아보니, 다족 로봇 보행에서는 단순히 관절 Action을 직접 학습시키기보다 CPG, Tripod Gait, gait phase, foot contact, motion prior, imitation learning 등을 함께 사용하는 경우가 많은 것을 알 수 있었다.

따라서 이번 단계에서는 강화학습을 잠시 멈추고, 사람이 직접 만든 주기적 보행 패턴인 CPG를 먼저 적용해 보기로 하였다.

6족 로봇 보행에는 Tripod Gait와 CPG 같은 알려진 기본 패턴이 존재한다. 하지만 현재 프로젝트의 거미 로봇은 특정 Skeletal Mesh, Physics Asset, Constraint 축, 질량 분포, 마찰 조건을 가진 커스텀 물리 로봇이므로, 일반적인 보행 패턴이 그대로 정답이 된다고 볼 수는 없다.

관련 연구를 보면 6족 로봇에서는 CPG를 최종 정답으로 사용하기보다, 기본 보행 리듬을 만드는 prior 또는 저차원 gait generator로 사용하고, 강화학습이 CPG 파라미터를 조정하도록 구성하는 사례가 많다. 이는 24개 관절 Action을 처음부터 직접 탐색하는 것보다 학습 공간을 줄이고, 보행 패턴이 형성될 가능성을 높이는 방향이다.

또한 보유한 보행 애니메이션은 imitation learning이나 motion prior로 활용할 수 있다. 다만 애니메이션의 본 회전값을 그대로 학습에 넣는 것이 아니라, 현재 프로젝트의 24개 Action 값으로 변환하고, 해당 행동을 Learning Agents Recorder로 기록해 demonstration 데이터로 만드는 과정이 필요하다.

따라서 이번 프로젝트에서는 CPG와 애니메이션을 서로 배타적인 방법으로 보지 않는다. CPG는 단순하고 조정 가능한 보행 가설 생성기로 사용하고, 애니메이션은 사람이 만든 motion prior로 사용한다. 이후 이 둘 중 물리적으로 유효한 행동을 Recorder, Imitation Learning, PPO Fine-tuning으로 연결하는 방향이 현실적이다.

찾아본 참고자료들 정리#

정리하면, 6족 거미 로봇 보행을 처음부터 24개 관절 Action으로 직접 학습시키기보다는, CPG나 애니메이션 기반 motion prior를 통해 보행 후보를 만들고, 강화학습이 이를 현재 물리 환경에 맞게 조정하도록 하는 계층형 구조가 더 현실적이라고 판단했다.

2. 구현 방향 설계#

2.1. 기본 방향#

이번 단계에서는 기존 Learning Agents 구조를 새로 바꾸지 않고, 이미 검증된 24개 Action 기반 관절 제어 경로를 그대로 사용한다. 다만 24개 Action을 만드는 주체를 하나로 고정하지 않는다.
현재 사용할 수 있는 보행 후보는 두 가지라 할 수 있다.
Action Source 역할
CPG Debug Controller 수식 기반 Tripod Gait 패턴 생성
Animation Action Driver 기존 보행 애니메이션을 24개 Action으로 변환
두 방식 모두 최종적으로는 같은 경로를 사용한다.
```
flowchart TD
    A[CPG Debug Controller] --> C[24개 Action 배열]
    B[Animation Action Driver] --> C

    C --> D[SpiderJointControllerComponent]
    D --> E[Physics Constraint Angular Drive]
    E --> F[거미 로봇 관절 구동]
```
이렇게 설계하는 이유는 CPG와 애니메이션을 서로 경쟁 관계로 보지 않기 위해서이다.
CPG는 단순하고 조정 가능한 보행 가설이고, 애니메이션은 이미 존재하는 보행 motion prior이다. 둘 중 어느 하나가 정답이라고 보기보다, 둘 다 현재 물리 로봇에서 유효한지 확인할 수 있는 Action Source로 취급한다.

Action Source	역할
CPG Debug Controller	수식 기반 Tripod Gait 패턴 생성
Animation Action Driver	기존 보행 애니메이션을 24개 Action으로 변환

2.2. 왜 Action Source 구조로 나누는가#

이전 단계에서 PPO가 출력한 24개 Action이 SpiderJointControllerComponent를 거쳐 실제 관절 제어까지 전달되는 것은 확인하였다.

따라서 이번 단계의 핵심은 관절 제어기를 새로 만드는 것이 아니라, 어떤 방식으로 24개 Action을 만들 것인가이다.

flowchart TD
    A[Action Source] --> B[24개 Action 생성]
    B --> C[SpiderJointControllerComponent]
    C --> D[Target Orientation 변환]
    D --> E[Physics Constraint Angular Drive]
    E --> F[물리 관절 구동]

    G[PPO Policy] --> A
    H[CPG Debug Controller] --> A
    I[Animation Action Driver] --> A

이 구조를 사용하면 이후에 다음 비교가 가능해진다.

비교 대상	확인할 내용
PPO Policy	학습된 정책이 스스로 만든 행동
CPG Debug Controller	사람이 만든 주기적 Tripod Gait
Animation Action Driver	기존 보행 애니메이션에서 추출한 행동

즉, 이번 설계의 핵심은 보행 패턴을 하나로 확정하는 것이 아니라, 여러 Action Source를 같은 관절 제어 경로에서 비교할 수 있게 만드는 것이다.

2.3. CPG의 역할#

CPG는 수식 기반 보행 후보를 만든다.

6족 로봇에서는 Tripod Gait처럼 알려진 기본 패턴이 있으므로, 이를 가장 단순한 보행 prior로 사용한다.

flowchart TD
    A[6개 다리] --> B[Group A]
    A --> C[Group B]

    B --> B1[Front Left]
    B --> B2[Middle Right]
    B --> B3[Rear Left]

    C --> C1[Front Right]
    C --> C2[Middle Left]
    C --> C3[Rear Right]

두 그룹은 반대 위상으로 서로 번갈아가며 움직인다.

sequenceDiagram
    participant A as Group A
    participant B as Group B

    Note over A,B: Phase 0.0 ~ 0.5
    A->>A: Stance / 지면을 밀기
    B->>B: Swing / 다리 들어 앞으로 보내기

    Note over A,B: Phase 0.5 ~ 1.0
    A->>A: Swing / 다리 들어 앞으로 보내기
    B->>B: Stance / 지면을 밀기

CPG를 사용하면 다음과 같은 이점을 얻을 수 있다.
- 보행 주기와 다리 위상 관계를 명확하게 만들 수 있음
- 보폭, 들어올림, 지면 밀기 세기를 수치로 조정할 수 있음
- 실패했을 때 원인을 비교적 해석하기 쉬움
- 이후 PPO가 CPG 파라미터를 조정하는 구조로 확장할 수 있음

2.4. 애니메이션의 역할#

기존 보행 애니메이션도 사용한다.
다만 애니메이션을 그대로 재생하는 것은 이번 목적과 다르다. 애니메이션을 단순히 재생하면 Skeletal Mesh는 움직이지만, 현재 프로젝트의 24개 Action 기반 물리 관절 제어와 직접 연결되지 않기 때문이다. 그래서 기존의 걷기 애니메이션은 다음과 같은 방식으로 사용하도록 하자.
```
flowchart TD
    A[보행 AnimSequence] --> B[프레임별 Bone Transform 읽기]
    B --> C[관절별 기준 자세 대비 회전량 계산]
    C --> D[24개 Action 값으로 변환]
    D --> E[SpiderJointControllerComponent]
    E --> F[Physics Constraint 관절 구동]
```
즉, 애니메이션은 “보여주기용 재생”이 아니라 Action을 만들기 위한 motion prior로 사용한다.
이 방식이 필요한 이유는 다음과 같다.
- 이미 보유한 보행 동작을 버리지 않고 활용할 수 있음
- 사람이 만든 자연스러운 움직임을 초기 보행 후보로 사용할 수 있음
- CPG보다 복잡한 관절 간 관계를 포함할 수 있음
- 이후 Learning Agents Recorder로 기록해 imitation learning 데이터로 확장할 수 있음

2.5. CPG와 애니메이션의 관계#

CPG와 애니메이션은 둘 중 하나만 선택해야 하는 관계가 아니다.

둘은 서로 다른 성격의 보행 prior이기 때문이다.

구분	CPG	애니메이션
성격	수식 기반 패턴	기존 동작 기반 패턴
장점	단순하고 조정 쉬움	자연스러운 움직임 포함
단점	실제 보행과 다를 수 있음	물리 Constraint와 안 맞을 수 있음
활용	Tripod Gait 테스트, 파라미터 조정	Motion Prior, Imitation Learning 준비

따라서 이번 단계에서는 두 방식을 같은 Action Source 구조로 묶어서 사용해보도록 하자

flowchart TD
    A[보행 후보 생성] --> B[CPG 기반 후보]
    A --> C[Animation 기반 후보]

    B --> D[24개 Action]
    C --> D

    D --> E[ApplyJointActions]
    E --> F[물리 로봇 반응 확인]

    F --> G{어느 후보가 물리적으로 유효한가?}

    G --> H[CPG가 유효함]
    G --> I[Animation이 유효함]
    G --> J[둘 다 일부만 유효함]

    H --> K[PPO가 CPG 파라미터 조정]
    I --> L[Recorder / Imitation Learning]
    J --> M[CPG + Animation Prior 조합]

2.7. 설정값은 코드에 고정하지 않기#

다리별 Action Index, 위상, 진폭, 방향 반전 여부는 코드에 직접 고정하지 않는다.

현재 프로젝트의 관절 순서는 DA_SpiderJointConfig에 의해 정의되어 있으므로, CPG와 Animation Driver 모두 이 순서를 기준으로 24개 Action을 생성해야 한다.

flowchart TD
    A[DA_SpiderJointConfig] --> B[24개 Action 순서]
    C[CPG Leg Config] --> D[다리별 Action Index 묶음]
    E[Animation Joint Mapping] --> F[Bone과 Action Index 매핑]

    D --> G[CPG Action 생성]
    F --> H[Animation Action 생성]

    B --> G
    B --> H

    G --> I[ApplyJointActions]
    H --> I

이렇게 하면 관절 순서나 본 구조가 바뀌어도 코드 수정이 아니라 설정 수정으로 대응할 수 있다.

2.8. 전체 실행 흐름#

이번 단계의 전체 흐름은 다음과 같다.

flowchart TD
    A[BP_SpiderRobot] --> B{Action Source 선택}

    B --> C[CPG Debug Controller]
    B --> D[Animation Action Driver]

    C --> E[Tripod Gait 기반 24개 Action 생성]
    D --> F[AnimSequence 기반 24개 Action 생성]

    E --> G[SpiderJointControllerComponent]
    F --> G

    G --> H[Physics Constraint Angular Drive]
    H --> I[거미 로봇 이동 확인]

또한, 이번 단계에서의 최종 목표는 결국 CPG 또는 애니메이션 기반 Action을 넣었을 때, 현재 물리 거미 로봇이 앞으로 이동할 가능성이 있는가? 라고 생각해야한다

2.9. 이후 확장 방향#

CPG나 애니메이션 기반 Action 중 물리적으로 유효한 후보가 확인되면, 이후에는 Learning Agents와 다시 연결해서 사용해보자

flowchart TD
    A[유효한 Action Source 확인] --> B[Learning Agents Recorder]
    B --> C[Observation / Action Demonstration 기록]
    C --> D[Imitation Learning]
    D --> E[PPO Fine-tuning]

또는 PPO가 24개 Action을 직접 출력하지 않고, CPG 파라미터만 조정하는 계층형 구조로 확장할 수도 있다.

flowchart TD
    A[PPO Policy] --> B[CPG Parameters]
    B --> C[CPG Generator]
    C --> D[24개 Action 생성]
    D --> E[SpiderJointControllerComponent]
    E --> F[물리 로봇]

3. 후기#

지금까지의 과정은 대부분 Unreal에서 제공하는 Learning Agents 구조를 따라가면서 Blueprint 중심으로 학습 루프를 구성한 것에 가깝다.

Interactor, Policy, Trainer, Training Environment를 연결하고, PPOTrainer에서 출력된 Action이 실제 거미 로봇의 관절 제어까지 전달되는 것을 확인하는 과정은 생각보다 명확했다(노드는 많을지언정…). 물론 중간에 노드 이름이나 연결 방식 때문에 시행착오가 있었지만, 큰 틀에서는 Unreal Learning Agents가 제공하는 구조 안에서 작업을 진행할 수 있었고, 수행하는 방식도 대부분 개발자 문서에 적혀져 있어서 따라하면서 구현하기 어렵지는 않았다.

하지만 이제부터는 조금 어려워질 것 같은게, 단순히 Learning Agents의 노드를 연결하는 것이 아니라, 현재 로봇이 실제로 걸을 수 있도록 보행 prior를 직접 만들어야 하고, CPG 기반 Tripod Gait를 설계하거나, 기존 보행 애니메이션을 24개 Action 값으로 변환하거나, 이후 이를 Recorder와 Imitation Learning으로 연결하는 과정은 결국 직접 C++ 기반으로 구조를 만들어야 하는 부분이기 때문이다.

처음에는 PPO를 더 오래 돌리면 언젠가 걷지 않을까 생각했지만, 관련 논문과 사례를 찾아보면서 다족 로봇 보행은 단순한 전방 이동 보상만으로 해결되는 문제가 아니라는 것을 알게 되었다. CPG, gait phase, foot contact, motion prior, imitation learning처럼 보행 패턴을 형성하기 위한 여러 보조 구조가 함께 사용되는 경우가 많았다.

따라서 다음 단계에서는 무작정 학습 시간을 늘리기보다, 먼저 CPG와 애니메이션을 Action Source로 정리하고, 이들이 현재 물리 거미 로봇에서 유효한 보행 후보가 될 수 있는지 확인해볼 예정이다.

앞으로는 Blueprint만으로 끝나는 작업보다는 C++ 컴포넌트 구현, Action 매핑 구조, 애니메이션 본 회전값 추출, Learning Agents Recorder 연동처럼 조금 더 직접적인 구현이 많아질 것 같다. 그래도 관련 논문과 오픈소스 예제, GitHub에 공개된 여러 로봇 보행 프로젝트들이 참고할 만한 방향을 제공하고 있으므로, 하나씩 비교해보면서 현재 프로젝트에 맞는 방식으로 적용해보려고 한다.

4. 출처#

주제	자료(+링크)	프로젝트에서 볼 부분
CPG + RL	Combined Reinforcement Learning and CPG Algorithm to Improve the Locomotion Performance of Hexapod Robots on Complex Terrains	CPG 기본 리듬 + RL 적응 구조
Terrain-adaptive CPG	Terrain-adaptive Central Pattern Generators with Reinforcement Learning for Hexapod Locomotion	CPG는 gait 생성, DRL은 파라미터 조정
계층형 6족 보행	Adaptive Gait Generation for Hexapod Robots Based on Reinforcement Learning and Hierarchical Framework	24개 joint 직접 제어 대신 action 차원 축소
Motion Prior + RL	Learning Natural and Robust Hexapod Locomotion over Complex Terrains via Motion Priors based on Deep Reinforcement Learning	애니메이션 또는 최적화 동작을 prior로 쓰는 방향
Imitation Learning Survey	Imitation Learning for Legged Robot Locomotion: A Survey	모방학습이 보행 reward 설계 부담을 줄이는 흐름
Unreal Learning Agents IL	Epic Learning Agents Imitation Learning Tutorial	Controller, Recorder, Imitation Trainer 흐름

16. 보행 Prior 설계