📝ROS2 topic/service/action

topic vs. service vs. action

• Basic - Interfaces

• Topics vs Services vs Actions

• Topic은 발행/구독(비동기적 스트리밍)에 적합하고, 상태·센서·지속적 명령에 주로 사용

• Service는 요청-응답(단발성 RPC)에 적합

• Action은 장시간 실행되는 작업(목표/피드백/결과/취소)이 필요할 때 쓰는 상위 추상으로, 내부적으로는 토픽+서비스 패턴을 사용

핵심 비교 (한눈에)

항목	Topic	Service	Action
통신방식	publish/subscribe (비동기, 스트리밍)	request/response (RPC)	goal/feedback/result (상태ful, 취소 가능)
사용사례	센서 데이터, 상태 브로드캐스트, 지속 명령 (예: cmd_vel)	파라미터 조회, 단발 명령(예: 초기화), 간단한 쿼리	내비게이션 목표, 그립 동작(장시간), 운동 계획 실행
피드백	없음(별도 토픽으로 구현 가능)	응답만	주기적 피드백 제공 가능
취소/중단	별도 메커니즘 필요	없음(요청 단위라 중단 개념 없음)	표준 취소/중단 제공
다중구독/다중발행	자연스럽게 지원(1:N, N:1)	클라이언트-서버(1:1)	클라이언트-서버(여러 클라이언트 가능)
QoS 제어	상세 QoS 설정 가능 (reliable, transient_local 등)	QoS 사용 가능하나 일반적은 낮음	내부적으로 토픽/서비스 사용 → QoS 영향 받음
구현 복잡도	낮음	낮음	약간 높음 (action 인터페이스 필요)

Guide

1. 지속적인 스트리밍(실시간 센서, 주기적 상태, 로우레벨 제어) → Topic. 예: LiDAR, 카메라, IMU, 로봇의 현재 조인트 상태, cmd_vel 같은 주기적 velocity 명령. 이유: 저지연, 다수 구독자/발행자 OK, QoS로 내구성/신뢰성 조정 가능.

2. 단발성 요청과 응답(즉각적인 처리) → Service. 예: 맵 초기화, 로그 다운로드, 파라미터 조회/설정, 간단한 계산 요청. 이유: 요청-응답 형태가 자연스럽고 구현이 간단. 동기 호출이 기본이라 로직 단순화 가능.

3. 목표 기반의 장시간 작업(중간 피드백 필요, 취소 가능) → Action. 예: 이동 로봇의 목표 지점, 팔의 복잡한 포즈 트래젝토리, 그립/조작 시퀀스. 이유: 목표 전송 → 주기적 피드백(진행률) → 결과/상태/취소 흐름을 표준화함.

장단점

Topic 장단점

• 장점
  • 단순하고 경량. 낮은 오버헤드.
  • 다중 수신자/발행자에 적합.
  • QoS로 전송 보장/일시적 구독자 복구(transient_local) 등 제어 가능.
• 단점
  • 요청-응답, 피드백, 취소 같은 패턴을 직접 구현해야 함(복잡해질 수 있음).
  • 상태 추적(logic 상태 기계)이 필요하면 토픽만으로는 관리가 번거로움.
• Understanding topics

Service 장단점

• 장점
  • 동기적(또는 비동기 Future)으로 간단한 RPC 패턴 구현 쉬움.
  • 호출과 응답이 명확해 오류 처리/타임아웃 관리가 편함.
• 단점
  • 긴 시간 작업에는 부적합(블로킹 위험, 클라이언트 구현 복잡).
  • 피드백 또는 중간 상태 전송 표준화 없음.
• Understanding servies

Action 장단점

• 장점
  • 장시간 작업에 적합: 목표, 주기적 피드백, 최종 결과, 취소를 표준화.
  • 클라이언트가 상태(accepted, executing, canceled, succeeded 등)를 관찰 가능.
  • 내장된 취소 메커니즘과 결과 코드로 안정적인 제어 흐름 제공.
• 단점
  • 토픽/서비스보다 구현 복잡도 ↑ (액션 정의 파일, 서버/클라이언트 보일러플레이트).
  • 오버헤드가 있어서 단순/초저지연 메시지에는 불필요할 수 있음.
  • QoS에 주의: 액션 내부 통신의 QoS 설정 필요하면 복잡해짐.
• Understanding actions

기술적 고려사항 (성능·신뢰성·QoS 등)

• 지연(latency): 토픽은 설계에 따라 매우 낮은 지연을 줄 수 있음. 서비스/액션은 RPC 흐름/상태 관리 때문에 토픽보다 약간의 오버헤드 존재.
• QoS: ROS2에서는 토픽·서비스·액션 모두 QoS를 설정 가능(특히 토픽). 센서 같은 중요한 데이터는 reliable 또는 transient_local 고려.
• 스케일링: 다수의 구독자가 필요하면 토픽이 자연스럽다. 서비스는 1:1 패턴이기 때문에 동시 요청 처리를 고려해야 함(서버에서 스레드/큐 처리).
• 에러 처리: 액션은 결과 상태로 실패/취소/타임아웃을 표준화해서 보낼 수 있어 에러 처리 구조화에 유리.

실무 디자인 패턴 & 권장

• 센서 → 토픽
• 로우레벨 제어 명령(주기적) → 토픽 (cmd_vel, joint_commands 등)
• 단발성 명령(설정, 질의) → 서비스
• 목표기반 장시간 작업 → 액션
• 혼합 사용 권장: 예) 로컬 컨트롤러는 토픽으로 주기적 제어, 상위 제어기는 액션으로 목표 전송(진행 피드백 수신), 필요시 서비스로 설정/쿼리.
• 상태 전파: 시스템 상태는 토픽으로 브로드캐스트 (예: /robot/state) → 여러 모듈이 구독.

Example

• Topic: 퍼블리셔 geometry_msgs/Twist 로 10Hz로 속도 발행 → 로컬 컨트롤러가 구독해 모터 제어.
• Service: /reset_odometry 호출 → 서버가 즉시 odom reset 후 성공 응답 반환.
• Action: /navigate_to goal(목표 좌표) 전송 → 주기적 피드백(거리/진행률) 수신 → 도중에 취소 가능 → 완료 시 result(성공/실패 코드).

시스템 구성시 생각해볼 질문들

1. 작업이 지속적/스트리밍인가? → Topic
2. 작업이 단발성 요청-응답인가? → Service
3. 작업이 목표 기반/장시간/피드백·취소 필요인가? → Action

대부분 시스템은 토픽 + 액션 + 서비스를 혼합해서 씁니다. 토픽은 데이터 파이프라인(센서/상태), 서비스는 구성·설정·쿼리, 액션은 복잡한 목표 실행 흐름을 맡기면 아키텍처가 깔끔해집니다.

---

1. Topic (토픽) — 게시판 / 방송 🎙️
   • 누군가가 내용을 계속 써 붙이는 게시판(또는 라디오 방송)이에요.
   • 어떻게 쓰나요?: 한 사람이 게시판에 글(메시지)을 붙이면, 여러 사람이 와서 그 글을 읽을 수 있어요. 글을 붙이는 사람은 누가 읽는지 신경쓰지 않아요.
   • 언제 쓰면 좋을까?: 카메라가 매번 사진을 보내거나(예: 매초 한 장), 센서가 계속 값(속도, 온도)을 보내야 할 때.
   • 예시
     • 로봇 카메라가 계속 사진을 올리는 곳: /camera/image
     • 바퀴 속도를 계속 알려주는 곳: /cmd_vel
2. Service (서비스) — 전화로 물어보기 ☎️
   • 전화로 질문하고 바로 답을 받는 것과 같아요.
   • 어떻게 쓰나요?: 내가 “연필 있어?”라고 물어보면, 상대가 “응, 여기 있어”라고 바로 대답해요. 요청(request) → 응답(response) 한 번에 끝나요.
   • 언제 쓰면 좋을까?: 즉시 답을 받아야 할 때. 예: “지금 위치 알려줘”, “맵 리셋해줄래?”
   • 예시
     • /reset_odometry 라는 서비스에 요청하면 “리셋 완료”라고 바로 응답.
3. Action (액션) — 심부름 시키기 + 중간 소식 받기 🧑‍✈️📣
   • 친구에게 긴 심부름을 시키는 것과 비슷해요. “부엌에서 주스 가져와”라고 시키면, 친구는 가다가 중간에 전화로 “지금 부엌에 있어요”, “거의 다 왔어요” 같은 소식을 알려줄 수 있어요. 그리고 끝나면 “끝났어요”라고 말해요. 필요하면 심부름을 그만두라고(취소) 할 수도 있어요.
   • 어떻게 쓰나요?: 목표(goal)를 주면 서버가 그걸 수행하면서 중간 피드백(feedback) 을 알려주고, 완료되면 결과(result) 를 보내요.
   • 언제 쓰면 좋을까?: 시간이 걸리는 일이나 중간 진행 상황을 알고 싶을 때. 예: “지금 이 위치까지 이동해”, “그 물건을 집어 들어”
   • 예시
     • /arm/move_to_pose 액션: 목표 위치로 가는 동안 “지금 여기까지 왔어요(피드백)”, 끝나면 “성공/실패(결과)”.

방식	비유	언제 쓰나
Topic	게시판/방송	계속 흘러오는 데이터(카메라, 센서)
Service	전화	한 번 물어보고 바로 답받을 때
Action	긴 심부름 + 중간보고	오래 걸리는 작업, 진행상황/취소 필요할 때

1. 카메라가 매초 사진을 올려요 → Topic (/camera/image)
2. 로봇에게 “맵 다시 초기화해”라고 바로 요청 → Service (/reset_map)
3. 로봇에게 “저 상자 가져와”라고 시키면 → Action (/pick_box)
   • 로봇: “출발했어요(피드백)”, “집어 들었어요(피드백)”, “완료(결과)”

QoS 참고

한 줄 요약

QoS는 발행자(publisher)와 구독자(subscriber)가 “어떻게” 메시지를 주고받을지 약속하는 설정이에요. (신뢰성, 보관, 큐 크기, 만료시간 등) 이 설정으로 네트워크 상태 · 지연 · 대역폭 · late-joiner(나중에 구독을 시작한 노드) 처리를 조절할 수 있어요.

• 토픽을 편지로 보면, QoS는 “편지를 어떻게 보낼까/보존할까”에 대한 약속이에요.
  • reliable = 등기우편: 반드시 배달하려 시도(재전송).
  • best_effort = 엽서/통상우편: 한 번만 던지고 끝(빠르지만 분실될 수 있음).
  • transient_local = 우체통에 보관: 나중에 와도 우체통에서 편지를 찾아볼 수 있음(라칭과 유사).

주요 QoS 옵션

1. Reliability(신뢰성)
   • RELIABLE : 메시지 손실을 줄이려 재전송함(중요한 명령/결과에 사용).
   • BEST_EFFORT : 재전송 안 함(센서 스트리밍 같이 빠른 갱신이 중요하고 일부 손실 허용될 때).
2. Durability(내구성)
   • VOLATILE : 구독자가 없으면 메시지 버려짐(기본).
   • TRANSIENT_LOCAL : 최근 메시지를 보관해서 새로 구독해도 마지막 메시지 받을 수 있음 (ROS1의 latching과 유사).
3. History & Depth(히스토리/큐 크기)
   • KEEP_LAST + depth = N: 최신 N개만 보관.
   • KEEP_ALL: 가능한 모든 메시지를 보관(메모리/리소스 주의).
4. Deadline
   • 발행자가 정한 주기(예: 0.1s) 안에 메시지를 보내야 하는지 약속. 기간 넘기면 알림/경고 가능.
5. Liveliness(생존성 확인)
   • 발행자가 살아있는지 확인하는 설정. (자동/수동 방식 등)
6. Lifespan(수명)
   • 메시지가 “유효한 시간”을 가짐 — 시간이 지나면 폐기. (예: 이벤트성 알림)

실무 예시 — 어떤 토픽에 어떤 설정을 쓸까

(vision, arm, hand 기준)

• Camera 이미지 (/camera/image_raw)
  • 권장: BEST_EFFORT, KEEP_LAST depth 5
  • 이유: 이미지는 매우 자주 오고, 오래된 이미지는 쓸모가 없으며 약간의 프레임 손실은 괜찮음. 대역폭 절약.
• Detection 결과 (/vision/detections)
  • 권장: RELIABLE, KEEP_LAST depth 5, 또는 TRANSIENT_LOCAL(late-joiner에게 최신 결과 제공)
  • 이유: 검출 결과는 놓치면 안되는 경우가 있어 신뢰성 필요. 다만 빈도는 낮음.
• Arm/Hand 명령 (/arm/move_to_pose 액션 내부 토픽 또는 /allegro_hand_position_controller_r/commands)
  • 권장: RELIABLE, KEEP_LAST depth 1~10
  • 이유: 명령 손실은 위험하므로 재전송 보장 필요.
• Joint state (/joint_states)
  • 권장: RELIABLE, KEEP_LAST depth 10
  • 이유: 상태 정보를 정확히 받아야 되는 경우가 많음.
• 진단/로그 토픽
  • 권장: BEST_EFFORT 또는 RELIABLE (use-case에 따라)

QoS가 실제로 바꿔놓는 것 (결과)

• BEST_EFFORT → 더 낮은 지연, 패킷 손실 허용. 네트워크가 혼잡할 때 메시지 빠짐.
• RELIABLE → 재전송으로 신뢰성 ↑, 하지만 네트워크/지연·오버헤드 ↑.
• TRANSIENT_LOCAL → 새로 구독해도 최근 메시지 확보 가능(예: 상태/설정).
• KEEP_ALL → 메모리·디스크 부담 커질 수 있음(주의).

간단한 코드 예 (rclpy)

from rclpy.qos import QoSProfile, QoSReliabilityPolicy, QoSHistoryPolicy

# 예: 카메라 토픽용 QoS
camera_qos = QoSProfile(
    reliability=QoSReliabilityPolicy.BEST_EFFORT,
    history=QoSHistoryPolicy.KEEP_LAST,
    depth=5
)

# 예: 중요한 명령 토픽용 QoS
cmd_qos = QoSProfile(
    reliability=QoSReliabilityPolicy.RELIABLE,
    history=QoSHistoryPolicy.KEEP_LAST,
    depth=10
)

그리고 퍼블리셔/서브스크라이버 생성 시 이 QoSProfile을 넘겨주면 됩니다.

언제 QoS를 바꿔야 할까? 체크리스트

• 네트워크가 불안정하고 중요한 메시지면 → RELIABLE.
• 메시지가 실시간·자주 갱신되고 오래된 메시지는 필요없다면 → BEST_EFFORT.
• 어떤 토픽은 나중에 시작하는 노드가 최근 상태를 꼭 받아야 한다면 → TRANSIENT_LOCAL.
• 메모리/대역폭 한계가 걱정되면 → history/depth를 낮춰라.

간단 요약 (표)

목적	권장 QoS 설정
카메라/이미지 스트리밍	BEST_EFFORT, KEEP_LAST, depth=3~10
센서/상태 (중요)	RELIABLE, KEEP_LAST, depth=5~20
제어 명령(중요)	RELIABLE, KEEP_LAST, depth=1~10
초기 상태 전달(나중 가입자 필요)	TRANSIENT_LOCAL