QoS(Quilty of service)

Qos(Quilty of Service) 

DDS  ->  퍼블리셔-서브스크라이버 기반의 통신 미들웨어
QoS  ->  메시지 전달의 품질을 어떻게 보장할지를 설정하는 정책 집합
즉, "어떻게 데이터를 보내고 받을 것인지"에 대한 규칙, 약속, 조건을 정의하는 것이 QoS이다.

• 퍼블리셔 또는 서브 스크라이버 선언 시 Qos를 매개 변수로 지정하여 원하는 통신 방식 설정 가능
• Qos로 바꿀 수 있는 것은 데이터 전송 시 실시간성(real time) 설정 관련 부분, 대역폭 옵션, 데이터 지속성, 중복성 등이 있음
• TCP 또는 UDP 방식을 선택적으로 사용 가능
  • TCP : 신뢰성(Reliability) 중심
  • UDP : 속도 중심

대표적인 Qos 항목 6가지 -> 현재 DDS에서 설정 가능한 Qos 항목으로는 22가지가 있다.

• Reliability : 메세지를 반드시 전달할 것인가?(RELIABLE) 아니면 가끔 유실돼도 괜찮은지(BEST_EFFORT)를 정하는 정책

BEST_EFFORT	데이터 송신과 전송 속도를 중시하며 네트워크에 따라 유실 발생 가능성이 있다. => UDP
RELIABLE	데이터 수신과 신뢰성을 중시하며 유실 발생시 재전송을 통해 수신을 보장한다 => TCP

 

• History : 데이터를 몇 개나 보관할 지 결정하는 Qos 정책

KEEP_LAST	- 정해진 메세지 큐 사이즈(depth)만큼 데이터 보관 - depth : 메세지 큐 사이즈( KEEP_LAST 설정일 경우에만 유효
KEEP_ALL	모든 데이터 보관 (최대 사이즈는 DDS 벤더마다 다름) -> 시스템 메모리 한도까지

 

 

• Durability : 늦게 구독한 노드에게 이전 메세지를 줄지 말지 정하는 정책
  -> 구독자가 늦게 데이터를 요청하더라도 이전의 내용을 알게 할 것인가(TRANSIENT_LOCAL) 모르게하고 들어온 시점부터 받게하겠다(VOLATILE)

TRANSIENT_LOCAL	Publisher가 최근 발행한 메세지를 저장하고, 나중에 등장한 Subscriber에게 메세지를 보내준다. (개수는 History에서 결정 , depth로)
VOLATILE	Subscription이 생성되기 전 데이터는 무효이다. 즉 새로운 메세지만 받는다 -> 휘발성

※ Durability가 TRANSIENT_LOCAL이어야 New Subscriber가 과거 메시지를 받을 수 있다! 얼마나 받을 수 있는지는 History(Depth)에 따라 메세지 양이 정해진다는 것을 기억하자

 

• Deadline : 퍼블리셔가 정해진 시간 간격 안에 메시지를 계속 보내지 않으면, 또는 구독자가 지정된 주기 내 수신하지 못하면, 경고 이벤트 (콜백) 가 발생하는 옵션 => 상태 체크
  -> 일정 시간 안에 메세지가 안오면 경고를 주는 정책
  
  • 동작 예시
    • 예를 들어 Deadline = 1초면, 퍼블리셔는 1초마다 최소 1개의 메시지를 보내야 함.
    • 구독자는 그 주기 내에 메시지를 못 받으면 이벤트 콜백 실행 (예: "센서 고장 났나?" 같은 처리).
  • 사용 목적 : 일정 주기로 데이터가 들어와야 정상임을 보장하고, 누락/지연을 감지하고 싶을때 사용
  • 비유 : "1분마다 네가 메세지를 보내기로 했잖아? 근데 안 왔네? 뭔가 문제가 있겠구만!!"

Duration

Deadline을 확인하는 주기로 토픽에 후속 메세지가 게시되는데 설리는 최대 예상 시간이다.

• Lifespan(생명주기) : 퍼블리셔가 보낸 메시지가 지정된 시간 동안만 유효하며, 그 시간이 지나면 구독자 측에서 받더라도 무시되거나 폐기된다. => 유통기한
  -> 메세지를 일정 시간 후 폐기할지 안할지 정하는 정책
  
  • 동작 예시
    • 예를 들어 Lifespan = 2초 라면, 메시지가 퍼블리셔에서 발행된 후 2초 이내에만 유효하다고 할때
    • 구독자가 2초가 지나고 이 메시지를 받으면, 해당 메시지는 유효하지 않으므로 폐기한다.
  • 사용 목적 : 오래된 데이터를 무시하고, 최신 정보만 반영하고 싶을 때 사용
  • 비유 : "이 우유는 제조 후 2시간 지나면 상하니까 버려야해!"

Duration

Lifespan을 확인하는 주기로 메세지가 오래되었거나 만료된 것으로 간주하지 않고, 메세지를 게시하고 수신할 때까지 걸리는 최대 시간 ( 만료된 메세지는 자동으로 삭제되며 실제로 수신되지 않는다.)

• Liveliness : 퍼블리셔(노드 또는 토픽)가 아직 살아 있는지 (즉, 장애 없이 작동 중인지)를 확인하는 QoS 정책
  -> publisher가 살아있는지 확인하는 방법
  
  • 수신자(Subscriber) 입장에서 "publisher가 죽었는지 아닌지"를 판단하는데 사용
  • 이것을 잘 설정해두면 센서 노드가 중단되었는지 통신이 끊겼는지 빠르게 탐지할 수 있다.
  • Liveliness의 역할
    • 실시간 시스템에서 중요 정보 감지
    • 발행자의 상태 모니터링
    • 데이터 갱신 주기 보장

liveliness

-자동 또는 메뉴얼 중 어떤 것으로 확인할지 지정하는 옵션(3가지 중 하나를 선택해야한다.) - AUTOMATIC : 시스템이 알아서 확인하는 것으로 노드의 publisher(게시자)가 하나가 메세지를 발행하기만 하면 해당 publisher는 자동으로 살아 있다고 간주되는 옵션 -> 카메라 센서가 주기적으로 영상을 퍼블리싱 → 메시지만 보내면 자동으로 살아있다고 판단 - MAUNUAL_BY_NODE : publisher Node가 직접 "살아있다"는 신호를 보내야하는 것으로 노드 전체 기준으로 확인한다. -> 노드가 장애 복구 기능을 갖추고 있고, API로 직접 "나 살아있어!"를 보내는 구조 → 센서가 자주 끊기는데 다시 복구될 수 있을 때 유용. - MANUAL_BY_TOPIC : publisher가 특정 토픽 단위로 API를 호출하여 살아있다고 주장해야하는 가장 정밀한 제어 방식이다. ->동일 노드가 여러 센서를 관리하는 경우, 센서별 상태를 관리해야 할 때 사용 (ex. LiDAR는 죽었지만 IMU는 살아있을 때를 구분하고 싶을 때)

lease_duration

Liveliness를 확인하는 주기로 퍼블리셔가 살아있다고 간주되는 최대 시간을 의미 -> 만약 이 시간 동안 퍼블리셔가 메시지를 보내지도 않고, Liveliness API를 통해 "살아있다"는 알림도 안 하면, 시스템은 퍼블리셔가 죽었다고 판단

 

Duration 안에는 second = 키워드를 명시적으로 적어줘야한다.

• lease_duration = 1초 + AUTOMATIC → 퍼블리셔가 1초 이내에 메시지를 안 보내면, 죽은 것으로 판단하는 정책

=>Duration 안에는 second = 키워드를 명시적으로 적어줘야한다.

내부적으로 세팅된 Qos 설정 및 권장 사항

=> ROS2 Service 의 경우 특별한 케이스 외에는 기본 Qos(Default)를 사용

유저 QoS 세팅 방법

 

주의할 점은 Publisher와 Subscriber 또는 Server와 Client 간의 Qos 통신 정책이 일치해야 원활한 통신이 된다.
-> 예외의 경우도 있기는 하지만 많이 사용 안하고 특수 목적에 따라 사용한다.

 

그것에 대한 내용은 아래 ROS2 공식 문서를 참고하기를 바란다.

 

https://docs.ros.org/en/rolling/Concepts/Intermediate/About-Quality-of-Service-Settings.html

Quality of Service settings — ROS 2 Documentation: Rolling documentation