저희는 백엔드 리플레이 메커니즘을 액션 리플레이에서 상태 리플레이로 업그레이드 했습니다
핵심 3 단계
🔘상태 기록 ( 전체 정보 보존 )
🔘표현 압축 ( 비용 절감 )
🔘물리 일관성 검증 ( 이상값 제거 )
이번 업데이트의 배경은 다음과 같습니다
➖
🥹 액션 리플레이의 한계
저희의 목표는 로봇을 웹에서 별다른 장벽 없이 원격 조작할 수 있도록 만들고,
이 데이터를 서버로 자연스럽게 옮겨 학습과 서로 다른 시뮬레이션 환경 간 리플레이에 활용하는 것이었습니다
이 파이프라인은 여러 환경을 거칩니다
사용자 브라우저(WASM)
> 서버 시뮬레이터(Python MuJoCo)
> 타깃 시뮬레이터
처음에는 액션 리플레이 방식을 사용했습니다
즉, 사용자가 내린 명령을 기록해 그대로 다시 재생하는 방식이었습니다
하지만 작업 시간이 길어질수록 성공률이 크게 떨어졌습니다
🥹 근본 원인
시뮬레이션 환경마다 존재하는 근본적인 이질성에서 비롯됩니다
시뮬레이터마다 수치 정밀도, 물리 엔진 로직, 타임스텝, 충돌 처리 방식 등에
작은 차이가 존재합니다.
그리고 동적 시스템에서는 이런 미세한 차이가 시간이 지날수록 계속 누적되고 증폭됩니다.
상태 변화는 아래와 같이 이어집니다
[현재 상태 + 현재 액션 > 다음 상태]
초기에 생긴 아주 작은 오차 하나가 접촉 지점을 바꾸고,
그로 인해 충돌 반응이 달라지며,
결국 전체 궤적이 완전히 다른 방향으로 갈라지게 됩니다
즉, 같은 액션을 인력해도 서로 다른 시뮬레이터에서는 같은 결과가 나오지 않을 수 있다는 뜻입니다
그래서 액션 시퀀스만 기록하는 방식으로는 물리적으로 일관적 궤적을 안정적으로 재현하기 어렵습니다
🥹 그래서 상태 리플레이로 전환
이제는 " 어떤 액션이 실행됐는가"가 아니라
"시스템이 실제로 어떤 물리 상태를 거쳤는가" 를 기록합니다
전체 환경의 상태 스냅샷을 저장하고
리플레이할 때 이를 그대로 불러오도록 하여
중간 인과 과정을 다시 계산하는 문제를 우회했습니다
물론 이 방식도 문제가 있습니다
1. 데이터 용량 문제
데이터 구조를 새롭게 설계해
1초 분량의 궤적을 약 1KB수준까지 압축할 수 있도록 만들었습니다
2. 부정행위 가능성
사용자가 중간 궤적을 조작해
더미 데이터를 만들 가능성도 있었습니다
최근의 안티봇 업데이트와도 연결되는 부분입니다
이를 해결하기 위해 저희는 물리 일관성 검증을 도입했습니다
이 과정에서 물리 엔진은 일종의 심판 역할을 합니다
검증 방식은 다음과 같습니다
[상태+액션] 추출 > 서버 시뮬레이터에서 1스텝 실행 > 예측 상태 생성 > 기록된 상태와 비교
이때 오차가 허용 범위를 넘으면 해당 데이터는 거부됩니다
🥹 디노이징 문제
서로 다른 시뮬레이터 간 리플레이는 결국 노이즈가 섞인 궤적 데이터를 다루는 문제라고 볼 수 있습니다
즉 , 실제로는 다음과 같은 구조입니다
실제 궤적 + 크로스 시뮬레이션 오차
저희의 목표는 이런 구조적인 오차가 존재하더라도
물리적으로 일관된 궤적을 복원하는 것입니다
서로 다른 시뮬레이터 사이에 편차가 생기는 것은 피할 수 없습니다
하지만 상태 기록,압축된 표현, 단계별 물리 검증을 통해
Axis는 보다 신뢰할 수 있는 결과를 보장합니다
이번 업그레이드가 실제로 어떤 차이를 만드는지는 위의 성능 비교표에서 확인할 수 있습니다
표에서는 여러 작업에 대해 액션 리플레이와, 상태 리플레이의 성공률을 비교하고 있습니다
Axis X | Axis 한국 공지 채널 | Axis 한국 채팅방
» Axis Hub