URDF는 ROS에서 한 로봇의 링크·조인트·형상과 관성 구조를 공유하기 좋고, SDF는 로봇뿐 아니라 센서·마찰·조명·물리 엔진·여러 모델이 놓인 월드까지 표현합니다. 둘 중 하나를 고르는 문제라기보다 기준 모델과 시뮬레이션 확장을 어디에 둘지 정해야 변환 손실을 줄일 수 있습니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
URDF와 SDF는 같은 XML이라도 해결하는 범위가 다르다
URDF와 SDF 모두 링크·조인트를 표현할 수 있지만 중심 역할이 다릅니다. 로봇 시뮬레이터 비교 글이 실행 환경을 고르는 글이라면, 이 글은 시뮬레이터와 ROS 도구에 넘길 모델 파일의 표현 경계를 다룹니다.
한 로봇의 기구 구조와 ROS 프레임을 공유하려면 URDF가 자연스럽고, 여러 모델·조명·지형·물리 엔진·센서가 있는 장면을 재현하려면 SDF가 더 넓은 정보를 담습니다. 프로젝트에서는 두 형식을 경쟁시키기보다 기준과 파생 관계를 명확히 두는 편이 좋습니다.
URDF는 한 로봇의 링크와 조인트 트리를 중심으로 읽는다
ROS 2 URDF 공식 문서는 URDF를 로봇의 형상과 조직을 정의하는 XML 형식으로 설명합니다. link에 visual·collision·inertial을 두고 joint로 부모와 자식 링크의 연결, 축, 제한을 표현합니다.
robot_state_publisher와 RViz, 여러 ROS 패키지는 이 구조를 robot_description으로 받아 TF와 시각화를 만듭니다. 모델이 하나의 루트에서 뻗는 트리라는 전제는 단순하고 호환성이 좋지만 폐루프 기구와 월드 전체를 표현할 때는 제약이 됩니다.
SDF는 로봇 모델 바깥의 월드와 물리 조건까지 포함한다
SDFormat 공식 소개는 SDF가 로봇, 정적·동적 객체, 조명, 지형과 물리 정보를 표현하는 형식이라고 설명합니다. model뿐 아니라 world, physics, scene, light, actor와 plugin을 하나의 계층에서 구성할 수 있습니다.
시뮬레이터가 재현해야 할 것은 로봇 형상만이 아닙니다. 바닥 마찰, 중력, 충돌 접촉, 센서 노이즈와 업데이트율, 주변 설비의 위치가 함께 맞아야 실제 시험과 가까운 결과가 나옵니다.
| 표현 대상 | URDF | SDF |
|---|---|---|
| 로봇 링크·조인트 | 주요 역할 | 지원 |
| 한 월드의 여러 모델 | 직접 표현하지 않음 | world·include |
| 물리·조명·지형 | 확장 의존 | 명시적 지원 |
| 센서·플러그인 | 도구별 확장 | 표준 요소·플러그인 |
visual·collision·inertial은 두 형식 모두에서 따로 확인한다
보이는 mesh가 정확해도 collision이 지나치게 단순하거나 inertial 값이 틀리면 시뮬레이션 동작은 달라집니다. visual은 렌더링, collision은 접촉 계산, inertial은 질량·무게중심·관성텐서를 담당하므로 세 요소를 같은 형상으로 복사하는 습관은 피해야 합니다.
관성 행렬이 물리적으로 유효한지, collision 원점과 크기가 mesh에 맞는지, 단위가 m·kg·rad인지 검사합니다. CAD 내보내기 뒤에는 링크별 질량 합, 무게중심과 관절축을 실제 설계값과 대조해야 합니다.
프레임과 pose 문법 차이는 눈에 보이지 않는 오차를 만든다
URDF joint origin과 link 요소의 origin은 부모·자식 관계에서 해석됩니다. SDF는 pose와 frame, relative_to 같은 표현을 사용할 수 있으므로 TF2 좌표계 글에서 다룬 방향과 기준 프레임을 변환 전후로 다시 그려야 합니다.
mesh가 비슷한 위치에 보여도 센서 광축, collision 원점, joint 축의 부호가 어긋날 수 있습니다. 기준 자세에서 프레임 축을 표시하고 대표 joint를 움직여 부모·자식 변환이 기대한 방향인지 확인하는 시험이 필요합니다.
SDF world는 모델 배치와 환경 재현을 맡는다
SDFormat world 튜토리얼은 world 좌표계 안에 model을 직접 정의하거나 include로 재사용하는 방식을 보여줍니다. 같은 로봇 모델을 이름과 pose만 바꿔 여러 번 배치할 수 있어 다중 로봇과 설비 장면을 구성하기 좋습니다.
월드 파일에는 지면, 조명, 환경 객체와 물리 엔진 설정을 두고 로봇 모델은 별도 자산으로 유지하면 재사용성이 높아집니다. 장면 하나에 모든 model XML을 복사하면 수정 반영과 버전 추적이 어려워집니다.
센서 시뮬레이션은 형상보다 업데이트와 노이즈 설정이 중요하다
SDF sensor 요소는 카메라·LiDAR·IMU 등 센서 유형과 업데이트율, 노이즈, topic 또는 plugin 연결을 표현할 수 있습니다. 시야각과 해상도가 맞아도 timestamp·update_rate·noise가 실물과 다르면 인식과 제어 부하 시험이 왜곡됩니다.
SDFormat sensor 명세에서 사용하는 버전과 지원 요소를 확인하고, 실제 시뮬레이터가 그 버전을 어떻게 구현하는지도 봅니다. 명세에 존재하는 요소가 모든 엔진에서 동일한 물리를 보장하지는 않습니다.
URDF 안의 gazebo 확장은 편리하지만 의존성을 남긴다
하나의 URDF를 유지하면서 gazebo 태그로 마찰·센서·plugin 정보를 덧붙일 수 있습니다. ROS 구조와 시뮬레이션 확장을 한 파일에서 관리하는 장점이 있지만 확장 태그를 모르는 도구는 그 정보를 사용하지 않습니다.
SDFormat의 URDF 확장 문서는 변환 결과와 fixed joint lumping 등을 확인하는 방법을 설명합니다. 확장 태그가 많아질수록 생성된 SDF를 빌드 산출물로 보존하고 diff하는 절차가 필요합니다.
URDF를 Gazebo에 넣으면 내부적으로 SDF 변환이 일어난다
Gazebo Sim의 URDF spawn 문서는 libsdformat이 URDF를 SDF 표현으로 변환해 월드에 로드한다고 설명합니다. 화면에 로봇이 나타났다는 사실만으로 모든 정보가 보존됐다고 볼 수는 없습니다.
변환된 링크 이름, fixed joint 병합, inertial, collision, plugin reference와 센서 frame을 출력해 원본 의도와 비교합니다. 경고를 무시하면 제어기 joint 이름이나 TF·센서 topic이 뒤늦게 어긋날 수 있습니다.
기준 모델 하나와 소비 도구별 생성물을 분리하면 유지보수가 쉬워진다
xacro 또는 템플릿에서 공통 치수·mesh·joint 정의를 만들고 URDF와 SDF를 생성하는 방식이 자주 쓰입니다. 중요한 것은 어느 파일이 사람이 수정하는 기준인지, 어느 파일이 자동 생성물인지 저장소 규칙에 적는 것입니다.
제어용 URDF에는 ros2_control 인터페이스가 필요할 수 있고 시뮬레이션 SDF에는 physics·sensor plugin이 필요합니다. 공통 요소는 한 곳에서 생성하되 소비 도구별 필수 요소는 명시적으로 테스트합니다.
변환 시험은 구조·프레임·물리·센서 네 층으로 나눈다
구조 시험은 link·joint 수와 이름, 프레임 시험은 기준 pose와 축 방향, 물리 시험은 낙하·마찰·관절 제한, 센서 시험은 topic·frame·update_rate·noise를 비교합니다. 숫자 diff와 실제 동작 시험을 함께 써야 합니다.
모델 parser 성공만으로 합격시키지 않습니다. 정지 자세, 대표 joint sweep, 지면 접촉, 센서 정적 장면과 짧은 제어 시나리오를 실행해 생성물과 엔진 조합별 회귀 기준을 만듭니다.
| 검증 층 | 비교 항목 | 시험 |
|---|---|---|
| 구조 | link·joint·이름 | 목록 diff |
| 프레임 | origin·axis·pose | 기준 자세·joint sweep |
| 물리 | 질량·관성·마찰 | 낙하·접촉·제한 |
| 센서 | frame·rate·noise | 정적 장면·topic 통계 |
형식 선택은 가상 시운전의 검증 범위에서 결정한다
단순 RViz 확인과 실제 물리 시험은 같은 모델 요구가 아닙니다. 가상 시운전과 디지털 트윈 글의 검증 범위를 먼저 정하고, 구조·제어·센서·환경 중 어느 요소를 재현해야 하는지에 맞춰 URDF와 SDF의 역할을 배분합니다.
인수 기준에는 모델 버전, 생성 명령, 사용하는 SDF 명세와 시뮬레이터 버전, 변환 경고, 회귀 시험 결과를 포함합니다. 이 정보가 있어야 모델이 보이는 데서 끝나지 않고 반복 가능한 시험 자산이 됩니다.
URDF와 SDF 차이에서 자주 묻는 질문
URDF와 SDF 중 하나만 사용해야 하나요?
아닙니다. URDF를 ROS 구조의 기준으로 두고 SDF를 시뮬레이션 확장으로 생성하거나, 지원 범위가 맞으면 SDF를 중심으로 운영할 수 있습니다.
URDF도 센서를 표현할 수 있나요?
도구별 확장 태그와 플러그인으로 연결할 수 있지만 월드·물리·센서 표현은 SDF가 더 직접적입니다. 사용하는 소비 도구의 지원 범위를 확인해야 합니다.
URDF가 Gazebo에서 보이면 변환이 성공한 건가요?
시각적 로드는 첫 단계입니다. 링크 이름, fixed joint, 관성, 충돌, 센서와 플러그인 연결이 보존됐는지 생성된 SDF와 동작 시험으로 확인해야 합니다.
SDF를 robot_state_publisher가 바로 읽을 수 있나요?
지원은 ROS 배포판과 parser plugin 구성에 따라 다릅니다. 사용 환경의 공식 문서와 호환 태그를 확인하고 TF 결과를 검증해야 합니다.
모델 회귀 시험에서 가장 먼저 볼 것은 무엇인가요?
link·joint 이름과 프레임 축, 질량·관성 합, collision, 센서 frame과 update_rate를 기준 모델과 비교하는 것이 좋습니다.
URDF·SDF 지원 범위와 변환 동작은 ROS 2, SDFormat과 Gazebo 버전에 따라 달라집니다. 사용 중인 버전의 명세와 생성 결과를 함께 보존해야 합니다.