학원에서 ROS2에 대해 배웠는데, ROS2의 깊은 원리에 대해 따로 공부해봤다.
ROS1과 ROS2의 차이점, ROS2의 통신 방식과 지원 인터페이스에 대해 정리해봤다.
ROS1 vs ROS2
ROS1의 철학
중앙 집중식: master node를 중심으로 돌아간다.
빠른 개발과 실험 우선. 복잡한 설정 없이 연구자들이 빠르게 프로토타입을 만들 수 있다.
단순함이 중점이다. 실전 배포에선 한계에 노출된다.
ROS2의 철학
master node 없이 p2p 분산 시스템
보안 (DDS) 지원으로 실제 산업에서 사용할 수 있게 함.
ROS1의 master node가 없는 ROS2에선, 노드들이 서로 찾기 위해 Discovery 매커니즘을 사용한다:
- Simple Discovery(멀티캐스트): 각 노드가 네트워크에 '나 이런 Topic을 가지고 있어'라는 신호를 보내고, 다른 노드들이 이를 받아서 자동으로 연결한다. 노드가 많아지면 네트워크 트래픽이 n^2 로 증가한다.
- Discovery Server: 중앙 서버를 통해 Discovery 정보를 관리한다. 대규모 시스템이나 멀티캐스트가 안 되는 상황에서 유용하다.
ROS2의 통신 방식
사용자가 node간 통신을 쉽게 구현할 수 있도록, ROS2에서 통신 인터페이스를 지원한다. 이 인터페이스는 파일 확장자로 구분한다.
- Topic
.msg: 비동기 단방향 (Pub/Sub). 센서 스트림, 상태 공유 등에 사용 - Service
.srv: 동기 양방향 (Req/Resp). 설정 변경 등 - Action
.action: 비동기 양방향 (Goal/Feedback/Result). 취소가 가능한 긴 작업에 사용
Unlike ROS 1, which primarily only supported TCP, ROS 2 benefits from the flexibility of the underlying DDS transport in environments with lossy wireless networks where a “best effort” policy would be more suitable, or in real-time computing systems where the right Quality of Service profile is needed to meet deadlines.
공식문서에도 언급하듯이 ROS2는 DDS를 이용하고 있다.
DDS와 QoS
ROS2 QoS 설정
↓ (rclcpp::QoS로 변환)
DDS QoS 정책들 (Reliability, History, Durability 등 22개)
↓ (DDS 구현체 FastDDS/CycloneDDS로 전달)
실제 RTPS 프로토콜 통신 (UDP/TCP 위에서 동작)- publisher가 QoS를 설정하고 Topic에 publish하면(create_publisher() 호출) DDS DataWriter가 생성된다.
- subscriber가 같은 Topic을 구독하면 DDS DataReader가 Publisher를 Discovery한다
- DDS가 QoS 호환성을 검사한다.
- 호환되면 RTPS 통신을 시작한다. QoS 정책에 따라 재전송/버퍼링/타임아웃 등을 적용한다.
QoS
통신 품질을 정하는 설정 옵션이다. ROS2에서 publisher, subscriber가 메시지를 주고받을 때 '얼마나 신뢰성 있게 보낼지, 얼마나 오래 보관할지, 유실을 허용할지' 등을 QoS로 정한다.
UDP처럼 유실돼도 상관 없지만 지연이 적어야 하는 데이터, TCP처럼 신뢰성이 중요한 데이터로 나뉘는데, 이 두 데이터를 똑같이 다루면 안 되기 때문에 QoS로 통신 성격을 고른다.
Publisher 노드, Subscriber 노드에서 QoS를 설정하면 된다.
Publisher 노드:
#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"
class MinimalPublisher : public rclcpp::Node
{
public:
MinimalPublisher()
: Node("minimal_publisher")
{
auto qos = rclcpp::QoS(rclcpp::KeepLast(10)); // History: KEEP_LAST, depth=10
qos.reliable(); // Reliability: RELIABLE
qos.durability_volatile(); // Durability: VOLATILE
publisher_ = this->create_publisher<std_msgs::msg::String>("chatter", qos);
}
private:
rclcpp::Publisher<std_msgs::msg::String>::SharedPtr publisher_;
};
Subscriber 노드:
subscription_ = this->create_subscription<std_msgs::msg::String>(
"chatter",
qos,
std::bind(&MinimalSubscriber::topic_callback, this, std::placeholders::_1)
);
QoS가 건드리는 주요 요소
- History/ Depth: 과거 메시지를 몇 개까지 보관할지 (최신 N개만 보관 vs 전부 보관)
- Reliability: 유실을 감수하고 빠르게 보낼지(BEST_EFFORT), 재전송해서 확실히 보낼지(RELIABLE)
- Durability: 늦게 붙은 subscriber에게 예전 메시지를 다시 줄지(TRANSIENT_LOCAL) 말지(VOLATILE)
DDS
OMG (Object Management Group)가 정의한 표준 미들웨어 스펙이며, ROS2는 이 DDS를 기반으로 통신을 구현한다. Fast-DDS, Cyclone DDS 등 다양한 구현체를 선택할 수 있다.
- 데이터 중심: 메시저/노드가 아니라 topic을 중심으로 통신을 구성함
- 발행-구독: pub가 topic에 데이터를 올리고, subscriber가 관심 있는 topic을 구독해서 받는다. 중간 브로커 (ROS1에서의 master node)가 필요 없다.
- 분산형: 모든 노드가 직접 연결되어 중앙 장애점이 없고, 네트워크 변화에도 자동 복구된다.
노드들은 신경쓰지 않고, Topic에 어떤 데이터를 올릴지만 개발자가 결정하면 된다. 그 후엔 설정되어 있는 QoS에 맞춰서 전달된다.
RTPS (Real-Time Publish-Subscribe)
DDS의 실제 네트워크 전송 프로토콜. DDS가 어떻게 통신할지의 설계도라면, RTPS는 그 설계도를 UDP/IP 레이어에서 실제 패킷으로 구현한다.
다른 DDS 벤더끼리도 RTPS 표준 때문에 서로 통신이 가능하다.
QoS는 RTPS 헤더에 넣어서 재전송/버퍼링/타임아웃 등을 네트워크 레벨에서 처리한다.
출처
ROS2 공식문서 - Quality of Service settings
DDS 이해하기
ROS2, DDS와 QoS
DDS와 RTPS 이해하기
