이전 글에서 DDS와 RTPS가 무엇인지와 그 관계에 대해서 간단하게 정리했다. (DDS와 RTPS 개념정리)
이번 시간에는 DDS-RTPS의 communication의 주체인 RTPS Entity의 structure와 RTPS Entity들이 주고 받는 RTPS message에 대해 알아보고 정리해보겠다.
DDS-RTPS Structure
DDS-RTPS의 communication의 주체인 RTPS Entity는 아래와 같은 구조로 되어있다.
- Entity : RTPS communication의 주체로 DDS domain상에서 고유한 id를 갖고 있다.
- Participant : Entity로서 Endpoint들을 담고 있는 컨테이너이다. ROS에서 node를 생성하면 RTPS Participant가 생성이 된다.
- Endpoint : Entity로서 RTPS message의 source 또는 destination이 될 수 있는 communication의 endpoint이다.
- Writer : Endpoint로서 data update 정보를 매칭된 Reader에게 보내고, Reader로부터 acknowledgment를 받는다. ROS에서 publisher를 생성하면 Writer가 생성된다.
- Reader : Endpoint로서 매칭된 Writer로부터 data update 정보를 수신하고, 완료 또는 실패에 대한 acknowledge를 보낸다. ROS에서 subscriber를 생성하면 Reader가 생성된다.
- HistoryCache : CacheChange들의 컨테이너이다. Writer쪽 HistoryCache는 Writer에 의한 CacheChange에 대한 History를 담고 있다. Reader쪽 HistoryChache는 매칭된 Writer에 의한 CacheChange에 대한 History를 담고 있다. HistoryCache에 CacheChange를 얼마나(몇 개나) 보관할 것인지는 QoS 설정에 따라 달라진다.
- CacheChange : 데이터에 대한 변경사항 (생성, 수정, 삭제)을 담고 있다.
DDS-RTPS Message
RTPS Writer와 Reader 사이에 교환되는 RTPS message는 아래와 같은 구조로 되어있다.
- Message : Message는 fixed-size인 Header가 있고, 다음으로 여러 개의 Submessage가 따를 수 있다.
- Header : message의 protocol이 RTPS라는 것과 protocol version 등을 담고 있다.
- Submessage : submessage의 종류에 따라 구조가 다르다. RTPS Entity를 target으로 하는 DATA, HEARTBEAT, GAP, AckNack 등 Entity Submessage의 경우에는 source와 destination정보를 담은 readerId, writerId 필드에 Reader, Writer Entity의 고유한 id 정보가 들어간다.
- Submessage Header : Submessage의 종류, submessage length와 endian정보 등을 담고 있다.
- Submessage Elements :
- HeaderExtension : RTPS message의 optional한 정보를 담고 있다. 만약 HeaderExtension이 존재한다면 Header 바로 다음에 존재해야한다. RTPS message length, Timestamp, Checksum 등을 담고 있을 수 있다.
- DATA : Writer에서 Reader로 전송되는 submessage로서 application의 데이터 값에 관련된 정보(ChangeCache)를 담고 있다.
- HEARTBEAT : Writer에서 Reader로 전송되는 submessage로서 Writer의 HistoryCache에서 available한 ChangeCache에 대한 정보를 보내준다. firstSN (Writer HistoryCache의 가장 낮은 sequence number)와 lastSN (Writer HistoryCcache의 가장 높은 sequence number) 정보 등을 담고 있다.
- GAP : Writer에서 Reader로 전송되는 submessage로서 Writer HistoryCache에서 특정 sequence number ChangeCache가 더 이상 이용 가능하지 않으며 앞으로 송신되지 않을 것이란 것을 Reader에 알려준다.
- AckNack : Reader에서 Writer로 전송되는 submessage로서 Reader의 state를 알려준다.
- NackFrag : DATA, HEARTBEAT 정보는 fragment되어 전송될 수 있다. (그 때는 DATAFRAG, HEARTBEATFRAG submessage type을 이용) 이 때 어떤 fragment가 수신되지 않았는지 Reader에서 Writer로 전송되는 submessage이다.
Summay
ROS node를 생성하면 Participant가 생성되며 Publisher, Subscriber를 생성하면 DataWriter, DataReader가 생성된다. 기본적으로는 Writer가 Reader에게 데이터의 변경사항에 대한 정보를 RTPS message에 담아 보내는 구조이다. 이 때 DATA, HEARTBEAT, GAP, AckNack 등 RTPS submessage를 활용하게 된다.
Qos설정에 따라 (최소한의 overhead로 빠르게 정보를 주고받을지 또는 신뢰성을 위해 fault-tolerance하게 정보를 주고받을지 등) Writer와 Reader의 동작이 달라지게 되고 활용되는 RTPS message도 달라지게 된다. 다음 시간에 더 구체적으로 살펴보도록 하겠다.
References
'Robotics > ROS' 카테고리의 다른 글
DDS RTPS 패킷 확인해보기 (wireshark) (0) | 2022.03.01 |
---|---|
DDS RTPS의 Discovery Protocol (0) | 2022.02.12 |
DDS RTPS의 동작(behavior) (1) | 2022.02.11 |
DDS와 RTPS 개념정리 (0) | 2022.02.04 |
ROS 2 설치 (Windows WSL 이용) (0) | 2022.02.03 |