# ROS2의 아키텍처 개요

#### DDS 기반 구조

ROS2는 기존의 ROS1과 달리 **DDS(Data Distribution Service)** 표준을 기반으로 통신을 수행한다. DDS는 분산 환경에서의 실시간 통신을 지원하기 위한 미들웨어 표준으로, 퍼블리셔-서브스크라이버(이하 pub-sub) 모델을 구현한다. 이러한 표준 기반의 구조를 통해 ROS2는 다음과 같은 특징을 갖는다.

* 플랫폼 독립성
* 상호 운용성
* 다양한 트랜SPORT 계층 지원

DDS의 네트워크 트랜SPORT 계층은 로컬 네트워크나 WAN에서 멀티캐스트 기반 브로드캐스팅, TCP, UDP 등을 활용해 노드 간의 효율적인 데이터 교환을 가능케 한다. 따라서 실시간성이 중요한 로봇 애플리케이션에서 다양한 시스템 요구사항(QoS, 확장성, 안정성 등)을 충족할 수 있다.

#### ROS Middleware(RMW) 계층

ROS2의 구조는 DDS를 바로 사용하는 대신, **RMW(ROS Middleware)** 라는 추상화 계층을 제공한다. RMW 계층은 하위 DDS 벤더 구현체를 감싸서, ROS2 상부 레이어(예: rclcpp, rclpy 등)에서 DDS 세부 사항을 모르더라도 쉽게 사용할 수 있도록 설계된다. 덕분에 사용자는 DDS의 세부 구현 방식을 신경 쓸 필요가 없고, 필요에 따라 다양한 DDS 벤더를 선택해 사용할 수 있다.

* 주요 역할
  * DDS 벤더별 인터페이스 추상화
  * 로우 레벨 DDS 통신 설정 및 초기화
  * 토픽, 서비스, 액션, 파라미터 등의 RCL(ROS Client Library) 요청을 DDS 프레임워크로 전달

#### 퍼블리셔-서브스크라이버(pub-sub) 모델

ROS2의 가장 핵심적인 통신 방식은 pub-sub 모델이다. pub-sub 모델에서 노드는 퍼블리셔(메시지를 발행)와 서브스크라이버(메시지를 구독)로 구성되며, 다음과 같은 일반적인 데이터 흐름을 갖는다.

1. 퍼블리셔 노드가 특정 토픽에 대한 메시지를 발행한다.
2. 서브스크라이버 노드는 같은 토픽을 구독하고 있다면 메시지를 수신한다.

DDS를 통해 노드 간 메시지 교환이 자동으로 이루어지며, 내부적으로는 메시지 유형(인터페이스 정의)과 토픽 이름을 기준으로 구독 가능 여부가 판별된다.

#### QoS 설정

ROS2에서는 다양한 **QoS(Quality of Service)** 설정을 지원한다. 예를 들어 아래와 같은 여러 QoS 파라미터를 제공한다.

* 신뢰성(Reliability)
* 내구성(Durability)
* 히스토리(History)
* 우선순위(Deadline)

QoS는 퍼블리셔와 서브스크라이버 쌍이 서로 호환될 때만 정상 동작한다. DDS의 QoS 설정은 다음과 같은 벡터 $\mathbf{q}$로 표현할 수 있다.

$$
\mathbf{q} = (q\_\mathrm{reliability},, q\_\mathrm{durability},, q\_\mathrm{history},, \dots )
$$

각 요소 $q\_i$는 DDS 벤더별로 다양한 설정 값을 가진다. 설정 조합에 따라 메시지 지연, 안정성, 메시지 손실 허용 범위 등을 세밀하게 조절할 수 있다.

#### Discovery 매커니즘

ROS2의 Discovery(노드 검색) 과정은 DDS의 Participant Discovery를 따른다. 모든 노드는 네트워크 상에서 자동으로 상대 노드를 검색하여 통신 가능성을 파악한다. 이 과정은 다음과 같은 단계를 거친다.

1. DDS 파티시펀트가 네트워크 상에 자신을 브로드캐스팅한다.
2. 이미 존재하는 파티시펀트들은 새로운 파티시펀트를 인지하고, Pub/Sub 정보를 교환한다.
3. 상호 pub-sub 설정이 맞는다면 자동으로 연결(매치)되어 메시지 교환이 시작된다.

이러한 Discovery 매커니즘은 노드가 추가되거나 제거될 때 자동으로 변화를 감지할 수 있다.

#### 전체 계층 구조 예시 (mermaid)

아래는 ROS2 계층 구조를 간략히 표현한 예시다:

{% @mermaid/diagram content="graph LR
A\["응용 계층 (예: 노드)"] --> B\["ROS Client Library (rclcpp 등)"]
B --> C\["RMW 계층"]
C --> D\["DDS 벤더 구현체"]
D --> E\["네트워크 계층"]" %}

DDS 위에 RMW가 위치하고, 그 위에 ROS Client Library가 있으며, 최상단에는 응용 프로그램으로서 노드가 위치하는 전형적인 구조를 보여준다.

#### 노드 생명주기(Lifecycle)

ROS2에서 노드(Node)는 상태(State)라는 개념을 통해 동작 단계를 관리할 수 있다. 전통적인 ROS1에서는 노드가 시작되면 단순히 초기화되고 종료될 때까지 계속 달리는 구조였으나, ROS2는 노드가 서로 다른 상태를 가질 수 있도록 **노드 생명주기(Lifecycle)** 인터페이스를 제공한다.

* **Unconfigured**: 노드가 생성된 직후 상태로 아직 활성화되지 않은 단계
* **Inactive**: 노드가 필요한 자원은 할당했지만, 실제 pub-sub 연결이나 콜백 실행이 비활성화된 단계
* **Active**: pub-sub를 통한 메시지 처리, 콜백 실행 등이 활성화된 정상 동작 상태
* **Finalized**: 노드가 종료된 상태

이 상태 전이(State transition)는 다음과 같은 집합 $\mathbf{S}$과 전이 함수 $\delta$로 정의할 수 있다.

$$
\mathbf{S} = {\text{Unconfigured},, \text{Inactive},, \text{Active},, \text{Finalized}}δ:S×Event→S\delta : \mathbf{S} \times \mathbf{Event} \rightarrow \mathbf{S}
$$

여기서 $\mathbf{Event}$는 노드 내부 혹은 외부에서 발생하는 이벤트(예: `on_configure`, `on_activate`, `on_deactivate`, `on_cleanup` 등)이다.

#### 노드 컴포지션(Composition)

ROS2는 여러 노드를 하나의 프로세스 안에서 실행하여 시스템 리소스를 효율적으로 사용하는 **컴포지션(Composition)** 기능을 제공한다. 이 방식은 다음과 같은 장점을 갖는다.

* 메모리 및 CPU 사용량 감소
* 프로세스 간 통신이 아닌 프로세스 내부 통신(인프로세스)으로 지연(latency) 감소
* 런타임 시 노드 동적 로딩 가능

컴포지션이 동작할 때, 각 노드는 별도의 실행 컨텍스트(Context)를 갖거나 공유할 수 있으며, 이를 통해 pub-sub, 서비스, 액션 등의 리소스 충돌을 방지한다.

#### Executors와 콜백 그룹(Callback Group)

ROS2는 콜백 처리를 담당하는 실행 스케줄러로 **Executor** 개념을 도입했다. Executor는 노드에서 발생하는 여러 콜백(예: 메시지 수신, 타이머, 서비스 요청 등)을 어떤 스레드에서, 어떤 순서로 처리할지 관리한다. Executor는 크게 다음과 같은 목표를 가진다.

1. 스레드 풀(Thread pool) 혹은 싱글 스레드 등 다양한 스케줄링 정책 지원
2. 콜백 간 충돌 방지 및 우선순위 관리
3. 실시간 환경에서의 예측 가능한 스케줄링

또한 ROS2는 콜백을 묶어서 처리할 수 있는 **콜백 그룹(Callback Group)** 개념을 제공한다. 특정 콜백 그룹에 속한 콜백은 동시 실행 여부를 설정할 수 있어, 자원 충돌(Critical section)이나 데이터 무결성(Integrity) 문제를 예방할 수 있다.

* **Mutually Exclusive Group**: 그룹 내 콜백은 동시 실행 불가능
* **Reentrant Group**: 그룹 내 콜백은 동시에 실행 가능

#### Domain과 Participant

ROS2에서 DDS를 통해 노드들이 서로 통신할 때, 물리적 혹은 논리적 네트워크를 구분하기 위해 **Domain** 개념을 사용한다. 하나의 Domain은 특정 Domain ID를 갖는다. 동일한 Domain ID를 가진 노드들끼리만 서로 Discover(탐색)되어 pub-sub가 연결된다.

* **Participant**: DDS에서 노드는 직접 DDS 엔티티로서 존재하지 않고, Participant라는 개념을 통해 DDS 네트워크에 등록된다.
* **Publisher / Subscriber**: Participant 내부에서 실제 메시지 송수신을 담당하는 DDS 엔티티.
* **Topic**: DDS에서의 메시지 채널명. ROS2 노드가 사용하는 토픽 명과 DDS Topic 명을 매핑하여 사용한다.

이러한 구조 덕분에 서로 다른 로봇 시스템(예: Domain ID가 10인 네트워크와 20인 네트워크)을 네트워크 상에서 물리적으로 분리하지 않고도 충돌 없이 운영할 수 있다.

#### 보안(Security) 구조

ROS2는 DDS의 **DDS-Security** 표준을 통해 보안 기능을 지원한다. 인증(Authentication), 암호화(Encryption), 접근 제어(Access Control) 등의 기능을 제공하여, 네트워크 상에서 민감한 데이터를 다룰 때 안전하게 통신할 수 있다.

* **Authentication**: 인증서(Certificate) 기반으로 DDS Participant를 인증
* **Access Control**: 설정 파일(Policy 파일) 기반으로 주어진 토픽에 대한 읽기/쓰기를 허용하거나 거부
* **Encryption**: 메시지 자체에 대한 암호화를 수행

#### 실시간(Real-time) 지원

ROS2는 다양한 임베디드 시스템 및 산업용 로봇 시스템에서 요구하는 **실시간성**을 고려하여 설계되었다. DDS 자체가 실시간 통신을 목적으로 하는 표준이며, 추가적으로 ROS2는 다음과 같은 기법을 통해 실시간 처리를 지원한다.

* **프로세스 우선순위 및 스레드 고정**: RT(Real-Time) 운영체제 또는 POSIX RT 확장 기능을 활용해 프로세스와 스레드에 우선순위를 부여하고 CPU 코어를 고정(Pinning)함으로써, 예측 가능한 응답 시간을 확보할 수 있다.
* **동적 메모리 할당 최소화**: 실시간 시스템에서는 런타임 시 동적 메모리 할당으로 인한 예측 불가능한 지연을 피해야 한다. ROS2는 콜백 처리 시 동적 할당 최소화, 사전 할당(Pre-allocation) 기법 등을 권장한다.
* **제로 카피(Zero-copy) 통신**: DDS의 일부 구현체에서 제공하는 Zero-copy 통신 방식을 사용하면, 메시지를 복사하지 않고 송수신 버퍼를 공유할 수 있다. 이렇게 하면 메모리 사용량 및 복사 시간을 줄여 지연을 단축한다.

이를 수학적으로 살펴보면, 시스템 응답 시간을 $\mathrm{resp}$라 할 때, 메모리 복사, 스케줄링 지연, 네트워크 지연 등을 각각 $\Delta t\_\mathrm{mem}$, $\Delta t\_\mathrm{sched}$, $\Delta t\_\mathrm{net}$라 하면,

$$
T\_\mathrm{resp} \approx \Delta t\_\mathrm{mem} + \Delta t\_\mathrm{sched} + \Delta t\_\mathrm{net}
$$

이며, ROS2는 $\Delta t\_\mathrm{mem}$와 $\Delta t\_\mathrm{sched}$를 가능한 한 최소화하도록 설계된다.

#### 서비스(Service) 통신

ROS2는 요청-응답(Request-Response) 형태의 **서비스 통신** 방식을 제공한다. pub-sub 모델만으로는 구현하기 어려운 직접적인 RPC(Remote Procedure Call) 패턴을 지원하기 위해 사용된다.

* **서비스 서버**: 특정 서비스를 제공하는 노드. 요청을 받아서 결과를 반환한다.
* **서비스 클라이언트**: 서비스를 호출하는 노드. 응답을 기다리는 형태로 동작한다.

내부적으로는 DDS의 Requester/Responder 모델을 사용하며, 서비스 메시지 형식은 다음처럼 요청(Request)과 응답(Response)으로 구분되어 있다:

$$
\text{ServiceMessage} = {\mathbf{Request},, \mathbf{Response}}
$$

각각 $\mathbf{Request}$와 $\mathbf{Response}$는 별도의 필드(데이터 구조)를 갖는다.

#### 액션(Action) 통신

액션(Action)은 목표 지점 설정, 장시간에 걸친 작업, 중간 피드백 등의 기능을 필요로 하는 경우 사용된다. 예를 들어, 로봇이 특정 경로를 따라 이동하는 동작을 수행할 때 중간 위치 정보를 끊임없이 피드백 받아야 할 수 있다.

* **Goal**: 액션 서버에게 특정 명령(목표)을 전달할 때 사용
* **Feedback**: 액션 서버에서 중간 진행 상태를 액션 클라이언트에게 전달
* **Result**: 최종 완료 또는 실패 상태를 결과 형태로 전달

액션은 내부적으로 다음과 같은 메시지 구조를 갖는다:

$$
\mathbf{Action} = {\mathbf{Goal},, \mathbf{Feedback},, \mathbf{Result}}
$$

ROS2에서 액션은 pub-sub, 서비스, 그리고 피드백 스트림을 종합적으로 활용하여 구현된다.

#### 파라미터(Parameter) 서버

ROS1에서 **파라미터 서버**는 마스터(ROS Master)에 의해 제공되었지만, ROS2에서는 중앙 집중식 파라미터 서버가 없어졌다. 대신 각 노드가 자체적으로 파라미터를 관리하고, 필요하면 다른 노드의 파라미터를 동적으로 조회하거나 수정할 수 있다.

* **로컬 파라미터**: 노드 내부에서 유지되는 파라미터
* **파라미터 이벤트**: 노드 간 파라미터 변경 사실을 알리기 위한 pub-sub 토픽
* **파라미터 서비스**: 특정 노드의 파라미터를 읽고 쓸 수 있도록 하는 서비스

이를 통해 로컬 상태 기반 파라미터 관리가 가능해지며, 분산 시스템에서 각 노드는 필요에 따라 파라미터를 조정할 수 있다.

#### ROS 그래프(ROS Graph)

ROS2에서 **ROS 그래프**란, 현재 실행 중인 노드, 토픽, 서비스, 액션 등이 어떤 방식으로 연결되어 있는지를 나타내는 추상화된 개념이다. 내부적으로 DDS Discovery가 이를 구성하며, 사용자는 CLI(명령줄 인터페이스) 도구(예: `ros2 node list`, `ros2 topic list`, `ros2 service list`, `ros2 action list` 등)를 사용해 전체 그래프를 조회할 수 있다.

아래 다이어그램은 예시 그래프를 단순화한 형태이다:

{% @mermaid/diagram content="graph LR
N1\["Node A"] -- Topic1 --> N2\["Node B"]
N2 -- Topic2 --> N3\["Node C"]
N3 -- Service --> N1
N2 -- Action --> N1    " %}

* **Node A**: 토픽1의 퍼블리셔, Service Server, Action Server
* **Node B**: 토픽1의 서브스크라이버, 토픽2의 퍼블리셔
* **Node C**: 토픽2의 서브스크라이버, Service Client

이처럼 여러 노드가 연결되어 각종 ROS 인터페이스를 통해 협력 동작한다.

#### 시뮬레이션 시간과 클록(Clock)

ROS2는 물리 세계의 시간뿐 아니라 시뮬레이션, 재현(Replay) 등의 다양한 시간 소스를 지원하기 위해 **클록(Clock)** 추상화를 도입했다. 이는 다음과 같은 시간 유형을 제공한다.

* **ROS 시간**: 시뮬레이션이나 로그 재생(Replay) 시, 실제 시간과 별개로 흘러가는 시간
* **시스템 시간**: 운영체제(OS)의 실제 시스템 시간
* **스테디(steady) 시간**: OS 의존성을 최소화한 일관된 시간 흐름 (예: 고정 주기 타이머 기반)

이러한 시간 소스를 $\mathbf{t}$라고 정의하면, 예를 들어 ROS 시간이 실제 시간과 다른 배율(scale factor) $\alpha$로 흐른다고 할 때,

$$
\mathbf{t}*\mathrm{ROS}(t) = \alpha \cdot \mathbf{t}*\mathrm{real}(t) + \beta
$$

처럼 관계를 표현할 수 있다. 여기서 $\beta$는 시작 시간 오프셋이다. 따라서 시뮬레이션 환경에서 고속으로 시간 흐름을 재생하거나, 특정 시점으로 되돌리는 기능 구현이 가능하다.

#### 이름 공간(Namespaces)

ROS2에서는 노드나 토픽, 서비스, 액션 등의 리소스를 계층적으로 관리하기 위해 **이름 공간(Namespaces)** 개념을 지원한다. 이름 공간을 적절히 활용하면 여러 노드가 같은 이름의 토픽을 사용하더라도 충돌 없이 운영할 수 있다.

* **global namespace**: 루트(‘/’) 기준 경로
* **relative namespace**: 현재 노드 혹은 부모 이름 공간을 기준으로 하는 상대 경로
* **private namespace**: 노드 자체의 고유 이름 공간

예를 들어, 노드 A가 `/robot1/odom`이라는 토픽을 퍼블리시하고, 노드 B가 `/robot2/odom`이라는 토픽을 퍼블리시하면, 두 토픽은 서로 다른 데이터 스트림으로 취급되어 충돌하지 않는다.

#### Launch 아키텍처

ROS2는 여러 노드를 손쉽게 실행, 종료, 파라미터 설정 등을 통합 관리하기 위해 **launch 시스템**을 제공한다. 이는 Python 스크립트를 기반으로 하며, YAML 등을 사용해 파라미터를 정의할 수 있다. 아키텍처적으로 launch는 다음 기능을 수행한다.

1. 노드 프로세스 생성 및 모니터링
2. 파라미터 전달
3. 환경 변수, 이름 공간, remapping 등 설정
4. 실행 순서 제어(노드 간 의존 관계를 고려한 시퀀스)

복잡한 로보틱스 애플리케이션에서 다양한 노드(예: 센서 노드, 제어 노드, SLAM 노드, UI 노드 등)를 한꺼번에 띄울 때 유용하다.

#### 로깅(Logging) 아키텍처

ROS2의 로깅은 **rcl\_logging** 패키지를 통해 추상화되어 있다. 사용자는 `rclcpp::Logger` 또는 `rclpy` 모듈의 로그 함수를 호출하며, 내부적으로는 다음 단계로 처리된다.

* **로거(Logger)**: 로그를 기록하는 사용자 인터페이스
* **로깅 백엔드**: 실제 로그 메시지를 파일, 콘솔, 네트워크 스트림 등 다양한 방식으로 출력
* **로그 수준(Severity level)**: DEBUG, INFO, WARN, ERROR, FATAL 등

로그 메시지의 형식, 출력 위치, 파일 로테이션, 시간 스탬프 포함 여부 등을 설정 파일(예: YAML)로 정의할 수 있다.

#### 테스트(Testing) 아키텍처

ROS2는 시스템의 신뢰성을 확보하기 위해 단위 테스트(Unit test), 통합 테스트(Integration test), 시스템 테스트(System test) 등을 지원하는 다양한 테스트 인프라를 제공한다. 주요 구성 요소는 다음과 같다.

* **ament\_cmake**: 빌드 시스템으로, 테스트 스크립트를 통합 관리
* **rclcpp/rclpy 테스트**: gtest, pytest 등의 표준 테스트 프레임워크와 연동
* **launch\_testing**: 노드 실행을 포함한 통합 테스트 지원

테스트 환경에서 노드를 실행하고, 메시지를 주고받고, 결과를 검증할 수 있으며, 이를 통해 ROS2 애플리케이션의 기능 및 성능을 자동화된 방식으로 점검 가능하다.

#### 인터페이스 정의(ROS Interfaces)와 IDL

ROS2는 메시지, 서비스, 액션에 대한 인터페이스를 정의하기 위해 **.msg**, **.srv**, **.action** 파일 형식을 사용한다. 이 파일들을 기반으로 DDS에서 표준으로 사용하는 **IDL(Interface Definition Language)** 코드를 자동 생성한다. 이를 통해 C++, Python 등 다양한 언어에서 동일한 인터페이스를 사용하는 것이 가능하다.

* **메시지(.msg)**: 퍼블리셔-서브스크라이버 통신에 사용되는 데이터 구조
* **서비스(.srv)**: 요청-응답 형식의 데이터를 정의하는 구조(요청/응답 두 영역)
* **액션(.action)**: 목표(Goal), 중간 피드백(Feedback), 최종 결과(Result)를 정의하는 구조

ROS2 빌드 시스템(예: ament\_cmake, ament\_python)은 인터페이스 정의 파일을 자동으로 스캔하여, 아래와 같은 과정을 통해 코드를 생성한다.

1. **IDL 생성**: .msg, .srv, .action 파일을 DDS IDL 파일로 변환
2. **타입 서포트 코드 생성**: DDS IDL을 각 언어별 타입 서포트(C/C++, Python 등)로 생성
3. **사용자 API 생성**: 사용자가 메시지, 서비스, 액션을 쉽게 선언하고 사용할 수 있는 헬퍼 함수 및 클래스를 생성

이를 통해 ROS2는 DDS와 언어 간 격차를 추상화하고, 사용자는 인터페이스 정의만으로 여러 언어에서 동일한 구조를 공유하며 통신할 수 있다.

#### ament와 colcon 빌드 시스템

ROS2는 기본적으로 **ament**라는 빌드 도구와, 패키지 관리를 위한 **colcon**을 사용한다. 이러한 빌드 시스템은 ROS1의 `catkin` 빌드 시스템을 발전시킨 형태로, 다음과 같은 특징을 갖는다.

* **단일 워크스페이스 내 다중 패키지 빌드**: colcon을 통해 워크스페이스 내 여러 패키지를 순차 혹은 병렬로 빌드
* **test, install, package 명령 지원**: `colcon test`, `colcon install`, `colcon package` 등 다양한 명령을 통해 테스트 실행, 설치, 배포를 자동화
* **확장성**: 플러그인 형태로 빌드 과정을 확장 가능(예: ament\_python, ament\_cmake, ament\_lint 등)

실행 순서나 빌드 의존성은 `package.xml`과 `CMakeLists.txt`(또는 `setup.py`)에 지정되며, colcon은 이를 분석해 올바른 순서로 각 패키지를 빌드한다.

#### Intra-process 통신과 Shared Memory

ROS2는 **Intra-process 통신**(같은 프로세스 내부에서 노드 간 통신)과 **Shared Memory** 최적화 방안을 제공한다. 이를 통해 데이터 복사를 줄이고, 지연(latency)을 단축할 수 있다.

* **Intra-process**: 퍼블리셔와 서브스크라이버가 동일한 프로세스 안에서 실행될 경우, DDS를 거치지 않고도 포인터 또는 참조를 통해 직접 메시지를 전달할 수 있다.
* **Shared Memory**: Zero-copy 방식으로 물리 메모리를 공유하는 DDS 벤더나 RMW 구현체가 제공되면, 프로세스 간 송수신 시에도 메시지 복사 횟수를 최소화할 수 있다.

이를 수학적으로 표현하면, 만약 메시지 크기가 $\mathbf{m}$이라고 할 때, 일반적인 네트워크(pub-sub) 전송 시 복사 비용 $C\_\mathrm{copy}$가 $\alpha \cdot |\mathbf{m}|$라면, Intra-process나 Shared Memory를 사용하면

$$
C\_\mathrm{copy}' \approx \beta \cdot |\mathbf{m}|
$$

으로, $\beta < \alpha$를 기대할 수 있어, 전송 지연을 줄이는 데에 효과적이다.

#### 언어 지원과 Client Library

ROS2는 대표적으로 C++(rclcpp), Python(rclpy) 클라이언트 라이브러리를 공식 지원한다. 이외에도 Java, C, Rust 등 다양한 언어 지원이 커뮤니티를 통해 지속적으로 확장되고 있다.

* **rcl**: ROS2의 가장 얇은 클라이언트 계층(순수 C API). rclcpp, rclpy 등 상위 라이브러리가 이를 기반으로 구성
* **rclcpp**: C++11 이상 표준 기반으로 작성된 API. OOP(객체 지향) 스타일로 노드, 퍼블리셔, 서브스크라이버 등을 정의
* **rclpy**: Python API. 파이썬 스크립트를 통해 노드 실행, 메시지 송수신, 서비스 호출 등을 손쉽게 구현

각 언어 클라이언트는 RMW 계층을 통해 DDS 구현체와 연결되며, 동일한 ROS2 그래프 내에서 상호 교환 가능하다.

#### ROS2 CLI 구조

ROS2에서는 명령줄 인터페이스(CLI) 도구를 제공한다. `ros2`라는 기본 명령어를 통해 다양한 하위 명령을 실행할 수 있다.

* **ros2 node list**, **ros2 node info**: 현재 실행 중인 노드 확인, 상세 정보 조회
* **ros2 topic list**, **ros2 topic echo**, **ros2 topic pub**: 토픽 목록, 메시지 구독, 메시지 발행
* **ros2 service list**, **ros2 service call**: 서비스 목록, 서비스 호출
* **ros2 action list**, **ros2 action send\_goal**: 액션 목록, 액션 서버에 목표 전송
* **ros2 launch**: launch 파일 실행

CLI는 ROS2의 그래프 상태를 관찰, 디버깅, 테스트하기 위한 강력한 도구이며, 이를 통해 실시간으로 노드나 통신 상태를 확인할 수 있다.

#### 크로스 컴파일(Cross-compilation)

ROS2는 임베디드 보드나 특정 하드웨어 아키텍처(ARM, RISC-V 등)에 배포하기 위해 **크로스 컴파일**을 지원한다. 이는 다음과 같은 과정을 따른다.

1. 크로스 컴파일러 툴체인 설정(예: aarch64 용 툴체인)
2. colcon 빌드 시 툴체인 파일(toolchain file) 지정
3. 필요한 ROS2 패키지를 대상으로 의존성 관리 후 빌드 수행
4. 타깃 보드로 빌드 결과물(실행 파일, 라이브러리) 배포

크로스 컴파일 과정에서 소스 레벨의 변경 없이도 ROS2 애플리케이션을 다양한 임베디드 플랫폼에서 구동 가능하게 한다.