SAPIEN의 능동 스테레오 깊이는 장면의 기하학적 정답 깊이를 그대로 꺼낸 영상과 다릅니다. 공식 예제의 StereoDepthSensor는 좌우 적외선 영상을 렌더링하고 그 영상에서 깊이를 계산한 뒤 RGB 카메라 좌표에 맞춰 반환합니다. 학습 입력을 해석하려면 깊이맵의 모양뿐 아니라 어떤 영상에서 계산됐는지, 어느 카메라 기준인지, 속도를 높이면서 무엇을 바꿨는지 함께 알아야 합니다.
이 글은 2026년 10월 15일 확인한 SAPIEN의 Realistic Depth 문서를 설명합니다. 해당 문서는 SAPIEN 3 API로 이식되지 않아 일부 함수 이름이 달라질 수 있다고 명시합니다. 아래 흐름과 함수 이름은 그 문서의 설명 범위이며, 현재 환경의 설치·실행 안내가 아닙니다. 이 글을 위해 센서를 렌더링하거나 깊이 정확도와 처리 속도를 측정하지 않았습니다.
같은 장면에서도 깊이가 만들어지는 경로가 다릅니다
기하학적 정답 깊이는 시뮬레이터가 알고 있는 장면을 기준으로 얻는 값입니다. 실제 스테레오 카메라는 두 영상의 대응 관계를 찾아 거리를 추정하므로, 무늬가 부족하거나 가려진 부분에서는 다른 결과가 나올 수 있습니다. 실제 장치의 방식과 실패 조건은 스테레오·ToF·구조광 깊이 카메라 비교에서 먼저 볼 수 있습니다.
SAPIEN의 해당 센서 예제는 RGB 영상 외에 적외선 영상 두 장을 만듭니다. take_picture()가 영상을 얻고, 그다음 compute_depth()가 깊이맵을 계산합니다. 따라서 학습 코드가 받는 깊이에는 선택한 렌더링과 스테레오 처리 설정의 영향이 들어갑니다. 장면에 물체가 있다는 사실과, 그 물체의 표면에서 이용할 만한 깊이가 계산됐다는 사실을 나눠 봐야 하는 이유입니다.
예를 들어 같은 상자를 두 입력으로 학습시킨다고 가정해 보겠습니다. 하나는 장면의 기하학적 깊이이고, 다른 하나는 시뮬레이션한 적외선 영상에서 계산한 깊이입니다. 모델 구조와 상자 위치를 그대로 두더라도 입력을 만든 과정이 달라집니다. 이 비교는 가상의 설명이며, 어느 쪽이 실제 로봇에서 더 높은 성공률을 낸다는 실험 결과가 아닙니다. 센서 처리를 추가했다는 이유만으로 특정 실물 카메라와의 오차가 검증되는 것도 아닙니다.
반환 좌표는 RGB 카메라 기준입니다
문서에 따르면 최종 깊이맵은 RGB 카메라와 같은 좌표계와 해상도로 변환됩니다. 적외선 영상으로 깊이를 계산했더라도, 반환된 깊이의 좌표 기준을 적외선 카메라로 간주하면 안 됩니다. 포인트클라우드 역시 RGB 카메라에서 바라본 좌표이며, 축은 오른쪽이 x, 아래쪽이 y, 앞쪽이 z입니다.
| 확인할 출력 | 문서가 설명하는 의미 | 연결할 때 남길 정보 |
|---|---|---|
| RGB 영상과 좌우 IR 영상 | 깊이 계산 전 센서가 얻은 영상들 | 각 영상의 해상도와 센서 설정 |
| 최종 깊이맵 | RGB 카메라 좌표·해상도에 맞춘 깊이 | RGB 카메라 기준과 출력 해상도 |
| 포인트클라우드 | RGB 카메라 기준의 3차원 점 | 축 방향, 카메라 자세, 목적 좌표계 |
카메라 좌표에서 앞에 있는 점을 곧바로 로봇 베이스 앞의 점으로 해석할 수는 없습니다. 센서가 팔에 달렸다면 장착 관계와 그 시점의 팔 자세를 통해 목적 좌표로 옮겨야 합니다. 예제에서 시각화용으로 점의 축 방향을 바꾸는 부분도 카메라와 로봇 사이의 외부 보정을 대신하지 않습니다.
센서를 어떤 액터에 장착했는지도 기록해 두는 편이 좋습니다. 해당 문서는 액터가 움직이면 센서가 함께 움직이고, set_local_pose는 장착된 액터에 대한 상대 자세를 바꾼다고 설명합니다. 같은 상대 자세라도 액터의 위치가 바뀌면 장면을 보는 위치가 달라집니다.
속도를 높인 설정이 관측값까지 바꿀 수 있습니다
공식 예제는 scene.step() → scene.update_render() → sensor.take_picture() → sensor.compute_depth() 순서로 진행됩니다. 물리 상태를 갱신하고, 그 상태를 렌더링한 다음, 얻은 영상에서 깊이를 계산하는 순서입니다. 데이터셋을 만들 때 이 순서와 프레임 기준을 남겨야 어떤 상태의 깊이를 저장했는지 추적할 수 있습니다.
문서는 렌더링 샘플 수인 rt_samples_per_pixel, 적외선 해상도인 ir_resolution, 시차 범위 설정인 max_disp를 줄이는 방법을 제시합니다. 동시에 이런 변경이 출력 깊이에도 영향을 줄 수 있다고 경고합니다. 처리 시간이 줄었다는 기록만으로 이전과 같은 관측을 더 빨리 얻었다고 결론 내릴 수는 없습니다.
infrared_only=True로 RGB 렌더링을 생략하는 선택은 입력 구성부터 확인해야 합니다. 깊이만 쓰는 처리와 RGB·깊이를 함께 쓰는 정책은 필요한 출력이 다릅니다. 또한 문서의 최종 깊이는 여전히 RGB 카메라 좌표와 해상도에 맞춰집니다. rgb_resolution이라는 이름이 붙었다고 해서 깊이 출력과 무관한 설정으로 빼면 안 됩니다.
설정을 비교하려면 장면·센서 자세를 고정하고 한 항목씩 바꾸는 작은 확인부터 시작할 수 있습니다. 출력 해상도, 깊이가 비어 있는 부분, 경계 부근의 값과 처리 시간을 함께 기록하면 속도 변화와 관측 변화가 섞였는지 볼 수 있습니다. 이는 독자가 수행할 비교 제안이며, 여기서 얻은 측정 결과는 없습니다.
DLPack으로 옮겨도 복사가 전혀 없는 것은 아닙니다
문서는 DLPack을 이용하면 깊이맵이나 포인트클라우드를 다른 GPU 라이브러리에 전달할 때 불필요한 CPU 왕복을 피할 수 있다고 설명합니다. 다만 제시된 PyTorch 예제는 from_dlpack(...) 뒤에 .clone()을 호출합니다. 예제 전체를 “메모리 복사가 없는 경로”라고 소개하면 이 추가 복사 단계를 빠뜨리게 됩니다.
성능을 비교할 때는 센서 계산 시간, CPU와 GPU 사이의 전송, GPU에서 텐서를 복사하는 시간을 구분해 두세요. DLPack을 썼다는 표기만으로 처리 시간을 예측하거나, 복사를 제거해도 데이터의 수명과 사용 방식이 그대로라고 가정할 수는 없습니다.
처음 설정을 검토할 때는 세 가지를 먼저 적으면 됩니다. 깊이를 기하에서 얻었는지 IR 영상에서 계산했는지, 반환 좌표와 해상도가 무엇인지, 속도 개선을 위해 영상 생성과 메모리 전달에서 무엇을 바꿨는지입니다. 이 정보가 있어야 같은 “깊이 입력”이라는 이름 아래 서로 다른 데이터를 비교하는 일을 피할 수 있습니다.