Booil Jung

ROS2 Humble Hawksbill 설치 보고서

Robot Operating System 2 (ROS2) Humble Hawksbill은 2022년 5월에 릴리스된 장기 지원(Long-Term Support, LTS) 배포판이다. LTS 릴리스는 안정성과 장기적인 유지보수가 중요한 상용 제품 개발 및 장기간의 학술 연구 프로젝트에 있어 핵심적인 역할을 수행한다. Humble Hawksbill은 2027년 5월까지 표준 지원이 보장되므로, 개발자는 예측 가능한 유지보수 로드맵 하에 안정적인 로봇 애플리케이션을 구축하고 배포할 수 있다. 이는 단순한 기능 제공을 넘어, 보안 패치, 버그 수정, 그리고 커뮤니티 지원의 지속성을 보장한다는 점에서 중요한 의미를 가진다.

ROS2를 시스템에 설치하는 방법은 크게 두 가지로 나뉜다: 데비안 패키지를 통한 바이너리 설치와 소스 코드로부터 직접 빌드하는 방법이다.

데비안 패키지 설치는 대다수의 사용자를 위해 공식적으로 권장되는 방식이다. 이 방법은 apt 패키지 관리자를 사용하여 사전 컴파일된 바이너리를 설치하므로, 복잡한 의존성 패키지들을 자동으로 해결하고 시스템의 정규 업데이트 프로세스와 원활하게 통합된다는 장점이 있다. ROS2를 ‘있는 그대로’ 즉시 활용하여 개발을 시작하고자 하는 사용자에게 가장 빠르고 안정적인 경로를 제공한다.

소스 코드 빌드는 보다 높은 수준의 제어와 유연성이 필요한 고급 사용자 및 개발자를 위한 방법이다. ROS2의 핵심 패키지를 직접 수정하거나, 공식 바이너리를 지원하지 않는 운영체제(예: Debian Bullseye, 최신 Raspberry Pi OS)에 설치하거나, 아직 공식 릴리스에 포함되지 않은 최신 개발 버전을 사용해야 할 경우 이 방법이 필수적이다. 그러나 이 방식은 rosdep을 통한 의존성 수동 관리와 colcon을 이용한 전체 빌드 과정의 복잡성을 수반하며, 상당한 시간과 전문 지식을 요구한다.

ROS2 배포판은 특정 Ubuntu 버전에 강하게 결속되어 있다는 특징을 가진다. 예를 들어, Humble Hawksbill은 Ubuntu 22.04 (Jammy Jellyfish)를 공식 지원 플랫폼으로 지정하고 있다. 이러한 강한 결속은 해당 환경에서 최고의 안정성을 보장하는 기반이 되지만, 동시에 다른 Linux 배포판이나 다른 버전의 Ubuntu를 사용하는 개발자들은 공식 바이너리 패키지의 편리함을 누릴 수 없다는 근본적인 한계를 드러낸다. 결과적으로, 특정 하드웨어 제약이나 운영체제 요구사항을 가진 광범위한 사용자층은 필연적으로 더 복잡하고 잠재적 오류 발생 가능성이 높은 ‘소스 코드 빌드’ 경로를 선택할 수밖에 없다. 이는 ROS 커뮤니티 내에서 기술적 진입 장벽을 높이는 요인으로 작용할 수 있다.

따라서 본 보고서에서 제시하는 데비안 패키지를 통한 설치 방법은 ‘Ubuntu 22.04 사용자’라는 명확한 전제 조건 하에서 가장 안정적이고 효율적인 선택지임을 명확히 인지해야 한다. 본 보고서는 이 방법을 중심으로, 시스템 요구사항부터 설치, 검증, 그리고 문제 해결에 이르기까지의 전 과정을 상세히 기술하는 데 초점을 맞춘다.

ROS2 Humble Hawksbill의 안정적인 설치와 운영을 위해서는 공식적으로 지원되는 플랫폼 환경을 갖추는 것이 필수적이다.

ROS2 설치를 진행하기에 앞서, 운영체제와 모든 시스템 패키지를 최신 상태로 업데이트하는 것은 가장 중요하고 선행되어야 할 단계이다. 특히 새로 설치한 Ubuntu 22.04 시스템에서는 이 과정이 생략될 경우 치명적인 문제를 야기할 수 있다.

sudo apt update && sudo apt upgrade -y

이 단계가 중요한 기술적 이유는 ROS2 패키지와 시스템의 핵심 라이브러리 간의 의존성 관계에 있다. ROS2 Humble의 데스크톱 버전(ros-humble-desktop)은 libudev1과 같은 특정 버전의 라이브러리에 의존한다. 만약 시스템이 초기 설치 상태에 머물러 있어 구버전의 systemd 및 udev 관련 패키지를 가지고 있다면, apt 패키지 관리자는 이 의존성 충돌을 해결하기 위해 예상치 못한 결정을 내릴 수 있다. 최악의 경우, apt는 libudev1을 설치하기 위해 ubuntu-desktop, systemd, udev 등 시스템 운영에 필수적인 핵심 패키지들을 제거하려고 시도할 수 있다. 이는 GUI 환경의 손상은 물론, 시스템을 부팅 불능 상태로 만들 수 있는 매우 심각한 문제이다. 따라서, ROS2 설치 전 시스템을 완전히 업데이트하는 것은 선택이 아닌 필수 절차이다.

ROS2의 다양한 커맨드라인 도구(CLI)와 그래픽 도구(GUI)는 파일 경로, 로그 메시지, 설정 파일 등을 처리할 때 UTF-8 문자 인코딩을 가정하고 동작한다. 시스템 로케일이 UTF-8을 지원하도록 설정되어 있지 않으면, 패키지 빌드나 노드 실행 과정에서 예기치 않은 파싱 오류나 동작 이상이 발생할 수 있다. 특히 Docker 컨테이너와 같이 최소한의 환경으로 구성된 시스템에서는 기본 로케일이 POSIX로 설정되어 있을 수 있어 이 설정이 더욱 중요하다.

다음 절차에 따라 시스템 로케일을 확인하고 en_US.UTF-8로 설정한다.

  1. 현재 로케일 확인:

    locale 명령어를 실행하여 출력 결과에 UTF-8이 포함되어 있는지 확인한다.

  2. 로케일 패키지 설치 및 생성:

    만약 UTF-8 로케일이 설정되어 있지 않다면, 다음 명령어를 순차적으로 실행하여 필요한 패키지를 설치하고 로케일을 생성한다.

    sudo apt update && sudo apt install locales
sudo locale-gen en_US en_US.UTF-8

  3. 시스템 기본 로케일 업데이트:

    시스템 전반에 걸쳐 기본 로케일 설정을 적용한다.

    sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8

  4. 현재 쉘 환경에 적용:

    변경된 설정을 즉시 현재 터미널 세션에 적용하기 위해 환경 변수를 export한다.

    export LANG=en_US.UTF-8

  5. 최종 확인:

    다시 locale 명령어를 실행하여 LANG과 LC_ALL 등의 변수가 en_US.UTF-8로 올바르게 설정되었는지 최종 확인한다.

이러한 사전 준비 단계들은 단순히 설치를 위한 절차를 넘어, 설치 과정이나 이후 ROS2 사용 중에 문제가 발생했을 때 가장 먼저 확인해야 할 ‘진단 기준선(Diagnostic Baseline)’의 역할을 한다. 대부분의 초기 문제는 ROS2 자체의 복잡성보다는 이러한 기본적인 시스템 환경 설정의 누락에서 비롯되는 경우가 많기 때문이다. 문제가 발생했을 때 이 설정들이 올바르게 완료되었는지 확인함으로써, 문제의 범위를 효과적으로 좁히고 근본 원인에 더 빠르게 접근할 수 있다.

ROS2 패키지를 apt를 통해 설치하기 위해서는, 시스템이 ROS2 패키지 저장소의 위치를 알고 해당 저장소를 신뢰할 수 있도록 설정하는 과정이 필요하다. 이 과정은 세 가지 명확한 단계로 구성되며, 반드시 아래 제시된 순서대로 진행해야 한다.

ROS2의 많은 의존성 패키지들은 Ubuntu의 공식 ‘Main’ 저장소가 아닌, 커뮤니티에 의해 유지보수되는 ‘Universe’ 저장소에 포함되어 있다. 따라서 ROS2 설치에 앞서 이 저장소를 반드시 활성화해야 한다.

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

apt는 패키지를 설치할 때 해당 패키지가 신뢰할 수 있는 출처로부터 제공되었으며, 전송 과정에서 변조되지 않았음을 암호학적으로 검증한다. 이 검증을 위해, ROS2 패키지 저장소의 소유자인 Open Robotics의 GPG(GNU Privacy Guard) 공개 키를 시스템의 신뢰 목록에 추가해야 한다. 이는 악의적인 패키지 설치로부터 시스템을 보호하는 필수적인 보안 절차이다.

sudo apt update && sudo apt install curl -y
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg

위 명령어는 curl을 사용하여 공식 ROS 배포판 GitHub 저장소에서 공개 키 파일을 다운로드하고, 이를 apt가 키링 파일로 인식하는 표준 위치인 /usr/share/keyrings/ 디렉토리에 저장한다.

마지막으로, 시스템의 패키지 소스 목록에 공식 ROS2 저장소의 주소를 추가한다. 이 주소는 /etc/apt/sources.list.d/ros2.list 파일에 저장된다. 아래 명령어는 쉘 스크립팅을 활용하여 현재 시스템의 아키텍처(예: amd64, arm64)와 Ubuntu 배포판의 코드명(예: jammy)을 자동으로 탐지하여 정확한 저장소 주소를 동적으로 생성한다.

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null

이 명령어가 성공적으로 실행되면, apt는 이제 ROS2 Humble 패키지를 찾고 설치할 준비를 마치게 된다.

저장소 설정이 완료된 후, apt가 새로 추가된 ROS2 저장소의 패키지 목록을 인지할 수 있도록 패키지 캐시를 다시 한번 업데이트한다.

sudo apt update

이제 사용자의 목적과 필요에 따라 적절한 ROS2 메타패키지를 선택하여 설치할 수 있다. ROS2는 여러 개의 메타패키지를 제공하여 설치 규모를 조절할 수 있도록 한다.

일반적인 개발 환경에서는 ros-humble-desktop과 ros-dev-tools를 모두 설치하는 것이 가장 좋다.

ROS2 패키지를 성공적으로 설치했더라도, 터미널에서 ros2와 같은 명령어를 즉시 사용할 수는 없다. ROS2 관련 실행 파일과 라이브러리를 현재 터미널 세션에서 인식할 수 있도록 환경을 설정하는 과정이 필요하다. 이 과정은 ‘소싱(sourcing)’이라고 불리며, setup.bash 스크립트를 실행하여 수행된다.

source /opt/ros/humble/setup.bash

이 source 명령어는 /opt/ros/humble/ 디렉토리에 위치한 setup.bash 스크립트를 현재 쉘의 컨텍스트 내에서 실행한다. 이 스크립트의 핵심적인 역할은 다음과 같다:

이 환경 설정은 현재 터미널 세션에만 유효하다. 따라서 새 터미널 창을 열 때마다 이 소싱 과정을 반복해야 한다.

매번 새 터미널을 열 때마다 source 명령어를 수동으로 입력하는 것은 번거로운 작업이다. 이 과정을 자동화하기 위해, 쉘이 시작될 때마다 자동으로 실행되는 스크립트 파일에 해당 명령어를 추가할 수 있다. bash 쉘을 사용하는 경우, 이 파일은 사용자의 홈 디렉토리에 있는 ~/.bashrc이다.

다음 명령어를 실행하면 source /opt/ros/humble/setup.bash 라인이 ~/.bashrc 파일의 맨 끝에 추가된다.

echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc

이후, 변경된 .bashrc 파일을 현재 터미널에 즉시 적용하거나, 새 터미널을 열면 자동으로 ROS2 환경이 활성화된다. 현재 터미널에 바로 적용하려면 다음 명령어를 실행한다.

source ~/.bashrc

이 자동화 설정은 ROS2 개발 환경의 편의성을 크게 향상시키며, 개발자가 환경 설정의 번거로움 없이 즉시 작업에 집중할 수 있도록 돕는다.

설치가 성공적으로 완료되었고, ROS2의 핵심 통신 시스템이 올바르게 작동하는지 확인하기 위한 최종 검증 절차를 수행한다. demo_nodes_cpp와 demo_nodes_py 패키지에 포함된 talker와 listener 예제 노드를 실행하는 것은 C++와 Python 클라이언트 라이브러리가 모두 정상적으로 설치되고 연동되는지 동시에 확인할 수 있는 가장 확실한 방법이다.

검증 절차는 두 개의 터미널 창을 사용하여 진행한다.

  1. 첫 번째 터미널 (Publisher 실행):

    새 터미널을 열고 C++로 작성된 talker 노드를 실행한다. 이 노드는 chatter라는 토픽으로 “Hello World” 메시지와 카운터를 주기적으로 발행(publish)하기 시작한다.

    ros2 run demo_nodes_cpp talker

    터미널에는 [INFO][minimal_publisher]: Publishing: 'Hello World: 1', [INFO][minimal_publisher]: Publishing: 'Hello World: 2' 와 같은 로그가 계속해서 출력될 것이다.

  2. 두 번째 터미널 (Subscriber 실행):

    별도의 새 터미널을 열고 Python으로 작성된 listener 노드를 실행한다. 이 노드는 chatter 토픽을 구독(subscribe)하여, talker 노드가 발행하는 메시지를 수신하고 화면에 출력한다.

    ros2 run demo_nodes_py listener

성공 기준: listener 노드를 실행한 두 번째 터미널에 [INFO][minimal_subscriber]: I heard:, [INFO][minimal_subscriber]: I heard: 와 같이 talker가 보내는 메시지가 순차적으로 출력된다면, 설치가 성공적으로 완료된 것이다. 이는 ROS2의 핵심 통신 메커니즘인 DDS(Data Distribution Service) 기반의 발행/구독 모델이 C++와 Python 노드 간에 완벽하게 작동하고 있음을 증명한다.

이 간단한 데모는 ROS2의 가장 기본적인 통신 방식을 보여준다. ROS2의 개념을 더 깊이 이해하고 싶다면, 공식 튜토리얼을 따라 직접 publisher와 subscriber 노드를 C++ 또는 Python으로 작성하고 colcon으로 빌드해보는 과정을 진행하는 것이 좋다.

ROS2 설치 과정은 대부분 원활하게 진행되지만, 시스템 환경이나 사용자 실수로 인해 몇 가지 예측 가능한 문제들이 발생할 수 있다. 이 장에서는 가장 빈번하게 발생하는 오류 유형을 체계적으로 분석하고, 그 원인과 명확한 해결 방안을 제시한다.

APT 저장소 설정 단계에서 발생하는 오류는 대부분 절차의 순서나 명령어의 정확성과 관련이 있다.

설치는 성공적으로 완료되었으나, 데모 노드 간 통신이 이루어지지 않거나 ros2 node list, ros2 topic list 등의 명령어가 아무런 출력을 내지 못하는 경우가 있다.

ROS2 Humble을 시스템에서 완전히 제거하거나, 소스 빌드로 전환하기 위해 기존 바이너리 설치를 삭제해야 할 경우 다음 명령어를 사용한다. ~nros-humble-* 와일드카드는 ros-humble-로 시작하는 모든 패키지를 대상으로 지정하여 일괄적으로 제거한다.

sudo apt remove ~nros-humble-* && sudo apt autoremove

autoremove는 ROS2 패키지들이 의존했지만 더 이상 다른 패키지에서 필요로 하지 않는 라이브러리들을 함께 정리해준다. 시스템을 설치 이전의 상태로 완전히 되돌리려면, 추가적으로 /etc/apt/sources.list.d/ros2.list 파일과 /usr/share/keyrings/ros-archive-keyring.gpg 파일을 수동으로 삭제하는 것이 좋다.

오류 유형 (Error Type) 대표 메시지 (Example Message) 원인 분석 (Cause Analysis) 해결 방안 (Resolution)
GPG Key Error NO_PUBKEY F42ED6FBAB17C654 ROS2 저장소의 GPG 공개 키가 시스템에 등록되지 않았거나, 저장소 추가 이후에 키 등록을 시도함. sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg 명령어를 재실행하여 키를 등록한다.
Repository Error 404 Not Found, E: The repository '... jammy Release' does not have a Release file. 지원되지 않는 OS 버전(예: Ubuntu 20.04)에서 설치를 시도하거나, /etc/apt/sources.list.d/ros2.list 파일의 URL이 잘못됨(예: ROS1 주소 오기입). OS 버전을 확인하고, ros2.list 파일의 내용을 공식 문서와 대조하여 정확한 저장소 주소로 수정한다.
Network Error ros2 run 예제 실행 시 노드 간 통신 불가, ros2 topic list에 아무것도 표시되지 않음. 시스템 방화벽(ufw)이 ROS2 노드 탐색에 사용되는 DDS 멀티캐스트(UDP) 트래픽을 차단함. ros2 multicast send/receive로 테스트 후, sudo ufw allow in proto udp to 224.0.0.0/4 명령어로 방화벽을 설정한다.
Dependency Conflict apt가 ubuntu-desktop 등 중요 시스템 패키지 제거를 시도함. ROS2 설치 전 sudo apt upgrade를 실행하지 않아, 시스템의 핵심 라이브러리(예: systemd, udev)와 ROS2 의존성 간 버전 충돌 발생. sudo apt update && sudo apt upgrade -y를 먼저 실행하여 시스템을 최신 상태로 만든 후, ROS2 설치를 재시도한다.

본 보고서에서 다룬 데비안 패키지 설치가 대부분의 사용자에게 권장되지만, 특정 시나리오에서는 소스 코드로부터 직접 ROS2를 빌드하는 것이 필수적이거나 더 유리하다. 소스 빌드가 필요한 명확한 사례는 다음과 같다.

ROS2 소스 빌드는 정해진 도구 체인(toolchain)을 사용하여 체계적으로 진행된다. 전체 과정을 상세히 다루지는 않지만, 핵심 도구들의 역할에 대한 개념적 이해는 다음과 같다.

  1. 소스 코드 다운로드 (vcstool): ROS2는 수백 개의 개별 git 저장소에 분산되어 있다. vcstool은 .repos라는 매니페스트 파일을 읽어, 이 모든 저장소의 소스 코드를 지정된 작업 공간(workspace)의 src 디렉토리로 한 번에 클론하거나 업데이트하는 역할을 한다.
  2. 의존성 설치 (rosdep): 소스 코드를 컴파일하기 전에, 해당 코드들이 의존하는 시스템 라이브러리(예: libconsole-bridge-dev, python3-yaml)들이 먼저 설치되어야 한다. rosdep은 작업 공간 내 모든 패키지의 package.xml 파일을 스캔하여 필요한 모든 시스템 의존성을 목록으로 만든 뒤, apt와 같은 시스템 패키지 관리자를 통해 자동으로 설치해주는 강력한 도구이다.
  3. 컴파일 및 설치 (colcon): colcon(collective construction)은 ROS2의 공식 빌드 도구이다. colcon은 작업 공간 내 패키지들의 의존성 관계를 분석하여 올바른 순서로 병렬 빌드를 수행한다. 빌드가 완료되면, 결과물(실행 파일, 라이브러리, 파이썬 파일, 설정 파일 등)을 install 디렉토리에 체계적으로 정리하여 설치한다.

소스 빌드는 최고의 유연성과 제어 능력을 제공하지만, 그에 상응하는 비용과 단점을 명확히 인지해야 한다.

결론적으로, 소스 코드 빌드는 명확한 목적을 가진 숙련된 개발자에게는 강력한 도구이지만, 특별한 이유 없이 선택할 경우 불필요한 복잡성과 시간 낭비를 초래할 수 있다. 따라서 로봇 공학을 학습하거나 애플리케이션을 개발하는 대부분의 사용자에게는, 안정성과 편의성이 검증된 데비안 패키지 설치로 시작하여 ROS2 생태계에 익숙해진 후, 필요에 따라 소스 빌드를 탐구하는 것이 가장 현명하고 효율적인 접근 방식이라 할 수 있다.