이 책은 ROS 2의 기본 개념과 설치부터 CLI, Python 중심의 Client Library, 중급 개발 기법, TF2·상태추정·SLAM·Nav2·MoveIt2, 그리고 DDS/RMW·성능·테스트·배포·AI Agent까지 한 흐름으로 학습하도록 구성한다. 명령과 예제 코드는 실행 방법뿐 아니라 각 옵션과 API가 맡는 역할까지 함께 설명한다.

이 책을 어떻게 사용할 것인가#

학습 순서는 일곱 단계다. ① ROS 2가 무엇인지 개념을 잡는다. ② Jazzy를 설치하고 CLI로 실행 중 시스템을 관찰한다. ③ Python의 rclpy로 package와 Node를 직접 작성한다. ④ ROS 2 시스템을 재사용 가능하게 구성하는 중급 개발기법을 익힌다. ⑤ 좌표·모델·상태추정과 시뮬레이션으로 로봇 시스템을 구성한다. ⑥ SLAM·Nav2·MoveIt2·비전으로 자율로봇 기능을 통합한다. ⑦ DDS/RMW·성능·테스트·배포·AI Agent까지 전문가 수준으로 확장한다.

독학 규칙 명령을 복사해 실행하는 것에서 끝내지 않는다. 어떤 Node가 생겼는가, 어떤 Topic이 흐르는가, frame은 무엇인가, 누가 상태를 가지고 있는가, 실패하면 어느 계층부터 볼 것인가를 매번 답한다.

명령과 예제 코드를 읽는 최소 규칙#

이 책은 Python의 기본 문법 자체를 반복 설명하지 않는다. 다만 Python을 알아도 바로 뜻을 알기 어려운 ROS 2 API, Linux shell 문법, 빌드 도구, 네트워크·시간·좌표계 개념은 첫 등장 때 충분히 설명하고, 뒤의 관련 실습과 단원 정리에서 두세 차례 다른 예시로 다시 풀어 쓴다. 같은 용어가 다시 등장하면 그 실습에서 무엇을 의미하고 왜 필요한지 확인한다.

~ 현재 Linux 사용자의 홈 디렉터리. 예: ~/ros2_ws

$NAME shell 환경변수의 값을 참조. 예: $ROS_DOMAIN_ID

\ shell 명령을 다음 줄까지 이어 쓰는 line continuation

| 앞 명령의 표준출력을 뒤 명령의 표준입력으로 넘기는 pipe

# shell/Python에서 주석. 같은 기호라도 실행 환경은 별개

package / executable ros2 run에서 앞은 패키지, 뒤는 설치된 실행 진입점

name:=value ros2 launch argument 전달 형식

--ros-args 이 뒤부터 ROS 전용 CLI 인자라는 경계

목차#

Part 0. About ROS 2 — 공식 입문 개념을 한 번에 이해하기

0장. About ROS — ROS 2가 무엇이며 무엇을 제공하는가

Part I. Installation — ROS 2 Jazzy 설치와 환경 준비

1장. Installation 선택지와 이 교재의 기준 환경

2장. Ubuntu 24.04에 ROS 2 Jazzy 설치

Part II. Tutorials — Beginner: CLI tools

3장. Configuring environment — shell과 ROS 환경

4장. Using turtlesim, ros2, and rqt

5장. Understanding nodes

6장. Understanding topics

7장. Understanding services

8장. Understanding parameters

9장. Understanding actions

10장. rqt_console로 로그 보기

11장. Launching multiple nodes

12장. rosbag2로 데이터 기록·재생

Part III. Tutorials — Beginner: Client libraries

13장. colcon으로 ROS 2 package 빌드하기

14장. Workspace와 Package 만들기

15장. Publisher와 Subscriber — Python

16장. Service와 Client — Python

17장. Custom msg·srv·action Interface

18장. Python Parameter·ros2doctor

Part III-A. Intermediate ROS 2 개발

Part IV. Concepts & Development Deep Dive

19장. ROS 2를 분산 시스템으로 이해하기

20장. Package 구조·빌드 체계·개발환경 진단

21장. Node·Topic·Message·QoS·Custom Interface

22장. Service·Action·Parameter·Launch·Lifecycle

23장. Topic·Service·Action·Launch·Remapping을 직접 구현하기

Part V. 로봇을 움직이며 배우기

24장. Jazzy 시뮬레이터와 이동로봇을 ROS Graph로 읽기

25장. 실습 프로젝트 — LaserScan + FSM 장애물 회피

Part VI. 공간·로봇 모델·상태추정

26장. TF2와 SE(2)/SE(3): 좌표와 시간을 함께 다루기

27장. URDF·Xacro·robot_state_publisher·RViz2

28장. Gazebo·ros2_control·시뮬레이션과 실제 하드웨어의 경계

29장. Twist·차동구동·Odometry

30장. 센서·공분산·Kalman Filter·robot_localization

31장. 실습 프로젝트 — TF2 장애물 검출기와 RViz Marker

32장. 실습 프로젝트 — VFF 반응형 회피·rosbag2·테스트

Part VII. SLAM과 Nav2

33장. Occupancy Grid·Scan Matching·Pose Graph·Loop Closure

34장. TurtleBot3 Cartographer와 지도 작성

35장. AMCL과 지도 기반 Localization

36장. Nav2 아키텍처·Costmap·Planner·Controller

37장. Behavior Tree·Lifecycle·Bringup·튜닝

38장. Nav2 Python API와 실전 시나리오

39장. 실습 프로젝트 — Behavior Tree를 Nav2 행동으로 연결하기

40장. 실습 프로젝트 — Nav2 목표 이동·피드백·취소·순찰

41장. 실습 프로젝트 — TurtleBot3 Cartographer SLAM에서 Nav2까지

Part VIII. 로봇팔·비전 통합

42장. MoveIt2·Planning Scene·E0509

43장. Hand-Eye·3D 비전·Pick 파이프라인

Part IX. 재사용 가능한 ROS 2 시스템

44장. 실습 프로젝트 — Custom Interface + Lifecycle Node

45장. 남이 실행할 수 있는 ROS 2 패키지로 마감하기

Part X. 전문가 ROS 2 엔지니어링

46장. Executor·Callback Group·시간·동시성

47장. rosbag2·로그·네트워크·WSL2·성능 진단

48장. 통합 설계 원칙과 종합 실습

49장. 실습 프로젝트 — Executor·Callback Group·QoS 실패 실험

50장. DDS/RMW·Discovery·QoS 요청/제공 모델

51장. Composition·Intra-process·프로세스 경계 설계

52장. Tracing·Latency·Throughput·메모리·성능 측정

53장. Multi-machine·Multi-robot·Clock·Namespace·Network

54장. Plugin Architecture — Nav2·ros2_control을 확장하는 방법

55장. 테스트·CI·버전·배포·품질 선언

Part XI. 전문가 사례연구

사례연구 1. 하나의 ROS 2 패키지로 Topic·Service·Action·Parameter·Launch를 모두 연결하기

사례연구 2. TF2·URDF를 이용해 센서 좌표를 로봇 좌표로 바꾸기

사례연구 3. 차동구동 Odometry를 계산하고 보정하기

사례연구 4. rosbag 하나로 SLAM 문제를 반복 재현하기

사례연구 5. Nav2가 “안 간다”를 15분 안에 분해하는 절차

사례연구 6. 비전 기반 Pick을 단계별로 검증하기

사례연구 7. 로봇 프로젝트를 “데모”가 아니라 검증 가능한 시스템으로 마무리하기

Part XII. 로보틱스를 위한 AI·LLM·RAG·Agent

56장. 로봇 개발자가 알아야 할 LLM 핵심 개념

57장. 프롬프트 엔지니어링: 자연어를 안정적인 인터페이스로 만들기

58장. LLM API·Structured Output·Tool Calling

59장. Open Source·Local LLM과 Ollama

60장. RAG 기초: 로봇 매뉴얼을 검색 가능한 지식으로 만들기

61장. Advanced RAG: 검색 품질을 단계적으로 높이기

62장. LangChain·LlamaIndex를 구성요소로 이해하기

63장. Autonomous Agent와 Tool-using Robotics

64장. AI 페어 프로그래밍을 ROS 2 개발에 제대로 사용하기

65장. 통합 프로젝트 — 자연어 명령을 검증된 ROS 2 Action으로 연결하기

부록 A. Ubuntu 24.04 + ROS 2 Jazzy 설치와 핵심 CLI

부록 B. 최소 패키지 템플릿

부록 C. 로봇공학 수식 치트시트

부록 D. 확인문제 해설

부록 E. 공식 참고자료

부록 F. 실습 코드 구조와 자료

부록 G. 기술 참고자료

부록 H. AI·LLM·RAG 실무 치트시트

부록 I. ROS 2 Jazzy 전문 레퍼런스

I.1 Node 실행 인자·Remapping·Parameter·Logging 운용

I.2 QoS 전체 모델과 rosbag2 QoS Override

I.3 관찰가능성: Logging·Topic Statistics·ros2 doctor

I.4 SROS2와 DDS Security: 로봇 네트워크를 신뢰경계로 설계하기

I.5 TF2 심화: 시간·Stamped Data·MessageFilter

I.6 Domain ID·RMW·Discovery Server·Multi-machine 운영

I.7 ROS 2 내부 인터페이스와 Zero-copy 성능 최적화

Part 0. About ROS 2 — 공식 입문 개념을 한 번에 이해하기#

0장. About ROS — ROS 2가 무엇이며 무엇을 제공하는가#

이 장에서는 ROS 2의 역할과 핵심 구성요소를 먼저 정리한다. 이후 설치와 실습에서 반복해서 등장하는 Node, Graph, Interface, Parameter, Client Library, Discovery를 여기서 기준 개념으로 잡는다.

약어 표기 ROS: Robot Operating System(로봇 운영체제) · ROS 2: Robot Operating System 2(로봇 운영체제 2)

0.1 ROS는 전통적인 운영체제가 아니다#

ROS(Robot Operating System)는 로봇 애플리케이션을 만들고 배포하고 실행하고 유지보수하기 위한 오픈소스 생태계다. 이름에는 Operating System이 들어가지만 Linux나 Windows처럼 CPU·메모리·파일시스템을 직접 관리하는 커널형 운영체제가 아니다. 여러 로봇 프로그램이 서로 통신하고 재사용 가능한 소프트웨어로 구성되도록 framework, tools, libraries, 표준 interface를 제공한다.

실제 로봇에서는 카메라 driver, LiDAR driver, localization, perception, planner, controller, UI가 서로 다른 프로세스·언어·컴퓨터에서 실행될 수 있다. ROS 2는 이들을 하나의 ROS Graph 안에서 발견하고 연결하며, 데이터를 주고받는 공통 규칙을 제공한다.

0.2 ROS 생태계의 세 축: Framework, Tools, Capabilities#

Framework는 로봇 기능 자체가 아니라 기능들을 연결하는 배관(plumbing)이다. Tools는 동작을 관찰하고 구성한다. Capabilities는 그 위에서 실제 localization, navigation, manipulation 같은 로봇 기능을 제공한다.

0.3 Node는 ROS Graph의 기본 실행 단위다#

Node는 ROS 2 Graph에 참여하는 논리적 계산 단위이며 일반적으로 한 가지 책임을 맡는다. 하나의 Node는 동시에 Publisher, Subscriber, Service Server/Client, Action Server/Client, Parameter를 가질 수 있다. Node는 같은 프로세스 안에 있을 수도 있고 다른 프로세스·다른 컴퓨터에 있을 수도 있다.

Node와 executable은 다르다 executable은 운영체제가 실행하는 프로그램 파일이고 Node는 ROS Graph의 논리적 참가자다. 하나의 executable이 여러 Node를 포함할 수 있다.

0.4 Interfaces: Topic, Service, Action#

Node는 실행되는 프로그램의 이름과 같지 않다. 하나의 프로세스에서 여러 Node를 실행할 수도 있으므로 ros2 node list는 ROS Graph의 논리 노드를 보여준다.

Topic은 지속적인 데이터 스트림에 적합하다. Service는 요청과 응답이 한 쌍이며 짧은 작업에 적합하다. Action은 장시간 작업을 goal·feedback·result로 다루며 cancel을 지원한다. 각 interface는 .msg, .srv, .action 정의로 데이터 구조를 기술하고 ROS가 Python에서 사용할 수 있는 메시지 타입 코드를 생성한다.

0.5 Message·Service·Action 정의 파일#

# .msg
float32 temperature
string frame_name

# .srv
string mode
---
bool accepted
string message

# .action
geometry_msgs/PoseStamped goal
---
bool success
---
float32 progress

msg는 field 목록, srv는 요청과 응답을 ---로 구분하고, action은 goal·result·feedback 세 부분을 두 개의 ---로 나눈다. field에는 정수·실수·문자열·배열·다른 ROS message 타입을 사용할 수 있다.

0.6 Parameter는 Node별 설정값이다#

Parameter는 각 Node가 보유하는 런타임 설정값이다. Topic처럼 계속 흘러가는 데이터가 아니라 해당 Node의 동작을 조절하는 설정에 가깝다. 예를 들어 카메라 exposure, controller gain, 최대속도, map frame 이름 등을 parameter로 둘 수 있다.

0.7 Client Library: Python의 rclpy#

ROS 2의 Node는 통신에 필요한 API(Application Programming Interface, 응용 프로그램 인터페이스)를 제공하는 Client Library를 이용해 작성한다. 이 책의 Python Client Library는 rclpy다. rclpy는 Node 생성, Publisher와 Subscription 등록, Service·Action 호출, Parameter 관리, Executor 실행을 제공한다. ROS Graph의 Topic·Service·Action은 특정 언어에 묶이지 않으므로, 먼저 Python 예제로 동작을 익힌다.

0.8 Discovery와 분산 Graph#

ROS 2 Node는 중앙 master 하나에 등록하는 방식이 아니라 middleware의 discovery를 통해 서로를 찾는다. 따라서 같은 네트워크·도메인에서 실행되는 Node들이 자동으로 Graph를 구성할 수 있다. 이후 QoS와 DDS/RMW를 배우면 이 discovery와 실제 전송 계층을 더 깊게 다룬다.

0.9 ROS 2 Jazzy Jalisco#

ROS 2는 배포판(distribution) 단위로 릴리스된다. Jazzy Jalisco는 Ubuntu 24.04(Noble)를 주요 Ubuntu 플랫폼으로 사용하는 장기지원 계열의 ROS 2 배포판이다. package 이름에는 ros-jazzy- 접두가 붙고 설치 위치는 일반적으로 /opt/ros/jazzy다.

Part I. Installation — ROS 2 Jazzy 설치와 환경 준비#

1장. Installation 선택지와 이 교재의 기준 환경#

교재 기준 Windows 11 + WSL2(Windows Subsystem for Linux 2, Windows용 Linux 하위 시스템 2) Ubuntu 24.04 또는 Ubuntu 24.04 네이티브 환경에서 ROS 2(Robot Operating System 2, 로봇 운영체제 2) Jazzy Desktop deb 패키지를 설치하는 흐름을 주 기준으로 한다.

1.1 설치 방식 선택#

이 교재에서는 일반 사용·개발 목적이므로 Ubuntu deb package를 선택한다. source build는 ROS 2 core 자체를 수정하거나 바이너리가 없는 플랫폼을 지원해야 할 때 검토한다.

1.2 Desktop과 ROS(Robot Operating System, 로봇 운영체제)-Base#

ros-jazzy-desktop은 core 통신 기능뿐 아니라 RViz, demo, tutorial 등 GUI와 학습도구를 포함한다. ros-jazzy-ros-base는 통신 라이브러리·message·CLI 중심의 최소 설치로 GUI 도구가 없다. 이 교재는 tutorial과 RViz를 사용하므로 Desktop을 권장한다.

1.3 Ubuntu 24.04(Noble) 확인#

lsb_release -a
uname -m

lsb_release는 Ubuntu 배포판 정보를, uname -m은 CPU(Central Processing Unit, 중앙처리장치) architecture를 확인한다. Jazzy의 Ubuntu 패키지는 Noble 24.04를 기준으로 제공된다.

1.4 Ubuntu 실행 환경 준비하기#

Ubuntu는 PC(Personal Computer, 개인용 컴퓨터)에 직접 설치하거나 Windows 안의 WSL2·가상머신에서 실행할 수 있다. 직접 설치하면 운영체제가 장치에 바로 접근하고, 듀얼부팅은 재부팅할 때 Windows와 Ubuntu 중 하나를 선택한다. 가상머신은 Windows를 실행한 채 가상의 PC에서 Ubuntu를 구동한다. WSL2는 Windows 안에서 Linux 개발환경을 제공한다. 터미널·패키지 실습은 어느 방식으로도 시작할 수 있으며, GUI(Graphical User Interface, 그래픽 사용자 인터페이스)와 외부 장치 연결은 선택한 환경에서 따로 확인한다.

PC에 직접 설치할 때는 Ubuntu 24.04 Desktop의 CPU에 맞는 ISO 이미지를 준비한다. ISO는 설치 디스크 전체를 담은 파일이다. 일반적인 Intel·AMD 64비트 PC는 amd64 이미지를 사용한다. Rufus에서 설치용 USB(Universal Serial Bus, 범용 직렬 버스)와 ISO를 선택하고 UEFI(Unified Extensible Firmware Interface, 통합 확장 펌웨어 인터페이스) PC에 맞춰 GPT 파티션 방식을 지정한다. UEFI는 PC의 부팅 펌웨어 규격이며, GPT는 디스크 파티션 정보를 저장하는 방식이다. USB 기록이 완료되면 PC의 부팅 메뉴에서 해당 USB의 UEFI 항목을 선택한다.

Windows와 함께 설치하려면 먼저 기존 데이터를 백업하고 Windows 디스크 관리에서 볼륨을 축소해 할당되지 않은 공간을 확보한다. Ubuntu 설치기의 Install Ubuntu alongside Windows Boot Manager는 Windows와 함께 설치하는 선택지다. Erase disk and install Ubuntu는 선택한 디스크를 지우는 선택지이므로 듀얼부팅 단계에서 서로 구분해야 한다. 설치 전에 최종 디스크 구성 화면에서 Windows 파티션과 Ubuntu에 배정할 공간을 확인한다.

BitLocker 또는 장치 암호화가 감지되면 Windows에서 복구 키와 암호화 상태를 확인한 뒤 설치기가 요구하는 절차를 따른다. 부팅 순서 설정은 PC별로 메뉴와 키가 다르다. 설치가 끝나면 USB를 제거하고 GRUB 메뉴에서 Ubuntu와 Windows가 각각 부팅되는지 확인한다. GRUB은 부팅할 운영체제를 고르는 부트로더다.

가상머신으로 실습할 때는 VirtualBox에 새 Linux 가상머신을 만들고 Ubuntu 24.04 ISO를 가상 광학 드라이브에 연결해 설치한다. 가상머신 안의 디스크는 PC의 실제 Windows 파티션과 구분된다. Ubuntu 화면에서 터미널을 열고 아래 명령으로 설치된 운영체제를 확인한 뒤 ROS 2 설치로 진행한다.

cat /etc/os-release
python3 --version

cat은 파일 내용을 터미널에 출력한다. /etc/os-release의 VERSION_ID가 24.04인지 확인한다. python3 --version은 실행 가능한 Python 3의 버전을 보여준다. 가상머신·WSL2·직접 설치 모두 ROS 2 Jazzy를 설치하는 Linux 쪽에서 이 명령을 실행한다.

2장. Ubuntu 24.04에 ROS 2 Jazzy 설치#

약어 표기 ROS 2: Robot Operating System 2(로봇 운영체제 2)

2.1 UTF-8 Locale 확인#

locale
sudo apt update && sudo apt install -y locales
sudo locale-gen en_US en_US.UTF-8
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
export LANG=en_US.UTF-8
locale

ROS(Robot Operating System, 로봇 운영체제) 도구와 Python package가 파일명·로그 문자열을 일관되게 처리하도록 UTF-8 locale을 사용한다. export는 현재 shell과 자식 프로세스가 볼 환경변수를 설정한다.

2.2 Universe repository 활성화#

sudo apt install -y software-properties-common
sudo add-apt-repository universe

Ubuntu Universe repository에는 ROS dependency로 사용되는 여러 package가 포함된다. add-apt-repository는 apt source 구성을 관리하는 명령이다.

2.3 ROS 2 apt source 등록#

sudo apt update && sudo apt install -y curl
export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F'"' '{print $4}')
curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb"
sudo dpkg -i /tmp/ros2-apt-source.deb

ros2-apt-source package는 ROS package repository 주소와 서명 key 구성을 설치한다. curl은 파일을 내려받고 dpkg -i는 .deb 파일을 설치한다. 명령이 길어 보이지만 목적은 현재 Ubuntu codename에 맞는 ROS repository 설정 package를 내려받아 설치하는 것이다.

2.4 개발 도구와 ROS 2 Desktop 설치#

sudo apt update
sudo apt upgrade
sudo apt install -y ros-dev-tools
sudo apt install -y ros-jazzy-desktop

ros-dev-tools에는 colcon, rosdep 및 개발에 자주 필요한 도구 묶음이 포함된다. ros-jazzy-desktop은 ROS 2 Jazzy Desktop variant다.

2.5 환경 활성화#

source /opt/ros/jazzy/setup.bash
printenv ROS_DISTRO

source는 setup.bash를 현재 shell에 적용한다. ROS_DISTRO가 jazzy라면 해당 터미널은 Jazzy 환경을 보고 있다. 새 터미널을 열면 다시 source해야 한다.

2.6 설치 검증: Python talker와 listener#

# Terminal A
source /opt/ros/jazzy/setup.bash
ros2 run demo_nodes_py talker

# Terminal B
source /opt/ros/jazzy/setup.bash
ros2 run demo_nodes_py listener

Python talker가 std_msgs/msg/String 메시지를 Topic으로 발행(Publish)하고 Python listener가 구독(Subscribe)해 같은 번호의 메시지를 받으면 Node 실행·Discovery·Topic 전송이 정상 동작한다. 두 프로그램은 직접 서로를 호출하는 것이 아니라 이름과 메시지 타입이 일치하는 Topic을 통해 연결된다.

정상 결과: talker에는 Publishing: Hello World..., listener에는 I heard: Hello World...가 반복된다. 각 프로세스를 다른 터미널에서 실행하므로 터미널별로 ROS 환경을 source해야 한다.

2.7 자동 source 설정#

echo 'source /opt/ros/jazzy/setup.bash' >> ~/.bashrc
source ~/.bashrc

.bashrc는 Bash가 새 interactive shell을 열 때 읽는 설정 파일이다. >>는 기존 파일 끝에 한 줄을 추가한다. 같은 source 줄을 여러 번 중복 추가하지 않도록 주의한다.

2.8 제거·문제해결 원칙#

apt 설치 문제는 OS version, apt repository, package index, 네트워크와 mirror 상태를 먼저 확인한다. package가 일부 설치되지 않는다고 바로 build from source로 우회하지 말고 apt update와 repository 설정을 점검한다. 이 교재 뒤의 진단 장에서 ros2 doctor와 환경변수 점검을 더 자세히 다룬다.

Part II. Tutorials — Beginner: CLI tools#

3장. Configuring environment — shell과 ROS 환경#

약어 표기 ROS: Robot Operating System(로봇 운영체제)

3.1 setup.bash의 역할#

ROS package를 설치해도 shell의 PATH·PYTHONPATH·AMENT_PREFIX_PATH 같은 검색경로가 자동으로 바뀌지는 않는다. setup.bash는 현재 shell이 /opt/ros/jazzy 아래 executable, Python module, package resource를 찾도록 환경변수를 추가한다.

source /opt/ros/jazzy/setup.bash
printenv | grep -i ROS
which ros2

which ros2는 shell이 실제로 실행할 ros2 CLI(Command-Line Interface, 명령줄 인터페이스) 위치를 보여준다. 여러 ROS 배포판이나 workspace를 source했을 때 어떤 환경을 보고 있는지 확인하는 기본 진단이다.

3.2 환경변수와 ROS_DOMAIN_ID#

echo $ROS_DISTRO
echo $ROS_DOMAIN_ID
export ROS_DOMAIN_ID=10

ROS_DOMAIN_ID는 discovery domain을 분리한다. 같은 네트워크에서도 domain ID가 다르면 기본적으로 서로 발견하지 않는다. 여러 교육생이 같은 LAN(Local Area Network, 근거리 통신망)에서 같은 Topic 이름을 사용할 때 충돌을 줄일 수 있다.

3.2.1 팀별 도메인과 localhost 범위 확인#

ROS_DOMAIN_ID를 설정하지 않으면 기본 도메인 0을 사용한다. 이 값은 같은 네트워크에서 서로 발견할 ROS 2(Robot Operating System 2, 로봇 운영체제 2) participant 그룹을 나누지만, 암호화나 접근 제어를 제공하는 보안 경계는 아니다. ROS_LOCALHOST_ONLY=1은 discovery와 통신 범위를 현재 PC(Personal Computer, 개인용 컴퓨터)로 제한한다. 두 환경변수는 이미 실행 중인 노드에 소급 적용되지 않으므로 값을 바꾼 뒤 관련 노드를 종료하고 새 터미널에서 다시 실행한다.

먼저 같은 LAN의 두 PC에서 두 변수를 해제한다. echo가 빈 줄이면 설정되지 않은 상태이며, ROS_DOMAIN_ID는 기본값 0으로 동작한다.

unset ROS_DOMAIN_ID ROS_LOCALHOST_ONLY
echo $ROS_DOMAIN_ID
echo $ROS_LOCALHOST_ONLY

송신 PC에서 talker를, 수신 PC에서 listener를 실행한다. 같은 기본 도메인과 호환되는 DDS(Data Distribution Service, 데이터 분산 서비스) 설정을 사용하면 다른 PC의 메시지를 받을 수 있다.

# 송신 PC
ros2 run demo_nodes_py talker

# 수신 PC
ros2 run demo_nodes_py listener

같은 공간에서 여러 팀이 실습할 때는 팀별로 도메인 값을 다르게 지정한다. 아래 명령은 각 팀의 모든 송신·수신 터미널에 동일하게 적용한다. 1팀이 10, 2팀이 20을 사용하면 같은 팀 안에서는 발견되지만 팀 사이에서는 노드와 토픽이 보이지 않는다.

# 1팀의 모든 ROS 2 터미널
export ROS_DOMAIN_ID=10

# 2팀의 모든 ROS 2 터미널
export ROS_DOMAIN_ID=20

한 PC 안에서만 통신하도록 제한하려면 송신·수신 터미널 모두에서 ROS_LOCALHOST_ONLY를 켠다. 같은 도메인을 쓰더라도 다른 PC의 listener는 메시지를 받지 못하고, 송신 PC에서 새로 실행한 listener만 메시지를 받는다. 실제 로봇과 제어 PC처럼 서로 다른 장치가 통신해야 하는 구성에서는 이 값을 해제해야 한다.

export ROS_LOCALHOST_ONLY=1
echo $ROS_LOCALHOST_ONLY

# 실습을 마친 뒤 원래 범위로 복귀
unset ROS_DOMAIN_ID ROS_LOCALHOST_ONLY

통신 결과를 확인할 때는 각 터미널에서 echo로 환경변수를 먼저 비교하고, ros2 node list와 ros2 topic list로 discovery 결과를 확인한다. 도메인 값이 같아도 방화벽, 멀티캐스트 차단, 서로 다른 RMW(ROS Middleware Interface, ROS 미들웨어 인터페이스) 구현의 설정 때문에 통신하지 못할 수 있으므로 ROS_DOMAIN_ID만 반복 변경하며 원인을 추정하지 않는다.

3.3 현재 경로와 파일 구조 읽기#

셸은 명령을 입력하고 프로그램을 실행하는 환경이다. 터미널마다 현재 작업 디렉터리가 하나씩 있으며, 상대 경로는 그 위치를 기준으로 해석된다. Python 코드가 올바르더라도 다른 폴더에서 실행하면 파일을 찾지 못할 수 있다. 명령을 실행하기 전에 pwd로 현재 위치를 확인하는 습관을 들인다.

pwd
ls
ls -a
ls -l
cd ~
mkdir -p ~/ros2_shell_practice/robot_basic
cd ~/ros2_shell_practice
touch robot_basic/hello_ros.py
ls -l robot_basic

같은 이름의 바깥 ROS package 폴더와 안쪽 Python package 폴더는 역할이 다르다. ~/ros2_ws/src/turtle_robot은 package.xml과 setup.py가 있는 ROS package 루트이고, 그 안의 turtle_robot은 Python 모듈을 담는 폴더다. Python package에 넣는 __init__.py는 이 폴더를 일반 Python package로 인식하게 한다. 이 실습의 ros2_shell_practice는 파일 실행을 연습하는 폴더이며, ROS package는 14장의 ros2 pkg create로 생성한다. ament_python 패키지에서 setup.py의 console_scripts는 ros2 run의 실행 이름을 Python 함수에 연결한다. 등록을 바꾸었다면 다시 빌드·source한다.

3.4 Python 명령 실행과 파일 직접 실행#

텍스트 편집기로 ~/ros2_shell_practice/robot_basic/hello_ros.py를 열고 아래 내용을 저장한다. 첫 줄의 shebang은 파일을 직접 실행할 때 사용할 인터프리터를 운영체제에 알려준다. /usr/bin/env python3는 PATH에서 python3를 찾아 실행한다.

#!/usr/bin/env python3

print("Hello ROS 2")

cd ~/ros2_shell_practice
python3 robot_basic/hello_ros.py
chmod +x robot_basic/hello_ros.py
./robot_basic/hello_ros.py

두 실행 모두 Hello ROS 2를 출력한다. python3 파일.py는 Python 인터프리터가 읽을 수 있는 파일을 받아 실행하므로 파일 자체의 실행 권한은 필요하지 않다. ./파일.py는 파일 자체를 실행하므로 실행 권한과 올바른 shebang이 필요하다. chmod +x는 실행 권한을 추가하고, ./는 현재 디렉터리를 기준으로 경로를 지정한다. chmod는 ROS package 등록이나 console_scripts 생성을 대신하지 않는다.

Permission denied라면 ls -l로 실행 권한을 확인한다. No such file or directory라면 pwd와 파일 경로를 확인한다. 파일이 존재하는데 /usr/bin/env 관련 오류가 난다면 첫 줄이 정확한지, Windows 줄바꿈 CRLF가 섞였는지 확인하고 편집기에서 LF로 저장한다. which python3는 PATH에서 선택된 인터프리터를 보여준다. ROS apt 패키지를 사용할 때는 어떤 Python 환경을 실행하는지 함께 확인한다.

3.5 bashrc와 alias로 반복 명령 줄이기#

alias는 긴 셸 명령에 짧은 이름을 붙이는 기능이다. ~/.bashrc에 아래 두 줄을 넣으면 작업공간 루트로 이동하는 cw와 소스 폴더로 이동하는 cs를 사용할 수 있다. 텍스트 편집기로 기존 파일에 추가하고 같은 줄을 중복해서 넣지 않는다.

alias cw='cd ~/ros2_ws'
alias cs='cd ~/ros2_ws/src'

source ~/.bashrc
type cw
cw
pwd

source는 설정을 현재 셸에 적용한다. type cw는 cw가 어떤 alias로 정의되어 있는지 보여준다. cw 실행 뒤 pwd가 홈 디렉터리 아래 ros2_ws를 가리키면 정상이다. 다른 셸·새 PC에서는 alias가 정의되어 있지 않을 수 있으므로 명령의 원래 형태인 cd ~/ros2_ws도 함께 이해한다.

ROS 기본 환경은 /opt/ros/jazzy/setup.bash로 활성화하고, 자신의 workspace는 빌드가 끝난 뒤 ~/ros2_ws/install/setup.bash로 활성화한다. alias로 폴더를 이동하는 일과 source로 검색 경로를 적용하는 일은 별개다. echo $ROS_DOMAIN_ID가 빈 줄이어도 환경변수가 설정되지 않았다는 뜻일 수 있으며, 그 자체만으로 설치 실패를 뜻하지 않는다.

4장. Using turtlesim, ros2, and rqt#

4.1 turtlesim이 무엇인가#

turtlesim은 ROS 2 핵심 개념을 시각적으로 배우기 위한 가벼운 2D demo package다. 실제 robot driver 없이도 Node, Topic, Service, Parameter, Action, remapping을 모두 실습할 수 있어 공식 beginner tutorial의 공통 실습대상으로 사용된다.

4.2 설치와 실행#

sudo apt install -y ros-jazzy-turtlesim
ros2 run turtlesim turtlesim_node

ros2 run <package> <executable> 형식이다. turtlesim package의 turtlesim_node executable을 실행하면 /turtlesim Node가 Graph에 나타나고 GUI 창이 열린다.

4.3 teleop 실행#

# 다른 terminal
source /opt/ros/jazzy/setup.bash
ros2 run turtlesim turtle_teleop_key

teleop은 keyboard 입력을 받아 turtle의 속도명령 Topic으로 변환한다. terminal focus가 teleop 창에 있어야 key 입력이 전달된다.

4.4 rqt와 rqt_graph#

rqt
rqt_graph

rqt는 Qt 기반 ROS(Robot Operating System, 로봇 운영체제) GUI(Graphical User Interface, 그래픽 사용자 인터페이스) plugin framework이고 rqt_graph는 Node·Topic 연결관계를 시각화한다. 이 시점부터 CLI(Command-Line Interface, 명령줄 인터페이스)와 Graph를 함께 보면서 명령이 실제 연결을 어떻게 바꾸는지 확인한다.

5장. Understanding nodes#

5.1 실행 중 Node 확인#

ros2 node list
ros2 node info /turtlesim

node list는 현재 Graph에서 발견된 Node 이름을 보여준다. node info는 해당 Node가 가진 subscribers, publishers, services, action 등을 나열해 외부 interface를 확인한다.

5.2 Node 이름 Remapping#

ros2 run turtlesim turtlesim_node --ros-args --remap __node:=my_turtle
ros2 node list

--ros-args 뒤는 ROS 전용 실행 인자다. --remap은 이름 매핑을 바꾸고 __node는 Node 이름 자체를 지정하는 특별한 key다. 기존 /turtlesim을 rename하는 것이 아니라 새 process의 Node가 my_turtle이라는 이름으로 생성된다.

5.3 Node와 process의 관계#

하나의 process에 여러 Node가 있을 수 있고 같은 Node class를 여러 process에서 서로 다른 이름으로 실행할 수도 있다. ROS(Robot Operating System, 로봇 운영체제) CLI(Command-Line Interface, 명령줄 인터페이스)가 다루는 것은 OS(Operating System, 운영체제) PID(Process Identifier, 프로세스 식별자)보다 ROS Graph의 Node identity다.

6장. Understanding topics#

6.1 Topic 목록·타입 확인#

ros2 topic list
ros2 topic list -t
ros2 topic info /turtle1/cmd_vel -v

-t는 Topic 이름과 message type을 같이 보여준다. -v는 publisher/subscriber endpoint와 QoS(Quality of Service, 서비스 품질)까지 상세하게 보여준다.

6.2 Topic data 보기#

echo는 Topic이 흘리는 메시지의 실제 필드를 보여 주고, info는 발행자·구독자 연결을 보여 준다. 앞에서 본 Node와 Topic의 차이를 이 두 명령으로 확인한다.

ros2 topic echo /turtle1/pose
ros2 interface show turtlesim/msg/Pose

topic echo는 수신 message를 터미널에 출력한다. interface show는 해당 type의 field 구조를 보여준다. 값을 해석하려면 먼저 message type과 field 의미를 확인해야 한다.

6.3 CLI(Command-Line Interface, 명령줄 인터페이스)에서 직접 Publish#

ros2 topic pub --once /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 1.0}, angular: {z: 0.5}}"

ros2 topic pub --rate 10 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.5}, angular: {z: 0.2}}"

--once는 한 번, --rate 10은 초당 10회 publish한다. 뒤의 중괄호는 YAML(YAML Ain't Markup Language, 데이터 직렬화 형식) 형식의 message field 값이다. Topic은 subscriber가 응답을 반환하는 구조가 아니다.

6.4 Topic frequency 측정#

ros2 topic hz /turtle1/pose
ros2 topic bw /turtle1/pose

hz는 실제 수신 frequency, bw는 data bandwidth를 측정한다. 이후 센서 Topic 성능진단에서도 동일하게 사용한다.

7장. Understanding services#

7.1 Service 목록과 타입#

ros2 service list
ros2 service list -t
ros2 service type /spawn
ros2 interface show turtlesim/srv/Spawn

Service는 client가 request를 보내면 server가 response를 반환하는 구조다. service type과 request/response field를 확인한 뒤 call해야 한다.

7.2 turtle 생성 Service 호출#

ros2 service call /spawn turtlesim/srv/Spawn "{x: 2.0, y: 2.0, theta: 0.0, name: 'turtle2'}"

service call은 이름, service type, YAML(YAML Ain't Markup Language, 데이터 직렬화 형식) request 순으로 쓴다. 호출이 완료되면 response가 반환된다. 지속 작업이 아닌 짧은 request/response에 적합하다.

7.3 Service와 Topic 선택 기준#

앞 절의 Topic은 응답을 보장하지 않는 지속적 전달이고, Service는 한 요청에 한 응답을 돌려준다. 시간이 오래 걸리며 중간 진행률이 필요한 제어는 Action을 사용한다.

계속 흐르는 센서·상태는 Topic, 한 번 요청하고 즉시 결과를 받는 작업은 Service가 자연스럽다. 로봇팔의 관절각·TCP(Tool Center Point, 공구 중심점) 위치·카메라 영상·힘/토크처럼 계속 갱신되는 값은 Topic에 맞고, 그리퍼 열기·오류 상태 초기화처럼 짧게 끝나는 요청은 Service에 맞다. Home 이동이나 Pick처럼 수초 이상 걸리며 진행 상태·완료 결과·중도 취소가 필요한 작업은 Action을 사용한다. 전원 투입처럼 짧은 요청으로 보이더라도 실제 장비에서는 안전 승인과 상태 전이가 필요할 수 있으므로 하드웨어 인터페이스의 계약을 먼저 확인한다.

8장. Understanding parameters#

8.1 Parameter 목록과 값 확인#

Parameter는 Topic처럼 계속 발행하는 데이터가 아니라 특정 Node의 설정값이다. 변경 대상 Node와 Parameter 이름을 함께 지정한다.

ros2 param list /turtlesim
ros2 param get /turtlesim background_r

Parameter는 Node 안에 저장된 설정값이다. get은 현재 값을 읽고 set은 실행 중 값을 변경한다.

8.2 값 변경과 화면 갱신#

ros2 param set /turtlesim background_r 80
ros2 service call /clear std_srvs/srv/Empty "{}"

background_r를 바꾸고 clear service를 호출하면 배경색이 변경된다. Parameter 변경과 실제 동작 반영이 항상 자동으로 연결되는 것은 아니며 Node 구현에 따라 달라진다.

8.3 Parameter dump/load#

ros2 param dump /turtlesim > turtlesim.yaml
ros2 param load /turtlesim turtlesim.yaml

>는 명령 출력을 파일로 저장하는 shell redirection이다. dump 결과는 YAML(YAML Ain't Markup Language, 데이터 직렬화 형식)로 저장할 수 있고 load로 다시 적용할 수 있다. 재현 가능한 설정관리의 기본이다.

9장. Understanding actions#

9.1 Action을 직접 경험하기#

turtlesim teleop에서 방향회전 key를 누르면 회전 goal이 Action으로 실행되고 진행중 feedback과 완료 result를 받을 수 있다. 긴 작업이면서 중간 상태와 취소가 필요한 경우라는 Action의 특성을 시각적으로 확인할 수 있다.

9.2 Action 목록과 정보#

Action의 Goal은 시작 요청, Feedback은 진행 중 정보, Result는 완료 결과다. Service와 달리 작업 중 취소 요청을 받을 수 있다.

ros2 action list
ros2 action list -t
ros2 action info /turtle1/rotate_absolute
ros2 interface show turtlesim/action/RotateAbsolute

Action 정의는 Goal, Result, Feedback 세 message 구조를 포함한다. action info는 client/server 수를 확인한다.

9.3 CLI(Command-Line Interface, 명령줄 인터페이스)로 goal 보내기#

ros2 action send_goal /turtle1/rotate_absolute   turtlesim/action/RotateAbsolute "{theta: 1.57}" --feedback

--feedback을 붙이면 goal 실행 중 feedback을 계속 표시한다. Action은 Service와 달리 cancel과 진행상태가 핵심이다.

10장. rqt_console로 로그 보기#

10.1 로그와 severity#

ROS(Robot Operating System, 로봇 운영체제) logger는 DEBUG, INFO, WARN, ERROR, FATAL 같은 severity를 사용한다. rqt_console은 여러 Node가 내는 로그를 한 화면에서 필터링해 볼 수 있어 복잡한 시스템에서 어떤 Node가 문제를 보고했는지 찾기 쉽다.

rqt_console
ros2 run turtlesim turtlesim_node --ros-args --log-level WARN

--log-level WARN은 해당 실행의 logger threshold를 WARN 이상으로 올린다. 로그가 너무 많을 때 severity를 조절해 필요한 신호를 남긴다.

11장. Launching multiple nodes#

11.1 Launch가 필요한 이유#

실습 초기에는 Node마다 terminal을 열었지만 실제 robot은 수십 개 Node를 함께 실행한다. Launch는 어떤 program을 어떤 이름·namespace·parameter·remapping으로 실행할지 하나의 재현 가능한 구성으로 묶는다. Launch는 개별 노드의 내부 코드를 바꾸지 않고도 여러 노드의 실행 순서·이름·설정값을 함께 재현하는 실행 구성이다.

11.2 기존 Launch 실행#

ros2 launch turtlesim multisim.launch.py

ros2 launch <package> <launch_file> 형식이다. package에 설치된 launch file을 찾아 그 안에 정의된 여러 action을 실행한다.

11.3 Launch와 run 차이#

ros2 run은 executable 하나를 직접 실행하는 데 적합하고 ros2 launch는 여러 Node와 설정을 함께 구성하는 데 적합하다. 뒤의 client library 파트에서 직접 launch file을 작성한다.

12장. rosbag2로 데이터 기록·재생#

12.1 Topic 기록#

mkdir -p ~/bag_files
cd ~/bag_files
ros2 bag record /turtle1/cmd_vel /turtle1/pose

ros2 bag record는 선택한 Topic message와 timestamp를 storage에 저장한다. 실제 장비에서 한 번 발생한 상황을 나중에 반복 재현하는 데 매우 중요하다.

12.2 bag 정보 확인#

ros2 bag info <bag_directory>

bag info는 duration, message count, Topic type과 개수 등 기록 metadata를 보여준다.

12.3 재생#

ros2 bag play <bag_directory>

bag play는 기록한 message를 다시 publish한다. turtlesim을 새로 실행한 상태에서 재생하면 기록한 cmd_vel 흐름이 다시 전달되는 것을 볼 수 있다. 뒤의 SLAM·vision 디버깅에서도 동일한 방식으로 sensor 입력을 재현한다.

Part III. Tutorials — Beginner: Client libraries#

13장. colcon으로 ROS 2 package 빌드하기#

약어 표기 ROS 2: Robot Operating System 2(로봇 운영체제 2)

13.1 colcon의 역할#

colcon은 Python 파일을 직접 실행하는 명령이 아니라 여러 ROS(Robot Operating System, 로봇 운영체제) package의 빌드와 설치를 지휘하는 도구다. 빌드한 뒤 source해야 현재 터미널이 새 package를 찾을 수 있다.

colcon은 workspace 안 여러 package의 의존관계를 보고 각 package의 실제 빌드도구를 올바른 순서로 호출하는 meta-build/orchestration 도구다. CMake나 setuptools를 대체하는 compiler가 아니다.

13.2 workspace 만들기와 source 추가#

mkdir -p ~/ros2_ws/src
cd ~/ros2_ws/src
# 예제 package나 자신의 package를 이곳에 둔다
cd ~/ros2_ws

workspace는 여러 ROS package를 함께 빌드·실행하기 위한 작업공간이다. 관례적으로 원본 package는 src 아래에 둔다.

13.3 Underlay source#

source /opt/ros/jazzy/setup.bash

/opt/ros/jazzy는 이미 설치된 base environment(underlay)다. workspace를 빌드하면 그 위에 자신의 install 공간을 overlay로 source한다.

13.4 build·test·source#

cd ~/ros2_ws
colcon build --symlink-install
colcon test
colcon test-result --verbose
source install/setup.bash

build 후 build/install/log가 생긴다. install/setup.bash를 source하면 현재 shell에서 새 package를 ros2 run/launch로 찾을 수 있다.

13.5 선택 빌드#

colcon list
colcon build --packages-select my_package
colcon build --packages-up-to my_app

--packages-select는 지정 package만, --packages-up-to는 지정 package와 dependency까지 빌드한다.

14장. Workspace와 Package 만들기#

14.1 workspace 구조#

ros2_ws/
├── src/
├── build/
├── install/
└── log/

src는 원본, build/install/log는 colcon이 만드는 산출물이다. Git에는 일반적으로 src의 source와 configuration을 넣고 build/install/log는 제외한다.

14.2 Python package 생성#

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_python --license Apache-2.0   --dependencies rclpy std_msgs py_pubsub

--build-type ament_python은 Python package용 ament 규칙을 사용한다는 뜻이다. --dependencies는 package.xml에 dependency를 추가하고 --license는 package metadata를 설정한다.

14.3 생성 파일 읽기#

14.4 NumPy로 로봇 데이터 다루기#

NumPy는 센서값·관절값·이미지·좌표 행렬처럼 여러 수를 한꺼번에 계산하는 Python 라이브러리다. 핵심 객체 ndarray는 같은 자료형의 데이터를 여러 차원의 배열로 저장한다. Python list의 +는 목록을 이어 붙이지만 NumPy 배열의 +는 대응하는 요소를 더한다. 로봇의 여러 관절에 같은 보정값을 더하거나 센서값의 평균을 구할 때 반복문 대신 배열 연산을 사용할 수 있다.

sudo apt install python3-numpy
python3 -c "import numpy as np; print(np.__version__)"

apt의 python3-numpy는 Ubuntu의 Python 환경에 NumPy를 설치한다. python3 -c는 뒤의 문자열을 짧은 Python 프로그램으로 실행하며, np.__version__은 설치된 NumPy 버전이다. 아래 예제를 numpy_practice.py에 저장하고 python3 numpy_practice.py로 실행한다.

import numpy as np

angles = [30.0, 45.0, -10.0]
joint = np.array(angles, dtype=np.float64)
offset = np.array([1.0, -2.0, 3.0])

print(angles + angles)
print(joint + offset)
print(joint * 2)
print(np.mean(joint))
print(joint.shape, joint.ndim, joint.dtype)
print(joint.tolist())

np.array는 Python 목록에서 ndarray를 만든다. dtype=np.float64는 소수 계산을 위한 64비트 실수 자료형을 지정한다. joint + offset은 [31. 43. -7.], joint * 2는 [60. 90. -20.]을 출력한다. np.mean은 전체 요소의 평균을 구한다. shape는 각 축의 크기이며 이 예제에서는 (3,), ndim은 축의 개수여서 1이다. tolist()는 배열을 Python 목록으로 돌려준다. ROS(Robot Operating System, 로봇 운영체제) 메시지에 값을 넣을 때 메시지 필드가 요구하는 자료형과 단위도 함께 맞춘다.

import numpy as np

data = np.array([[1, 2, 3],
                 [4, 5, 6],
                 [7, 8, 9]])
print(data.shape)
print(data[0, :])
print(data[:, -1])
print(data[:, 1])
print(data.reshape(-1))
print(data.sum(axis=1))
print(data.sum(axis=0))

NumPy의 다차원 인덱싱은 [행, 열]처럼 축마다 인덱스를 지정한다. :는 해당 축 전체를 선택한다. axis는 연산으로 줄일 축의 번호다. shape=(행, 열)에서는 axis=0이 행 축, axis=1이 열 축이다. reshape는 요소의 총수를 유지하면서 배열 형태를 바꾸며 -1은 해당 크기를 NumPy가 계산하도록 한다.

기본 슬라이싱은 원본 메모리를 공유하는 view를 반환할 수 있다. 잘라 낸 배열을 바꿀 때 원본도 바뀌지 않게 하려면 data[:, 1].copy()처럼 명시적으로 복사한다. 이미지가 shape=(높이, 너비, 채널)로 표현되면 image[y, x, channel] 순서로 접근한다. 채널의 색상 순서는 사용하는 라이브러리와 영상 형식에서 확인한다.

import numpy as np

a = np.array([[1, 2], [3, 4]])
b = np.array([[5, 6], [7, 8]])
print(a * b)
print(a @ b)

*는 같은 위치의 요소끼리 곱하므로 [[5, 12], [21, 32]]가 된다. @는 행렬곱이므로 [[19, 22], [43, 50]]가 된다. 두 행렬의 행렬곱은 앞 행렬의 열 수와 뒤 행렬의 행 수가 같아야 한다. 좌표 변환에서 회전 행렬을 점 벡터에 적용할 때는 이런 선형대수 연산의 의미를 확인해 사용한다.

15장. Publisher와 Subscriber — Python#

Python의 rclpy로 Publisher와 Subscriber를 구현한다. 먼저 타이머 기반 발행과 수신 콜백을 만들고, 같은 Topic 이름·메시지 타입·호환되는 QoS(Quality of Service, 서비스 품질)가 통신을 결정하는 원리를 turtlesim에서 확인한다.

rclcpp::Node를 상속하고 create_publisher<MessageT>()와 create_wall_timer()를 사용한다. SharedPtr는 publisher와 timer 객체의 수명을 Node와 함께 관리한다. Python의 create_publisher()/create_timer()와 개념은 같다.

15.1 Python Publisher#

import rclpy
from rclpy.node import Node
from std_msgs.msg import String

class MinimalPublisher(Node):
    def __init__(self):
        super().__init__('minimal_publisher')
        self.publisher_ = self.create_publisher(String, 'topic', 10)
        self.timer = self.create_timer(0.5, self.timer_callback)
        self.i = 0

    def timer_callback(self):
        msg = String()
        msg.data = f'Hello World: {self.i}'
        self.publisher_.publish(msg)
        self.i += 1

Python Publisher는 Node를 상속해 만들고 create_publisher()로 발행 대상을 등록한다. create_timer()의 Callback은 지정한 주기마다 Executor가 실행하는 함수다. Topic의 이름과 Message 타입이 수신 노드와 맞아야 메시지가 전달된다.

15.1.1 turtlesim 속도 명령 Publisher#

/turtle1/cmd_vel은 geometry_msgs/msg/Twist 메시지로 거북이의 선속도와 각속도를 받는다. 평면 이동에서는 linear.x가 전진 속도, angular.z가 회전 속도다. turtlesim의 위치·선속도 단위는 시뮬레이터 좌표 단위이고, angular.z는 rad/s이므로 실제 이동로봇의 m/s와 동일하다고 가정하지 않는다.

import rclpy
from rclpy.node import Node
from geometry_msgs.msg import Twist


class TurtleVelocityPublisher(Node):
    def __init__(self):
        super().__init__('lesson_05_cmd_vel_publisher')
        self.publisher = self.create_publisher(
            Twist, '/turtle1/cmd_vel', 10)
        self.timer = self.create_timer(0.1, self.publish_velocity)

    def publish_velocity(self):
        message = Twist()
        message.linear.x = 1.0
        message.angular.z = 0.0
        self.publisher.publish(message)


def main(args=None):
    rclpy.init(args=args)
    node = TurtleVelocityPublisher()
    rclpy.spin(node)
    node.destroy_node()
    rclpy.shutdown()

create_publisher(Twist, '/turtle1/cmd_vel', 10)의 마지막 10은 기본 QoS의 queue depth다. create_timer(0.1, ...)은 노드 clock을 기준으로 callback을 약 0.1초마다 executor에 준비시키므로 목표 발행률은 10 Hz다. 운영체제 스케줄링과 callback 부하로 실제 주기는 조금 흔들릴 수 있으며, timer callback 안에서 sleep하면 다음 callback과 다른 처리를 막을 수 있다. 여기서 QoS depth=10은 아직 처리하지 못한 메시지를 얼마나 보관할지 결정하는 큐 크기다. QoS는 단순 속도 설정이 아니라 발행자와 구독자가 합의해야 하는 전달 조건이다.

setup.py의 console_scripts에 실행 이름을 등록한 뒤 선택 빌드하고 workspace를 source한다. --packages-select는 지정한 패키지만 빌드하고, --symlink-install은 Python 소스 수정이 install 공간에 심볼릭 링크로 반영되게 해 반복 개발을 빠르게 한다.

'lesson_05_cmd_vel_publisher = turtle_robot.lesson_05_cmd_vel_publisher:main',

cd ~/ros2_ws
colcon build --packages-select turtle_robot --symlink-install
source install/setup.bash

turtlesim과 Publisher를 서로 다른 터미널에서 실행하고, 세 번째 터미널에서 실제 메시지 값과 발행률을 확인한다. 다른 teleop이나 제어 노드가 같은 토픽을 동시에 발행하면 명령이 번갈아 도착해 움직임이 불안정해질 수 있으므로 먼저 종료한다.

# 터미널 A
ros2 run turtlesim turtlesim_node

# 터미널 B
ros2 run turtle_robot lesson_05_cmd_vel_publisher

# 터미널 C
ros2 topic echo /turtle1/cmd_vel
ros2 topic hz /turtle1/cmd_vel

echo에서 linear.x가 1.0, angular.z가 0.0으로 보이고 topic hz가 약 10 Hz이면 의도한 메시지와 주기가 전달되는 것이다. Ctrl+C는 현재 터미널의 노드를 종료하지만 다른 터미널의 노드까지 종료하지 않으므로 실습을 마칠 때 각각 정리한다.

15.2 Python Subscriber#

class MinimalSubscriber(Node):
    def __init__(self):
        super().__init__('minimal_subscriber')
        self.subscription = self.create_subscription(
            String, 'topic', self.listener_callback, 10)

    def listener_callback(self, msg):
        self.get_logger().info(f'I heard: {msg.data}')

15.3 setup.py entry point#

entry_points={
    'console_scripts': [
        'talker = py_pubsub.publisher_member_function:main',
        'listener = py_pubsub.subscriber_member_function:main',
    ],
}

Python은 setup.py의 console_scripts가 ros2 run에서 사용할 executable 이름과 Python main 함수를 연결한다. 새 실행 이름을 추가하거나 변경했을 때는 colcon build 뒤 source install/setup.bash를 다시 실행한다. Python 파일 경로와 ros2 run의 실행 이름은 console_scripts가 연결한다.

15.4 Build·Run과 통신 검증#

cd ~/ros2_ws
colcon build --packages-select py_pubsub --symlink-install
source install/setup.bash

# 서로 다른 터미널에서 실행
ros2 run py_pubsub talker
ros2 run py_pubsub listener

# 별도 터미널에서 Graph 확인
ros2 topic info /topic
ros2 topic echo /topic

Python으로 만든 Publisher와 Subscriber는 같은 Topic 이름, 일치하는 Message 타입, 호환되는 QoS를 통해 연결된다. source install/setup.bash는 빌드한 패키지를 현재 셸의 검색 경로에 추가하며, ros2 topic info는 이 연결에 참여한 Publisher·Subscription 수를 확인하는 명령이다.

15.5 turtlesim 위치 메시지 구독하기#

문자열 토픽에서 출발해 실제 상태 메시지로 구독 대상을 바꿔 보자. turtlesim의 /turtle1/pose는 turtlesim/msg/Pose 타입을 사용한다. x와 y는 시뮬레이터 좌표계의 위치이고 theta는 라디안 단위의 방향각이다. 화면 픽셀 좌표와 물리 로봇의 미터 좌표를 그대로 혼동하지 않는다. 메시지 타입은 데이터 구조이고 토픽 이름은 그 데이터를 보내는 채널 이름이다.

새 패키지 turtle_robot을 만들고, 안쪽 Python package 폴더에 노드 파일을 저장한다. 아래 package 생성 명령은 새 패키지를 만들 때 한 번 실행한다. 이미 같은 패키지를 만들었다면 기존 구조와 의존성을 확인해 사용한다.

source /opt/ros/jazzy/setup.bash
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws/src
ros2 pkg create turtle_robot --build-type ament_python --dependencies rclpy turtlesim

--build-type ament_python은 Python 패키지의 빌드 체계를 선택한다. --dependencies는 생성할 package.xml에 의존 패키지를 등록한다. rclpy는 Python ROS 2(Robot Operating System 2, 로봇 운영체제 2) API(Application Programming Interface, 응용 프로그램 인터페이스)이며 turtlesim은 Pose·Color 메시지를 제공한다. package.xml에 두 패키지의 depend 항목이 있는지 확인한다.

터미널 A에서 ros2 run turtlesim turtlesim_node를 실행하고 터미널 B에서 ros2 run turtlesim turtle_teleop_key를 실행한다. 각 터미널에서 먼저 Jazzy 환경을 source한다. 방향키 입력은 turtle_teleop_key가 실행 중인 터미널에 포커스를 두고 보낸다. 터미널 C에서는 다음으로 메시지 구조를 확인한다.

ros2 topic type /turtle1/pose
ros2 interface show turtlesim/msg/Pose
ros2 topic echo /turtle1/pose

type은 토픽의 타입을 확인하고 interface show는 그 타입의 필드 정의를 보여준다. echo는 수신 메시지를 계속 출력하며 Ctrl+C로 종료한다. Pose에는 x·y·theta 외에 linear_velocity·angular_velocity도 있다. 이번 노드는 위치와 방향만 출력한다.

파일 경로: ~/ros2_ws/src/turtle_robot/turtle_robot/lesson_01_pose_subscriber.py

import rclpy
from rclpy.node import Node
from rclpy.executors import ExternalShutdownException
from turtlesim.msg import Pose


class PoseSubscriber(Node):
    def __init__(self):
        super().__init__('lesson_01_pose_subscriber')
        self.subscription = self.create_subscription(
            Pose, '/turtle1/pose', self.on_pose, 10)

    def on_pose(self, msg):
        self.get_logger().info(
            f'x={msg.x:.2f}, y={msg.y:.2f}, '
            f'theta={msg.theta:.2f} rad')


def main(args=None):
    rclpy.init(args=args)
    node = PoseSubscriber()
    try:
        rclpy.spin(node)
    except (KeyboardInterrupt, ExternalShutdownException):
        pass
    finally:
        node.destroy_node()
        if rclpy.ok():
            rclpy.shutdown()


if __name__ == '__main__':
    main()

create_subscription의 인자는 메시지 타입, 토픽 이름, 수신 callback, QoS 설정 순이다. 여기서 정수 10은 KEEP_LAST 방식의 depth를 지정한다. QoS는 대기 메시지 보관 방식과 전달 정책을 정하며, depth는 수신이 밀릴 때 보관할 최신 메시지 수다. self.on_pose는 함수를 지금 호출하지 않고 callback으로 등록한다. 실제 메시지를 받으면 executor가 msg를 인자로 전달해 호출한다.

get_logger().info는 이 노드 이름과 시각을 붙여 INFO 수준 로그를 남긴다. rclpy.init은 ROS(Robot Operating System, 로봇 운영체제) 통신 context를 초기화하고 spin은 준비된 callback을 처리한다. destroy_node는 노드의 자원을 정리하고 shutdown은 context를 종료한다. rclpy.ok는 context가 아직 활성화되어 있는지 확인한다. Ctrl+C로 중단하더라도 정리 경로가 실행되도록 main을 구성했다. ExternalShutdownException은 context가 외부에서 종료되어 spin을 계속할 수 없을 때 발생한다. 이 예제에서는 키보드 중단과 함께 종료 경로로 처리한다.

setup.py의 기존 console_scripts 목록에 다음 항목을 추가한다. 기존 entry_points를 통째로 새로 만들지 않고 목록에 실행 이름을 등록한다.

'lesson_01_pose_subscriber = turtle_robot.lesson_01_pose_subscriber:main',

등호 왼쪽이 ros2 run에서 입력할 실행 이름이다. 오른쪽은 Python package.모듈:함수다. 파일명이 같더라도 등록한 실행 이름이 다르면 ros2 run에는 왼쪽 이름을 입력해야 한다. setup.cfg의 script_dir와 install_scripts가 $base/lib/turtle_robot을 가리키는지도 확인한다. 이 경로가 ROS에서 Python 실행 명령을 찾는 설치 위치다.

cd ~/ros2_ws
colcon build --packages-select turtle_robot --symlink-install
source install/setup.bash
ros2 pkg executables turtle_robot
ros2 run turtle_robot lesson_01_pose_subscriber

--packages-select는 지정한 패키지를 선택해서 빌드하고 --symlink-install은 지원되는 파일을 링크해 소스 수정이 설치 공간에 반영되게 한다. setup.py의 실행 등록이나 의존성을 바꿨다면 다시 빌드한다. source install/setup.bash는 빌드 결과를 현재 터미널의 검색 경로에 반영한다. ros2 pkg executables는 등록된 실행 이름을 확인한다. 거북이를 움직이면 x·y·theta가 바뀌어 출력되는지 확인한다.

15.6 바닥 색상 메시지 구독하기#

/turtle1/color_sensor는 거북이 위치에서 읽은 바닥 색상을 turtlesim/msg/Color로 보낸다. r·g·b는 각각 0~255 범위의 빨강·초록·파랑 값이다. Pose와 같은 subscriber 구조를 쓰지만 토픽 이름과 메시지 타입, 읽는 필드가 바뀐다.

ros2 topic type /turtle1/color_sensor
ros2 interface show turtlesim/msg/Color
ros2 topic echo /turtle1/color_sensor

파일 경로: ~/ros2_ws/src/turtle_robot/turtle_robot/lesson_02_color_subscriber.py

import rclpy
from rclpy.node import Node
from rclpy.executors import ExternalShutdownException
from turtlesim.msg import Color


class ColorSubscriber(Node):
    def __init__(self):
        super().__init__('lesson_02_color_subscriber')
        self.subscription = self.create_subscription(
            Color, '/turtle1/color_sensor', self.on_color, 10)

    def on_color(self, msg):
        self.get_logger().info(
            f'R={msg.r}, G={msg.g}, B={msg.b}')


def main(args=None):
    rclpy.init(args=args)
    node = ColorSubscriber()
    try:
        rclpy.spin(node)
    except (KeyboardInterrupt, ExternalShutdownException):
        pass
    finally:
        node.destroy_node()
        if rclpy.ok():
            rclpy.shutdown()


if __name__ == '__main__':
    main()

setup.py의 console_scripts에 아래 항목을 추가하고 15.8과 같은 빌드·source 절차를 수행한다. run의 실행 이름만 lesson_02_color_subscriber로 바꾼다.

'lesson_02_color_subscriber = turtle_robot.lesson_02_color_subscriber:main',

위치가 달라져도 균일한 바닥에서는 RGB(Red, Green, Blue, 적·녹·청 색상) 값이 그대로일 수 있다. 숫자가 변하지 않는 것과 메시지가 도착하지 않는 것을 구분한다. echo에서 메시지가 반복된다면 전송은 이루어지고 있다. background_r·background_g·background_b parameter를 바꾸고 /clear를 호출하면 배경색을 바꿔 관찰할 수 있다.

ros2 param set /turtlesim background_r 200
ros2 param set /turtlesim background_g 40
ros2 param set /turtlesim background_b 80
ros2 service call /clear std_srvs/srv/Empty "{}"

param set은 실행 중인 노드의 설정값을 바꾼다. /clear는 그림과 배경을 새 설정으로 갱신하는 service이며 Empty는 요청 데이터가 없는 service 타입이다. {}는 비어 있는 요청을 YAML(YAML Ain't Markup Language, 데이터 직렬화 형식) 형식으로 표현한다. 거북이가 지나간 선의 색과 배경의 색은 다를 수 있으므로 선이 없는 곳에서 관찰해 본다.

15.7 한 노드에서 위치와 색상을 함께 출력하기#

두 subscription을 한 노드에 등록하고 각 callback에서 가장 최근 메시지를 저장한다. 별도의 timer callback은 1초마다 저장된 값을 읽어 한 줄로 출력한다. 메시지 수신 주기와 출력 주기를 분리하면 빠른 토픽을 모두 로그에 쓰지 않고도 현재 상태를 관찰할 수 있다.

파일 경로: ~/ros2_ws/src/turtle_robot/turtle_robot/lesson_03_pose_color_subscriber.py

import rclpy
from rclpy.node import Node
from rclpy.executors import ExternalShutdownException
from turtlesim.msg import Color, Pose


class PoseColorSubscriber(Node):
    def __init__(self):
        super().__init__('lesson_03_pose_color_subscriber')
        self.latest_pose = None
        self.latest_color = None
        self.pose_subscription = self.create_subscription(
            Pose, '/turtle1/pose', self.on_pose, 10)
        self.color_subscription = self.create_subscription(
            Color, '/turtle1/color_sensor', self.on_color, 10)
        self.timer = self.create_timer(1.0, self.report)

    def on_pose(self, msg):
        self.latest_pose = msg

    def on_color(self, msg):
        self.latest_color = msg

    def report(self):
        if self.latest_pose is None or self.latest_color is None:
            return
        pose = self.latest_pose
        color = self.latest_color
        self.get_logger().info(
            f'위치 x={pose.x:.2f}, y={pose.y:.2f} | '
            f'색상 R={color.r}, G={color.g}, B={color.b}')


def main(args=None):
    rclpy.init(args=args)
    node = PoseColorSubscriber()
    try:
        rclpy.spin(node)
    except (KeyboardInterrupt, ExternalShutdownException):
        pass
    finally:
        node.destroy_node()
        if rclpy.ok():
            rclpy.shutdown()


if __name__ == '__main__':
    main()

create_timer(1.0, self.report)는 노드의 clock을 기준으로 1초 간격 timer를 만들고 report를 callback으로 등록한다. timer도 spin 중 executor가 실행한다. 최신 값은 첫 메시지 이전에 None으로 시작하므로 두 토픽을 모두 받은 뒤에만 출력한다. subscription callback에서는 값을 저장하고 바로 돌아가며, sleep으로 1초를 기다리지 않는다. 하나의 spin에서 두 수신 callback과 timer가 처리된다.

이 코드는 각 토픽의 최신 값을 묶는 방식이다. 두 메시지가 정확히 같은 시각에 측정됐다는 뜻은 아니다. Pose와 Color에는 Header timestamp가 없으므로 이 실습에서 측정 시각 기준 동기화를 할 수 없다. 실제 카메라·IMU(Inertial Measurement Unit, 관성측정장치) 등을 결합할 때는 Header의 timestamp와 message_filters 같은 동기화 방법을 검토한다. 토픽 하나가 멈추면 저장된 마지막 값이 계속 남으므로 실장비에서는 수신 시각과 데이터 유효시간도 관리한다.

'lesson_03_pose_color_subscriber = turtle_robot.lesson_03_pose_color_subscriber:main',

setup.py에 실행 이름을 등록한 뒤 다시 빌드하고 새 터미널에서 Jazzy와 overlay를 source한다.

source /opt/ros/jazzy/setup.bash
source ~/ros2_ws/install/setup.bash
ros2 run turtle_robot lesson_03_pose_color_subscriber

turtlesim이 실행 중이면 대략 1초마다 위치와 RGB 값이 한 줄로 출력된다. 위치 숫자는 현재 거북이 상태에 따라 달라진다. turtlesim을 실행하지 않으면 두 메시지가 도착하지 않으므로 출력하지 않는다.

15.8 관찰과 오류 진단 실습#

ros2 node list
ros2 node info /lesson_03_pose_color_subscriber
ros2 topic info /turtle1/pose --verbose
ros2 topic hz /turtle1/pose
rqt_graph

node info에서 두 subscription을 확인하고 rqt_graph에서 turtlesim이 두 토픽을 통해 같은 subscriber로 연결되는지 본다. topic info --verbose는 endpoint별 상세 정보와 QoS를 보여준다. hz는 해당 관찰 subscriber가 받은 메시지의 빈도를 측정한다. 이 값은 timer의 로그 출력 빈도와 다르며 시스템 부하와 QoS의 영향을 받을 수 있다.

직접 실험해 보자. 먼저 timer 주기를 0.5초로 바꿔 출력 주기만 달라지는지 확인한다. 다음으로 한 subscription의 토픽 이름을 잘못 지정해 두 메시지를 기다리는 조건을 관찰한다. 마지막으로 get_logger 대신 출력 내용을 바꾸고, 코드 파일 수정과 console_scripts 수정에서 각각 필요한 빌드 절차를 구분해 설명한다.

15.9 위치를 읽고 벽 앞에서 회전하기#

15.4.1의 속도 Publisher에 Pose Subscriber를 결합한다. /turtle1/pose에서 받은 최신 위치와 방향을 저장하고, 0.1초마다 앞으로 갈지 제자리에서 회전할지 결정한다. 첫 위치 메시지가 오기 전에는 제어 명령을 발행하지 않는다. 파일은 ~/ros2_ws/src/turtle_robot/turtle_robot/lesson_06_turtle_cmd_and_pose.py에 저장한다.

import math
import rclpy
from rclpy.node import Node
from rclpy.executors import ExternalShutdownException
from geometry_msgs.msg import Twist
from turtlesim.msg import Pose


class TurtleCmdAndPose(Node):
    def __init__(self):
        super().__init__('lesson_06_turtle_cmd_and_pose')
        self.pose = None
        self.publisher = self.create_publisher(
            Twist, '/turtle1/cmd_vel', 10)
        self.subscription = self.create_subscription(
            Pose, '/turtle1/pose', self.receive_pose, 10)
        self.timer = self.create_timer(0.1, self.control)

    def receive_pose(self, message):
        self.pose = message

    def control(self):
        if self.pose is None:
            return
        p = self.pose
        dx = math.cos(p.theta)
        dy = math.sin(p.theta)
        toward_wall = (
            (p.x < 1.5 and dx < 0)
            or (p.x > 9.5 and dx > 0)
            or (p.y < 1.5 and dy < 0)
            or (p.y > 9.5 and dy > 0)
        )
        message = Twist()
        if toward_wall:
            message.angular.z = 1.5
        else:
            message.linear.x = 1.0
        self.publisher.publish(message)


def main(args=None):
    rclpy.init(args=args)
    node = TurtleCmdAndPose()
    try:
        rclpy.spin(node)
    except (KeyboardInterrupt, ExternalShutdownException):
        pass
    finally:
        if rclpy.ok():
            node.publisher.publish(Twist())
        node.destroy_node()
        if rclpy.ok():
            rclpy.shutdown()

theta는 rad 단위 방향각이다. cos(theta)와 sin(theta)는 각각 화면의 x축·y축 방향으로 향하는 성분이며 이동 거리 자체가 아니다. 왼쪽 경계 근처이면서 dx < 0이면 왼쪽 벽을 향하고, 오른쪽 경계 근처이면서 dx > 0이면 오른쪽 벽을 향한다. 아래·위 경계는 dy의 부호로 판정한다. 따라서 벽 가까이 있어도 화면 안쪽을 향한다면 전진한다.

1.5와 9.5는 이 실습에서 미리 회전하기 위한 turtlesim 좌표 임계값이다. 조건이 참이면 linear.x는 0이고 angular.z만 1.5이므로 제자리에서 반시계 방향으로 회전한다. 조건이 거짓이면 linear.x만 1.0이다. 매 주기 새 Twist를 만들면 이전 전진·회전 값이 다음 명령에 남지 않는다. 실제 로봇에서는 센서, 제동거리, 로봇 크기와 좌표계에 맞춰 제어 기준을 다시 설계해야 한다.

setup.py의 console_scripts 목록에 아래 entry point를 추가한다. package.xml에는 rclpy, geometry_msgs, turtlesim의 실행 의존성이 필요하다. 기존 turtle_robot 패키지에서 해당 의존성을 먼저 확인한다.

'lesson_06_turtle_cmd_and_pose = turtle_robot.lesson_06_turtle_cmd_and_pose:main',

cd ~/ros2_ws
source /opt/ros/jazzy/setup.bash
colcon build --packages-select turtle_robot --symlink-install
source install/setup.bash
ros2 run turtle_robot lesson_06_turtle_cmd_and_pose

다른 터미널에서 Jazzy를 source하고 turtlesim_node를 실행한다. teleop과 lesson_05 속도 Publisher는 종료해 같은 cmd_vel 토픽에 다른 명령이 섞이지 않게 한다. 아래 teleport_absolute 서비스로 거북이를 오른쪽 벽 가까이, 바깥쪽 방향(theta=0)으로 놓으면 회전하다가 화면 안쪽을 향할 때 전진하는 것을 볼 수 있다. 서비스 이름과 타입은 ros2 service list -t로 확인할 수 있다.

ros2 run turtlesim turtlesim_node

# 검증용 별도 터미널
ros2 service call /turtle1/teleport_absolute \
  turtlesim/srv/TeleportAbsolute "{x: 10.0, y: 5.5, theta: 0.0}"
ros2 topic echo /turtle1/cmd_vel
# echo를 Ctrl+C로 종료한 뒤
ros2 topic hz /turtle1/cmd_vel

회전 중에는 linear.x=0.0, angular.z=1.5이고 전진 중에는 linear.x=1.0, angular.z=0.0인지 확인한다. 발행률은 약 10Hz가 목표다. 오른쪽 경계에서 theta를 약 3.14로 두면 안쪽을 향하므로 바로 전진해야 한다. 이 두 경우를 비교하면 위치만으로 회전하는 구현과 방향까지 판정하는 구현의 차이를 확인할 수 있다. 종료 시 0 속도를 한 번 발행하지만 DDS(Data Distribution Service, 데이터 분산 서비스) 전달을 보장하는 절차는 아니며, turtlesim의 명령 timeout 동작과 구분해서 이해한다.

16장. Service와 Client — Python#

Python의 rclpy로 Service Server와 Client를 구현한다. Service는 요청(Request)을 보내고 응답(Response)을 돌려받는 짧은 작업에 쓰며, 실행 중인 노드가 다른 일을 계속해야 할 때는 call_async()와 Future를 이용한다.

Service server는 service type, 이름, callback을 등록한다. callback은 typed Request를 읽고 Response를 채운다.

async_send_request()는 즉시 future를 반환한다. executor가 response event를 처리한 뒤 future가 완료된다.

16.1 Python Service#

from example_interfaces.srv import AddTwoInts

self.srv = self.create_service(
    AddTwoInts, 'add_two_ints', self.add_two_ints_callback)

def add_two_ints_callback(self, request, response):
    response.sum = request.a + request.b
    return response

16.2 Python Client#

self.cli = self.create_client(AddTwoInts, 'add_two_ints')
while not self.cli.wait_for_service(timeout_sec=1.0):
    self.get_logger().info('service not available, waiting...')

request = AddTwoInts.Request()
request.a = 2
request.b = 3
future = self.cli.call_async(request)

wait_for_service()는 server discovery를 기다리고 call_async()는 thread를 막지 않은 채 Future를 반환한다. Future는 결과가 당장 준비되지 않았음을 표현하는 객체다. call_async() 직후에 결과를 읽는 것이 아니라 Executor가 응답을 처리한 뒤 future.result()로 꺼낸다.

16.2.1 turtlesim Service Client: 순간이동과 생성#

turtlesim의 /turtle1/teleport_absolute와 /spawn은 같은 Client 흐름을 연습하기 좋다. 먼저 ros2 service type과 ros2 interface show로 서비스 타입과 Request 필드를 확인한다. Topic 메시지와 달리 Service는 Request와 Response가 한 타입 안에 함께 정의된다.

ros2 service type /turtle1/teleport_absolute
ros2 interface show turtlesim/srv/TeleportAbsolute
ros2 service type /spawn
ros2 interface show turtlesim/srv/Spawn

아래 노드는 거북이를 (2.0, 2.0), theta=0.0 rad로 한 번 이동시킨 뒤 종료한다. create_client()의 첫 인자는 서비스 타입, 둘째 인자는 ROS(Robot Operating System, 로봇 운영체제) Graph에 등록된 서비스 이름이다. wait_for_service()는 서버가 discovery될 때까지 확인하고, call_async()는 Request를 보내면서 Future를 즉시 반환한다.

import rclpy
from rclpy.node import Node
from turtlesim.srv import TeleportAbsolute


class TeleportClient(Node):
    def __init__(self):
        super().__init__('lesson_08_teleport_client')
        self.client = self.create_client(
            TeleportAbsolute, '/turtle1/teleport_absolute')

    def send_request(self):
        request = TeleportAbsolute.Request()
        request.x = 2.0
        request.y = 2.0
        request.theta = 0.0
        return self.client.call_async(request)


def main(args=None):
    rclpy.init(args=args)
    node = TeleportClient()
    try:
        while not node.client.wait_for_service(timeout_sec=1.0):
            node.get_logger().info('teleport service를 기다리는 중')
        future = node.send_request()
        rclpy.spin_until_future_complete(node, future)
        future.result()
        node.get_logger().info('순간이동 완료')
    finally:
        node.destroy_node()
        if rclpy.ok():
            rclpy.shutdown()


if __name__ == '__main__':
    main()

spin_until_future_complete()는 executor가 Service 응답 이벤트를 처리하도록 spin하면서 지정한 Future의 완료를 기다린다. 한 번 요청하고 프로그램을 끝내는 명령형 Client에 적합하다. future.result()는 완료된 Response를 꺼내며, 통신 실패나 서버 측 오류가 있으면 예외가 발생할 수 있으므로 실제 애플리케이션에서는 try/except로 실패 경로도 기록한다. 여기서 Executor는 콜백을 실제로 실행하는 ROS 2(Robot Operating System 2, 로봇 운영체제 2) 실행기다. spin_until_future_complete()는 Future가 끝날 때까지 Executor가 이벤트를 처리하게 하므로, 다른 콜백 안에서 무심코 다시 호출하지 않는다.

/spawn으로 바꿀 때는 Client 타입과 Request 필드가 달라진다. Spawn Response의 name에는 실제로 생성된 거북이 이름이 들어온다. 같은 이름이 이미 존재하면 요청이 실패하므로 이름을 바꾸거나 turtlesim을 다시 시작한다.

from turtlesim.srv import Spawn

self.client = self.create_client(Spawn, '/spawn')
request = Spawn.Request()
request.x = 8.0
request.y = 8.0
request.theta = 0.0
request.name = 'turtle2'
future = self.client.call_async(request)

# Future가 완료된 뒤
response = future.result()
self.get_logger().info(f'생성된 이름: {response.name}')

cd ~/ros2_ws
colcon build --packages-select turtle_robot --symlink-install
source install/setup.bash
ros2 run turtlesim turtlesim_node
# 다른 터미널에서
ros2 run turtle_robot lesson_08_teleport_client

16.2.2 한 번 기다리기와 응답 콜백#

Service 응답을 처리하는 방식은 노드의 수명에 따라 고른다. 한 번 호출하고 종료하는 Client는 spin_until_future_complete()로 기다릴 수 있다. Subscriber·Timer와 함께 계속 실행되는 노드는 응답 콜백을 등록해 기존 callback 처리를 멈추지 않는 편이 안전하다.

# 한 번 호출하고 종료하는 프로그램
future = node.send_request()
rclpy.spin_until_future_complete(node, future)
response = future.result()

# 계속 실행되는 노드
future = self.client.call_async(request)
future.add_done_callback(self.on_response)

def on_response(self, future):
    try:
        response = future.result()
        self.get_logger().info('서비스 완료')
    except Exception as exc:
        self.get_logger().error(f'서비스 실패: {exc}')

Future는 나중에 도착할 Response의 완료 상태와 결과를 보관한다. Subscription callback 안에서 spin_until_future_complete()로 같은 executor를 다시 기다리면 다른 callback이 실행되지 못해 교착이나 응답 지연이 생길 수 있다. 이런 노드에서는 call_async() 뒤 add_done_callback()을 사용하고, 동시에 여러 요청을 보내지 않도록 pending 상태를 관리한다. 앞서 설명한 Future의 완료 콜백은 응답이 도착할 때 실행된다. Node가 계속 동작해야 한다면 응답을 기다리며 블로킹하기보다 이 방식을 우선 고려한다.

16.2.3 Pose 구독과 SetPen 서비스를 결합하기#

다음 노드는 /turtle1/pose를 계속 구독하고 x=5.5 경계를 넘을 때만 /turtle1/set_pen을 호출한다. 왼쪽에서는 노란색, 오른쪽에서는 초록색 선을 그린다. 같은 영역의 Pose가 반복 수신될 때 Service를 계속 호출하지 않도록 current_region과 pending을 사용한다.

import rclpy
from rclpy.node import Node
from turtlesim.msg import Pose
from turtlesim.srv import SetPen


class RegionPenClient(Node):
    def __init__(self):
        super().__init__('lesson_10_region_pen_client')
        self.client = self.create_client(SetPen, '/turtle1/set_pen')
        self.subscription = self.create_subscription(
            Pose, '/turtle1/pose', self.on_pose, 10)
        self.current_region = None
        self.pending = False

    def on_pose(self, message):
        region = 'left' if message.x < 5.5 else 'right'
        if region == self.current_region or self.pending:
            return
        if not self.client.service_is_ready():
            return

        request = SetPen.Request()
        if region == 'left':
            request.r, request.g, request.b = 255, 255, 0
        else:
            request.r, request.g, request.b = 0, 255, 0
        request.width = 3
        request.off = 0

        self.pending = True
        future = self.client.call_async(request)
        future.add_done_callback(
            lambda done, target=region: self.on_response(done, target))

    def on_response(self, future, target):
        self.pending = False
        try:
            future.result()
            self.current_region = target
        except Exception as exc:
            self.get_logger().error(f'set_pen 실패: {exc}')


def main(args=None):
    rclpy.init(args=args)
    node = RegionPenClient()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        if rclpy.ok():
            rclpy.shutdown()


if __name__ == '__main__':
    main()

SetPen.Request의 r·g·b는 0~255 색상값, width는 선 굵기, off는 1일 때 펜 끄기다. service_is_ready()는 현재 discovery된 서버가 있는지 즉시 확인한다. pending은 이전 요청의 Response가 오기 전에 다음 요청이 겹치는 것을 막는다. 응답이 성공했을 때만 current_region을 갱신하므로 실패한 요청은 다음 Pose에서 다시 시도할 수 있다.

ros2 run turtlesim turtlesim_node
ros2 run turtlesim turtle_teleop_key
# 세 번째 터미널
ros2 run turtle_robot lesson_10_region_pen_client

16.3 Service가 적합하지 않은 경우#

수초 이상 걸리는 이동이나 작업을 Service callback에서 오래 수행하면 client와 executor가 불필요하게 묶인다. 진행률·취소·최종결과가 필요한 작업은 Action으로 설계한다.

17장. Custom msg·srv·action Interface#

17.1 Interface 전용 package#

custom interface는 재사용성을 위해 별도 ament_cmake package에 두는 경우가 많다. .msg/.srv/.action은 Python 코드가 아니라 IDL(Interface Definition Language, 인터페이스 정의 언어) 기반 정의 입력이며 build 과정에서 언어별 타입 코드가 생성된다.

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_cmake --license Apache-2.0 tutorial_interfaces
mkdir -p tutorial_interfaces/msg tutorial_interfaces/srv tutorial_interfaces/action

17.2 msg와 srv 예#

# msg/Num.msg
int64 num

# srv/AddThreeInts.srv
int64 a
int64 b
int64 c
---
int64 sum

17.3 CMake와 package.xml#

find_package(rosidl_default_generators REQUIRED)
rosidl_generate_interfaces(${PROJECT_NAME}
  "msg/Num.msg"
  "srv/AddThreeInts.srv"
)

rosidl_default_generators가 interface 정의를 Python 등 필요한 target language code로 생성한다. package.xml에는 buildtool/export/runtime 관련 rosidl dependency와 interface package group을 선언한다.

17.4 build와 검증#

cd ~/ros2_ws
colcon build --packages-select tutorial_interfaces
source install/setup.bash
ros2 interface show tutorial_interfaces/msg/Num
ros2 interface show tutorial_interfaces/srv/AddThreeInts

interface show에 구조가 보이면 생성·설치·source가 정상이다.

17.5 Action 정의#

# action/Fibonacci.action
int32 order
---
int32[] sequence
---
int32[] partial_sequence

Action은 goal/result/feedback 세 부분이다. 실제 Action server/client 구현은 뒤의 심화 Action 장에서 자세히 다룬다.

18장. Python Parameter·ros2doctor#

Python Node에서 Parameter를 선언하고 CLI(Command-Line Interface, 명령줄 인터페이스)·Launch·YAML(YAML Ain't Markup Language, 데이터 직렬화 형식)로 설정값을 바꾸는 방법, ros2doctor로 환경을 점검하는 방법을 실습한다. 학습자는 실행할 때 바뀌는 설정과 코드 자체를 구분할 수 있어야 한다.

18.1 Python Node에서 Parameter 선언#

self.declare_parameter('my_parameter', 'world')
value = self.get_parameter('my_parameter').value
self.get_logger().info(f'Hello {value}!')

18.2 CLI·Launch·YAML로 Override#

ros2 run my_package my_node --ros-args -p my_parameter:=robot

# YAML 예
my_node:
  ros__parameters:
    my_parameter: robot

parameter는 코드의 default와 배포 설정을 분리한다. CLI -p, launch의 parameters, YAML file이 같은 parameter interface를 통해 값을 주입한다. Override란 코드에서 선언한 기본값 대신 실행 환경의 값을 적용하는 것이다. --ros-args -p는 명령행, YAML은 설정 파일, Launch의 parameters는 실행 구성에서 같은 Parameter를 지정한다.

18.2.1 속도 Parameter를 CLI와 YAML로 운용하기#

고정 숫자로 작성한 turtlesim 속도 Publisher를 Parameter 기반으로 바꾸면 코드를 수정하지 않고 실행 중 속도를 조정할 수 있다. 기본값을 실수로 선언하면 Parameter 타입도 double로 결정되므로 CLI에서도 2가 아니라 2.0처럼 실수 값을 사용한다.

import rclpy
from rclpy.node import Node
from geometry_msgs.msg import Twist


class CmdVelParameterPublisher(Node):
    def __init__(self):
        super().__init__('lesson_13_cmd_vel_parameters')
        self.declare_parameter('linear_speed', 1.0)
        self.declare_parameter('angular_speed', 0.0)
        self.publisher = self.create_publisher(
            Twist, '/turtle1/cmd_vel', 10)
        self.timer = self.create_timer(0.1, self.publish_velocity)

    def publish_velocity(self):
        message = Twist()
        message.linear.x = float(
            self.get_parameter('linear_speed').value)
        message.angular.z = float(
            self.get_parameter('angular_speed').value)
        self.publisher.publish(message)


def main(args=None):
    rclpy.init(args=args)
    node = CmdVelParameterPublisher()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        if rclpy.ok():
            rclpy.shutdown()


if __name__ == '__main__':
    main()

publish_velocity()가 매 주기 현재 Parameter를 읽으므로 ros2 param set의 결과가 다음 Timer callback부터 반영된다. 시작할 때 한 번만 읽어 멤버 변수에 저장하는 구현이라면 실행 중 변경값은 자동 반영되지 않는다. 변경 검증이나 여러 값을 원자적으로 함께 적용해야 할 때는 Intermediate I.2절의 Parameter 변경 검증 callback을 사용한다.

ros2 run turtle_robot lesson_13_cmd_vel_parameters

# 다른 터미널
ros2 param list /lesson_13_cmd_vel_parameters
ros2 param get /lesson_13_cmd_vel_parameters linear_speed
ros2 param describe /lesson_13_cmd_vel_parameters linear_speed
ros2 param set /lesson_13_cmd_vel_parameters linear_speed 2.0
ros2 param set /lesson_13_cmd_vel_parameters angular_speed 1.0

ros2 param describe는 현재 값이 아니라 ParameterDescriptor를 조회한다. 선언된 타입과 설명, 읽기 전용 여부, 정수·실수 범위가 설정되어 있으면 그 제약까지 확인할 수 있다. set하기 전에 describe로 계약을 확인하면 문자열·정수·실수 타입을 잘못 전달하는 실수를 줄일 수 있다. 실행 중 조정한 값을 재사용하려면 dump 결과를 YAML로 저장한다. 최상위 키는 대상 노드의 이름 또는 완전한 이름이며, ros__parameters 아래가 실제 Parameter 사전이다. dump에 포함된 불필요한 항목을 제거하더라도 들여쓰기와 노드 이름은 유지한다.

/lesson_13_cmd_vel_parameters:
  ros__parameters:
    linear_speed: 2.0
    angular_speed: 1.0

config/cmd_vel.yaml을 패키지의 실행 산출물에 포함하려면 setup.py가 YAML을 install 공간으로 복사하도록 등록한다. glob은 config 폴더의 .yaml 파일 목록을 만들고, data_files의 목적 경로는 package share 디렉터리다. setup.py나 data_files를 바꾼 뒤에는 다시 빌드해야 한다.

from glob import glob

data_files=[
    # 기존 항목 유지
    ('share/' + package_name + '/config', glob('config/*.yaml')),
]

cd ~/ros2_ws
colcon build --packages-select turtle_robot --symlink-install
source install/setup.bash

ros2 run turtle_robot lesson_13_cmd_vel_parameters   --ros-args   --params-file   ~/ros2_ws/install/turtle_robot/share/turtle_robot/config/cmd_vel.yaml

# 파일 없이 시작값만 바꿀 때
ros2 run turtle_robot lesson_13_cmd_vel_parameters   --ros-args   -p linear_speed:=1.5   -p angular_speed:=0.5

--ros-args는 뒤의 인자를 ROS(Robot Operating System, 로봇 운영체제) 전용 인자로 해석하는 경계다. --params-file은 YAML 파일을 읽고, -p name:=value는 한 Parameter를 명령행에서 덮어쓴다. 소스의 config 경로가 아니라 install 공간의 파일로 실행해 보아야 패키지가 다른 컴퓨터에도 배포 가능한 상태인지 검증할 수 있다. 이 명령을 읽을 때 --ros-args 뒤가 ROS 전용 설정이라는 경계부터 찾는다. 그다음 --params-file 또는 -p의 의미를 확인하면 긴 명령행도 구조가 보인다.

18.3 ros2doctor#

ros2 doctor
ros2 doctor --report

ros2doctor는 ROS 환경, network, middleware, package 상태를 종합적으로 검사한다. 특정 Topic 하나를 분석하는 도구라기보다 설치·환경 전체의 1차 건강검진 도구다.

pluginlib::ClassLoader<Polygon> loader(
"polygon_base", "polygon_base::Polygon");
auto polygon = loader.createSharedInstance("polygons::Square");

18.4 기본 과정 완료 기준#

· Node와 Topic·Service·Action·Parameter를 CLI에서 관찰하고, 각 통신 방식이 적합한 상황을 구분할 수 있다.

· colcon, workspace, underlay/overlay, package와 setup.py의 console_scripts가 각자 맡는 역할을 설명할 수 있다.

· Python rclpy로 Publisher/Subscriber 및 Service Server/Client를 만들고, Timer·Subscription·Service Callback이 언제 실행되는지 설명할 수 있다.

· custom msg/srv/action은 rosidl을 통해 Python에서 import 가능한 타입이 되며, interface 정의를 바꾸면 재빌드해야 한다는 사실을 이해한다.

· Topic 통신에서 Message 타입과 QoS(Quality of Service, 서비스 품질)가 맞아야 하고, Service Client의 Future가 응답을 기다리는 상태를 나타낸다는 사실을 설명할 수 있다.

· Launch는 여러 노드의 실행 구성을 재현하고 rosbag2는 Topic 데이터를 기록·재생한다는 사실을 설명할 수 있다.

여기까지 익혔다면 Python으로 Node·Topic·Service·Action·Parameter를 CLI와 코드에서 다루고, workspace와 package를 직접 구성할 수 있다. 아래 종합 정리로 실행 명령과 개념의 연결을 다시 확인한 뒤 Intermediate로 넘어간다.

18.5 Beginner 종합 정리 — ROS 2(Robot Operating System 2, 로봇 운영체제 2)를 Python으로 연결하기#

Beginner에서는 개별 명령을 외우기보다 한 로봇 시스템을 설명하는 순서를 익혔다. 예를 들어 turtlesim을 띄운 뒤 키보드 명령을 보내고 거북이의 위치를 기록하려면 어떤 Node가 있는지, 어떤 Topic이 연결되는지, 각 메시지의 타입과 QoS가 무엇인지 차례로 조사한다.

핵심 요소를 하나의 그림으로 이해하기#

Node는 기능별 실행 단위다. Publisher는 Topic에 메시지를 보내고, Subscriber는 같은 Topic의 메시지를 받아 Callback을 실행한다. Topic은 연속적인 상태·센서·명령 스트림에 적합하다. 같은 이름이라도 Message 타입이 다르거나 QoS가 호환되지 않으면 의도한 통신이 성립하지 않는다.

Service는 Request를 보내고 Response를 받는 짧은 원격 호출이다. Client의 call_async()는 Future를 반환하므로, Node는 응답을 기다리는 동안 다른 Callback을 처리할 수 있다. Future는 응답이 도착했다는 표식과 그 결과를 담는 객체다. 실행기는 Executor이며, Callback은 데이터가 도착하거나 타이머가 만료되었을 때 Executor가 호출하는 함수다.

Action은 시간이 걸리는 목표 지향 작업을 다룬다. Goal은 시작 지시, Feedback은 진행 상황, Result는 최종 결과이며 작업 취소도 가능하다. Parameter는 Node별 동작 설정값, Launch는 여러 Node와 설정을 재현하는 실행 구성, rosbag2는 Topic 데이터의 기록·재생 장치다. 즉, 통신(Topic·Service·Action), 설정(Parameter), 실행(Launch), 관찰·재현(CLI·rosbag2)이 서로 역할을 나누어 하나의 시스템을 이룬다.

한 번 더 실행하는 CLI 점검 순서#

다른 터미널마다 source /opt/ros/jazzy/setup.bash 또는 source ~/ros2_ws/install/setup.bash를 실행한다. source는 현재 셸의 경로와 환경변수를 바꾸는 동작이며, 한 터미널에서 실행해도 다른 터미널에는 자동 전파되지 않는다.

# 터미널 A: turtlesim 실행
ros2 run turtlesim turtlesim_node

# 터미널 B: 주요 인터페이스 확인
ros2 node list
ros2 topic list -t
ros2 topic info /turtle1/pose
ros2 topic echo /turtle1/pose
ros2 service list -t
ros2 action list -t
ros2 param list /turtlesim

# 터미널 C: 데이터 기록과 재생
ros2 bag record -o beginner_pose /turtle1/pose
ros2 bag info beginner_pose

ros2 node list는 노드를, topic list -t는 Topic과 메시지 타입을 보여 준다. topic info는 Publisher·Subscription 개수를 확인하는 데 쓰고, echo는 메시지 내용을, hz는 수신 주기를 확인한다. service list -t와 action list -t는 요청/작업 인터페이스를, param list는 특정 Node에 속한 설정값을 찾는 명령이다. ros2 bag record는 흐르는 메시지를 저장한다.

Python 노드 개발의 다섯 단계#

① ros2 pkg create --build-type ament_python으로 패키지를 만든다. ② rclpy.node.Node를 상속해 Publisher·Subscription·Service·Timer 중 필요한 인터페이스를 등록한다. ③ setup.py의 console_scripts에 모듈과 main 함수를 연결한다. ④ colcon build --packages-select 패키지명 --symlink-install로 빌드한다. ⑤ source install/setup.bash 뒤 ros2 run 패키지명 실행이름으로 구동한다.

--symlink-install은 Python 소스 수정 시 설치 공간에 심볼릭 링크를 유지하는 옵션이다. 새 console_scripts나 설정 파일 등록처럼 설치 메타데이터를 바꾸면 다시 빌드해야 한다. Python 코드의 create_publisher(MessageType, topic_name, qos_depth)는 메시지 타입, Topic 이름, 큐 깊이를 차례로 받는다는 점을 실제 코드에서 확인한다.

통신방식 선택과 장애 분석 연습#

연습 1. 레이저 스캔을 초당 여러 번 전달한다면 Topic이다. 연습 2. 새 거북이를 한 번 생성하고 생성된 이름을 받는다면 Service다. 연습 3. 일정 거리 이동을 요청하고 진행률을 보면서 필요하면 취소한다면 Action이다. 연습 4. 최대속도 수치를 코드 수정 없이 바꾼다면 Parameter다. 연습 5. 여러 노드를 같은 설정으로 다시 실행한다면 Launch다.

통신이 보이지 않을 때는 순서대로 확인한다. (1) 노드가 실행 중인가? ros2 node list. (2) Topic/Service/Action 이름이 맞는가? 관련 list 명령. (3) 메시지 타입이 같은가? ros2 topic type 또는 ros2 interface show. (4) QoS가 호환되는가? ros2 topic info -v. (5) Terminal의 환경 source와 ROS_DOMAIN_ID가 맞는가? (6) Service Client의 Future를 기다리는 동안 Executor가 응답 Callback을 처리할 수 있는가?

마지막으로 자신의 말로 설명해 보자. "Node가 Topic을 발행하면 구독자의 Callback이 Executor에서 실행된다. Service의 요청 결과는 Future로 받는다. 오래 걸리는 목표는 Action을 사용한다. Parameter로 값을 바꾸고 Launch로 실행구성을 재현한다." 이 흐름을 turtlesim의 실제 노드·Topic 이름에 대입할 수 있으면 Beginner의 핵심을 습득한 것이다.

Part III-A. Intermediate ROS 2 개발#

I.1 rosdep과 package.xml dependency 의미#

rosdep은 package.xml의 의존성 이름을 Ubuntu apt 등 플랫폼별 설치 패키지와 연결한다. ROS 2 Python package도 외부 dependency를 사용하면 package.xml에 선언해야 다른 PC(Personal Computer, 개인용 컴퓨터)에서 재현할 수 있다.

sudo rosdep init     # 시스템에서 최초 한 번
rosdep update        # rosdistro index cache 갱신
rosdep install --from-paths src --ignore-src -r -y

--ignore-src는 현재 workspace source로 이미 제공되는 ROS package를 시스템 패키지로 다시 설치하지 않게 한다. 새로운 PC나 CI에서 재현 가능한 build를 만들려면 import가 되는지만 보지 말고 package.xml dependency가 정확해야 한다.

Client는 create_client<ActionT>()로 server를 찾고 SendGoalOptions에 goal response, feedback, result callback을 연결한다. Python의 ActionClient와 상태모델은 동일하다.

같은 process에 component를 배치하면 process 간 serialization 비용을 줄일 수 있지만 fault isolation은 약해진다. 이 trade-off는 51장에서 성능·격리 관점으로 더 깊게 다룬다.

이 패턴은 library/helper API(Application Programming Interface, 응용 프로그램 인터페이스)가 구체적인 Node class 대신 필요한 기능 계약에 의존하도록 만들어 재사용성을 높인다.

I.2 Parameter 변경 감시 — 로컬 검증과 전역 이벤트를 구분한다#

parameter 변경을 다루는 방식은 두 가지다. 자신의 Node가 값을 받아들이기 전에 검사하려면 on-set callback을 사용하고, 다른 Node를 포함해 발생한 parameter event를 관찰하려면 ParameterEventHandler를 사용한다.

# Python: 자신의 parameter 변경 검증
from rcl_interfaces.msg import SetParametersResult

def validate(params):
    for param in params:
        if param.name == 'max_speed' and param.value <= 0:
            return SetParametersResult(successful=False, reason='must be > 0')
    return SetParametersResult(successful=True)

self.add_on_set_parameters_callback(validate)

# Python: parameter event 구독
from rclpy.parameter_event_handler import ParameterEventHandler
self.handler = ParameterEventHandler(self)
self.cb_handle = self.handler.add_parameter_callback(
    parameter_name='max_speed',
    node_name='/controller',
    callback=lambda p: self.get_logger().info(str(p.value)))

ParameterEventHandler에서 등록한 Callback은 Handler 객체와 Callback 핸들을 유지해야 계속 호출된다. 이 점은 Timer나 Subscription 객체를 Node에 보관하는 것과 같은 수명 관리 원칙이다.

I.3 Launch Intermediate — Substitution과 Event Handler#

Launch argument는 즉시 Python 변수로 확정되는 값이 아니라 launch 실행 context에서 평가될 수 있다. LaunchConfiguration, EnvironmentVariable, FindPackageShare, PathJoinSubstitution 같은 substitution은 재사용 가능한 launch 구성을 만든다.

from launch import LaunchDescription
from launch.actions import DeclareLaunchArgument, RegisterEventHandler
from launch.event_handlers import OnProcessExit
from launch.substitutions import LaunchConfiguration
from launch_ros.actions import Node

robot_ns = LaunchConfiguration('robot_ns')
node = Node(package='demo_nodes_cpp', executable='talker', namespace=robot_ns)

return LaunchDescription([
    DeclareLaunchArgument('robot_ns', default_value='robot1'),
    node,
    RegisterEventHandler(OnProcessExit(target_action=node, on_exit=[])),
])

Substitution은 실행 시점 값 치환, Event Handler는 process start/exit·shutdown 같은 event에 따라 후속 action을 실행하는 규칙이다. 큰 시스템에서는 IncludeLaunchDescription으로 하위 launch를 나누고 namespace·parameter file·remapping을 상위에서 주입한다.

I.4 tf2·Testing·URDF(Unified Robot Description Format, 통합 로봇 기술 형식)·RViz는 기존 심화부로 연결한다#

따라서 이 네 영역은 Intermediate 튜토리얼을 다시 옮기기보다 기존 심화 장을 읽는 편이 중복이 적고 학습 깊이도 높다.

I.5 Intermediate 완료 체크#

· package.xml dependency 태그와 rosdep의 역할을 설명할 수 있다.

· Python에서 Action Client의 Goal·Feedback·Result·Cancel 흐름과 Future의 완료 시점을 구분할 수 있다.

· Python Executor가 Timer·Subscription·Service Callback을 처리한다는 점을 설명할 수 있다.

· Callback Group 설정이 필요한 이유와 동기 대기에서 생기는 교착 위험을 설명할 수 있다.

· parameter 변경 검증 callback과 ParameterEventHandler의 차이를 설명할 수 있다.

· LaunchConfiguration/substitution/event handler를 사용해 재사용 가능한 launch 구성을 만들 수 있다.

· tf2·Testing·URDF·RViz는 뒤의 심화 장에서 실제 로봇 문맥으로 확장할 수 있다.

Part IV. Concepts & Development Deep Dive#

19장. ROS 2를 분산 시스템으로 이해하기#

이 장을 끝내면 실행 중인 Graph를 읽어 Node·Topic·Service·Action의 역할을 설명한다.

약어 표기 ROS 2: Robot Operating System 2(로봇 운영체제 2)

19.1 ROS 2는 로봇 제어 프로그램이 아니라 연결 규칙이다#

독자의 첫 질문 ROS 2를 로봇을 움직이는 단일 라이브러리로 생각하면 뒤에서 계속 혼란이 생긴다. ROS 2는 센서·인식·계획·제어 프로그램이 서로 발견되고 데이터를 교환하도록 만드는 통신·실행 프레임워크다. 실제 모터 구동은 드라이버나 controller가 담당하고, ROS 2는 그 기능들을 연결한다.

새 시스템을 볼 때는 소스코드보다 먼저 어떤 노드가 있고 무엇을 발행하며 무엇을 요청받는가를 본다. 카메라 노드는 영상을 발행하고, 인식 노드는 영상을 구독해 검출 결과를 발행하며, 상위 행동 노드는 그 결과를 받아 이동 Action을 보낼 수 있다. 이 연결관계가 ROS Graph다.

ROS 2는 센서, 인식, 계획, 제어, 기록, 시각화를 하나의 거대한 실행파일에 넣지 않고 여러 기능 단위로 나누어 연결하도록 만든다. 이때 중요한 것은 “노드를 많이 만드는 것” 자체가 아니라 각 기능 사이의 경계를 명시적으로 만드는 것이다. 경계가 명확하면 카메라 드라이버를 바꾸거나 시뮬레이터를 실제 로봇으로 교체해도 상위 로직을 재사용하기 쉬워진다.

실무에서 새로운 로봇을 받았을 때 가장 먼저 API 문서를 처음부터 읽을 필요는 없다. 실행시킨 뒤 `ros2 node list`, `ros2 topic list -t`, `ros2 service list -t`, `ros2 action list -t`를 보면 시스템이 어떤 계약을 외부로 드러내는지 빠르게 알 수 있다. 이것이 ROS 2의 강점이다.

19.2 ROS(Robot Operating System, 로봇 운영체제) Graph와 프로세스의 차이#

바로 확인 talker/listener를 실행한 상태에서 `ros2 node list`와 `ros2 node info /talker`를 실행한다. 프로세스와 ROS Graph의 논리적 Node가 같은 개념이 아니라는 것을 확인한다.

운영체제 프로세스와 ROS Node를 분리해서 이해하면 composition이 쉬워진다. 하나의 프로세스에 여러 Node를 넣으면 전달 비용을 줄일 수 있지만 한 프로세스의 실패가 여러 Node에 영향을 줄 수 있다. 반대로 프로세스를 분리하면 격리와 재시작은 쉬워지지만 통신 비용이 늘 수 있다.

Node는 ROS Graph에 참여하는 논리적 기능 단위다. 프로세스는 운영체제가 관리하는 실행 단위다. 초반에는 “노드 하나 = 프로세스 하나”로 생각해도 큰 문제는 없지만, 실제로는 하나의 프로세스 안에 여러 Node를 넣을 수 있고, 반대로 하나의 기능을 여러 Node가 협력해 구현할 수도 있다. 이 구분은 나중에 composition, executor, 성능 최적화를 이해할 때 중요해진다.

Bash복사

ros2 node list
ros2 node info /camera_node
ros2 topic list -t
ros2 service list -t
ros2 action list -t
rqt_graph

관찰 포인트 `node info`는 특정 노드가 publish/subscribe/service/action 중 무엇을 제공하는지 보여준다. 코드가 없어도 노드의 역할을 역으로 추론할 수 있다.

19.3 ROS 2의 계층: rclpy에서 DDS(Data Distribution Service, 데이터 분산 서비스)까지#

이 책의 Python Node는 `rclpy` API(Application Programming Interface, 응용 프로그램 인터페이스)로 Publisher를 만들지만, 메시지가 곧바로 소켓으로 전송되는 것은 아니다. 호출은 공통 C 계층 `rcl`과 RMW(ROS Middleware Interface, ROS 미들웨어 인터페이스)(ROS Middleware) 추상화를 거쳐 선택된 DDS 계열 미들웨어에 전달되고, 그곳에서 discovery·직렬화·전송을 처리한다. 따라서 프로세스 내부 함수 호출과 달리 QoS(Quality of Service, 서비스 품질), 패킷 손실, 네트워크 설정, 시계 차이에 따라 통신이 달라질 수 있다. 초반에는 DDS API를 외우기보다 문제가 어느 계층에서 생겼는지 구분한다.

19.4 데이터 흐름과 명령 흐름을 분리한다#

Topic/Service/Action을 고르는 기준은 문법이 편한지가 아니라 정보의 수명주기다. 센서 샘플은 계속 흘러가며 특정 수신자가 없어도 생산될 수 있다. Service는 짧은 질의에 답하고, Action은 작업이 시작된 뒤 피드백·완료·취소라는 상태를 가진다.

판단 연습 카메라 영상→Topic, 일회성 설정 조회→Service, 15초짜리 로봇 이동→Action, 속도 제한값→Parameter로 생각해 본다.

카메라 영상, LiDAR scan, joint state처럼 계속 생성되는 정보는 “흐르는 데이터”다. 반면 “그리퍼를 닫아라”, “목표 위치로 이동하라”는 작업 요청이다. 이 둘을 같은 Topic으로 억지로 표현하면 완료 여부, 오류, 취소, 진행상황을 표현하기 어려워진다. ROS 2는 Topic, Service, Action을 구분해 이런 의미 차이를 인터페이스 수준에서 표현한다.

19.5 분산 시스템으로 생각해야 하는 이유#

ROS 2에서는 코드가 정상이어도 Publisher와 Subscriber가 다른 namespace를 바라보거나 메시지 타입·QoS가 맞지 않으면 통신할 수 없다. TF(Transform, 좌표변환)가 있어도 센서 timestamp와 맞지 않을 수 있고, Lifecycle state·네트워크 discovery가 원인일 수도 있다. 오류를 좁힐 때에는 Graph와 endpoint → 메시지 타입·QoS → frame·time → parameter·lifecycle·network → 코드 순으로 실제 실행 상태를 조사한다.

장 핵심 정리#

• ROS 2의 기본 단위는 파일이 아니라 실행 중인 Node와 인터페이스다.

• ROS Graph를 먼저 관찰하면 구현을 몰라도 시스템 구조를 추론할 수 있다.

• Topic/Service/Action은 문법 차이가 아니라 작업 의미의 차이다.

• ROS 2 문제는 코드·네트워크·시간·QoS·frame 등 여러 층에서 발생한다.

확인 문제#

1. Node와 프로세스가 같은 개념이 아닌 이유를 설명하라.

2. 센서 스트림과 장시간 명령을 같은 Topic으로 처리하면 어떤 문제가 생기는가?

3. 새 로봇 시스템을 처음 관찰할 때 사용할 CLI(Command-Line Interface, 명령줄 인터페이스) 순서를 적고 각 명령에서 무엇을 확인할지 설명하라.

20장. Package 구조·빌드 체계·개발환경 진단#

20.1 Ubuntu 24.04 + ROS 2(Robot Operating System 2, 로봇 운영체제 2) Jazzy + WSL2(Windows Subsystem for Linux 2, Windows용 Linux 하위 시스템 2)의 역할#

WSL2는 ROS 2 코드 작성과 colcon 빌드, RViz2, 일반적인 Gazebo 학습에는 충분히 실용적이다. 다만 실제 LiDAR·RealSense·USB serial을 연결하거나 회사/로봇 네트워크의 multicast discovery를 다룰 때는 Windows↔︎WSL 경계가 추가된다. 문제를 만났을 때 ROS 문제인지 WSL 네트워크/USB 문제인지 분리할 수 있어야 한다.

20.2 Shell, 환경변수, source#

`source`는 설치 작업이 아니라 현재 shell 프로세스의 환경을 바꾸는 명령이다. 한 터미널에서 source했다고 다른 터미널까지 자동으로 적용되지 않는다. 새 터미널을 열 때마다 `/opt/ros/jazzy/setup.bash`와 필요하면 workspace의 `install/setup.bash`를 읽혀야 한다.

실전 진단 `which ros2`, `printenv ROS_DISTRO`, `echo $AMENT_PREFIX_PATH`를 보면 지금 터미널이 어떤 ROS(Robot Operating System, 로봇 운영체제)와 workspace를 보고 있는지 빠르게 확인할 수 있다.

Bash복사

source /opt/ros/jazzy/setup.bash
source ~/ros2_ws/install/setup.bash
printenv ROS_DISTRO
printenv AMENT_PREFIX_PATH

빌드했는데 예전 코드가 실행되거나 package를 못 찾을 때는 거의 항상 “어느 workspace가 source되어 있는가”를 확인해야 한다. 여러 workspace를 동시에 쓰면 overlay 순서가 더 중요해진다.

20.3 Workspace의 네 폴더#

`src`는 사람이 관리하는 원본이고, `build/install/log`는 빌드 시스템이 만든 산출물이다. Git에는 보통 package 소스만 넣고 build/install/log는 제외한다. 이 구분을 지키면 빌드가 꼬였을 때 산출물을 지우고 재생성해도 원본을 잃지 않는다.

Bash복사

mkdir -p ~/ros2_ws/src
cd ~/ros2_ws
colcon build
source install/setup.bash

20.4 Package는 의존성·배포 경계다#

Package 경계는 폴더 정리보다 중요하다. 메시지 정의, 하드웨어 드라이버, 알고리즘, 상위 애플리케이션을 적절히 분리하면 서로 다른 팀·언어·배포 주기로 관리할 수 있다. 반대로 모든 코드를 한 package에 넣으면 의존성이 엉키고 작은 변경에도 전체를 다시 검증해야 한다.

Bash복사

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_python --license Apache-2.0 \
  --dependencies rclpy std_msgs learning_ros2

20.5 package.xml, setup.py, CMakeLists.txt를 읽는 순서#

처음 보는 package를 읽을 때는 구현보다 metadata가 빠른 지도다. `package.xml`은 빌드/실행 의존성을, `setup.py` 또는 `CMakeLists.txt`는 무엇을 설치하고 어떤 executable을 노출하는지 말해 준다. 이 세 파일을 먼저 읽으면 package 역할을 빠르게 추정할 수 있다.

20.6 colcon build와 선택 빌드#

20.6.1 colcon은 컴파일러가 아니라 workspace 빌드 지휘자다#

`colcon`은 CMake나 Python 빌드 도구 자체를 대체하지 않는다. 하나의 workspace 안에 여러 ROS 2 package가 있을 때, 각 package의 의존관계를 파악하고 필요한 순서대로 해당 package의 실제 빌드 도구를 호출하는 meta-build/orchestration 도구다. 메시지 정의 패키지는 주로 CMake/ament_cmake를, Python package라면 setuptools/ament_python을 통해 실제 설치 작업이 이루어진다.

핵심 구분 컴파일은 compiler와 CMake가 하고, Python package 설치는 setuptools가 한다. ament는 ROS 2 package용 빌드·설치 규칙을 제공하고, colcon은 workspace 전체를 묶어 어떤 package를 어떤 순서로 빌드·테스트할지 조율한다.

20.6.2 여러 package의 의존순서를 자동으로 처리한다#

다음과 같은 workspace를 생각해 보자. `robot_app`이 `perception`을 사용하고, `perception`이 `my_interfaces`의 custom message를 사용한다면 `robot_app`을 먼저 빌드할 수 없다. colcon은 package metadata를 이용해 의존관계를 보고 선행 package부터 처리한다.

Bash복사

ros2_ws/
└── src/
    ├── my_interfaces/
    ├── camera_driver/
    ├── perception/
    └── robot_app/

의존관계 예:
my_interfaces
      ↓
camera_driver
      ↓
perception
      ↓
robot_app

workspace 루트에서 `colcon build`를 실행하면 package를 이름순으로 무작정 빌드하는 것이 아니라 의존성을 고려해 처리한다. 특정 package와 그 의존 package까지 빌드하고 싶다면 `--packages-up-to`가 유용하다.

20.6.3 빌드했다고 바로 ros2 run에서 보이는 것은 아니다#

`colcon build`가 끝나면 결과는 `install/` 아래에 만들어진다. 현재 shell은 그 위치를 자동으로 알지 못하므로 overlay 환경을 읽혀야 한다.

Bash복사

cd ~/ros2_ws
colcon build --symlink-install

source install/setup.bash

ros2 pkg list | grep my_package
ros2 run my_package my_node

개발 흐름은 ‘소스 작성 → colcon build → install 생성 → setup.bash source → ros2 run’이다. 새 터미널을 열었다면 `/opt/ros/jazzy/setup.bash`와 workspace의 `install/setup.bash`를 다시 source해야 한다.

20.6.4 --symlink-install은 특히 Python 개발에서 유용하다#

일반 설치에서는 package 파일이 `install/` 공간으로 복사될 수 있다. `--symlink-install`을 사용하면 가능한 파일은 원본 소스와 install 공간을 symbolic link로 연결해 개발 중 수정 반영을 빠르게 한다. Python source만 수정했을 때 매번 전체 복사 설치를 반복하지 않아도 되는 경우가 많다.

다시 빌드가 필요한 경우 `setup.py`, `package.xml`, CMake 설정, entry point, interface(.msg/.srv/.action), launch/config 설치 규칙을 바꾸었다면 다시 `colcon build`하는 습관을 유지한다.

20.6.5 전체 workspace 대신 필요한 package만 빌드한다#

Bash복사

# package 목록 확인
colcon list

# 특정 package만
colcon build --packages-select my_package

# my_app과 my_app이 필요로 하는 dependency까지
colcon build --packages-up-to my_app

# 특정 package만 test
colcon test --packages-select my_package
colcon test-result --verbose

workspace가 커질수록 선택 빌드가 중요해진다. `--packages-select`는 지정 package만 대상으로 삼고, `--packages-up-to`는 지정 package와 그 의존 package까지 포함한다. 처음 빌드하거나 의존 package까지 갱신해야 한다면 `--packages-up-to`가 더 안전하다.

20.6.6 CMake·setuptools·ament·colcon·rosdep의 관계#

`rosdep`과 `colcon`도 역할이 다르다. rosdep은 빌드에 필요한 외부 라이브러리가 준비되었는지를 해결하고, colcon은 준비된 환경에서 workspace package들을 어떤 순서로 빌드·테스트할지를 해결한다.

20.6.7 전체 흐름을 한 번에 보기#

Bash복사

package.xml
   │
   ├─ rosdep ─────────→ 외부 시스템 의존성 준비
   │
   └─ package dependency 정보
              ↓
           colcon
              ↓
     package 의존순서 계산
              ↓
   ┌──────────┴──────────┐
ament_cmake          ament_python
   ↓                     ↓
 CMake                setuptools
   └──────────┬──────────┘
              ↓
      build/ + install/ + log/
              ↓
     source install/setup.bash
              ↓
        ros2 run / ros2 launch

한 문장으로 colcon은 ROS 2 workspace 전체를 빌드하는 ‘지휘자’다. 직접 컴파일하기보다 각 package의 빌드 도구를 올바른 순서로 호출하고 build/test/install 과정을 workspace 단위로 관리한다.

이제 실제 명령을 적용한다. `colcon list`로 발견된 package를 확인하고, `colcon build --symlink-install`로 전체를 빌드한다. workspace가 커지면 `--packages-select`와 `--packages-up-to`를 사용해 범위를 줄인다.

Bash복사

cd ~/ros2_ws
colcon list
colcon build --symlink-install
colcon build --packages-select learning_ros2
colcon build --packages-up-to my_app

20.7 빌드 실패를 읽는 법#

빌드 로그는 맨 마지막 줄보다 처음 실패한 package와 최초 error를 찾는 것이 중요하다. 이후 package의 실패는 첫 실패 때문에 연쇄적으로 발생한 결과일 수 있다. Python import 오류, package.xml 누락, CMake target/install 누락, source 안 된 overlay를 서로 다른 층의 문제로 분리한다.

1. 가장 먼저 실패한 package를 찾는다. 뒤의 연쇄 실패 메시지는 원인보다 결과일 수 있다.

2. `rosdep install --from-paths src --ignore-src -r -y`로 시스템 의존성을 점검한다.

3. package.xml 의존성과 import/header 사용이 일치하는지 본다.

4. 빌드 환경이 꼬였으면 해당 package만 `build/`, `install/`에서 정리한 뒤 재빌드한다. 전체 삭제는 마지막 수단이다.

장 핵심 정리#

• source는 현재 shell이 어떤 ROS 설치/overlay를 보는지 결정한다.

• Package는 코드 묶음이 아니라 의존성과 설치 규칙을 가진 배포 단위다.

colcon은 compiler 자체가 아니라 workspace 여러 package의 의존관계를 계산하고 각 package의 빌드 도구를 호출하는 orchestration 도구다.

• 새 패키지를 읽을 때 package.xml → build/install 정의 → 실행 entry point → 코드 순으로 보면 빠르다.

확인 문제#

1. underlay와 overlay를 설명하고 source 순서가 왜 중요한지 설명하라.

2. `colcon build`가 어떤 계층의 도구인지 설명하고, build 성공 후 새 executable이 `ros2 run`에서 보이지 않을 때 확인할 항목을 세 가지 적어라.

3. interface package를 실행 노드 package와 분리하는 장점을 설명하라.

21장. Node·Topic·Message·QoS·Custom Interface#

이 장을 끝내면 publisher/subscriber를 작성하고 message 타입과 QoS 문제를 CLI(Command-Line Interface, 명령줄 인터페이스)로 진단한다.

약어 표기 QoS: Quality of Service(서비스 품질)

21.1 Node의 생명주기와 callback#

Node는 이벤트가 들어올 때 callback을 실행하는 객체다. `spin()`이 실행되는 동안 subscriber 메시지, timer, service 요청, action 이벤트가 준비되면 executor가 callback을 호출한다. 그래서 callback 안에서 오래 계산하거나 sleep하면 다른 이벤트 처리도 밀릴 수 있다.

코드 읽는 법 노드를 보면 먼저 `create_publisher`, `create_subscription`, `create_timer`, `create_service`, `ActionServer`를 찾는다. 이것만 표시해도 외부 인터페이스와 실행 주기를 대부분 파악할 수 있다.

일반적인 rclpy 노드는 `rclpy.init()`으로 통신 기반을 초기화하고, Node 객체를 만든 뒤, `rclpy.spin()`으로 이벤트를 기다린다. Subscriber 메시지 도착, Timer 만료, Service 요청 등은 callback으로 처리된다. 즉 ROS 2 노드는 “메인 루프에서 모든 것을 순서대로 실행하는 프로그램”이라기보다 이벤트가 도착할 때 반응하는 컴포넌트다.

Python복사

import rclpy
from rclpy.node import Node

class Heartbeat(Node):
    def __init__(self):
        super().__init__('heartbeat')
        self.timer = self.create_timer(1.0, self.tick)

    def tick(self):
        self.get_logger().info('alive')

def main():
    rclpy.init()
    node = Heartbeat()
    rclpy.spin(node)
    node.destroy_node()
    rclpy.shutdown()

21.2 Topic은 비동기 데이터 채널이다#

Publisher가 `publish()`를 호출했다고 subscriber 함수가 같은 call stack에서 즉시 실행되는 것은 아니다. 메시지는 미들웨어를 거쳐 전달되고 subscriber callback은 자신의 executor 스케줄에 따라 실행된다. 이 비동기성이 생산자·소비자를 느슨하게 결합하지만 동시에 지연·queue·QoS를 고려하게 만든다.

Publisher는 특정 Topic 이름과 Message 타입으로 샘플을 발행하고, Subscriber는 해당 Topic을 구독한다. Publisher는 Subscriber의 수나 구현을 몰라도 된다. 이 decoupling 덕분에 하나의 센서 데이터를 기록 노드, 시각화 노드, 인식 노드가 동시에 사용할 수 있다.

Bash복사

# 터미널 1
ros2 run demo_nodes_py talker

# 터미널 2
ros2 topic list -t
ros2 topic info /chatter -v
ros2 topic echo /chatter
ros2 topic hz /chatter

21.3 Message 타입을 먼저 확인한다#

Message 타입은 데이터 스키마다. `LaserScan`을 ranges 배열로만 보면 angle_min, angle_increment, frame_id, timestamp를 놓친다. 로봇에서는 숫자값 못지않게 단위·좌표계·시간이 의미를 결정하므로, 처음 보는 Topic은 `ros2 interface show`로 타입부터 읽는 습관이 중요하다.

ROS 2에서 Topic 이름만 맞는다고 통신하는 것이 아니다. 타입이 동일해야 하고, QoS도 호환되어야 한다. 따라서 새로운 Topic을 보면 `ros2 topic type`과 `ros2 interface show`로 구조를 먼저 확인한다. 예를 들어 `sensor_msgs/msg/LaserScan`은 단순 거리 배열이 아니라 각도 시작값, 각도 간격, 최소/최대 range, timestamp가 함께 있는 구조다. 이런 metadata를 무시하면 좌표계와 시간 해석이 틀어진다.

Bash복사

ros2 topic type /scan
ros2 interface show sensor_msgs/msg/LaserScan
ros2 interface show geometry_msgs/msg/Twist

21.4 Publisher와 Subscriber Python 예제#

예제를 그대로 실행한 뒤 publisher 주기, topic 이름, QoS depth를 하나씩 바꿔 본다. 수정→빌드→source→실행의 반복을 몸에 익히는 것이 목적이다. 한 번 돌아가는 것보다 변경이 Graph와 데이터율에 어떻게 반영되는지를 보는 편이 중요하다.

Python복사

from std_msgs.msg import String

class StatusPub(Node):
    def __init__(self):
        super().__init__('status_pub')
        self.pub = self.create_publisher(String, '/robot_status', 10)
        self.timer = self.create_timer(0.5, self.publish)
        self.count = 0

    def publish(self):
        msg = String()
        msg.data = f'ready {self.count}'
        self.pub.publish(msg)
        self.count += 1

class StatusSub(Node):
    def __init__(self):
        super().__init__('status_sub')
        self.sub = self.create_subscription(
            String, '/robot_status', self.on_msg, 10)

    def on_msg(self, msg):
        self.get_logger().info(msg.data)

Publisher 객체 해설 create_publisher()의 반환값은 publisher handle이며 보통 self.pub처럼 Node 객체가 보관한다. 마지막 10은 단순 배열 크기가 아니라 기본 QoS의 KEEP_LAST depth다. subscriber가 처리하지 못할 정도로 입력이 빠르면 오래된 샘플이 queue에 남아 지연으로 보일 수 있다.

마지막 인자 `10`은 단순 버퍼 숫자처럼 보이지만 실제로는 기본 QoS profile의 history depth에 해당한다. 고속 센서 데이터에서는 이 값이 크다고 항상 좋은 것이 아니다. 처리속도가 입력속도보다 느리면 오래된 샘플이 쌓여 “지연된 최신 데이터”를 처리하게 될 수 있다.

21.5 QoS는 통신 계약이다#

QoS는 publisher가 제공하는 성질과 subscriber가 요구하는 성질의 조합이다. subscriber가 RELIABLE을 요구하지만 publisher가 BEST_EFFORT만 제공하면 연결이 성립하지 않을 수 있다. 반대로 센서 스트림에서는 한 프레임 재전송보다 최신 데이터가 더 중요해 BEST_EFFORT가 합리적일 수 있다.

진단 순서 Topic이 보이는데 `echo`가 안 되면 ① 타입 ② publisher/subscriber 수 ③ `ros2 topic info -v`의 QoS ④ namespace/remap을 순서대로 본다.

QoS(Quality of Service)는 네트워크 품질 설정 정도가 아니라 Publisher와 Subscriber가 어떤 전달 성질을 요구하는지 표현하는 계약이다. 대표적으로 Reliability, Durability, History, Depth, Deadline, Lifespan 등이 있다. ROS 2에서는 Publisher가 제공하는 QoS와 Subscriber가 요구하는 QoS가 호환되어야 실제 연결이 성립한다.

센서 QoS 직관 카메라 30 fps에서 한 프레임을 잃었다고 재전송을 기다리는 동안 새 프레임이 여러 장 도착할 수 있다. 이런 스트림에서는 BEST_EFFORT가 더 자연스러운 경우가 많다. 반대로 중요 상태 이벤트나 명령은 RELIABLE이 적합할 수 있다.

QoS 불일치 진단#

Bash복사

ros2 topic info /camera/image_raw -v
ros2 topic echo /camera/image_raw --qos-reliability best_effort

QoS CLI 해설 --qos-reliability best_effort는 CLI subscriber가 사용할 QoS reliability를 명시적으로 바꾼다. 센서 publisher가 BEST_EFFORT인데 echo 쪽이 호환되지 않는 정책을 요구하면 Topic 이름과 타입이 맞아도 데이터가 보이지 않을 수 있다.

Topic 이름과 타입이 맞는데 데이터가 보이지 않으면 QoS를 의심한다. 특히 실제 센서 드라이버는 sensor data profile을 쓰는 경우가 많다.

21.6 Custom Interface: 문자열을 구조로 바꾸기#

Custom Interface는 문자열을 예쁘게 만드는 기능이 아니라 시스템 계약을 타입으로 고정하는 일이다. `.msg/.srv/.action`이 바뀌면 생성 코드가 다시 만들어져야 하므로 재빌드가 필요하다. 여러 package가 같은 interface package에 의존하도록 분리하면 타입 버전을 체계적으로 관리할 수 있다.

여러 값을 문자열 하나로 합치는 것은 빠른 데모에는 편하지만 장기적으로는 타입 안전성, 자동완성, 검증, 기록 분석을 망친다. 의미 있는 데이터 구조는 `.msg`, 짧은 요청/응답은 `.srv`, 장시간 작업은 `.action`으로 정의한다.

Code복사

# RobotStatus.msg
string name
float32 battery
bool ready
geometry_msgs/Pose pose

Interface package는 일반적으로 `ament_cmake`와 `rosidl_default_generators`를 사용한다. 한번 생성된 타입은 Python에서 import해 사용할 수 있다. 이는 ROS 2(Robot Operating System 2, 로봇 운영체제 2)가 언어 간 시스템을 구성하는 중요한 이유 중 하나다.

21.7 메시지 설계 원칙#

메시지에는 지금 필요한 값만 넣는 것이 아니라 장기 유지보수까지 고려한다. frame/time이 필요한 데이터에는 Header를 넣고, ROS 표준 메시지와 단위를 재사용하며, 서로 다른 주기로 변하는 정보를 하나의 거대한 메시지로 묶지 않는다.

• 단위를 명확히 한다. 위치는 meter, 각도는 radian 등 ROS(Robot Operating System, 로봇 운영체제) 표준 관례를 따른다.

• 가능하면 표준 메시지 타입을 재사용한다. Pose, Twist, Header를 새로 복제하지 않는다.

• 시간과 frame이 의미에 중요하면 `std_msgs/Header`를 포함한다.

• 한 메시지에 서로 다른 수명주기의 데이터를 억지로 묶지 않는다.

• 고빈도 raw data와 저빈도 semantic result는 별도 Topic으로 나누는 편이 좋다.

장 핵심 정리#

• Topic은 데이터 스트림, Message는 그 데이터의 타입 계약이다.

• QoS 불일치만으로도 이름과 타입이 같은 Topic이 연결되지 않을 수 있다.

• 센서 데이터는 최신성이 완전전달보다 중요할 수 있다.

• Custom Interface는 시스템의 의미를 타입에 담는 작업이다.

확인 문제#

1. 카메라 Topic에서 RELIABLE보다 BEST_EFFORT가 적합할 수 있는 이유를 설명하라.

2. Header가 필요한 메시지와 필요하지 않은 메시지의 예를 각각 들어라.

3. 문자열 기반 “x=1.2,y=3.4” 메시지보다 구조화 msg가 좋은 이유를 세 가지 적어라.

22장. Service·Action·Parameter·Launch·Lifecycle#

이 장을 끝내면 짧은 RPC와 장시간 작업 인터페이스를 직접 구분하고 구현한다.

22.1 Service: 짧고 완료가 빠른 RPC#

Service는 호출자가 응답을 기다리는 의미가 강하므로 짧고 경계가 분명한 작업에 적합하다. 서버 callback에서 모터가 실제로 10초 움직일 때까지 기다리게 만들면 client와 executor가 함께 묶일 수 있다. 진행상황과 취소가 필요한 작업은 Action으로 설계한다.

Service는 Client가 Request를 보내고 Server가 Response를 반환하는 구조다. 설정값 조회, 장비 상태 읽기, 짧은 계산처럼 호출이 빠르게 끝나는 작업에 적합하다. Service callback 안에서 수초 이상 blocking 작업을 수행하면 executor가 다른 callback을 처리하지 못할 수 있으므로 장시간 작업은 Action으로 설계한다.

Bash복사

ros2 service list -t
ros2 interface show example_interfaces/srv/AddTwoInts
ros2 service call /add_two_ints example_interfaces/srv/AddTwoInts "{a: 2, b: 3}"

22.2 Action: 작업의 수명주기를 표현한다#

Action에는 goal handle이 있고 각 goal은 accepted/executing/succeeded/canceled/aborted 같은 상태를 가진다. Feedback은 중간 진행상황, Result는 최종 결과다. Nav2 이동과 MoveIt trajectory가 Action인 이유는 작업 시간이 길고 취소·preemption이 실제 요구이기 때문이다.

Action은 Goal을 받고, 처리 중 Feedback을 보내며, 끝나면 Result를 반환한다. 필요하면 Cancel도 지원한다. Nav2의 NavigateToPose, MoveIt2의 trajectory 수행 같은 기능이 Action과 잘 맞는 이유는 “끝날 때까지 시간이 걸리고, 진행 중 상태와 취소가 필요하기 때문”이다.

Bash복사

ros2 action list -t
ros2 action info /navigate_to_pose
ros2 action send_goal /fibonacci example_interfaces/action/Fibonacci "{order: 8}" --feedback

Action을 “오래 걸리는 Service”라고만 생각하면 부족하다. Server는 Goal을 accept/reject할 수 있고, goal마다 상태가 존재한다. Client는 future/callback 형태로 결과를 비동기적으로 받을 수 있다. 이 비동기성을 이해해야 GUI나 상위 task manager가 로봇 움직임 동안 멈추지 않는다.

22.3 Parameter: 알고리즘과 튜닝값을 분리한다#

Parameter는 런타임 설정값을 코드 밖으로 드러낸다. 모든 변수를 parameter로 만들 필요는 없다. 운영 중 튜닝하거나 장비별로 바뀌는 값, launch/YAML로 배포해야 하는 값을 parameter로 만들고 내부 구현 세부값은 코드 안에 두는 편이 인터페이스가 명확하다.

Bash복사

self.declare_parameter('max_speed', 0.5)
max_speed = self.get_parameter('max_speed').value

# CLI
ros2 param list
ros2 param get /my_node max_speed
ros2 param set /my_node max_speed 0.3

Nav2와 MoveIt2처럼 파라미터가 많은 시스템에서는 YAML 파일이 사실상 시스템 설정 문서 역할을 한다. 파라미터 이름만 복사해 쓰지 말고 “어떤 subsystem의 어떤 물리적/알고리즘적 의미를 바꾸는가”를 이해해야 튜닝이 가능하다.

22.4 Launch: 시스템 구성을 코드로 만든다#

Launch는 여러 process를 띄우는 편의 기능을 넘어 namespace, remapping, parameter file, 조건, event handler, include 관계를 묶어 재현 가능한 시스템 구성을 만든다. 수동으로 터미널 여러 개를 열어야만 동작하는 시스템은 다른 사람이 재현하기 어렵다.

Python복사

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(package='learning_ros2', executable='status_pub',
             name='status_pub', parameters=[{'rate_hz': 2.0}]),
        Node(package='learning_ros2', executable='status_sub',
             name='status_sub'),
    ])

Launch Python 해설 Python launch 파일은 일반 Python 스크립트처럼 보이지만 ROS launch 시스템이 generate_launch_description()을 찾아 실행한다. LaunchDescription은 시작할 action들의 묶음이고, launch_ros.actions.Node는 특정 package/executable을 어떤 name·parameter·remap으로 실행할지 선언한다.

22.4.1 대화형 노드를 별도 터미널에서 실행하기#

키보드 입력을 직접 읽는 turtle_teleop_key는 일반 노드와 달리 사용자가 초점을 둔 대화형 터미널이 필요하다. 다음 Launch 파일은 turtlesim_node를 현재 Launch 프로세스에서 시작하고, teleop 노드는 GNOME Terminal 창을 하나 열어 그 안에서 실행한다.

from launch import LaunchDescription
from launch_ros.actions import Node


def generate_launch_description():
    turtlesim_node = Node(
        package='turtlesim',
        executable='turtlesim_node',
        name='turtlesim',
        output='screen',
    )

    teleop_node = Node(
        package='turtlesim',
        executable='turtle_teleop_key',
        name='turtle_teleop_key',
        output='screen',
        prefix='gnome-terminal --wait --',
    )

    return LaunchDescription([
        turtlesim_node,
        teleop_node,
    ])

Node의 package와 executable은 실행할 ROS(Robot Operating System, 로봇 운영체제) 패키지와 등록된 실행 파일을 지정하고, name은 ROS Graph에 보이는 노드 이름을 정한다. output='screen'은 표준 출력과 오류를 실행 화면에 보이게 한다. prefix는 실제 노드 명령 앞에 외부 명령을 붙이는 옵션이다. 여기서는 gnome-terminal이 새 창을 열고, --wait는 그 창에서 실행한 명령이 끝날 때까지 터미널 프로세스를 유지하며, 마지막 --는 터미널 옵션과 뒤의 노드 명령을 구분한다.

이 방식은 GNOME Terminal과 그래픽 세션이 있는 Ubuntu 데스크톱에 의존한다. SSH(Secure Shell, 보안 원격 셸) 접속, 컨테이너, CI(Continuous Integration, 지속적 통합) 같은 헤드리스 환경에서는 창을 열 수 없으므로 prefix를 제거하고 turtlesim_node만 Launch로 시작한 뒤, 입력 가능한 별도 터미널에서 ros2 run turtlesim turtle_teleop_key를 실행한다. 터미널 종류가 다르면 prefix 명령도 해당 프로그램의 실행 옵션에 맞게 바꿔야 한다.

Launch 파일은 소스 폴더에 존재하는 것만으로 ros2 launch에서 검색되지 않는다. ament_python 패키지라면 launch 폴더를 package share 디렉터리에 설치하도록 setup.py의 data_files에 등록한다. 아래 예에서는 launch/turtlesim_with_teleop.launch.py를 설치한다.

from glob import glob
import os


data_files=[
    # 기존 항목 유지
    (
        os.path.join('share', package_name, 'launch'),
        glob('launch/*.launch.py'),
    ),
]

cd ~/ros2_ws
colcon build --packages-select turtle_robot --symlink-install
source install/setup.bash
ros2 launch turtle_robot turtlesim_with_teleop.launch.py

setup.py 또는 launch 파일 설치 규칙을 바꾼 뒤에는 다시 빌드하고 새 install/setup.bash를 source해야 한다. ros2 launch의 첫 인자는 패키지 이름이고 둘째 인자는 install 공간의 share/<package>/launch에서 찾을 Launch 파일 이름이다.

22.5 Namespace와 Remapping#

Node 코드는 가능한 한 상대 이름을 사용하고, 배포 시 namespace와 remapping으로 실제 연결을 결정하는 편이 재사용성이 높다. 같은 perception node를 `/robot1`과 `/robot2`에 각각 올릴 수 있는 이유가 이 이름 해석 계층 때문이다.

같은 노드를 여러 로봇에 재사용하려면 하드코딩된 절대 Topic 이름을 줄이고 namespace/remapping을 이용한다. `/robot1/camera/image_raw`와 `/robot2/camera/image_raw`처럼 분리하면 같은 코드로 여러 인스턴스를 운영할 수 있다.

Bash복사

ros2 run turtlesim turtlesim_node --ros-args -r __ns:=/robot1
ros2 run my_pkg vision_node --ros-args -r image:=/camera/color/image_raw

Remapping 해설 -r은 remap 규칙을 뜻한다. __ns:=/robot1은 노드의 namespace를 바꾸는 특별 규칙이고, image:=/camera/color/image_raw처럼 일반 이름도 다른 이름에 연결할 수 있다. 코드를 바꾸지 않고 배포 환경에서 연결만 바꾸는 것이 remapping의 목적이다.

22.6 Lifecycle Node: 시작과 준비 완료를 구분한다#

일반 Node는 프로세스가 뜨면 곧바로 기능을 수행하지만, 실제 시스템에서는 장비 연결·지도 로드·controller 초기화 같은 준비 단계를 분리해야 할 때가 많다. Lifecycle은 configure/activate/deactivate/cleanup을 명시해 살아 있음과 서비스 가능함을 구분한다.

일반 노드는 프로세스가 실행되면 곧바로 동작한다. 하지만 지도 서버나 controller처럼 리소스 준비 순서가 중요한 컴포넌트는 configure와 activate를 분리하는 편이 안전하다. Lifecycle Node는 Unconfigured → Inactive → Active 등의 상태를 명시적으로 관리한다. Nav2가 여러 서버를 안정적으로 bringup하는 데 이 구조를 사용한다.

Bash복사

ros2 lifecycle nodes
ros2 lifecycle get /controller_server
ros2 lifecycle set /some_node configure
ros2 lifecycle set /some_node activate

Lifecycle CLI(Command-Line Interface, 명령줄 인터페이스) 해설 ros2 lifecycle get은 현재 state를 읽고, ros2 lifecycle set은 configure/activate 같은 transition을 요청한다. 프로세스가 실행 중이라는 사실과 lifecycle state가 Active라는 사실은 별개다.

상태와 프로세스의 차이 프로세스가 살아 있다는 사실과 기능이 Active라는 사실은 다르다. Nav2 서버가 node list에 보인다고 바로 navigation 요청을 받을 준비가 된 것은 아니다.

장 핵심 정리#

• Service는 짧은 request-response, Action은 장시간 작업의 상태 흐름을 표현한다.

• Parameter는 코드에서 튜닝값을 분리한다.

• Launch는 시스템 구성을 재현 가능한 코드로 만든다.

• Lifecycle은 “프로세스 존재”와 “기능 활성화”를 분리한다.

확인 문제#

1. 그리퍼 닫기 명령을 Service와 Action 중 무엇으로 만들지 판단 기준을 설명하라.

2. Launch가 단순 shell script보다 좋은 이유를 세 가지 적어라.

3. Nav2에서 Lifecycle이 유용한 이유를 설명하라.

23장. Topic·Service·Action·Launch·Remapping을 직접 구현하기#

이 장을 끝내면 짧은 RPC와 장시간 작업 인터페이스를 직접 구분하고 구현한다.

23.1 Topic: 생산자와 소비자를 분리한다#

먼저 하나의 정수를 주기적으로 발행하고 다른 노드가 구독해 누적합을 계산한다. 숫자 자체는 단순하지만 Publisher와 Subscriber가 서로의 Python 객체를 전혀 알지 않는다는 점이 핵심이다.

number_pub.py#

Python복사

import rclpy
from rclpy.node import Node
from std_msgs.msg import Int32


class NumberPublisher(Node):
    def __init__(self):
        super().__init__('number_pub')
        self.declare_parameter('rate_hz', 2.0)
        self.declare_parameter('start', 0)
        rate = float(self.get_parameter('rate_hz').value)
        self.value = int(self.get_parameter('start').value)
        self.pub = self.create_publisher(Int32, 'numbers', 10)
        self.timer = self.create_timer(1.0 / rate, self.tick)

    def tick(self):
        msg = Int32()
        msg.data = self.value
        self.pub.publish(msg)
        self.get_logger().info(f'publish {msg.data}')
        self.value += 1


def main(args=None):
    rclpy.init(args=args)
    node = NumberPublisher()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()


if __name__ == '__main__':
    main()

number_sub.py#

Python복사

import rclpy
from rclpy.node import Node
from std_msgs.msg import Int32


class NumberSubscriber(Node):
    def __init__(self):
        super().__init__('number_sub')
        self.total = 0
        self.sub = self.create_subscription(Int32, 'numbers', self.on_number, 10)

    def on_number(self, msg):
        self.total += msg.data
        self.get_logger().info(f'received={msg.data}, running_sum={self.total}')


def main(args=None):
    rclpy.init(args=args)
    node = NumberSubscriber()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()


if __name__ == '__main__':
    main()

23.2 두 터미널에서 실행하고 Graph를 관찰한다#

Bash복사

# 터미널 A
ros2 run r2lab_nodes number_pub

# 터미널 B
ros2 run r2lab_nodes number_sub

# 터미널 C
ros2 topic list -t
ros2 topic info /numbers -v
ros2 topic echo /numbers
ros2 topic hz /numbers
rqt_graph

`topic info -v`에서 endpoint와 QoS(Quality of Service, 서비스 품질) profile까지 본다. “Topic이 존재한다”만으로는 충분하지 않다. Publisher 수, Subscriber 수, 타입, reliability/durability가 기대와 맞는지 확인한다.

23.3 Launch와 Remapping#

Python복사

from launch import LaunchDescription
from launch_ros.actions import Node


def generate_launch_description():
    return LaunchDescription([
        Node(
            package='r2lab_nodes',
            executable='number_pub',
            name='number_source',
            parameters=[{'rate_hz': 4.0, 'start': 10}],
            remappings=[('numbers', '/lab/numbers')],
            output='screen',
        ),
        Node(
            package='r2lab_nodes',
            executable='number_sub',
            name='number_sink',
            remappings=[('numbers', '/lab/numbers')],
            output='screen',
        ),
    ])

Bash복사

ros2 launch r2lab_nodes basics.launch.py
rqt_graph

Launch 파일은 두 프로세스를 단순히 동시에 띄우는 기능을 넘어 node name, parameter, remapping을 한 곳에서 재현한다. 같은 executable을 다른 Topic 구조에 붙일 수 있기 때문에 노드 코드에 절대 Topic 이름을 하드코딩하는 습관을 줄일 수 있다.

23.4 Service: 짧은 요청/응답을 직접 만든다#

`r2lab_interfaces/srv/SetMode.srv`는 요청에 문자열 mode 하나를 받고, 응답으로 accepted와 message를 반환한다.

Code복사

string mode
---
bool accepted
string message

mode_server.py#

Python복사

import rclpy
from rclpy.node import Node
from r2lab_interfaces.srv import SetMode


class ModeServer(Node):
    def __init__(self):
        super().__init__('mode_server')
        self.mode = 'idle'
        self.srv = self.create_service(SetMode, 'set_mode', self.on_set_mode)

    def on_set_mode(self, request, response):
        allowed = {'idle', 'manual', 'auto'}
        if request.mode not in allowed:
            response.accepted = False
            response.message = f'unknown mode: {request.mode}'
            return response
        old = self.mode
        self.mode = request.mode
        response.accepted = True
        response.message = f'{old} -> {self.mode}'
        self.get_logger().info(response.message)
        return response


def main(args=None):
    rclpy.init(args=args)
    node = ModeServer()
    try:
        rclpy.spin(node)
    finally:
        node.destroy_node()
        rclpy.shutdown()


if __name__ == '__main__':
    main()

mode_client.py#

Python복사

import sys
import rclpy
from rclpy.node import Node
from r2lab_interfaces.srv import SetMode


class ModeClient(Node):
    def __init__(self):
        super().__init__('mode_client')
        self.client = self.create_client(SetMode, 'set_mode')

    def request(self, mode):
        while not self.client.wait_for_service(timeout_sec=1.0):
            self.get_logger().info('waiting for /set_mode ...')
        req = SetMode.Request()
        req.mode = mode
        return self.client.call_async(req)


def main(args=None):
    rclpy.init(args=args)
    node = ModeClient()
    mode = sys.argv[1] if len(sys.argv) > 1 else 'auto'
    future = node.request(mode)
    rclpy.spin_until_future_complete(node, future)
    result = future.result()
    if result is not None:
        node.get_logger().info(
            f'accepted={result.accepted}, message={result.message}')
    node.destroy_node()
    rclpy.shutdown()


if __name__ == '__main__':
    main()

비동기 Service 해설 create_client()는 Service client handle을 만든다. wait_for_service()는 server가 discovery될 때까지 기다리고, call_async()는 요청을 보내고 Future를 즉시 돌려준다. Future.result()는 완료된 뒤 실제 Response 객체를 얻는다. callback 안에서 동기 대기를 만들면 executor deadlock으로 이어질 수 있어 비동기 흐름을 기본으로 이해하는 편이 안전하다.

Bash복사

# 서버
ros2 run r2lab_nodes mode_server

# CLI로 직접 요청
ros2 service list -t
ros2 service call /set_mode r2lab_interfaces/srv/SetMode "{mode: auto}"
ros2 service call /set_mode r2lab_interfaces/srv/SetMode "{mode: impossible}"

# Python client
ros2 run r2lab_nodes mode_client auto

Service callback은 가능한 빨리 끝나야 한다. 10초 동안 로봇이 이동하는 동작을 service callback 안에서 직접 수행하면서 다른 callback까지 막는 설계는 피한다. 장시간·취소 가능 작업은 Action의 의미와 맞는다.

23.5 Action: goal-feedback-result-cancel을 직접 만든다#

Code복사

float32 target_x
float32 duration_sec
---
bool success
string message
---
float32 progress

timed_move_server.py#

Python복사

import time
import rclpy
from rclpy.action import ActionServer, CancelResponse, GoalResponse
from rclpy.node import Node
from r2lab_interfaces.action import TimedMove


class TimedMoveServer(Node):
    def __init__(self):
        super().__init__('timed_move_server')
        self.server = ActionServer(
            self,
            TimedMove,
            'timed_move',
            execute_callback=self.execute,
            goal_callback=self.on_goal,
            cancel_callback=self.on_cancel,
        )

    def on_goal(self, goal_request):
        if goal_request.duration_sec <= 0.0:
            return GoalResponse.REJECT
        return GoalResponse.ACCEPT

    def on_cancel(self, goal_handle):
        return CancelResponse.ACCEPT

    def execute(self, goal_handle):
        goal = goal_handle.request
        feedback = TimedMove.Feedback()
        steps = 20
        sleep_s = float(goal.duration_sec) / steps

        for i in range(steps):
            if goal_handle.is_cancel_requested:
                goal_handle.canceled()
                result = TimedMove.Result()
                result.success = False
                result.message = 'canceled'
                return result
            time.sleep(sleep_s)
            feedback.progress = float(i + 1) / steps
            goal_handle.publish_feedback(feedback)

        goal_handle.succeed()
        result = TimedMove.Result()
        result.success = True
        result.message = f'reached logical target x={goal.target_x:.2f}'
        return result


def main(args=None):
    rclpy.init(args=args)
    node = TimedMoveServer()
    try:
        rclpy.spin(node)
    finally:
        node.server.destroy()
        node.destroy_node()
        rclpy.shutdown()


if __name__ == '__main__':
    main()

Action API(Application Programming Interface, 응용 프로그램 인터페이스) 해설 Action은 Service보다 긴 작업을 위해 goal, feedback, result, cancel 상태를 가진다. GoalResponse는 goal을 받을지 결정하고, CancelResponse는 취소 요청을 허용할지 결정한다. server/client 코드는 goal handle을 통해 각 작업 인스턴스의 상태를 추적한다.

timed_move_client.py#

Python복사

import rclpy
from rclpy.action import ActionClient
from rclpy.node import Node
from r2lab_interfaces.action import TimedMove


class TimedMoveClient(Node):
    def __init__(self):
        super().__init__('timed_move_client')
        self.client = ActionClient(self, TimedMove, 'timed_move')

    def send(self, target_x=1.0, duration_sec=4.0):
        self.client.wait_for_server()
        goal = TimedMove.Goal()
        goal.target_x = float(target_x)
        goal.duration_sec = float(duration_sec)
        return self.client.send_goal_async(goal, feedback_callback=self.on_feedback)

    def on_feedback(self, msg):
        self.get_logger().info(f'progress={msg.feedback.progress:.0%}')


def main(args=None):
    rclpy.init(args=args)
    node = TimedMoveClient()
    send_future = node.send()
    rclpy.spin_until_future_complete(node, send_future)
    goal_handle = send_future.result()
    if not goal_handle.accepted:
        node.get_logger().error('goal rejected')
    else:
        result_future = goal_handle.get_result_async()
        rclpy.spin_until_future_complete(node, result_future)
        result = result_future.result().result
        node.get_logger().info(f'{result.success}: {result.message}')
    node.destroy_node()
    rclpy.shutdown()


if __name__ == '__main__':
    main()

Bash복사

# 터미널 A
ros2 run r2lab_nodes timed_move_server

# 터미널 B: CLI에서 feedback까지 관찰
ros2 action list -t
ros2 action send_goal /timed_move r2lab_interfaces/action/TimedMove \
  "{target_x: 1.0, duration_sec: 5.0}" --feedback

# 터미널 C: Python client
ros2 run r2lab_nodes timed_move_client

Action CLI(Command-Line Interface, 명령줄 인터페이스) 해설 ros2 action send_goal은 CLI에서 Action goal을 보낸다. --feedback을 붙이면 실행 중 feedback 메시지도 계속 표시한다. Action은 goal/result/feedback/cancel 채널을 내부적으로 묶어 하나의 장시간 작업 인터페이스로 제공한다.