# ROS2 Humble의 주요 개선 사항

#### DDS RMW 계층 구조의 성능 및 안정성 개선

ROS2 Humble에서는 DDS 기반의 RMW(Robot Middleware) 구현이 보다 안정적으로 동작하도록 내부 구조를 재정비하였다. 특히 기존 버전에서 발생하던 메시지 지연과 분산 네트워크에서의 오류를 낮추기 위해 다양한 최적화 기법을 적용하였다. 이를 통해 멀티 호스트 환경, 예를 들어 동일 네트워크 내 여러 기기에서 ROS2 노드들이 동시에 동작할 때 발생하는 트래픽 폭증을 효율적으로 제어한다.

DDS RMW 계층에서의 성능 개선은 다음과 같은 세부 요인에 의해 크게 좌우된다.

1. **메시지 직렬화/역직렬화 최적화** DDS 전송 시 필요한 직렬화 과정을 최소화하거나 보다 효율적인 포맷으로 변환하여 오버헤드를 줄인다.
2. **QoS 설정 자동화 및 확장** QoS(서비스 품질) 프로필의 파라미터를 시스템 환경에 따라 자동으로 조정하여 부하가 높은 환경에서도 안정적으로 메시지를 교환한다.
3. **구독자 기반 흐름 제어** 발행자(Publisher)가 구독자(Subscriber) 상태를 능동적으로 인지하고, 메시지 송신 속도를 적절히 조절함으로써 네트워크 혼잡을 줄인다.

네트워크 혼잡을 완화하기 위해서 $\mathbf{A}$가 메시지 전달 행렬을, $\mathbf{x}$가 메시지 발행 빈도를 나타내는 상태 벡터라 한다면, 각 시간 스텝 $t$에서의 메시지 분포는 다음과 같이 근사적으로 표현될 수 있다.

$$
\mathbf{x}(t) = \mathbf{A},\mathbf{x}(t-1)
$$

위와 같은 모델에서 $\mathbf{A}$가 안정적인 고정점을 갖도록 설계하면, 일정 시간이 지난 후 메시지 전달 빈도가 균형 상태를 유지한다.

#### 실시간 특성 강화

보다 정밀한 실시간 운영이 요구되는 로봇 시스템에서, ROS2 Humble은 실시간 스케줄링 및 Task 관리 전략을 개선했다. 특히 `rmw` 레벨에서 파라미터 설정을 통해 RT-Preempt 커널 또는 실시간 운영체제(RTOS)와의 결합이 수월해졌으며, 실시간 서비스를 위한 스레드 우선순위와 메모리 고정(locking) 등의 설정이 간소화되었다.

실시간 성능을 평가할 때는 다음과 같은 수식을 사용할 수 있다. $\mathbf{J}$를 태스크마다 발생하는 지터(jitter)를 모은 벡터로 두고, $\mathbf{W}$를 각 태스크의 스케줄링 윈도우를 나타내는 행렬로 놓으면, ROS2 시스템에서의 태스크 지터는 대략적으로 다음과 같이 계산된다.

$$
\mathbf{J} \approx \mathbf{W},\mathbf{x}\_{task}
$$

여기서 $\mathbf{x}\_{task}$는 각 태스크의 시작 시간, 실행 시간을 요소로 가진 벡터다. $\mathbf{W}$는 스케줄러 설정(우선순위, 메모리 고정, CPU 바운드 등)에 따라 달라지며, 이를 어떻게 구성하느냐에 따라 전체 지연이 크게 바뀐다.

#### 보안 및 액세스 제어 강화

ROS2 Humble에서는 시스템 전반의 보안을 강화하기 위한 새로운 액세스 제어 기법이 적용되었다. 이전 버전 대비 세분화된 권한 설정이 가능해지면서, 특정 노드나 토픽에 대한 읽기·쓰기가 명확히 분리될 수 있도록 구현되었다. 예를 들어, 센서 데이터 처리를 담당하는 노드만 특정 토픽에 접근할 수 있도록 하거나, 특정 액션 서버에 접근 권한을 제한하여 로봇 제어 권한이 의도치 않게 노출되지 않도록 막는다.

이러한 보안 적용 효과는 여러 측면에서 수치화해볼 수 있다. 예를 들어, 액세스 제어 정책을 적용했을 때 권한 없는 노드가 데이터에 접근할 확률을 $\mathbf{p}*{unauth}$라 두고, 권한 있는 노드가 필요한 데이터를 문제없이 받는 확률을 $\mathbf{p}*{auth}$라고 할 때, 다음과 같은 단순 모델로 시스템 보안도를 정의할 수 있다.

$$
\mathbf{S}*{security} = \mathbf{p}*{auth} - \mathbf{p}\_{unauth}
$$

실제 환경에서는 $\mathbf{p}*{auth}$가 1에 가깝고 $\mathbf{p}*{unauth}$가 0에 가까울수록, 즉 $\mathbf{S}\_{security}$가 높은 값을 가질수록 시스템은 보다 안전한 상태로 분류된다.

#### 멀티 아키텍처 및 이종 프로세서 지원

ROS2 Humble은 기존에 비해 더 폭넓은 프로세서 아키텍처(예: ARM, x86, RISC-V 등)와의 호환성 및 최적화를 지원한다. 특히 범용 CPU 외에도 GPU, FPGA와 같은 가속기용 하드웨어와 연동하기가 한결 수월해졌다. 멀티 아키텍처 지원이 활성화되면서 대규모 자율주행 로봇이나 분산 센서 시스템에서의 연산 분담이 효율적으로 이루어졌으며, 실시간 스트리밍 데이터(예: 카메라 영상, LiDAR 데이터)를 처리할 때 병렬 처리를 통한 성능 향상이 기대된다.

아키텍처별 성능 향상을 모델링하기 위해, 하드웨어별 처리 성능을 나타내는 벡터 $\mathbf{h}$와 소프트웨어 스택의 최적화 계수를 나타내는 행렬 $\mathbf{Q}$를 고려해볼 수 있다. 이때 최종 처리 성능 $\mathbf{p}$는 아래와 같이 근사화된다.

$$
\mathbf{p} = \mathbf{Q},\mathbf{h}
$$

$\mathbf{Q}$는 아키텍처마다 다른 값이 설정될 수 있으며, GPU 연산 가속 등 비(非) CPU 리소스를 활용하는 경우에는 해당 요소가 더 큰 가중치로 반영된다.

#### 메시지 로깅 및 모니터링 개선

로그 수집 및 모니터링 기능이 보강되어, 더 다양한 유형의 운영 정보를 실시간에 가깝게 수집할 수 있게 되었다. 이를 통해 노드 간 통신 지연, 자원 사용량, 메시지 유실 등을 더욱 체계적으로 파악할 수 있으며, 별도의 로깅 노드를 사용하지 않아도 주요 지표를 통합 뷰에서 확인할 수 있도록 인터페이스가 마련되었다.

개발자는 운영 중에 발생하는 이벤트를 상호 연관 분석하기 위해, 다음과 같은 형태로 노드별 타임라인을 시각화할 수 있다. 예를 들어 mermaid를 사용하면 아래와 같은 순서도를 작성할 수 있다.

{% @mermaid/diagram content="sequenceDiagram
participant NodeA
participant NodeB
participant Monitor
NodeA->>NodeB: Sensor data publish
NodeB-->>Monitor: Log state
Monitor->>NodeA: Request more info" %}

이러한 모니터링 구조는 설계 단계에서부터 별도의 설정 없이 자동으로 동작하도록 구성 가능하며, 문제가 발견되면 실시간으로 로깅 레벨을 변경해 디버깅에 필요한 정보를 얻을 수 있다.

#### Launch 시스템 개선

ROS2 Humble에서는 Launch 시스템(런치 파일 구조 및 동작 방식)에 여러 가지 변화가 도입되었다. 기존 ROS2의 Launch 파일은 XML, YAML, Python 등 다양한 형태로 작성할 수 있었으나, 복잡한 로직이나 조건 분기 처리에서는 직관성이 떨어질 수 있다는 문제가 있었다. Humble 버전에서는 기존 기능들을 개선하는 동시에, 런치 파일 작성 시 의존성 정의나 조건부 실행을 더욱 쉽게 표기할 수 있도록 문법이 확장되었다.

실행 순서를 제어하거나 다중 노드를 한꺼번에 실행할 때, 보다 세부적인 파라미터를 일괄 전달하기 위해서 런치 파일 내에서 다차원 구성을 허용한다. 예를 들어, 다음과 같이 여러 개의 노드를 순차적으로 실행한 뒤 특정 조건에서만 트리거되는 노드를 정의할 수 있다.

{% @mermaid/diagram content="flowchart TB
start(("Start")) --> node1\["Launch Node A"]
node1 --> node2\["Launch Node B"]
node2 --> cond{"Condition Check?"}
cond -- Yes --> node3\["Launch Node C"]
cond -- No --> done(("Done"))    " %}

런치 시스템 개선 사항 중 핵심은 노드 간 의존 관계(Dependency)에 대한 선언적 표기가 가능하다는 점이다. 예컨대 노드 A가 준비되어 있어야만 노드 B가 구동될 수 있다면, 런치 스크립트 상에서 명시적으로 의존성을 기술함으로써 사용자의 실수를 줄이고, 예상치 못한 시간차 문제를 방지한다.

이를 수식적으로 모델링하면, 노드 실행 순서를 나타내는 벡터 $\mathbf{x}\_{launch}$와 노드 간 의존 관계를 나타내는 행렬 $\mathbf{D}$가 있을 때, 런치 시점에서 실제 실행 가능 상태(ready 상태)를 $\mathbf{r}$라 하면, 다음과 같이 표현할 수 있다.

$$
\mathbf{r} = \mathbf{D},\mathbf{x}\_{launch}
$$

여기서 $\mathbf{D}$의 각 원소가 11이면 해당 노드 실행에 필요한 다른 노드가 이미 구동되었음을 의미한다. 만약 일부 노드가 필요한 조건을 만족하지 못한다면, $\mathbf{r}$의 해당 항목이 00이 되어 해당 노드는 실행되지 않는다.

#### 파라미터 관리 및 동적 재설정(Dynamic Reconfigure) 개선

ROS2 Humble 버전에서는 노드 파라미터를 실시간에 가깝게 재설정하고, 그 변화를 즉시 반영할 수 있는 메커니즘이 한층 성숙해졌다. 각 노드는 `declare_parameter`, `set_parameter` 등을 통해 내부 파라미터를 다루는데, 기존 대비 더 정교한 검증(유효 범위, 타입 체크) 로직을 지정할 수 있으며, 여러 개의 파라미터가 동시에 변경될 경우 일관성을 유지하도록 트랜잭션(transaction) 개념을 도입하였다.

특히 로봇 운영 중 센서나 동작 환경이 바뀔 때, 노드 재시작 없이도 파라미터를 갱신할 수 있다. 예를 들어, 자율주행 차량에서 LiDAR의 샘플링 레이트를 조정하거나 카메라 노드에서 화질 설정 등을 실시간으로 바꿔야 하는 상황에 바로 적용 가능하다. 이러한 동적 재설정 과정은 다음과 같이 모델링할 수 있다.

$$
\mathbf{p}*{new} = \mathbf{f}\bigl(\mathbf{p}*{old}, \Delta \mathbf{p}\bigr)
$$

여기서 $\mathbf{p}*{old}$는 기존 파라미터 벡터, $\Delta \mathbf{p}$는 변경하려는 파라미터 증분 벡터, $\mathbf{f}$는 트랜잭션을 통해 검증 및 병합 로직을 수행하는 함수이다. $\mathbf{p}*{new}$는 최종적으로 노드에 반영되는 새로운 파라미터 집합이 된다.

#### 라이프사이클(Lifecycle) 노드 확장

Humble 버전에서는 라이프사이클 노드를 좀 더 세분화하여, 상태 전이(State Transition)마다 커스텀 콜백을 쉽게 정의할 수 있게 되었다. 기존에도 구성(Configuring), 활성화(Activating), 비활성화(Deactivating), 종료(Shutting down) 등의 상태 전이가 존재했으나, Humble에서는 특정 시스템 요구에 따라 상태를 추가하거나 기존 상태 전이를 약간 더 유연하게 취급할 수 있는 API가 제공된다.

라이프사이클 노드의 전이 관계를 단순화하여 표현하면 다음과 같은 그래프 구조로 시각화할 수 있다.

{% @mermaid/diagram content="flowchart LR
inactive\[Inactive] --> configuring\[Configuring]
configuring --> active\[Active]
active --> deactivating\[Deactivating]
deactivating --> inactive
inactive --> shuttingdown\[Shutting Down]
active --> shuttingdown" %}

상태 전이가 일어날 때, 노드가 자체적으로 자원을 해제하거나 새로운 의존성을 로드하도록 콜백을 지정할 수 있으므로, 시스템 전체의 안정성을 높일 수 있다. 예를 들어, 액터(actor) 형태로 동작하는 노드가 새로운 메시지 유형을 구독하기 전, 관련 버퍼를 초기화하거나 QoS 프로필을 재설정하도록 구성 가능하다.

#### 빌드 시스템(ament) 개선

ROS2 Humble에서는 `ament` 빌드 시스템의 효율성과 유연성을 한층 높이는 방향으로 개선이 이루어졌다. 예컨대 빌드 과정에서 필요 이상의 리소스를 사용하거나, 종속성(Dependencies)을 중복으로 확인함으로써 빌드 시간이 오래 걸리는 문제를 보완했다. 또한, 빌드 캐시를 보다 체계적으로 관리하여, 이미 빌드된 패키지들의 변경 사항을 빠르게 반영하고, 불필요한 재빌드를 방지하도록 최적화하였다.

여기서 빌드 캐시를 c\mathbf{c}라는 벡터로 정의하고, 빌드해야 할 소스 코드의 상태를 s\mathbf{s}라는 벡터로 둘 때, 빌드 시스템이 각 소스 코드 요소를 재빌드해야 하는지 여부는 대략적으로 다음과 같은 형태의 판단 함수를 이용해 결정할 수 있다.

$$
f(\mathbf{s}, \mathbf{c}) =  \begin{cases} 1, & \text{if } g(\mathbf{s}, \mathbf{c}) > \tau,\ 0, & \text{otherwise}. \end{cases}
$$

여기서 $g(\mathbf{s}, \mathbf{c})$는 빌드에 필요한 변경 정도를 평가하는 함수이고, $\tau$는 어떤 임계값(threshold)으로, 이를 초과하면 재빌드가 필요한 것으로 간주한다. 실제 ROS2 Humble 빌드 시스템에서는 CMake 캐시나 Python 기반 스크립트를 통해 이 과정을 좀 더 정교하게 수행한다.

#### 테스트 및 품질 관리 개선

Humble 버전에서는 ROS2 패키지 전반에 대한 테스트 자동화와 커버리지 측정이 훨씬 용이해졌고, 개발자가 수월하게 적용하도록 튜토리얼과 샘플이 강화되었다. 예를 들어, `ament_cmake_test`와 같은 유틸리티가 발전하면서, 단위 테스트(unit test)는 물론 통합 테스트(integration test)도 최소한의 설정 변경만으로 수행 가능해졌다.

품질 관리 측면에서는 linters(코드 정적 분석 도구)와 함께, 문서화 수준, 예외 처리, 코드 스타일 등이 종합적으로 체크되도록 `ament_lint` 패키지가 확장되었다. 프로젝트별로 린트 규칙을 커스터마이징할 수 있어서, 조직이나 팀의 코딩 표준에 맞춰 품질 검증을 자동화하기 쉽다.

테스트 커버리지 $\mathbf{C}$를 측정한다고 할 때, 각 테스트 케이스가 커버하는 코드 영역을 행렬 $\mathbf{M}$으로 두고, 테스트 케이스 실행 여부를 나타내는 벡터 $\mathbf{t}$라 하면,

$$
\mathbf{C} = \mathbf{M},\mathbf{t}
$$

여기서 $\mathbf{C}$의 각 항목이 $1$이면 해당 코드 영역이 테스트에 의해 검증된 것이고, $0$이면 아직 검증되지 않은 영역을 의미한다. 이를 기반으로 개발자는 전체 코드베이스 중 어떤 부분이 테스트 사각지대인지 쉽게 확인할 수 있다.

#### Node Composition 및 Intraprocess 통신 개선

Humble 릴리스에서는 Node Composition 기능이 더욱 안정화되었다. 여러 노드를 하나의 프로세스 내에서 실행할 수 있게 함으로써, 프로세스 간 통신에 따르는 오버헤드를 줄이고, 자원을 공유할 수 있어 성능을 높인다.

특히 Intraprocess 통신을 활용하면 노드 간 데이터를 직렬화/역직렬화 과정을 생략하거나 최소화할 수 있어, 주파수 높은 메시지 스트리밍 상황(예: 카메라 영상 처리 등)에서 처리 지연을 크게 단축할 수 있다.

Node Composition 구조를 이해하기 쉽게 mermaid로 표현하면 다음과 같다.

{% @mermaid/diagram content="flowchart LR
subgraph Single Process
compNode1\[Composed Node1]
compNode2\[Composed Node2]
end
compNode1 --> compNode2" %}

하나의 프로세스 내부에서 compNode1과 compNode2가 직접 메모리를 교환하거나, 최소한의 복사 과정만을 수행하므로, 종전 대비 낮은 레이턴시와 적은 CPU 사용량이 기대된다.

Intraprocess 통신의 효율성은, 간단히 표현하면 다음과 같은 모델로 설명 가능하다. 노드 간 메시지 전달을 나타내는 $\mathbf{x}$, 직렬화 오버헤드를 나타내는 $\alpha$라 하고, 프로세스 내부 공유 메모리 접근 비용을 $\beta$라 두면, 통신에 필요한 총 비용 $\mathbf{T}$는 대략적으로

$$
\mathbf{T} \approx \alpha \cdot \mathbf{x}*{inter} + \beta \cdot \mathbf{x}*{intra}
$$

로 표현된다. 여기서 $\mathbf{x}*{inter}$는 프로세스 간 메시지 교환, $\mathbf{x}*{intra}$는 프로세스 내부 메시지 교환에 해당한다. $\alpha$와 $\beta$의 상대적 크기에 따라, Composition 전략의 성능 이점이 결정된다.

#### TF2 구조 및 성능 개선

좌표계 변환을 담당하는 TF2 라이브러리에서 일부 내부 구조가 개편되어, 더 적은 연산으로도 다수의 프레임(Frames) 변환을 처리할 수 있게 되었다. 특히 로봇 팔(Manipulator)처럼 링크(Links)가 많은 로봇에서, 매 순간 발생하는 프레임 변환 요청을 보다 효율적으로 캐싱(caching)하고, 불필요한 계산을 줄이는 최적화가 이루어졌다.

기존 TF2의 좌표 변환은 트리(Tree) 구조로 표현되지만, Humble 버전에서는 그래프(Graph) 기반 구현을 가정한 최적화 기법도 일부 적용될 수 있도록 준비되었다. 예컨대, 각 프레임 간 변환 관계를 행렬 $\mathbf{T}\_{ij}$ 형태로 유지한다면, 특정 경로를 따라 변환해야 할 때 매번 곱셈을 수행하지 않고, 이전에 계산된 결과를 재활용하거나, 스파스(sparse) 데이터 구조를 적용하는 방법을 쓸 수 있다.

다음은 3D 좌표 변환의 일반적인 형태를 행렬 곱으로 나타낸 예시이다.

$$
\mathbf{T}*{target} = \mathbf{T}*{base \rightarrow link\_1} \times \mathbf{T}*{link\_1 \rightarrow link\_2} \times \cdots \times \mathbf{T}*{link\_{n-1} \rightarrow link\_n}
$$

TF2 개선 사항으로 인해, 이러한 연쇄 변환을 수행할 때 중복 계산을 줄여 성능을 높일 수 있다.

#### Actions 인터페이스 개선

ROS2의 Actions 기능은 일련의 목표(Goal)를 설정하고, 해당 목표에 대한 피드백(Feedback)과 최종 결과(Result)를 주고받으며, 필요할 경우 액션을 취소(Cancel)할 수 있도록 구성된다. Humble 버전에서는 이러한 액션 메시지 구조와 전송 메커니즘에 여러 최적화가 도입되었다.

* **메시지 전송 효율 향상** 액션 서버(Action Server)와 액션 클라이언트(Action Client) 간의 상태 동기화 과정을 더 간소화하여, 불필요한 트래픽을 줄였다.
* **에러 처리 로직 고도화** 액션 실행 도중 오류가 발생했을 때, 서버와 클라이언트가 적절히 상호작용하여 빠르게 오류 상태를 감지하고 복구할 수 있도록 예외 처리가 강화되었다.
* **액션 생명주기 관리** 액션 목표(Goal)가 중단되거나 재개될 수 있는 다양한 상황을 보다 유연하게 표현하도록 상태 전이(state transition) 구조를 개선하였다. 여러 개의 목표가 동시에 존재할 때 우선순위를 부여하거나, 일괄 취소 시나리오를 간편하게 구현할 수 있다.

액션의 전이 과정을 단순화하여 mermaid로 표현하면 아래와 같다.

{% @mermaid/diagram content="flowchart LR
idle((Idle)) --> received\[Goal Received]
received --> executing\[Executing]
executing --> success((Success))
executing --> canceled((Canceled))
executing --> failure((Failure))" %}

액션 서버 입장에서, 여러 Goal을 동시에 처리할 때, 각각의 진행 상태를 $\mathbf{g}$라는 벡터로 두고, 전이 관계를 나타내는 행렬 $\mathbf{A}\_{action}$이라 하면, 각 타임 스텝 $\Delta t$에서

$$
\mathbf{g}(t + \Delta t) = \mathbf{A}\_{action} ,\mathbf{g}(t)
$$

와 같이 표현 가능하다. 여기서 $\mathbf{A}\_{action}$의 값에 따라, 실행 중인 Goal이 성공(success), 취소(canceled), 실패(failure) 등으로 분기한다.

#### rosbag2 개선

ROS2에서 rosbag2는 로봇 운용 중 발생하는 토픽 메시지, TF 변환 정보, 파라미터 변경 사항 등을 기록하고 재생하는 도구로 활용된다. Humble 버전에서는 다음과 같은 부분들이 향상되었다.

* **입출력(I/O) 성능 최적화** 고속 로그 작성이 필요한 상황에서 디스크 쓰기 횟수를 최소화하거나 버퍼링 전략을 개선하여, 메시지 누락이나 지연을 줄였다.
* **멀티 인스턴스 관리** 복수의 rosbag 인스턴스가 동시에 데이터 기록을 수행할 때, 충돌을 방지하기 위한 잠금(Locking) 및 세분화된 로깅 정책이 적용되었다.
* **플러그인 구조 확장** 각종 압축 알고리즘(GZip, Zstd 등)을 자유롭게 선택하거나, 신규 포맷(CDR, JSON, CSV 등)으로 로그를 저장할 수 있도록 플러그인 포인트가 보강되었다.

rosbag2의 내부 처리를 간단하게 나타내면, 입력 메시지 스트림 $\mathbf{m}(t)$이 있을 때, 이를 시간 구간 $\Delta t$ 별로 분할하여 로그 파일에 기록한다고 볼 수 있다. 이 과정을 간단하게 쓰면,

$$
\mathbf{L}(t) = \int\_{t}^{t+\Delta t} \mathbf{m}(\tau) , d\tau
$$

여기서 $\mathbf{L}(t)$는 $\Delta t$ 구간 동안 누적된 메시지의 집합(로그)을 나타낸다. rosbag2는 이 누적 과정을 효율적으로 수행하기 위해 비동기 I/O 기법을 활용하고, 메시지 시퀀스에 대한 타임스탬프를 정확히 부여한다.

#### CLI 툴 확장

ROS2에서의 CLI(Command Line Interface) 툴은 `ros2 topic`, `ros2 service`, `ros2 action`, `ros2 param` 등 다양한 명령을 제공한다. Humble 버전에서는 다음과 같은 기능이 추가·개선되었다.

* **자동 완성(Auto-completion) 개선** bash, zsh 등에서 명령어 자동 완성 스크립트가 정교해져, 토픽 이름, 서비스 이름, 노드 이름 등을 빠르게 검색할 수 있다.
* **상호 작용(Interactive) 명령 모드** 일부 명령은 반복적으로 쓰이기 때문에, 대화형(Interactive) 모드에서 여러 옵션을 순차적으로 선택·입력할 수 있도록 보조 기능이 추가되었다.
* **내장 도움말(Help) 세분화** 각 명령어에 대한 하위 옵션, 예시를 좀 더 자세히 안내함으로써, 초보자도 어렵지 않게 CLI 기능을 활용할 수 있다.

CLI 동작 흐름을 mermaid로 표현하면, 아래와 같다.

{% @mermaid/diagram content="flowchart TB
userInput(User types a command) --> parseCLI\[CLI Parser]
parseCLI --> checkOptions\[Check Options / Validate]
checkOptions --> executeCommand\[Execute Requested Operation]
executeCommand --> result\[Print Result / Wait for Next Input]" %}

클라이언트가 CLI로부터 입력을 받으면, 내부 파싱(parser) 로직이 명령어를 분석하고, 유효한 옵션인지 검증한 뒤, 실제 ROS2 API에 요청을 보내게 된다.

#### Cross-Compilation 및 임베디드 지원 강화

ROS2를 임베디드 장치나 리소스가 제한적인 환경에서 구동하기 위해서는 크로스 컴파일(Cross-Compilation) 툴체인 설정이 필요하다. Humble 버전에서는 다음과 같은 부분이 개선되었다.

* **colcon 플러그인 기반 크로스 컴파일 지원** 크로스 컴파일 시 필요한 툴체인 파일, 종속 라이브러리 등을 일괄 관리할 수 있는 플러그인 구조가 확립되었다.
* **경량화(Build Stripping) 옵션** 임베디드 환경에 불필요한 요소(디버그 심볼, 미사용 라이브러리 등)를 쉽게 제거하도록 `colcon`이나 `ament` 설정 단계에서 옵션을 제공한다.
* **RTOS/마이크로 커널 호환성 개선** FreeRTOS, Zephyr와 같은 마이크로 커널 기반 플랫폼에서도 ROS2 핵심 기능을 일정 부분 사용할 수 있도록 `rcl` 계층 최적화를 진행하였다.

이 과정을 수식화하면, 크로스 컴파일 결과물을 $\mathbf{b}*{target}$이라 하고, 호스트 환경에서의 소스 상태를 $\mathbf{s}*{host}$, 툴체인 설정을 나타내는 행렬 $\mathbf{T}\_{cc}$라 하면,

$$
\mathbf{b}*{target} = \mathbf{T}*{cc},\mathbf{s}\_{host}
$$

$\mathbf{T}*{cc}$는 목표 플랫폼에 맞게 컴파일러, 링커, 라이브러리 경로 등을 설정하는 연산을 내포한다. 만약 $\mathbf{T}*{cc}$가 잘못 구성되면 링크 오류, 라이브러리 불일치 등 문제가 발생하므로, ROS2 Humble에서는 이러한 설정 과정을 쉽게 확인할 수 있는 툴이 추가되었다.