이 문서는 Isaac Sim을 로봇, 센서, 물리, 작업 시나리오를 가상 환경에서 검증하는 시뮬레이션 도구로 정리한다. Isaac Sim은 Omniverse와 USD 기반으로 로봇 모델, gripper, 물체, 물리 속성, camera/LiDAR/IMU/contact sensor를 하나의 scene 안에서 구성할 수 있다.
핵심 흐름은 digital twin, USD scene 구성, PhysX 물리, OmniGraph 데이터 흐름, Python scripting이다. Pick-and-place 실습에서는 URDF import, gripper assembly, articulation/controller 설정, 물체 pose, goal pose가 함께 맞아야 manipulation이 성립한다. Isaac Sim은 실제 로봇에 적용하기 전 perception, control, sensor pipeline을 검증하는 중간 실험장으로 이해할 수 있다.
키워드: Isaac Sim, Omniverse, USD, OpenUSD, digital twin, PhysX, rigid body, collider, fixed joint, OmniGraph, sensor simulation, camera, LiDAR, IMU, contact sensor, URDF import, robot assembler, controller, pick-and-place, Python scripting, ROS2 bridge
Isaac Sim은 NVIDIA Omniverse 기반의 로봇 시뮬레이션 환경이다. Gazebo가 ROS 생태계에서 많이 쓰이는 물리 시뮬레이터라면, Isaac Sim은 고품질 렌더링, 물리 시뮬레이션, 센서 시뮬레이션, synthetic data, 로봇 조작 실험에 강점을 가진다.
Isaac Sim에서는 카메라 센서, LiDAR, IMU, contact sensor를 만들고, 물체를 배치하고, 로봇 모델을 import하고, controller를 통해 움직임을 실행할 수 있다. 이 과정은 실제 로봇 실험 전에 perception과 manipulation을 함께 검증하는 데 유용하다.
카메라 실습은 3D world와 2D image의 관계를 이해하게 한다. 카메라는 단순히 이미지를 저장하는 객체가 아니라, 3D 공간의 점을 이미지 평면 위 좌표로 투영하는 센서다.
Pick-and-place 실습은 로봇 모델 import, gripper assembly, 물체 생성, 목표 위치 설정, controller 실행이 모두 연결되어야 한다. 단순히 로봇 팔만 움직이는 것이 아니라, 그리퍼가 물체를 잡고, 목표 위치로 이동하고, 놓는 전체 작업 흐름을 구성한다.
이 실습은 manipulation이 perception, planning, control, physics가 모두 맞물리는 작업이라는 점을 보여 준다.
Isaac Sim pick-and-place 코드에서는 먼저 SimulationApp을 실행하고, world를 만든 뒤 URDF importer로 로봇과 gripper 모델을 불러온다. 이후 robot assembler를 통해 로봇과 gripper를 결합하고, controller 설정 파일을 사용해 움직임을 제어한다.
이 흐름은 로봇 시뮬레이션이 단일 함수 호출이 아니라는 점을 보여 준다. 모델 import, articulation root, gripper frame, controller config, 물체 pose, goal pose가 모두 맞아야 pick-and-place 작업이 성립한다.
카메라 실습에서는 world point를 image coordinate로 변환하는 과정을 확인할 수 있다. 이는 CV 결과를 로봇 행동으로 연결할 때 핵심이다. 이미지에서 검출된 물체가 실제 3D 공간의 어디에 있는지 알아야 로봇이 접근할 수 있기 때문이다.
LiDAR, IMU, contact sensor 실습은 perception이 이미지에만 한정되지 않는다는 점을 보여 준다. 실제 로봇은 여러 센서를 결합해 자신의 상태와 주변 환경을 이해한다.
Isaac Sim은 CV와 로봇의 연결 지점에서도 중요하다. 시뮬레이션 카메라로 이미지를 얻고, 그 이미지에서 물체를 검출하고, 검출 결과를 로봇의 목표 위치로 변환해 pick-and-place를 수행하는 구조를 만들 수 있다.
실습 backup 자료에는 Isaac Sim 본체 소스 일부와 함께 doosan-robot2/urdf/m0609_isaac_sim.urdf 같은 로봇 import용 모델이 들어 있다. 여기서 중요한 것은 Isaac Sim이 단순 3D viewer가 아니라 USD scene, PhysX physics, sensor simulation, robot articulation, Python scripting을 함께 제공하는 robotics simulation application이라는 점이다.
M0609 같은 실제 로봇을 Isaac Sim에서 쓰려면 URDF나 mesh를 가져와 USD scene 안의 articulation으로 구성해야 한다. URDF는 link/joint 구조를 제공하고, Isaac Sim은 이를 USD prim과 physics articulation으로 변환해 simulation에서 움직일 수 있게 한다. 변환 뒤에는 joint drive, collision, mass/inertia, material, scale, frame orientation을 확인해야 한다.
Isaac Sim 강의 흐름에서 camera, depth, lidar, contact sensor, IMU를 다루는 이유는 perception과 control을 실제 로봇 없이 검증하기 위해서다. Camera는 RGB image와 depth를 만들고, RTX lidar는 point cloud나 scan 정보를 만들며, contact sensor는 grasp나 충돌 상태를 확인하는 데 쓰인다. 이 sensor output이 ROS2 bridge나 Python API를 통해 perception pipeline으로 들어가면 실제 로봇 실험 전 디지털 환경에서 알고리즘을 검증할 수 있다.
Isaac Sim의 pick-and-place 예제는 로봇 model, gripper, task definition, controller가 함께 필요하다. 로봇은 articulation으로 움직이고, gripper는 end-effector로 조립되며, task는 pick target과 place target을 제공하고, controller는 motion policy나 RMPFlow 같은 방식으로 joint command를 만든다. 따라서 Isaac Sim에서 pick-and-place를 본다는 것은 “물체가 움직인다”보다 simulation scene, physics, robot controller, sensor feedback이 함께 맞물리는지를 보는 것이다.
Isaac Sim은 센서, 물체, 로봇 제어, 물리 환경을 한 장면 안에서 검증하는 로봇 시뮬레이션 환경이다.
디지털 트윈은 현실의 로봇, 설비, 공정을 가상 공간에 복제하고 현실과 가상의 상태를 연결하는 기술이다. 로봇 개발에서는 실제 하드웨어 실험에 시간과 비용이 많이 들고, 실수로 로봇이나 설비가 손상될 수 있다. 또한 같은 실험 조건을 반복하기 어렵다.
디지털 트윈은 이런 문제를 줄이기 위해 현실과 유사한 가상 환경을 만들고, 그 안에서 배치, 센서, 물리, 제어, 공정 흐름을 미리 실험하게 한다. 단순 3D 모델이 아니라 물리적 속성, 센서 특성, 데이터 연결까지 포함하는 가상 시스템이다.
디지털 트윈이 의미 있으려면 몇 가지 조건이 필요하다. 첫째, 기하학적 구조가 현실과 맞아야 한다. 로봇과 설비의 크기, 위치, 회전, 연결 관계가 실제와 다르면 시뮬레이션 결과도 의미가 약해진다.
둘째, 물리 속성이 반영되어야 한다. 질량, 무게 중심, 마찰, 충돌, 관성, joint constraint가 현실과 비슷해야 로봇 동작과 접촉 결과를 검증할 수 있다.
셋째, 센서가 시뮬레이션되어야 한다. 카메라, depth, LiDAR, IMU 같은 센서가 실제와 유사한 방식으로 데이터를 만들어야 perception 알고리즘을 검증할 수 있다.
넷째, 현실 시스템과 연결될 수 있어야 한다. 현실의 센서 데이터가 가상 환경으로 들어오거나, 가상 실험 결과가 실제 제어 전략으로 이어질 수 있어야 디지털 트윈의 가치가 커진다.
Omniverse는 실시간 3D 협업과 시뮬레이션을 위한 플랫폼이고, Isaac Sim은 그 위에서 로보틱스 시뮬레이션을 수행하는 애플리케이션이다. Omniverse는 여러 DCC 도구와 데이터를 연결하고, Isaac Sim은 로봇, 센서, 물리, ROS2 연동을 제공한다.
이 구조에서 Omniverse는 데이터와 협업 플랫폼, Isaac Sim은 로봇 실험 환경으로 이해할 수 있다. 즉 Isaac Sim은 디지털 트윈을 실제 로봇 개발에 적용하기 위한 실행 환경이다.
USD는 Universal Scene Description의 약자로, 복잡한 3D scene을 구성하고 교환하기 위한 데이터 포맷이다. 로봇, 설비, 물체, 재질, 조명, 물리 속성, 계층 구조를 하나의 scene graph로 표현할 수 있다.
USD를 사용하는 이유는 여러 도구에서 만든 자산을 하나의 공통 형식으로 연결하기 위해서다. Blender, CAD, 시뮬레이터, 렌더러가 서로 다른 형식을 쓰면 공정 환경을 통합하기 어렵다. USD는 이런 자산들을 계층적으로 조합하고, reference나 layer를 통해 큰 scene을 관리할 수 있게 한다.
Omniverse Nucleus는 USD 기반 scene과 자산을 중앙에서 관리하는 서버 역할을 한다. 여러 사용자가 같은 scene을 공유하거나, 외부 도구에서 만든 설비 모델을 Isaac Sim으로 가져올 수 있다. 이 구조는 공장 설비처럼 많은 자산이 포함된 디지털 트윈에서 중요하다.
디지털 트윈은 현실의 로봇과 공정을 가상 환경에 물리적으로 재현하고, USD는 그 가상 세계를 구성하는 공통 scene description 형식이다.
로봇 시뮬레이션에서 물체가 보이는 것만으로는 충분하지 않다. 로봇이 물체를 밀고, 잡고, 충돌하고, 컨베이어 위에서 이동시키려면 물리 엔진이 필요하다. PhysX는 Isaac Sim에서 rigid body, collider, joint, contact, gravity 같은 물리 현상을 계산하는 엔진이다.
PhysX를 이해해야 하는 이유는 시뮬레이션 결과가 물리 설정에 의해 달라지기 때문이다. Collider가 없으면 물체가 서로 통과할 수 있고, rigid body 설정이 없으면 물체가 물리적으로 움직이지 않는다. Mass, friction, restitution, collision shape가 실제와 다르면 로봇 조작 실험도 현실과 다르게 나온다.
Collider는 충돌 판정을 위한 형상이다. 화면에 보이는 mesh가 복잡하더라도 collision 계산에는 단순화된 collider를 사용할 수 있다. Rigid body는 물리 시뮬레이션에서 힘과 충돌에 반응하는 물체다.
Static object는 움직이지 않는 물체로, 바닥이나 고정 설비처럼 환경 기준이 되는 대상에 사용한다. Dynamic object는 힘과 충돌에 따라 움직이는 물체다. 로봇이 집어 올릴 cube나 컨베이어 위의 물체는 dynamic object가 될 수 있다.
Trigger는 물리적으로 충돌을 막기보다 어떤 영역에 들어왔는지 감지하는 용도로 쓰인다. 공정 자동화에서는 물체가 특정 위치를 지났는지 감지하는 sensor 영역처럼 사용할 수 있다.
공정 설비 배치에서는 world 좌표계와 local 좌표계를 구분해야 한다. 어떤 설비 위에 로봇을 올려놓거나, gripper를 robot flange에 붙이거나, 컨베이어 벨트를 특정 위치에 고정할 때 부모-자식 관계와 local transform이 중요하다.
Fixed joint는 두 물체를 물리적으로 고정된 관계로 묶는다. 예를 들어 로봇 base를 테이블 위에 고정하려면 base와 table 사이의 상대 위치가 정확해야 한다. local position을 잘못 설정하면 화면상 위치는 그럴듯해도 물리 연결이 어긋날 수 있다.
OmniGraph는 Isaac Sim에서 node graph 방식으로 데이터 흐름과 동작을 구성하는 도구다. 코드로 모든 동작을 작성하지 않고, node를 연결해 센서 데이터, trigger, controller, ROS2 publish/subscribe 같은 흐름을 만들 수 있다.
OmniGraph를 배우는 이유는 공정 자동화가 단순 Python script만으로 구성되지 않기 때문이다. 센서 이벤트가 발생하면 물체를 이동시키고, 컨베이어 상태를 바꾸고, ROS2 메시지를 publish하는 흐름을 graph로 표현할 수 있다.
PhysX는 Isaac Sim 안에서 물체와 로봇의 물리 반응을 계산하고, OmniGraph는 센서·이벤트·제어 흐름을 node graph로 구성하게 해 준다.
Isaac Sim은 GUI로 scene을 구성할 수도 있지만, 반복 가능한 로봇 실험과 자동화 공정을 만들려면 Python script가 필요하다. Python scripting은 물체 생성, 로봇 import, controller 실행, 센서 데이터 획득, task 구성 과정을 코드로 재현하게 해 준다.
GUI 조작은 한 번의 실험에는 편하지만, 같은 환경을 다시 만들거나 여러 조건을 반복 비교하기 어렵다. Python script로 scene을 만들면 실험 조건을 코드로 관리할 수 있고, 로봇 동작을 자동화할 수 있다.
Isaac Sim은 USD stage 위에 scene을 구성한다. Stage는 전체 3D 세계이고, prim은 stage 안의 객체 단위다. Sphere, Cube, Robot, Camera, Light 같은 요소가 prim으로 생성되고 배치된다.
Python API에서는 현재 stage를 가져오고, prim을 생성하거나 속성을 바꾸고, world를 step하면서 시뮬레이션을 진행할 수 있다. 이 구조를 이해하면 GUI에서 보이는 객체가 코드 안에서는 어떤 API 객체로 다뤄지는지 연결된다.
Isaac Sim Core API는 World, Scene, Object, Robot, Controller, Task 같은 추상화를 제공한다. World는 시뮬레이션 전체를 관리하고, Scene은 world 안의 객체들을 관리한다. DynamicCuboid나 VisualCuboid 같은 객체를 scene에 추가할 수 있다.
World step은 시뮬레이션을 한 프레임 진행시키는 과정이다. 매 step마다 controller를 호출하고, 로봇 상태를 읽고, 센서 데이터를 갱신할 수 있다.
Controller는 로봇에게 어떤 action을 줄지 계산한다. 예를 들어 differential drive controller는 선속도와 각속도를 좌우 바퀴 속도로 변환한다. Manipulator controller는 end-effector 목표를 joint command로 바꾸는 역할을 할 수 있다.
Task는 환경과 목표를 정의한다. Pick-and-place task라면 물체의 초기 위치, 목표 위치, 로봇과 gripper, 성공 조건을 포함한다. Task를 분리하면 scene 구성과 제어 로직을 더 체계적으로 관리할 수 있다.
수업 자료에서는 Isaac Sim과 VS Code, Jupyter Notebook 연동도 다룬다. 이는 긴 script를 작성하고 디버깅하거나, 실험적으로 API를 실행해 보기 위한 개발 환경 구성이다. 중요한 점은 Isaac Sim의 Python은 일반 시스템 Python과 다를 수 있으므로, Isaac Sim이 제공하는 Python 환경이나 extension 연동을 사용해야 한다는 것이다.
Isaac Python Scripting 실습 정리
Isaac Sim 강의 코드에는 hello_world.py, hello_world_extension.py, manipulator_tutorial.py 같은 script와 extension 예제가 들어 있다. 이 코드들은 stage를 열고, prim을 추가하고, robot을 배치하고, world를 step하며, controller를 호출하는 작업을 Python으로 수행한다. GUI에서 한 번 만든 장면은 재현이 어렵지만, script로 작성하면 같은 scene과 같은 초기 조건을 반복 실행할 수 있다.
Isaac Core API에서 World는 simulation loop와 physics step을 관리하는 상위 객체이고, Scene은 world 안에 배치된 robot, ground plane, object를 관리한다. Object나 robot prim은 scene 안에서 pose, scale, physics property를 가진다. 이 구분을 이해해야 “어디에 물체를 추가하는가”, “언제 simulation step을 돌리는가”, “어느 객체의 pose를 읽는가”가 명확해진다.
hello_world_extension.py 같은 예제는 단발 script와 extension의 차이를 보여 준다. Script는 실행 후 끝나는 자동화에 적합하고, extension은 Isaac Sim UI 안에서 panel, button, callback, long-running interaction을 제공할 때 필요하다. 로봇 설정 wizard나 teaching tool처럼 사용자가 시뮬레이터 안에서 반복 조작하는 기능은 extension 구조가 더 자연스럽다.
manipulator_tutorial.py 계열 코드는 manipulator를 scene에 올리고 controller로 움직이는 흐름을 보여 준다. 여기서 script는 단순히 로봇을 움직이는 명령 모음이 아니라, scene 구성, robot articulation 접근, controller 생성, target pose 또는 task 설정, simulation step 실행을 하나의 절차로 묶는다. 이 구조가 이후 Isaac Pick and Place, factory automation, sensor data generation으로 확장된다.
Isaac Sim Python Scripting API는 GUI로 만든 로봇 시뮬레이션을 코드로 재현하고, 물체 생성부터 controller와 task 실행까지 자동화하게 해 주는 도구다.
Isaac Sim scripting은 world, scene, prim을 코드로 구성하는 방식이다. GUI에서 배치한 장면을 코드로 재현할 수 있어야 실험 조건을 반복할 수 있다.
world = self.get_world()
world.scene.add_default_ground_plane()
franka = world.scene.add(
Franka(prim_path="/World/Fancy_Franka", name="fancy_franka")
)
world.scene.add(DynamicCuboid(
prim_path="/World/random_cube",
name="fancy_cube",
position=np.array([0.3, 0.3, 0.3]),
scale=np.array([0.0515, 0.0515, 0.0515]),
color=np.array([0, 0, 1.0]),
))
World는 simulation loop와 physics step을 관리하고, Scene은 world 안의 robot과 object를 관리한다. prim_path는 USD stage 안의 객체 주소다. 같은 화면에 보이는 robot과 cube도 내부적으로는 /World/... 경로를 가진 prim으로 관리된다.
이 코드가 digital twin 개념과 연결되는 이유는 Isaac Sim이 단순한 3D 뷰어가 아니라 로봇, 물체, 물리, 센서를 가진 가상 세계이기 때문이다. ROS2 bridge를 붙이면 Isaac scene의 robot state와 sensor data가 ROS topic/action/service로 연결되고, MoveIt이나 perception pipeline을 실제 장비 없이 먼저 검증할 수 있다.