🔵

Issac Sim 외부

이 글에서 다루는 질문은 ‘어떻게 Issac Sim의 카메라 출력을 다른 파이프라인에 집어넣는가?’와 ‘처리 결과를 어디에 어떤 형태로 보여줄 수 있는가?’ 입니다.

Issac Sim의 카메라 출력 → 다른 파이프라인

생성(camera prim → render product) → 추출 또는 전달(GPU 메모리 유지, numpy 배열로 복사, RTSP 인코드, ROS publish) → 처리(Warp 처리, Roboflow segmentation, 후처리) → 시각화 또는 소비(Isaac Sim overlay, RViz, Foxglove, RTSP 재송출)

Isaac Sim의 카메라 데이터는 기본적으로 camera prim → render product에서 만들어지고, 그 뒤에 어떤 경로를 타느냐에 따라 오버헤드의 성격이 달라집니다.

Warp 같은 GPU 경로

생성 → GPU frame 유지 → GPU 처리(Warp/커스텀 CUDA/추론) → 결과 소비

가장 빠른 경로입니다. Isaac Sim의 augmentation 문서는 Warp가 특히 좋은 이유를 데이터가 이미 GPU 메모리에 있을 때 GPU→CPU 복사를 피할 수 있기 때문이라고 직접 설명합니다(ref2). 즉, 렌더 결과가 GPU 쪽에 있고, 후속 처리도 Warp/GPU에서 하면 중간에 CPU 메모리로 내리는 단계가 줄어듭니다.

객체 복사 / numpy 배열로 직접 가져오기

생성 → CPU frame 추출(numpy 등) → CPU/GPU 추론 → 결과 소비

Render product나 Camera 클래스에서(camera.get_rgba()[:, :, :3]) ) 프레임을 Python/numpy 쪽으로 꺼내오는 경로입니다. Isaac Sim 문서도 Camera 클래스를 통해 render product 데이터를 가져오는 경로를 설명합니다. 여기서 가장 비싼 포인트는 네트워크가 아니라 GPUCPU 경계와 Python 레벨 복사입니다. RTSP처럼 인코딩/디코딩은 없지만, GPU에 있던 걸 CPU에 올리는 순간 이미 꽤 큰 비용이 붙습니다. 그래도 같은 프로세스에서 RTSP나 ROS를 거치지 않고 바로 추론한다면, 이 경로는 대체로 RTSP나 raw ROS보다 짧습니다. 왜냐하면 인코딩/디코딩, QoS(토픽 통신에서 “얼마나 믿을 수 있게, 얼마나 최근 데이터를, 얼마나 많이 보관하면서 보낼지”를 정하는 정책 묶음)에 기반한 DDS 큐잉(publish된 메시지가 바로 즉시 소비되지 못할 때 잠깐 쌓아두는 버퍼/대기열), 소켓 버퍼링이 없기 때문입니다.

Camera API는 get_rgb/get_rgba에 대해 device를 cpu 또는 cuda 계열로 선택할 수 있으며 반환형도 np.ndarray | wp.array라고 명시합니다. 즉 “Python/numpy 쪽으로 당겨와서 처리한다”는 말 자체는 맞지만, 그게 항상 CPU 복사를 뜻하는 건 아닙니다. device='cuda'로 GPU 쪽 배열을 유지할 수도 있습니다.

RTSP로 변환 후 RTSP 처리 SW에 넣기

생성 → 비디오 인코드(H.264/H.265) → RTSP 스트림 → 수신 측 디코드 → 추론 → 결과 소비

direct frame 경로에 비해 인코드, 패킷화, 버퍼링, 디코드가 추가됩니다. Isaac Sim 쪽은 RTSPWriter가 render product를 RTSP로 스트리밍하고, Roboflow 같은 소비자는 RTSP를 비디오 소스로 받아 디코드 후 추론하는 구조입니다.

프로세스 분리, 머신 분리, 다중 소비자 연결, 표준 비디오 툴과의 연동이 쉽습니다. 단점도 명확합니다. 프레임 전달을 위해 비디오 스트리밍 계층을 새로 얹는 비용이 붙습니다. NVIDIA Isaac ROS 성능 요약에서는 1080p 기준 H.264 encoder가 대략 2.7–10 ms, decoder가 대략 4.1–5.3 ms 수준으로 제시됩니다. 구현과 하드웨어 설정에 따라 차이가 있지만, 단순히 인코드+디코드만 봐도 대략 7–15 ms 정도의 추가 지연 구간이 생길 수 있다는 뜻입니다. 여기에 RTSP 버퍼와 애플리케이션 큐잉이 더 붙습니다.

저지연보다는 분리된 시스템 간 연결에서 가치가 큽니다. 같은 머신 내부에서 Isaac Sim과 추론기를 붙일 때는 direct frame보다 대체로 불리하지만, 다른 머신으로 보내거나 모니터링, 녹화, 복수 소비자를 붙일 때는 오히려 훨씬 편합니다.

raw ROS image

생성 → ROS raw image publish → DDS 전달 → subscriber 수신 → 추론 → 결과 소비

CPU 메모리화, 메시지 생성, 직렬화/전달, DDS 큐 관리, subscriber 측 복원입니다. 같은 머신이라도 raw는 데이터가 너무 크기 때문에 메모리 대역폭과 복사 비용이 무겁습니다. 다른 머신이면 네트워크까지 직접 압박합니다. 그래서 raw ROS image는 가장 범용적이지만, 고해상도·고FPS·다중 소비자일수록 가장 먼저 부담이 커지는 쪽입니다. 압축 artifacts 없이 원본 프레임이 꼭 필요하고, ROS graph 안에서 바로 후속 처리 노드들이 붙어 있으며, 해상도/FPS가 낮거나 같은 머신에서만 돌리는 경우 필요합니다.

ROS + compressed/image_transport 또는 H.264

생성 → ROS compressed image/H.264 publish → DDS 전달 → decode → 추론 → 결과 소비

compressed_image_transport는 JPEG/PNG 기반이고, ffmpeg_image_transport나 Isaac ROS Compression은 H.264/H.265 같은 비디오 코덱 경로를 제공합니다.

전송 관리 측면에서 RTSP와의 차이는 RTSP는 비디오 스트리밍 프로토콜 표준이지만, 이쪽은 ROS/DDS 생태계 안에 남는다는 차이가 있습니다. 토픽 기반 동기화, 다른 ROS 노드들과의 자연스러운 연결이 중요할 때 유리합니다. 반대로 “그냥 다른 프로세스에 비디오만 보내면 된다”면 RTSP가 더 단순한 경우가 많습니다.

ROS + NITROS

생성 → NITROS-adapted ROS type → NITROS-enabled node chain → 처리 → 결과 소비

“CPU 쪽 무거움”을 완화하려는 방향에 가깝습니다.

NITROS는 프레임 형식 그 자체라기보다 ROS 그래프 안에서 타입 적응과 협상으로 복사/직렬화를 줄이는 최적화 계층입니다. NITROS는 compatible node들 사이에서 불필요한 CPU serialization과 GPUCPU copy를 줄이도록 설계되어 있고, CUDA 노드는 입력과 출력을 GPU accelerated memory에서 직접 주고받을 수 있습니다.

NITROS의 이점은 경로 노드들이 모두 NITROS를 사용할 때 유의미합니다. 중간에 일반 ROS 노드, RViz, 일반 subscriber, 표준 sensor_msgs/Image subscriber가 끼면 결국 적응/변환이 필요해지고, 그 지점에서 CPU 메모리화나 직렬화 비용이 다시 들어옵니다.

처리 결과 → 어디에 어떤 형태로 보여주느냐

결과를 파일/데이터셋 형태로 저장하고 오프라인 시각화

가장 기본적인 방법입니다. 실시간 디버깅이 아니라면, 결과를 저장해 놓고 notebook이나 dataset viewer에서 다시 보는 것도 방법입니다.

Isaac Sim 안에서 2D 영상 오버레이처럼 보여주기

시각화 하면 가장 직관적으로 떠올리는 방식입니다. “segmentation 결과를 원본 카메라 영상 위에 반투명으로 덧씌워 보기”에 해당하기 때문입니다.

Isaac Sim은 기본적으로 이런 질문에 최적화돼 있습니다. “이 로봇을 이 장면에 놓으면 센서가 무엇을 보나?”, “이 정책이 이 물리 환경에서 어떻게 행동하나?”, “이 카메라와 랜덤화 설정으로 어떤 합성 데이터를 만들 수 있나?” 외부 비디오 스트림을 받아서 재생·중계·모니터링하기는 본업이 아닙니다.

물론 최근 Omniverse 플랫폼이 비디오 파일과 스트림을 RTX 머티리얼의 텍스처 소스로 사용할 수 있는 기능을 추가하고 있습니다. 나중에는 외부 비디오를 받아서, 예를 들어 벽면의 스크린, TV, 모니터, 광고판, 평면 메시에 재질의 일부로 매핑할 수 있게 되겠지요. 이건 “외부 영상도 장면 안으로 들여오는 수요”가 분명 존재하고 플랫폼 차원에서 조금씩 지원이 넓어지고 있다는 뜻입니다. 다만 이건 최신 Kit(우리는 예전에 레고 비유를 들며 Kit를 조합하여 Isaac Sim을 만든 것이라는 내용을 살펴봤습니다) 릴리스 노트에 나온 내용이고(ref1), 곧바로 “Isaac Sim 5.1에서 외부 RTSP를 센서 입력처럼 자연스럽게 쓸 수 있다”는 뜻까지는 아닙니다. 즉 철학 자체가 완전히 배타적인 건 아니지만, 핵심 제품 정체성은 여전히 시뮬레이터 쪽입니다.

Isaac Sim 내부 3D 씬에 직접 시각화

이건 가장 “시뮬레이터다운” 방식입니다. segmentation 결과를 받아서 3D bbox, 점군, 레이, 폴리라인, 마커를 씬의 일부로 다시 그리는 겁니다. Isaac Sim의 Debug Drawing Extension은 이런 용도에 잘 맞고, 선/점 디버그 기하를 지속적으로 유지할 수 있습니다.

이 방식이 특히 좋은 경우는 결과가 단순한 2D 마스크 자체보다 3D 위치, 충돌 판단, grasp 후보, 경로 계획, 로봇 좌표계와의 정합과 연결될 때입니다. 예를 들어 “이 segmentation이 가리키는 박스의 3D 중심이 어디냐”, “로봇 팔이 집을 target prim이 무엇이냐”를 같이 보려면 Isaac Sim 안에 다시 그리는 쪽이 가장 해석력이 좋습니다.

대신 단점은 비전 시스템이 돌려준 결과가 본질적으로 2D 마스크 이미지일 때, 그걸 Isaac Sim 3D 씬에 자연스럽게 다시 입히려면 추가 변환이 필요합니다. 3D에 입혀 버렸으니 2D 픽셀 오버레이에 덜 직관적이라는 점도 문제입니다.

ROS로 결과를 내보내고 RViz에서 보기

결과가 perception에서 끝나는 게 아니라 navigation, planning, manipulation으로 이어지면 RViz가 가장 자연스럽습니다. Isaac Sim도 ROS 2 Camera Helper와 bridge를 제공하니, “Isaac Sim 센서 → perception → ROS 결과 → RViz” 흐름은 구조적으로 잘 맞습니다.

ROS로 결과를 내보내고 Foxglove에서 보기

Foxglove는 이 문제에 꽤 잘 맞습니다. 공식 문서 기준으로 Image panel은 raw/compressed image와 compressed video를 표시할 수 있고, 2D annotations와 3D markers를 함께 올릴 수 있습니다. 3D panel은 depth image를 point cloud처럼 볼 수도 있습니다. ROS 2 데이터도 native, bridge, rosbridge 등으로 연결할 수 있습니다.

segmentation 결과 시각화라는 문제만 놓고 보면, Foxglove는 사실상 RViz와 영상 뷰어의 중간쯤입니다. 원본 이미지 위에 결과를 올려 보기 쉽고, 동시에 3D marker나 topic graph, diagnostics도 같이 볼 수 있습니다. 즉 2D perception debugging과 ROS 시스템 디버깅을 함께 하고 싶을 때 아주 강합니다.

처리된 결과를 다시 RTSP/비디오 스트림으로 만들어서 보기

결과를 annotated video frame으로 만든 뒤 다시 RTSP나 웹 스트림으로 내보내면, VLC·웹페이지·모니터링 시스템·별도 dashboard에서 쉽게 볼 수 있습니다. ROS를 몰라도 되고, Isaac Sim 내부 확장을 몰라도 됩니다. 단순히 “사람들이 결과 영상을 보기만 하면 된다”면 이게 제일 쉽습니다. 다른 머신, 다른 팀, 원격 UI에도 바로 붙습니다. 단점은 시뮬레이터 및 로봇 시스템과의 의미적 결합이 약합니다.

parse me : 언젠가 이 메모에 쓰이면 좋을 것 같은 재료들입니다.

•

Isaac Cortex에서 말하는 Graph와 이 글에서 말하는 Action Graph는 다른 존재입니다.

•

더 정확히 말하면, Cortex에도 “graph”가 있긴 하지만 그건 OmniGraph의 Action Graph가 아니라 Cortex의 Decider Network입니다.

from : 이 메모에 쓰인 생각을 만든 과거의 생각들과 연관관계를 설명합니다.

Isaac Sim 개발 환경 구축하기

•

이 글은 앞의 개발 환경 글에 이어진다고 볼 수 있다.

supplementary : 이 메모에 작성된 생각을 뒷받침하는 새로운 메모입니다.

opposite : 이 메모에 작성된 생각과 대조되는 새로운 메모입니다.

None

to : 이 메모에 작성된 생각으로부터 발전된 생각의 메모입니다.

ref : 생각에 참고한 자료입니다.

RTX - Video files and streams can now be used as texture sources in RTX materials, with initial support on Linux and Windows.

Kit 110.0 Release Notes — Omniverse Developer Guide

The use of warp is particularly advantageous for executing parallelizable tasks, especially if the data already resides in the GPUs memory, thus avoiding memory copies from GPU to CPU. For a better understanding of the tutorial, familiarity with omni.replicator, annotators, writers and warp is recommended.

Data Augmentation — Isaac Sim Documentation

프로젝트메모 템플릿 버전 2025.11.16