1. 왜 앞으로 가지 못할까?#

이전 단계에서는 BP_SpiderTrainingManager에서 PPOTrainer를 실제 학습 루프에 연결하고, Run Training을 통해 Policy Action이 로봇 관절 제어까지 전달되는 것을 확인하였다.

실행 결과 로봇의 다리는 실제로 움직였다. 몸체도 물리적으로 반응했고, 관절 Action이 SpiderJointController를 통해 적용되는 것도 확인할 수 있었다.

하지만 기대했던 것처럼 앞으로 걷지는 못했다.

영상에서 로봇은 다리를 움직이긴 하지만, 발로 지면을 밀어 몸체를 앞으로 보내는 느낌보다는 공중에서 허우적거리거나 제자리에서 흔들리는 모습에 가까웠다. 몸체도 앞으로 쭉 나아가기보다는 방향이 흐트러지거나, 살짝 회전하거나, 제자리에서 버둥거리는 것처럼 보였다.

처음에는 단순히 학습을 더 오래 돌리면 되는 문제인가 싶었다.

하지만 관련 논문들을 조금 찾아보니, 다족 로봇 보행은 단순히 PPO를 연결하고 “앞으로 가면 보상”을 주는 것만으로는 쉽게 만들어지지 않는다는 것을 알 수 있었다

1.1. 현재 상태#

• 현재 상황을 다시 한 번 정리해보자

  항목	현재 상태	판단
  PPO Trainer 실행	동작함	학습 루프 연결은 성공
  Policy Action 출력	동작함	Action 값이 생성되고 있음
  JointController 적용	동작함	관절 제어 전달 성공
  물리 반응	동작함	Constraint / Physics Asset은 반응함
  전방 이동	거의 없음	보행 패턴 형성 실패

1.2. 초기 보행이 형성되지 않은 이유#

다족 로봇의 보행은 단순히 관절을 움직이는 것만으로 만들어지지 않는다.

처음에는 다리가 움직이면 어느 정도 앞으로 갈 것이라고 생각했다.

하지만 실제로는 그렇지 않았다.

다양한 논문에서는 다족 로봇이 앞으로 가려면 단순히 관절이 움직이는 것만으로는 부족하고. 적어도 다음과 같은 구조가 필요하다.

1. 일부 발은 지면을 짚고 몸체를 지지한다.
2. 지면에 닿은 발은 몸체를 앞으로 밀어낸다.
3. 반대쪽 발은 공중으로 들어 앞으로 이동한다.
4. 들어 올린 발이 다시 지면에 닿는다.
5. 이 과정이 일정한 리듬으로 반복된다.

현재 로봇은 이 리듬이 아직 형성되지 않았다.

다리는 움직이지만, 어떤 발이 지면을 짚어야 하는지, 어떤 발이 공중으로 들어야 하는지, 언제 역할이 바뀌어야 하는지에 대한 기준이 없다. 그러다 보니 다리 움직임이 전방 추진력으로 이어지지 않고, 제자리 흔들림이나 불규칙한 움직임으로 나타난 것이다.

1.3. 관련 논문을 찾아보면서 알게 된 점#

처음에는 단순히 PPO를 더 오래 돌리면 언젠가는 걷지 않을까 생각했다.

하지만 비슷한 다족 로봇 강화학습 논문들을 찾아보니, 대부분 단순히 “앞으로 이동하면 보상”을 주는 방식만 사용하지는 않았다. 전방 속도뿐 아니라 발 접지 상태, 보행 phase, action 부드러움, 기본 자세 유지 같은 요소들을 함께 사용하고 있었다.

특히 아래 자료들이 현재 상황을 이해하는 데 도움이 되었다.

이 자료들을 보면서 현재 로봇이 앞으로 가지 못하는 이유를 조금 더 이해할 수 있었다.

문제는 PPO 자체가 아니라, PPO가 보행을 배울 수 있도록 도와주는 구조가 아직 부족하다는 점에 가까웠다. 지금 로봇은 관절 Action은 받고 있지만, 어떤 발이 지면을 짚어야 하는지, 어느 타이밍에 발을 들어야 하는지, 몸체 자세를 얼마나 안정적으로 유지해야 하는지에 대한 정보가 충분하지 않다.

논문들에서 반복적으로 보였던 요소들을 정리하면 다음과 같다.

여기서 특히 눈에 들어온 것이 Gait Phase와 CPG였다.

Gait Phase는 현재 보행 주기의 어느 시점인지를 나타내는 값이다. 쉽게 말하면, 지금은 어떤 다리가 땅을 짚고 있어야 하고, 어떤 다리가 공중에 떠 있어야 하는지를 알려주는 기준값에 가깝다.

CPG는 Central Pattern Generator의 약자이다. 복잡하게 생각하면 어렵지만, 지금 단계에서는 “수동 보행 리듬 생성기” 정도로 이해했다. 학습된 Policy가 아니더라도 다리별로 일정한 위상 차이를 주고, 기본적인 보행 패턴을 만들어주는 방식이다.

이 내용을 보고 나니 현재 로봇이 앞으로 가지 못하는 이유가 조금 더 명확해졌다.

지금 로봇은 다리를 움직일 수는 있지만, 그 움직임을 보행 리듬으로 정리할 기준이 부족하다. 어떤 발이 지면을 지지해야 하는지, 어떤 발이 공중에서 이동해야 하는지, 그 타이밍을 어떻게 나눠야 하는지가 아직 Observation이나 Reward에 충분히 반영되어 있지 않다.

그래서 다음 단계에서는 PPO를 계속 오래 돌리기보다, 먼저 CPG Debug Controller를 만들어 수동 보행 패턴으로 로봇이 전진 가능한지 확인해보기로 했다.

이 검증을 통해 현재 문제가 물리 구조의 문제인지, 아니면 PPO가 학습할 정보가 부족한 문제인지 먼저 분리해볼 수 있을 것 같다.

1.4. 현재 문제를 다시 정리해보기#

논문들을 참고한 뒤, 현재 문제를 다음과 같이 정리할 수 있었다.

이렇게 정리하고 나니, 바로 PPO를 더 오래 돌리는 것보다 먼저 확인해야 할 것들이 보였다.

1.5. 하나씩 검증해보기로 했다#

먼저 이 로봇이 물리적으로 앞으로 갈 수 있는 구조인지 확인하고, 그다음 PPO가 그 움직임을 학습할 수 있도록 Observation과 Reward를 추가해나가는 방식이 더 맞다고 판단했다.

전체 진행 방향은 다음과 같이 잡았다.

flowchart TD
    A[현재 상태<br/>관절은 움직이나 전방 보행은 부족] --> B[1. Forward 방향 확인]
    B --> C[2. CPG Debug Controller 구현]
    C --> D{수동 보행 패턴으로 전진 가능한가?}
    D -- 아니오 --> E[관절축 / 마찰 / 질량 / Constraint / ActionScale 조정]
    D -- 예 --> F[3. Foot Contact Observation 추가]
    F --> G[4. Gait Phase Observation 추가]
    G --> H[5. Gait Reward 추가]
    H --> I[6. Action Smoothness / 자세 안정화 보상 추가]
    I --> J[7. PPO 재학습]
    J --> K[8. 로그와 영상으로 결과 비교]

1.6. 첫 번째 확인: Forward 방향#

가장 먼저 확인할 것은 로봇의 전방 방향이다.

전방 이동 보상을 계산할 때 보통 Actor의 Forward Vector와 속도 벡터를 사용한다. 그런데 화면에서 보이는 로봇의 앞 방향과 Actor의 Forward Vector가 다르면, 로봇은 내가 생각한 앞 방향이 아닌 다른 방향으로 이동해도 보상을 받을 수 있다.

따라서 먼저 다음을 확인해야 한다.

이 부분이 틀리면 이후 Reward를 아무리 고쳐도 학습 방향이 어긋날 수 있으므로, 가장 먼저 확인하는 것이 좋다고 판단했다.

1.7. 두 번째 확인: CPG Debug Controller#

그다음에는 PPO를 잠시 끄고, 수동 보행 패턴을 넣어볼 생각이다.

이 기능을 CPG Debug Controller라고 부르기로 했다.

CPG Debug Controller는 학습된 Policy가 아니라, 정해진 보행 리듬에 따라 다리 관절 목표값을 만들어주는 테스트용 컨트롤러이다.

6족 로봇에서는 우선 세 다리씩 번갈아 움직이는 tripod gait를 기준으로 잡을 수 있다.

Group A가 지면을 짚고 몸체를 밀 때, Group B는 공중으로 들어 앞으로 이동한다. 이후 Phase가 바뀌면 두 그룹의 역할을 반대로 바꾼다.

이 검증을 통해 확인하고 싶은 것은 단순하다.

PPO 없이도 이 로봇이 앞으로 갈 수 있는가?

만약 CPG 패턴으로도 앞으로 가지 못한다면, 문제는 학습보다는 물리 설정 쪽일 가능성이 크다. 관절축, Constraint 방향, 발 마찰, 몸체 질량, ActionScale 등을 다시 확인해야 한다.

반대로 CPG 패턴으로 조금이라도 앞으로 간다면, 로봇의 물리 구조는 전진이 가능하다고 볼 수 있다. 그다음에는 PPO가 이 패턴을 학습할 수 있도록 Observation과 Reward를 보강하면 된다.

1.8. 세 번째 확인: 발 접지 정보#

보행에서 발 접지는 매우 중요한 정보다.

현재 Policy가 몸체 속도와 관절 각도만 보고 있다면, 어떤 발이 실제로 지면에 닿아 있는지 알기 어렵다.

하지만 다족 보행에서는 어떤 발이 지면에 닿아 몸체를 지지하고 있는지, 어떤 발이 공중에서 앞으로 이동 중인지가 중요하다.

따라서 각 발에 대해 접지 상태를 Observation에 추가할 계획이다.

이 정보가 있어야 이후에 “지금 이 발은 땅을 짚어야 하는데 실제로 짚고 있는가?” 같은 보상을 만들 수 있다.

1.9. 네 번째 확인: Gait Phase#

다음으로는 Gait Phase를 추가해야 한다.

Gait Phase는 현재 보행 주기의 어느 시점인지를 나타내는 값이다.

예를 들어 6족 로봇에서 Group A와 Group B가 번갈아 움직인다고 하면, 현재 Phase에 따라 어떤 그룹이 지면을 짚어야 하고 어떤 그룹이 공중으로 이동해야 하는지가 달라진다.

이 값을 Policy가 알 수 있어야 다리 움직임을 시간적인 패턴으로 정리할 수 있다.

Phase 값은 그대로 넣기보다 sin(phase), cos(phase) 형태로 넣는 것이 좋다. Phase가 한 바퀴 돌고 다시 처음으로 돌아갈 때 값이 갑자기 끊기는 문제를 줄일 수 있기 때문이다.

다리별 Phase Offset은 코드에 직접 박아 넣기보다 DataAsset이나 설정값으로 관리하는 것이 좋다. 그래야 나중에 6족에서 8족으로 확장하거나, 다른 보행 패턴을 실험할 때 구조를 그대로 재사용할 수 있다.

1.10. 다섯 번째 확인: Reward를 나눠서 보기#

지금부터는 Reward도 하나의 Total Reward만 보는 방식에서 벗어나야 한다.

앞으로 가면 보상, 넘어지면 패널티 정도로만 두면 로봇이 왜 제대로 걷지 못하는지 분석하기 어렵다.

그래서 Reward를 항목별로 나누어 확인할 계획이다.

이렇게 분리하면 학습 중에 어떤 항목이 문제인지 더 쉽게 볼 수 있다.

예를 들어 Forward Reward는 나오는데 Gait Reward가 낮다면, 앞으로 이동은 하지만 발 접지 패턴이 좋지 않은 것이다. TiltPenalty가 계속 크다면 자세 안정성이 문제일 수 있고, ActionSmoothnessPenalty가 크다면 관절 출력이 너무 불안정한 것일 수 있다.

1.11. 로그로 확인할 값#

이후부터는 영상만 보고 판단하지 않고, 로그도 함께 확인할 생각이다.

최소한 다음 값들은 Output Log 또는 TensorBoard에 기록해서 어떤 값이 이상치로 들어오는 지 판별을 해서 보완해나가야 하는 방향을 잡아야겠다.

ForwardSpeed
LateralSpeed
YawRate
BodyHeight
Roll
Pitch
FootContactCount
GaitPhase
Reward_Forward
Reward_Gait
Reward_TiltPenalty
Reward_ActionPenalty
Reward_Total

이 값을 보면 현재 로봇이 어떤 방식으로 움직이고 있는지 조금 더 객관적으로 확인할 수 있다.

2. 정리#

이번 실행을 통해 PPO 학습 루프가 로봇 관절 제어까지 연결되는 것은 확인할 수 있었다.

하지만 안정적인 전방 보행을 만들기 위해서는 단순히 관절을 움직이는 것만으로는 부족했다. 관련 논문들을 찾아보니, 다족 로봇 보행에는 발 접지 상태, 보행 Phase, 다리별 위상 차이, Action 부드러움, 기본 자세 유지 같은 요소들이 함께 필요하다는 것을 알 수 있었다.

따라서 다음 단계에서는 바로 PPO를 더 오래 돌리기보다, 먼저 CPG Debug Controller를 만들어 수동 보행 패턴으로 로봇이 실제로 앞으로 갈 수 있는지 확인해볼 예정이다.

이후에는 Foot Contact Observation, Gait Phase Observation, Gait Reward, Action Smoothness Penalty를 하나씩 추가하면서, 로봇이 단순히 다리를 움직이는 상태에서 실제 보행 패턴을 만들어가는 방향으로 개선해볼 생각이다.