부록 부록
A.3 REP 색인
A.3.1 이 부록의 사용법
REP(ROS Enhancement Proposal)는 ROS의 설계 결정이 기록되는 문서다. 규약이 왜 그렇게 정해졌는지, 어떤 대안이 검토되고 기각되었는지가 여기 남는다(15.5.3).
이 부록은 이 책이 참조한 REP들의 색인이며, 각각이 무엇을 다루고 이 책의 어느 장과 연결되는지를 정리한다.
정직: REP 번호와 제목은 원문으로 반드시 확인하라
(확인 필요). 이 색인은 기억과 관행에 기댄 개관이며, 번호가 틀렸거나 제목이 다를 수 있다. REP는 개정·대체되기도 하므로 현재 상태를 확인해야 한다. 이 책은 REP 원문을 인용하지 않으며, 여기 적힌 요약은 해당 REP를 찾아가기 위한 실마리로만 사용하라. 이 환경에서 확인하지 않았다(목차 3).
REP를 찾는 법:
| 방법 | 설명 |
|---|---|
| 공식 REP 색인 | 전체 목록·상태 |
| 번호로 직접 | REP 번호를 알 때 |
| 검색 | 주제어 + "REP" |
| 관련 패키지 문서 | 종종 REP를 인용 |
A.3.2 좌표·단위·센서 규약
이 책에서 가장 자주 인용한 REP들이다.
REP(확인 필요) | 주제 | 이 책의 장 |
|---|---|---|
| REP 103 | 표준 단위와 좌표 규약(SI, 오른손 z-up) | 7.1.2·5.1 |
| REP 105 | 이동 플랫폼 좌표 프레임(map·odom·base_link) | 5.1.7·7.1.3 |
| REP 145 | IMU 드라이버 규약 | 7.1.5·7.6 |
| REP 117 | 거리 측정의 정보 표현(무한·범위 밖) | 7.5 |
| REP 118 | 깊이 이미지 표현 | 7.2·7.4 |
견해: REP 103과 105는 이 책 전체의 전제다. 단위(미터·라디안·초), 축 방향(x 전방·y 좌측·z 상방), 프레임 계층(
map→odom→base_link)이 여기서 나온다. 로봇 소프트웨어를 쓰는 사람이라면 이 둘은 읽어 볼 가치가 있다 — 짧고, 이후의 많은 혼란을 예방한다.
견해: REP 145(IMU)를 모르면 융합이 안 맞는다(7.6). 방향·중력 포함 여부·공분산 규약이 여기 있고, 이것을 어긴 드라이버가 실제로 존재한다(7.1.8). IMU를 다룬다면 확인이 필요하다.
견해: REP 117의 "범위 밖 표현"이 실무에서 자주 문제가 된다(7.5). 측정 실패를 0으로 채우는 드라이버와 무한대로 채우는 드라이버가 섞여 있어, 어느 규약인지 확인하지 않으면 장애물이 없는 곳에 있다고 판단할 수 있다.
A.3.3 패키지·빌드·배포
REP(확인 필요) | 주제 | 이 책의 장 |
|---|---|---|
| REP 127 / 140 / 149 | package.xml 형식 1·2·3 | 4.4 |
| REP 144 | ROS 패키지 명명 규칙 — 이 책은 규칙 자체를 다루지 않는다(원문 확인) | 4.4(패키지 이름의 쓰임) |
| REP 2000 | ROS 2 릴리스와 대상 플랫폼(Tier) | 0.3·15.2.2 |
| REP 2004 | 패키지 품질 수준 | 14.7.2 |
| REP 2001 | 패키지 변형(ros_core·ros_base·desktop·desktop_full이 각각 무엇을 포함하나) | 0.4.5·7.2.12(플러그인이 어느 변형에 딸리나) |
견해: REP 2000이 배포판 계획의 근거 문서다(0.3). 어느 배포판이 어느 OS·아키텍처를 어느 Tier로 지원하는지가 여기 정리되며, 이행 계획(15.1)을 세울 때 확인할 첫 문서다.
견해: REP 2004(품질 수준)는 의존성 평가의 출발점이다(14.7.2). 다만 자기 선언이며 외부 감사가 아니라는 점(14.7.3)을 함께 기억해야 한다.
A.3.4 ROS 2 아키텍처·인터페이스
REP(확인 필요) | 주제 | 이 책의 장 |
|---|---|---|
| REP 2007 | 타입 적응(type adaptation)(확인 필요: 번호) | 1.3.12 |
| REP 2011 | 타입 해시(RIHS)와 타입 서술 — rcl/type_hash.h가 "설계 근거는 REP-2011"이라 적고, GetTypeDescription.srv도 해시를 "REP-2011 RIHS hash string"이라 부른다(원문 확인. REP 본문은 미대조(확인 필요)) | 1.3.5·1.3.13 |
REP 2016(확인 필요: 번호) | 타입 서술 배포(~/get_type_description) — 0.3이 이 번호로 적었으나 원문을 대조하지 못했다 | 0.3.6·1.3.13 |
| 인터페이스 정의 관련 | IDL·메시지 표현 | 1.2·1.3 |
| 실행 모델 관련 | 실행기·콜백(확인 필요: 해당 REP 존재 여부) | 2.2~2.4 |
| 보안 관련 | SROS 2 설계(확인 필요) | 13.2 |
정직: ROS 2의 여러 설계 결정이 REP가 아니라 설계 문서·디스커션·구현으로 정해진 경우도 많다. "이 주제에 REP가 있을 것"이라고 가정하지 말고, 없으면 설계 문서와 소스를 보는 것(15.5.4)이 실용적이다.
견해: 타입 적응은 GPU·커스텀 표현을 다룰 때 유용한 개념이다(1.3.12). 메시지 타입과 내부 표현을 분리해 불필요한 변환을 줄이는 메커니즘이며, 대용량 데이터 파이프라인에서 검토할 가치가 있다. Jazzy에서
rclcpp::TypeAdapter가 동작하는 것은 실행 확인했다(1.3.12) — 다만 REP 번호 자체는 원문을 대조하지 못했다(확인 필요: 번호).
A.3.5 로봇 응용 규약
REP(확인 필요) | 주제 | 이 책의 장 |
|---|---|---|
| REP 107 | 진단 시스템 | 6.9 |
| REP 147 | 항공기 표준 인터페이스 | — (이 책의 범위 밖) |
| 매니퓰레이터·액션 관련 | 궤적·제어 인터페이스(확인 필요) | 6.5·9.2 |
| 내비게이션 관련 | 인터페이스 규약(확인 필요) | 8.1~8.8 |
견해: REP 107(진단)이 이 책이 반복적으로 권한
/diagnostics규약의 근거다(6.9). 메시지 구조·집계 방식·상태 값의 의미가 여기서 나오며, 규약을 따르면rqt_robot_monitor같은 기존 도구가 그대로 연동된다(11.5.2).
A.3.6 REP를 읽는 법
| 절 | 무엇이 있나 |
|---|---|
| 초록·동기 | 왜 필요했는가 |
| 명세 | 실제 규약 |
| 근거(rationale) | 왜 이렇게 정했는가 |
| 대안 | 기각된 선택지 |
| 참조 구현 | 코드 |
| 상태 | Draft·Active·Final·Deprecated 등(확인 필요) |
견해: "근거"와 "대안" 절이 가장 유익하다. 명세만 읽으면 규칙을 알지만, 근거를 읽으면 왜 그 규칙이 있는지를 알게 되어 경계 상황에서 판단할 수 있다. 7.1.6에서 "규약을 지키라"고 했을 때, 그 규약의 이유를 아는 것이 이 부분이다.
견해: 상태를 확인하라. Deprecated나 Superseded인 REP를 근거로 삼으면 낡은 규약을 따르게 된다. 번호가 낮은 REP일수록 상태 확인이 필요하다.
견해: 전부 읽을 필요는 없다. 이 책이 인용한 것들 중 REP 103·105·145·107 정도가 실무자가 직접 읽어 볼 만한 것이며, 나머지는 필요할 때 찾으면 된다.
A.3.7 규약 준수 점검
이 책의 여러 장이 REP 준수를 확인하라고 했다. 그 목록이다.
| 확인 | 대상 | 장 |
|---|---|---|
| 단위(m·rad·s) | 모든 메시지 | 7.1.6 |
| 축 방향(x 전방·z 상방) | 프레임 | 7.1.2 |
| 프레임 이름·계층 | tf 트리 | 5.1.7 |
| optical frame | 3D 센서 | 7.1.4 |
| IMU 방향·중력·공분산 | IMU | 7.1.5·7.6 |
| 범위 밖 값 표현 | 거리 센서 | 7.1.7 |
| 진단 메시지 구조 | /diagnostics | 6.9.3 |
| 패키지 명명·메타데이터 | package.xml | 4.4 |
# 실무 점검 (7.1.9)
ros2 interface show sensor_msgs/msg/Imu # 규약 주석 확인
ros2 topic echo /imu --once # 실제 값 확인
ros2 run tf2_tools view_frames # 프레임 이름·계층견해: "드라이버가 REP를 지키는지 확인"이 센서 통합의 첫 단계다(7.1.9). 어긴 드라이버가 실제로 있고, 그것을 모른 채 융합하면 결과가 조용히 틀린다. 초기에 30분 확인하는 것이 나중의 며칠을 아낀다.
A.3.8 REP가 없는 영역
모든 것이 REP로 정해져 있지는 않다.
| 영역 | 사실상의 규약 출처 |
|---|---|
| Nav2 인터페이스 | 프로젝트 문서·코드 |
| MoveIt 규약 | 프로젝트 문서 |
ros2_control 인터페이스 이름 | 프로젝트 문서(6.2.4) |
| 시뮬레이터 연동 | 각 프로젝트 |
| 다중 로봇 규약 | 관행·프로젝트별 |
견해: "관행"이 규약처럼 작동하는 영역이 많다.
/cmd_vel·/odom·/scan같은 토픽 이름은 REP가 아니라 관행이지만, 어기면 기존 도구·패키지와 연동되지 않는다. 관행을 따르는 것이 상호운용의 실질적 조건이다(1.1.4).
견해: 관행을 어길 이유가 있다면 문서화하라(14.1.5). "우리는
/cmd_vel대신 다른 이름을 쓴다"는 결정 자체는 가능하지만, 왜 그런지 적혀 있지 않으면 나중에 온 사람이 실수로 되돌리거나 혼란을 겪는다.
A.3.9 이 책과 REP의 관계
이 책은 REP를 대체하지 않는다.
| 이 책이 하는 것 | REP가 하는 것 |
|---|---|
| 규약을 왜 지켜야 하는지 설명 | 규약을 정의 |
| 어겼을 때의 증상 제시 | 정확한 명세 |
| 실무 확인 방법 | 근거·대안 기록 |
| 장 간 연결 | 단일 주제 심층 |
견해: 규약이 애매하거나 이 책과 다르게 보이면 REP 원문이 우선이다. 이 책은 이해를 돕기 위해 요약·의역했으므로, 정확성이 필요한 순간에는 원문을 확인해야 한다. 목차 3에서 밝힌 정직성 원칙이 여기서도 적용된다.