로봇 명세와 장면 자산은 같은 파일이 아니다
URDF는 링크와 관절의 트리, visual/collision/inertial 등 로봇 모델을 표현한다. Xacro를 쓰면 매개변수와 매크로를 확장한 URDF가 importer 입력이 될 수 있다. USD는 이 모델을 장면 Prim과 관계/속성으로 구성하고 재질·센서·환경·여러 배치와 실험 의견까지 합성할 수 있는 더 넓은 표현이다. 따라서 URDF를 USD로 가져온다는 것은 원본을 동일한 문법으로 복사하는 일이 아니다. 어떤 정보를 어디에 표현하고 어떤 가정/옵션을 추가했는지 추적해야 한다.
가상 파이프라인을 네 산출물로 나누자. robot.xacro와 치수 설정은 원본, 이를 확장한 robot.urdf는 이번 입력의 구체화, generated/robot.usd는 도구가 생성한 자산, scene.usda는 그 자산을 참조하여 배치하는 장면이다. 실험별 이득이나 배치 변경은 별도 experiment 레이어로 관리할 수 있다. 원본에 없는 환경 조명/카메라를 USD 장면에 추가했다고 원본 URDF가 자동으로 갱신되는 것은 아니다.
어느 파일을 수정해야 하는지는 변경의 의미로 결정한다. 링크 길이나 실제 관절 영점 정의의 변경은 원본 모델과 관련 보정 자료에서 관리해야 할 수 있다. 장면에서 로봇 두 대의 배치 위치를 바꾸는 일은 scene 쪽이다. 도구가 만드는 generated 자산을 직접 고치면 다음 가져오기에서 수동 변경을 잃거나 수정 이유가 추적되지 않을 수 있다. 생성 결과를 잠그고 출처를 남기거나 재적용 가능한 override를 분리하는 정책을 정한다. 레이어를 나눴다는 사실만으로 원본 경로 변경에도 override가 자동 유지되는 것은 아니다.
변환은 정보의 대응표를 요구한다
URDF link는 대상의 시각/충돌/강체 Prim들로 나뉠 수 있고 joint는 두 바디와 로컬 프레임을 연결하는 관계로 표현될 수 있다. 원본 링크 하나가 USD Prim 하나라는 고정 규칙으로 수를 비교하지 않는다. 메시 병합이나 인스턴싱 같은 처리도 장면 구조를 바꿀 수 있다. 중요한 것은 공개 이름·프레임·물리 의미와 소비자가 요구하는 경로가 유지됐는지다. 원본 이름→대상 Prim 경로→실행 시 관절 이름의 표를 따로 두면 이름 문자열에 의존하는 브리지 오류를 줄일 수 있다.
그림 M10.02-1. 각 칸은 서로 다른 역할/근거다. 아래 방향은 자료/처리의 연결이며 실제 성공을 자동으로 보장하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
Isaac Sim 6.2 공식 importer 문서는 USD 이름 규칙에 맞지 않는 문자를 정리하는 동작, package:// 자원 경로 매핑, visual에서 collision을 만드는 선택지 등을 설명한다. 예를 들어 원본 관절 shoulder-pan이 대상 이름 shoulder_pan으로 바뀌었다는 합성 보고가 있다면 원래 이름으로 보내는 상태/명령의 매핑도 확인한다. 단순히 '-'를 '_'로 바꾸는 일반 치환만 믿으면 이미 shoulder_pan이라는 다른 이름과 충돌할 가능성도 있으므로 최종 대응표의 유일성을 검사한다.
collision 생성은 누락된 원본 정보를 새로 근사하는 일이다. 원본에 visual만 있는데 importer가 볼록 껍질을 만들었다면 ‘원본 collision을 그대로 보존’한 결과가 아니다. 구멍/접촉면이 바뀌지 않았는지 M08.04의 기준으로 비교한다. 질량/관성이나 기본 drive 값이 생성/추정됐다면 출처와 가정도 기록한다. 화면이 비슷하다는 사실은 이런 보존 검사를 대신하지 못한다.
단위·관절 관계·베이스를 수치로 확인한다
가상 팔의 길이 L=0.2 m, z축 회전 관절 q의 제한은 [−1,1] rad라고 하자. L은 원점에서 끝점까지 거리, q는 같은 영점에서 오른손 방향으로 도는 각도다. 모든 scale이 1이고 장면이 m 단위이면 q=0의 끝점은 (0.2,0,0), q=0.5 rad는 약 (0.175517,0.095885,0) m다. 작은 양의 자세까지 비교하면 길이는 맞지만 회전축이나 부호가 뒤집힌 경우를 잡을 수 있다.
USD RevoluteJoint 제한 속성은 degree 계약이므로 [−1,1] rad는 약 [−57.2958,57.2958] degree다. 반면 실행 API가 rad를 받으면 목표 q=0.5에는 변환을 중복 적용하지 않는다. 길이도 metersPerUnit과 전체 변환을 검사한다. 상위 scale=1이고 0.01 m/unit 장면이라면 0.2 m는 20 unit이다. 파일 속성과 제어 API, 원본 값과 최종 변환값을 섞지 않는 것이 핵심이다.
두 그리퍼 관절의 원본 관계가 q_R=0.04−q_L이라고 하자. 두 q는 m 단위이며 q_L=0.01이면 q_R=0.03이다. 합성 변환 보고서에 두 관절이 같은 값 0.01로 독립 설정됐다고 나오면 원본 관계가 유지된 것인지 추가 검사가 필요하다. 6.2 importer 문서는 mimic의 배율/오프셋 관계를 대상 스키마로 옮기는 동작을 설명하지만 그 사실만으로 모든 백엔드/설정에서 이미 검증됐다고 하지 않는다. 백엔드와 적용된 API, 실제 보고 결과를 함께 기록한다.
베이스 고정 여부도 물리 의미다. 6.2의 Base Type은 Source/Fixed/Mobile을 구분한다. Source는 원본 고정 관계를 그대로 두는 의미이며 고정 베이스의 동의어가 아니다. Fixed는 world와 루트를 고정하는 관계를 추가하고 Mobile은 그 관계를 제거하여 이동 가능하게 하는 선택이다. 탁자에 고정한 팔을 의도했는데 자유 베이스로 바뀌면 같은 관절각의 내부 기구학이 맞아도 전체 운동은 다르다. USD 표준 스키마와 PhysX/Newton 등 백엔드용 작성 내용도 구분하여 버전이 다른 문서의 옵션 이름을 섞지 않는다.
다시 가져와도 설명할 수 있는 자산
변환 보고에는 입력 원본/확장 URDF와 설정, 모든 메시/재질의 경로·개정/해시, 도구 버전과 옵션·경고, 출력 경로와 이름 대응표를 남긴다. 확장 URDF가 같아도 package://가 다른 메시로 해석되면 같은 자산이라고 할 수 없다. 상대 경로는 어느 파일 기준으로 해석되는지도 기록한다. 원본 파일 이름이 같다는 것은 내용 동일성의 증거가 아니다.
재가져온 뒤에는 자원 누락/표시, 이름·프레임·몇 개 기준 자세와 제한/mimic, 질량/COM/관성·collision·베이스, drive/상태/시간 연결 순으로 다시 확인한다. 실험 override가 기존 경로를 계속 대상으로 하는지도 본다. 원본 치수와 생성 USD만 새로 바꾸고 오래된 override가 숨긴 값을 그대로 쓰면 변경이 반영되지 않은 것처럼 보일 수 있다. M10.01에서 배운 최종 의견의 출처를 여기서 조사한다.
기존 3.1 모델은 실제 사례의 축/영점/루트를 살펴보는 연결 자료다. 아래 활동은 그 장치의 실제 정격이나 importer 실행 결과가 아니라 위 가상 모델의 보고서를 판단하는 연습이다. 판정 범위와 아직 모르는 항목을 분리해 적는다.