이름을 나누는 것과 실제 공간을 나누는 것은 다르다
두 로봇을 각각 /r1, /r2라는 namespace에서 실행하면 상대 이름의 scan, cmd_vel 등을 /r1/scan과 /r2/scan처럼 구별할 수 있다. namespace는 ROS 그래프의 이름을 묶는 방법이다. 메시지 내부의 frame_id나 물체 ID, 두 로봇의 실제 위치까지 자동으로 바꾸는 기능은 아니다. 절대 이름을 사용한 토픽·Action과 공유한 관리 서비스도 의도한 대상으로 연결되는지 확인한다.
그림 M18.05-1. 각 칸은 서로 다른 역할/근거다. 나란히 비교할 항목이며 위아래가 시간 순서를 뜻하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
Jazzy 다중 로봇 launch 예제는 로봇별 namespace와 초기 pose·설정을 연결한다. 예제가 있다는 사실은 서로 다른 로봇의 현재 지도·TF·관측과 통행 계획이 자동으로 조정됐다는 뜻이 아니다. 어느 네트워크·토픽·버퍼를 공유하는지, 어떤 노드가 어느 로봇의 명령을 받는지부터 표로 적는다.
같은 토픽 이름을 서로 다른 ROS domain이나 격리된 시스템에서 사용하는 설계도 가능하다. 반대로 한 domain에서 namespace로 구분해도 모든 메시지를 중앙 관측자가 받도록 연결할 수 있다. 명령 권한과 자료 접근, 로봇 식별을 독립적으로 정하고 이름이 다르니 물리 충돌이 없다는 결론을 내리지 않는다.
TF 토픽 이름과 frame 문자열을 따로 관리한다
공통 TF 버스와 버퍼를 사용하는 예에서 /r1/scan과 /r2/scan의 header.frame_id가 둘 다 laser이고, 두 RSP가 모두 base_link→laser를 발행한다고 하자. 토픽은 나뉘었지만 같은 TF 이름을 서로 다른 로봇의 배치로 덮어쓸 수 있다. 센서 자료를 로봇에 붙일 때 어느 laser인지 구별할 근거가 부족하다. 토픽 namespace만 수정해서는 해결되지 않는다.
이 공유 설계의 한 방법은 r1/odom, r1/base_link, r1/laser와 r2의 대응 이름처럼 고유 frame ID를 사용하는 것이다. RSP Jazzy README의 frame_prefix는 RSP가 발행하는 TF frame에 접두사를 붙인다. 다른 driver의 header.frame_id와 odometry·위치 추정기의 frame 설정까지 모두 자동 변경하는 것은 아니다. 그 생산자들도 같은 계약으로 맞춰야 한다.
RSP는 URDF 링크와 joint_states를 이용해 로봇 내부 링크 관계를 발행한다. odom→base_link는 odometry 생산자, map→odom은 전역 위치 추정기 등의 책임이다. 같은 변환을 두 노드가 서로 다른 값으로 발행하거나 한 자식 frame에 두 부모를 붙이지 않는다. 자료 생산자·부모·자식·시각·로봇 ID를 대조한다.
다른 방법은 로봇별 TF 토픽과 버퍼를 격리해 로컬에서는 odom/base_link 같은 이름을 유지하는 것이다. 이 경우에도 외부에서 결과를 합칠 때 frame 식별자와 공통 좌표 변환을 명시해야 한다. REP105의 다중 로봇 예는 서로 다른 지도를 공통 기준에 연결하고 외부 전달에서 식별을 분명히 하는 관계를 설명한다. 모든 설계에 하나의 접두사 정책을 강요하는 것이 아니라 공유 경계에서의 모호성을 제거하는 것이 핵심이다.
같은 이름의 지도도 원점과 축이 같지는 않다
로봇마다 독립적으로 만든 지도는 원점과 방향이 다를 수 있다. 지도 해상도·버전·층과 현재 정합, 단위와 시각의 관계를 합의해야 서로의 위치를 비교할 수 있다. 두 frame을 단순히 map으로 이름 변경하는 것은 좌표 정합이 아니다. 공통 지도 하나를 사용해도 각 로봇의 현재 pose 추정과 odom 보정은 별도다.
합성 예에서 R1은 지도 A에서 p_A=(1,0) m에 있다. A의 좌표를 공통 지도 M으로 옮기는 변환은 반시계 90° 회전 뒤 (2,0) m를 더한다. 90° 회전은 (x,y)를 (−y,x)로 보내므로 (1,0)→(0,1), 이후 p_M1=(2,1) m다. R2는 지도 B에서 p_B=(0.5,1) m이고, B→M은 회전 없이 (1,0) m를 더하므로 p_M2=(1.5,1) m다. 변환은 모두 로컬 지도에서 공통 지도로 보내는 방향이다.
두 위치는 같은 시각의 정확한 합성 입력이다. 공통 지도에서 중심 거리는 0.5 m다. 반지름이 각각 0.2 m인 원판 모델이면 반지름 합은 0.4 m이고 정적 기하 여유는 0.1 m다. 로컬 좌표를 직접 빼면 이런 비교를 잘못할 수 있다. 실제에는 지도 정합·위치 추정과 clock 오차, 몸체·적재물 및 경로 중간을 추가 확인해야 하므로 0.1 m를 실제 운용 안전 보장으로 쓰지 않는다.
지금의 분리 거리와 미래 경로 충돌을 구분한다
위 공통 지도에서 R1의 속도를 (−0.2,0), R2의 속도를 (+0.2,0) m/s로 주고 일정하다고 가정하자. 둘은 서로 가까워진다. 같은 시각 기준에서 t초 뒤 x좌표는 2−0.2t와 1.5+0.2t이므로 접촉 전 중심 거리는 0.5−0.4t m다. t=0.25 s에서 거리가 0.4 m로 접촉하고, t=0.5 s에서는 0.3 m로 겹친다. 지금 여유가 양수라고 미래 경로도 유효한 것은 아니다.
이 계산은 일정 속도·같은 축·정확 시각의 두 원판이라는 모형이다. 오래된 위치와 다른 clock의 속도를 조합해 그대로 예측하면 틀릴 수 있다. 위치·속도·계획의 취득·유효 시각과 불확실성, 지도·과업 버전을 함께 보낸다. 다른 로봇을 센서로 본다는 사실과 그 로봇의 예정 경로·중단 상태를 조정하는 일도 다른 근거다.
좁은 공동 구역은 시간과 실제 점유를 조정한다
복도 Z는 동시에 한 로봇만 사용할 수 있다고 정하자. 같은 clock의 예약은 R1이 [2,4) s, R2가 [3.5,5) s다. 대괄호는 시작 포함, 끝 제외라는 뜻이며 두 요청의 겹침은 [3.5,4)로 0.5 s다. namespace와 지도 정합이 모두 맞아도 이 자원 충돌은 남는다.
교육용 정책은 R1이 예정대로 끝났다는 조건에서 구역 사이 0.2 s 여유를 두도록 한다. R2의 구간을 [4.2,5.7) s로 제안하면 1.5 s의 사용 기간을 유지하며 처음보다 0.7 s 늦춘 것이다. 이 예약은 충돌 없는 실제 통행을 이미 관측한 결과가 아니다. 들어가기 전 현 점유와 최신 상태, 허용된 경로·대기 장소를 확인해야 한다.
변형에서 R2는 아직 구역 밖에 대기 중이고 R1의 실제 퇴장이 4.3 s에 확인됐다고 하자. 같은 0.2 s 정책이면 R2의 새 시작은 적어도 4.5 s여야 하며 같은 기간이면 끝은 6.0 s다. 과거 제안 4.2를 그대로 실행하는 것이 아니라 확인한 상태로 다시 조정한다. 예약 시각 만료나 통신 단절은 실제 퇴장의 관측이 아니다. 점유가 미상이면 '시간이 지났으니 비었다'고 채우지 않는다.
조정 계층과 개별 제어의 책임을 연결한다
Open-RMF 공식 소개는 여러 fleet과 문·엘리베이터 같은 시설 사이의 상호운용을 다루는 시스템을 설명한다. 본문의 단순 시간표는 그런 조정 필요성을 이해하는 개념 예이지 Open-RMF 예약 알고리즘이나 실제 fleet 실행을 구현한 것이 아니다. 예약·우선순위와 개별 로봇의 센서·충돌 검사·제어·정지 관측은 함께 필요하다.
두 로봇이 서로의 구역을 쥔 채 다음 구역을 기다리면 교착이 생길 수 있다. 모두에게 동시에 양보만 요구하면 계속 움직이지 못하거나 반복 재시도할 수 있다. 자원 획득 순서와 우선순위, 유효한 대기 위치와 해제 조건, 오래 기다린 요청의 처리 정책을 정하고 지연·단절·복구에서 검증한다. 임의 우선순위 하나가 모든 경우의 공정성이나 교착 해소를 보장한다고 주장하지 않는다.
기존 3.1 SO-101 기구학 모델의 frame 계약과 4.3 TF2 트리 설계의 좌표 연결을 보충으로 읽자. 아래 활동은 이름·기하·예약의 서로 다른 오류를 찾는 연습이며 실제 다중 로봇 충돌 회피 성과가 아니다.