Ubuntu ROS 실습(7)

ROS 2에서는 노드들이 서로 데이터를 주고받을 때 DDS를 통신 미들웨어로 사용한다.

처음에는 DDS라는 이름 자체가 생소했지만, 간단하게 생각하면 ROS 2에서 노드와 노드 사이의 데이터 통신을 담당하는 중간 계층이라고 이해할 수 있다.

---

1. ROS의 메시지 통신

ROS에서는 프로그램을 하나의 큰 프로그램으로 작성하지 않고 여러 개의 노드(Node)로 나누어 작성한다.

노드는 ROS에서 실행되는 최소 단위의 프로그램이라고 볼 수 있다.

예를 들어 TurtleBot3를 생각해 보면,

• 센서 데이터를 처리하는 노드
• 로봇의 상태를 관리하는 노드
• 위치를 추정하는 노드
• 경로를 계산하는 노드
• 모터를 제어하는 노드

등 여러 노드가 각각의 역할을 담당할 수 있다.

하지만 노드가 서로 독립적으로 실행되기만 하면 하나의 로봇 시스템으로 동작할 수 없다.

따라서 각 노드가 서로 데이터를 주고받아야 하는데, 이때 사용되는 데이터가 메시지(Message)이다.

ROS에서는 메시지를 주고받는 대표적인 방식으로 다음과 같은 개념을 사용한다.

• Topic
• Service
• Action
• Parameter

그중에서도 특히 Topic의 Publisher / Subscriber 구조가 ROS의 메시지 통신에서 중요한 개념이다.

예를 들어 센서 노드가 /scan 토픽에 LaserScan 데이터를 발행하면, 필요한 다른 노드들이 /scan을 구독하여 데이터를 사용할 수 있다.

---

2. ROS 1과 ROS 2의 통신 방식 차이

ROS 1과 ROS 2 모두 노드 사이에서 메시지를 주고받는 구조를 사용하지만, 내부적으로 통신을 처리하는 방식에는 차이가 있다.

ROS 1에서는 대표적으로 TCPROS와 같은 ROS 자체 통신 방식을 사용했다.

반면 ROS 2에서는 DDS(Data Distribution Service)를 통신 미들웨어로 사용한다.

즉, 간단하게 구조를 생각하면 다음과 같다.

ROS 1
노드 → ROS 통신 시스템 → 노드

ROS 2
노드 → ROS 2 → DDS Middleware → 노드

DDS를 도입하면서 ROS 2에서는 통신의 신뢰성, 실시간성, 보안, 동적 검색, QoS 등의 기능을 보다 체계적으로 사용할 수 있게 되었다.

---

3. DDS란?

DDS는 Data Distribution Service의 약자이다.

이름 그대로 데이터를 분산하여 전달하기 위한 서비스이며, ROS 2에서는 통신 미들웨어 역할을 한다.

여기서 미들웨어는 운영체제와 실제 애플리케이션 사이에서 통신과 같은 기능을 제공하는 소프트웨어 계층이라고 생각하면 이해하기 쉽다.

사용자 프로그램
      ↓
ROS 2
      ↓
DDS
      ↓
운영체제 / 네트워크

따라서 ROS 2에서 개발자가 노드와 토픽을 작성하면, 실제 노드 사이의 데이터 전달 과정에서는 DDS가 통신을 담당하게 된다.

---

4. DDS의 주요 특징

DDS에는 다양한 특징이 있는데, ROS 2에서 특히 중요한 부분을 정리하면 다음과 같다.

산업 표준

DDS는 OMG(Object Management Group)에서 관리하는 산업 표준이다.

ROS 1에서는 ROS 자체의 통신 방식에 대한 의존성이 컸지만, ROS 2에서는 산업 표준인 DDS를 사용한다.

따라서 ROS 2가 로봇 분야뿐만 아니라 자동차, IoT, 국방, 항공·우주 등의 다양한 산업 환경으로 확장되는 데에도 도움이 된다.

운영체제 독립

DDS는 특정 운영체제에 종속되지 않는다.

Linux, Windows, macOS, Android, VxWorks 등 다양한 운영체제에서 사용할 수 있다.

ROS 2 역시 여러 운영체제를 지원하기 때문에 이러한 DDS의 특징과 잘 맞는다.

즉, "운영체제가 달라지더라도 동일한 통신 구조를 사용할 수 있다."라고 이해하면 된다.

언어 독립

DDS는 특정 프로그래밍 언어에 종속되지 않는다.

ROS 2에서는 DDS를 직접 사용하는 대신 RMW(ROS Middleware) 계층을 두고, 그 위에서 다양한 ROS Client Library를 사용할 수 있도록 구성되어 있다.

예를 들어,

Python → rclpy
C++    → rclcpp
C      → rclc

와 같이 프로그래밍 언어에 맞는 ROS Client Library를 사용할 수 있다.

따라서 개발자는 DDS의 내부 동작을 직접 구현하지 않고 ROS 2에서 제공하는 인터페이스를 이용해 노드를 작성할 수 있다.

UDP 기반의 전송 방식

DDS는 일반적으로 UDP 기반의 통신 방식을 사용한다.

UDP는 TCP와 달리 연결을 유지하면서 모든 데이터의 전달을 보장하는 방식은 아니지만, 빠른 데이터 전달과 멀티캐스트 등에 유리하다.

특히 DDS에서는 여러 노드가 특정 데이터 영역에 참여할 수 있도록 멀티캐스트 등의 방식을 활용한다.

ROS 2에서는 이러한 통신 영역을 ROS_DOMAIN_ID를 이용해 구분할 수 있다.

export ROS_DOMAIN_ID=10

같은 방식으로 Domain ID를 설정하면 동일한 Domain에 있는 ROS 2 노드들이 서로 통신할 수 있다.

다만 UDP의 특성 때문에 데이터 전달의 신뢰성이 항상 보장되는 것은 아니며, ROS 2에서는 뒤에서 설명할 QoS를 이용하여 이러한 통신 특성을 조절할 수 있다.

데이터 중심(Data Centric)

DDS에서 자주 등장하는 개념 중 하나가 Data Centric, 즉 데이터 중심이라는 개념이다.

쉽게 말하면 단순히 "어떤 노드가 어떤 노드에게 데이터를 보낸다"는 것보다, "어떤 데이터가 존재하고, 누가 그 데이터를 필요로 하는가"를 중심으로 통신이 이루어진다고 볼 수 있다.

ROS 2에서 Publisher와 Subscriber를 사용하는 구조도 이러한 데이터 중심 통신과 연결된다.

예를 들어 TurtleBot3에서 LaserScan 데이터를 생각해 보면,

             /scan
               ↓
        LaserScan 데이터
          ↙          ↘
       AMCL        move_base

LaserScan을 발행하는 노드와 이를 필요로 하는 여러 노드가 직접 일대일로 연결되는 것이 아니라, /scan이라는 데이터를 중심으로 여러 노드가 연결된다.

동적 검색(Dynamic Discovery)

개인적으로 ROS 1과 ROS 2의 차이를 이해할 때 중요한 부분이라고 생각한 것이 Dynamic Discovery이다.

ROS 1에서는 ROS Master가 노드들의 정보를 관리했다.

        ROS Master
        /       \
      Node A   Node B

노드가 실행되면 Master에 자신의 정보를 등록하고, 다른 노드가 필요한 정보를 찾을 수 있도록 연결을 도와주는 구조였다.

반면 ROS 2에서는 DDS의 Dynamic Discovery 기능을 사용한다.

따라서 별도의 ROS Master가 없어도 DDS가 같은 Domain 안에서 노드와 토픽 등의 정보를 검색하고 서로 연결할 수 있다.

        Node A
          ↕
         DDS
          ↕
        Node B

즉, ROS 2에서는 ROS Master가 통신의 중심에 있는 구조가 아니라 DDS가 노드 검색과 통신을 담당한다.

이 부분은 ROS 1과 ROS 2의 구조적인 차이를 이해하는 데 중요한 부분이었다.

확장 가능한 아키텍처

DDS는 작은 임베디드 장치부터 대규모 분산 시스템까지 확장할 수 있도록 설계되어 있다.

ROS 역시 하나의 노드만 사용하는 것이 아니라 수십 개, 수백 개 이상의 노드가 서로 연결될 수 있기 때문에 이러한 확장성이 중요하다.

예를 들어 하나의 로봇에서 끝나는 것이 아니라,

Robot 1 ─┐
Robot 2 ─┼─ ROS 2 / DDS ─ Cloud
Robot 3 ─┘              └ Database

와 같이 여러 로봇과 서버, 클라우드 등의 시스템으로 확장할 수도 있다.

상호 운용성

DDS는 표준 규격을 따르는 여러 DDS 제품 사이에서 상호 운용성을 지원한다.

즉, DDS 표준을 준수하는 서로 다른 제품이나 구현을 사용하더라도 통신할 수 있도록 설계되어 있다.

ROS 2에서는 다양한 DDS 구현을 사용할 수 있으며, 대표적으로 다음과 같은 구현들이 있다.

• Fast DDS
• Cyclone DDS
• Connext DDS
• Gurum DDS 등

이러한 구조 덕분에 ROS 2가 특정 하나의 통신 구현에만 종속되지 않는다는 장점이 있다.

QoS (Quality of Service)

ROS 2에서 DDS를 사용하는 가장 중요한 이유 중 하나가 QoS(Quality of Service)이다.

QoS는 말 그대로 서비스 품질을 설정하는 기능이다.

쉽게 말하면, "이 데이터를 어떻게 전달할 것인가?"를 개발자가 설정할 수 있도록 해주는 기능이다.

예를 들어 데이터가 조금 손실되더라도 빠르게 전달하는 것이 중요한 경우와, 속도가 조금 느려지더라도 데이터를 반드시 전달해야 하는 경우는 서로 다른 설정이 필요하다.

대표적인 QoS 설정으로는 다음과 같은 것들이 있다.

• Reliability
• History
• Durability
• Deadline
• Lifespan
• Liveliness

보안

마지막은 Security이다.

ROS 1에서 상대적으로 부족했던 보안 부분을 ROS 2에서는 DDS의 보안 기능을 활용하여 강화할 수 있다.

DDS에는 DDS-Security라는 보안 관련 표준이 있으며, ROS 2에서는 이를 기반으로 통신 보안을 구성할 수 있다.

또한 ROS 커뮤니티에서는 SROS 2(Secure Robot Operating System 2)를 제공하여 ROS 2 시스템의 보안을 구성할 수 있도록 지원한다.

로봇이 단순한 개인 실습 환경을 넘어 실제 산업 환경에서 사용되기 위해서는 통신 보안도 중요한 요소이기 때문에 ROS 2에서 이러한 기능을 제공하는 것은 중요한 부분이라고 볼 수 있다.

---

마무리

이번에는 ROS 2의 통신 구조를 이해하기 위해 DDS(Data Distribution Service)에 대해 정리했다.

처음에는 DDS라는 용어 자체가 생소했지만, 전체적인 구조를 살펴보면서 ROS 2에서 DDS가 어떤 역할을 하는지 조금씩 이해할 수 있었다.

정리하면 ROS 2의 통신 구조는 다음과 같이 생각할 수 있다.

사용자 노드
    ↓
ROS 2 Client Library
    ↓
RMW
    ↓
DDS
    ↓
네트워크

ROS 2에서 개발자는 주로 Node, Topic, Service, Action과 같은 ROS의 인터페이스를 사용하지만, 실제 노드 사이의 데이터 통신은 그 아래에 있는 DDS 계층을 통해 이루어진다.

특히 이번 내용을 통해 ROS 1과 ROS 2의 차이도 조금 더 명확하게 이해할 수 있었다.

ROS 1에서는 ROS Master가 노드와 통신 정보를 관리하는 구조였다면, ROS 2에서는 DDS의 Dynamic Discovery를 통해 같은 Domain에 있는 노드들이 서로를 검색하고 통신할 수 있다.

또한 DDS의 QoS를 통해 데이터 전달의 신뢰성이나 지속성 등 통신 특성을 상황에 맞게 설정할 수 있다는 점도 알게 되었다.

이 내용이 처음에는 단순한 이론처럼 보였지만, 이후 진행한 TurtleBot3 실습에서 /scan, /tf, /map과 같은 토픽을 확인하면서 노드들이 서로 데이터를 주고받는 구조를 이해하는 데 도움이 되었다.

특히 하나의 로봇 시스템 안에서도 여러 노드가 각각 다른 역할을 담당하고 있기 때문에, ROS 2에서 노드들이 어떻게 서로 연결되고 데이터를 전달하는지를 이해하는 것이 중요하다는 것을 알 수 있었다.

다음 실습에서는 이러한 ROS 2의 통신 구조를 바탕으로 실제 로봇 시스템에서 노드와 센서 데이터가 어떻게 연결되는지 더 자세히 확인해 볼 예정이다.