AWS RoboMaker용 ROS 애플리케이션 빌드 및 번들링 기술 활용기

• workspace 업데이트만으로 번들을 업데이트하는 데 초기 colcon bundle 호출 시 만큼의 시간이 걸렸습니다.
• 업데이트된 번들을 로봇에 배포하는 속도가 원하는 만큼 빠르지 않았습니다. 다운로드 속도와 번들 콘텐츠를 추출하는 속도가 모두 기대에 미치지 못했습니다.

그런 만큼, 최적화를 통해 이 같은 한계를 줄이거나 없앤 이 번들 형식의 두 번째 버전을 발표하게 된 것이 정말 기쁩니다. 이제 이 형식은 부분 다운로드와 부분 추출을 지원합니다. 이는 세 가지 측면에서 중대한 이점이 있습니다.

• 2G/3G를 사용하는 로봇과 같이 대역폭이 한정된 원격 디바이스에서 업데이트에 사용되는 대역폭이 감소했습니다.
• 꼭 필요한 부분만 추출합니다. 즉, 번들의 대부분이 변경되지 않은 경우 전체를 다운로드하거나 추출하느라 요금이 낭비되지 않습니다. 이 같은 이점은 로우엔드 디바이스에서 시간을 크게 단축해 줍니다. 일례로, TurtleBots에서 재배포 시간이 60분에서 1분으로 단축되기도 했습니다.
• 이제 외부 아카이브가 압축되지 않기 때문에 증분 방식으로 번들링할 수 있습니다. 그 결과, 간단한 workspace 업데이트의 경우 5분 이상 걸리던 재번들링 시간이 몇 초로 단축되었습니다.

AWS RoboMaker는 이 새로운 버전을 기본적으로 지원합니다. 새롭게 개선된 기능을 사용해보려면 개발 환경에서 sudo pip3 install -U colcon-bundle을 실행하십시오. 이 블로그의 두 번째 부분에서는 이 새로운 형식의 구현 방식을 자세히 살펴보겠습니다. 궁금한 점, 아이디어 또는 문제가 있는 경우 언제든지 GitHub 알려 주시기 바랍니다.

colcon을 사용하여 AWS RoboMaker용 번들 작성

colcon을 사용하면 단 두 단계 만에 workspace를 번들링할 수 있습니다.

• colcon build로 workspace를 작성합니다.
• colcon bundle로 workspace를 번들링합니다.

빌드

catkin_make로 빌드할 수 있는 모든 ROS 패키지는 colcon build로도 빌드할 수 있습니다. 수개월간 ROS 패키지 작업을 진행하면서 colcon build를 사용하여 패키지를 빌드할 때에는 사소한 문제만 몇 가지 발생했습니다. catkin_make로 빌드할 때는 문제가 없는데 colcon build로 패키지를 빌드할 때 문제가 발생한다면, colcon-ros 문제에서 보고해 주시기 바랍니다.

참고: catkin_make와 colcon build 간의 가장 큰 변화는 devel 디렉터리가 더 이상 사용되지 않는다는 점입니다. 이제 workspace를 로컬 환경에 추가하려면 source install/setup.sh를 실행합니다.

번들링

colcon build로 workspace를 빌드하고 나면 build와 install 디렉터리가 생성됩니다. 번들링을 시작하려면 colcon bundle을 실행합니다. 도구가 종속 관계를 검사하고 모두 다운로드한 다음, 빌드된 workspace와 함께 AWS RoboMaker에서 사용할 번들로 압축합니다. 빌드된 번들은 bundle/output.tar에 있습니다.

자주 발생하는 빌드 문제

ROS1 개발용 표준 빌드 명령에는 catkin_make가 사용됩니다. colcon은 비교적 새로운 도구이기 때문에 익숙하지 않은 ROS1 개발자가 많겠지만 catkin 빌드와 완벽하게 호환됩니다. 저희가 이전에 catkin_make를 사용하여 빌드한 기존 ROS 패키지를 colcon build로 번들링하는 중에 몇 가지 사소한 문제가 발생했는데, 다른 개발자들이 시간과 수고를 아낄 수 있도록 여기서 그 문제에 대해 설명하려고 합니다.

중첩된 폴더의 CMAKElists.txt

빌드 시에 colcon이 workspace의 모든 패키지를 제대로 열거하지 못하는 문제가 자주 발생했습니다. 그로 인해 colcon bundle 호출이 실패하고 비정상적인 설치 디렉터리 구조가 생성됩니다. 이 문제는 대개 CMakeLists.txt가 있는 중간 디렉터리의 중첩된 폴더 구조로 인해 발생합니다. 이 같은 폴더 구조는 catkin_make를 사용할 때 디렉터리 내에 중첩된 패키지를 빌드하는 데 필요하지만, colcon을 사용할 경우에는 문제를 일으킵니다. Colcon은 임의의 다단계 중첩 폴더 구조를 지원하며 자동으로 패키지를 찾습니다. 다음 다이어그램을 참조하십시오.

src/
├── package_1/
│ ├── package.xml
| └── CMakeLists.txt (OK)
└── intermediate_directory/
    ├── package_2
    | ├── package.xml
    | └── CMakeLists.txt (OK)
    ├── package_3
    | ├── package.xml
    | └── CMakeLists.txt (OK)
    └── CMakeLists.txt (REMOVE)

CMAKELists.txt의 설치 지시문 누락

파일이 누락되는 문제도 발생했습니다. catkin_make를 사용할 때는 devel 디렉터리와 setup.sh가 모든 로컬 패키지를 ROS 도구의 검색 경로에 추가합니다. Colcon은 이와 다른 방식으로 작동합니다. 즉, 사용자가 지정하는 모든 대상을 install 디렉터리에 설치합니다. 따라서 모든 CMake install() 지시문이 실행됩니다. [a_launchfile] is neither a launch file in package [a_package] nor is [a_package] a launch file name 또는 [rosrun] Couldn't find executable named my_node below /opt/ros/kinetic/share/my_package 같은 오류가 발생할 경우, install()에 대한 호출을 CMakeLists.txt에 추가하면 문제가 해결될 수 있습니다. ROS Wiki에 자세한 방법을 잘 보여주는 예제가 있습니다.

자주 발생하는 번들링 문제

AWS RoboMaker에서 애플리케이션 번들 작업을 할 때 가장 많이 발생한 문제는 다음과 같습니다.

[Package Name]의 rosdep 정의를 찾을 수 없음

사용할 패키지에 올바른 ROS 패키지 이름을 사용하고 있는지 확인해야 합니다. apt에는 패키지 이름이 ros-kinetic-packagename과 같은 형식으로 지정되지만, package.xml에서는 packagename 형식이어야 합니다. ROS distro GitHub repo를 검색하여 패키지가 기존 rosdep 데이터베이스에 있는지 확인하십시오. 없다면 자습서 중 하나에서 설명하는 방법에 따라 rosdep에 종속 관계를 추가할 수 있습니다.

종속 관계 누락

다양한 오픈 소스 ROS 라이브러리를 번들링하면서 가장 많이 목격한 문제는 종속 관계가 누락되는 것이었습니다. 다른 패키지 때문에 빌드 환경에 종속 관계가 이미 설치되어 있고 아무 문제 없이 빌드되는 경우가 많지만, 패키지를 번들링하고 나면 그 종속 관계가 누락됩니다. 종속 관계가 누락된 경우에 일반적으로 나타나는 오류는 Could not load libxzy.so, No such file or directory some_script.py 또는 Could not load module 'python_dependency'입니다. 이 문제를 해결하려면 종속 관계를 필요로 하는 패키지의 package.xml에 종속 관계를 추가하고 다시 번들링합니다.

자체 apt 또는 pip 리포지토리의 애플리케이션에 종속 관계를 사용하는 경우, colcon bundle 호출에 해당 리포지토리를 포함해야 합니다. 이 문제를 해결하려면 다음과 같이 해보십시오.

빌드 및 번들링 완료

이제 AWS RoboMaker에서 시뮬레이션할 애플리케이션을 빌드하고 번들링할 수 있습니다. 개발 환경에서 sudo pip3 install -U colcon-bundle colcon-ros-bundle을 실행하여 패키지의 최신 버전으로 업그레이드합니다. 궁금한 점이 있거나 문제가 발생한 경우, 관련 GitHub repo를 게시해 주시면 언제든지 도와 드리겠습니다. 아래에서는 colcon bundle을 실행할 때 실제로 어떤 일이 일어나는지를 살펴보겠습니다.

번들 심층 분석

이 섹션에서는 번들 형식의 내부 구조와 colcon bundle의 구현 방식을 자세히 설명합니다. 이 섹션을 끝까지 읽으면 colcon bundle을 실행했을 때 어떻게 되는지를 잘 알 수 있습니다. 얼마나 사용하기 쉬운지를 알게 되고 colcon 생태계의 기반 위에서 직접 도구를 빌드해보는 계기가 되었으면 합니다. 나아가 커뮤니티에 관련 글을 게시하게 된다면 더할 나위가 없겠죠.

번들 파일 형식

‘번들’이란 AWS RoboMaker가 전체 ROS 애플리케이션을 실행하는 데 사용하는 패키징 형식으로, 로봇 또는 해당 시뮬레이션 애플리케이션의 전체 전이 폐쇄가 포함되어 있습니다. ROS가 이미 종속 관계를 선언하는 방법과 빌드 도구에 사용할 항목을 지정하는 표준 패키징 형식을 정의한 상태입니다. colcon을 사용하면 도구가 이 정보를 수집하고, 다양한 패키지 설치 프로그램(현재 pip 및 apt)을 호출하여 종속 관계를 가져오고, 가져온 종속 관계를 로컬 스테이징 영역에 설치한 후, 로컬로 빌드된 workspace와 함께 AWS RoboMaker가 사용할 수 있도록 번들로 패키징합니다.

이 워크플로우에서 ‘번들’이라는 것이 생성됩니다(‘번들’이 다소 진부한 이름이라는 점은 저희도 잘 알고 있습니다. 이 형식의 이름에 대한 아이디어가 있으면 리포지토리에서 문제를 제기해 주시기 바랍니다.) 번들 형식의 지정 내용은 colcon-bundle 리포지토리에 있습니다. 간단히 정리하면 다음과 같습니다.

이 다이어그램은 번들 형식의 V2를 보여 줍니다. 기록은 여기에서 확인할 수 있습니다. ‘번들’ 파일은 표준 GNU tar 형식을 따르며, 최소 3개의 구성 요소로 이루어집니다.

이 형식의 최신 버전을 사용하는 데 따른 이점은 앞에서 설명했습니다. V1과 V2 간에 가장 크게 바뀐 점은 다음과 같습니다.

전반적으로 이 같은 개선 사항들은 매우 만족스럽습니다. 다른 아이디어가 있는 경우 언제든지 GitHub에서 문제를 제기해 주시기 바랍니다.

colcon bundle 실행 흐름

이 섹션에서는 colcon bundle을 실행할 때 실제로 어떻게 되는지를 자세히 살펴보겠습니다. (colcon을 기반으로 도구를 빌드한 것은 정말 멋진 경험이었습니다. 전문화된 빌드 도구를 만들려는 경우, 기반 프레임워크로서 colcon의 가치를 한번 확인해 볼 것을 적극 추천합니다.)

colcon 생태계는 직접 종속 관계와 colcon-core만을 기반으로 하는 여러 개의 개별 Python 패키지로 이루어져 있습니다. colcon의 거의 모든 기능은 기반 인프라에서 colcon-core에 정의되는 ExtensionPoint로 모델링됩니다. colcon은 setuptool 진입점을 플러그인 메커니즘으로 활용하여 모듈화와 느슨한 결합이라는 목표를 실현합니다.

명령줄 인터페이스를 확장할 수 있도록, colcon은 VerbExtensionPoint를 통해 명령을 추가하는 기능을 지원합니다. 기능을 빌드하기 위해 저희는 bundle 동사를 생성하고 setup.cfg에 등록했습니다. 이 훌륭한 도구에 통합 명령을 구현하기 위해 필요한 작업은 그게 다였습니다. (이후 모든 작업은 저희 도메인에만 국한된 것이었습니다.) 그런 만큼 ROS 워크플로우와 관련하여 도구를 빌드하려면 colcon을 사용하는 것이 현명합니다! 그 이점은 아무리 강조해도 지나치지 않습니다.

colcon bundle을 호출한 후에는 일련의 작업이 실행되는데, 일부 작업은 colcon 인프라에서 제공되는 기능이고 일부는 저희가 직접 작성한 것입니다. 여기서도 설명하겠지만, 코드를 분석하여 각 작업이 어떻게 작동하는지를 자세히 살펴보시기 바랍니다.

1. 저희가 만든 VerbExtensionPoint인 BundleVerb를 호출합니다. 다른 확장 지점의 인수와 함께, 등록한 모든 인수가 포함된 context를 전달받습니다.
2. 그런 다음 일부 colcon-core 기능을 호출하여 workspace 파일 트리를 크롤링하고 패키지를 식별합니다. 그러면 bundle 실행 시에 포함될 각 패키지의 PackageDescriptor가 생성됩니다. 패키지 식별에는 PackageIdentificationExtensionPoint가 사용됩니다. ROS 패키지를 식별하기 위해 등록된 확장은 colcon-ros에 정의되는 RosPackageIdentification입니다. 이 확장은 ROS 패키지를 식별할 때 PackageDescriptor의 type을 ros.cmake, ros.catkin 또는 ros.ament로 설정합니다.
3. 패키지가 모두 식별되고 나면 colcon은 지정한 패키지 유형에 대해 등록된 모든 PackageAugmentationExtensionPoint를 실행합니다. 식별 기능 외에, RosPackageIdentification은 패키지의 package.xml을 구문 분석하고 패키지 설명자 메타데이터에 빌드, 테스트 및 런타임 종속 관계를 추가하는 확장 기능도 제공합니다.
4. 다시 코드로 돌아와서, 각 PackageDescriptor에 연결된 종속 관계 메타데이터를 검사하여 마지막 호출 후에 변경된 내용이 있는지 확인합니다. 변경된 내용이 없으면 종속 관계 분석을 추가로 하지 않고, 기존 종속 관계 오버레이를 사용하여, 빌드된 workspace의 번들링 작업을 계속 진행합니다. 종속 관계가 변경된 것으로 확인되면 전체 종속 관계 분석 작업을 계속 실행합니다.
5. 전체 종속 관계 분석 작업을 실행하는 동안 각 PackageDescriptor마다 해당 번들링 작업을 호출합니다. 현재 ros.catkin, ros.cmake 및 python 패키지 유형이 지원됩니다. 이 지원 기능은 colcon-bundle/setup.cfg및 colcon-ros-bundle/setup.cfg에 등록되어 있습니다. 해당 번들링 작업을 추가하면 새로운 패키지 유형을 지원할 수 있습니다. 각 패키지 유형별로, 해당 번들링 작업을 통해 종속 관계가 수집되고 각 종속 관계에 해당하는 BundleInstallerExtensionPoint가 호출됩니다. 저희의 ROS 작업에서는 rosdep를 사용하여 ROS 종속 관계 이름을 해당하는 시스템 패키지 이름으로 변환합니다.
6. 종속 관계가 설치 프로그램에 모두 등록되고 전체 전이 폐쇄가 결정된 후에는 libc*, gazebo* 등 인프라에서 제공하는 다른 패키지가 설치되지 않도록 시스템 패키지 목록에 블랙리스트를 적용합니다. --apt-package-blacklist 인수를 사용하면 사용자가 자체 블랙리스트를 제공하여 블랙리스트 동작을 재정의할 수 있습니다.
7. 블랙리스트를 적용한 후에는 종속 관계 등록 단계에서 사용된 모든 등록된 BundleInstallerExtensionPoint에 대해 install()을 호출합니다. 설치 프로그램이 모든 구성 요소를 --bundle-base(기본값: bundle)에 있는 디렉터리에 설치합니다. 다운로드와 설치가 완료되면 오버레이를 지원하는 setup.sh를 복사한 후 폴더에 tar 및 gzip을 적용하여 dependencies.tar.gz로 압축합니다.
8. 종속 관계가 아카이빙된 후에는 빌드된 최신 install 폴더를 아카이빙합니다. 오버레이가 가능하도록, 전체 --install-base(기본값: install) 디렉터리에 tar 및 gzip을 적용하여 setup.sh를 사용한 별도의 오버레이로 압축합니다.
9. 2개의 아카이브를 모두 생성한 후에는 빌드 프로세스에서 생성된 모든 메타데이터를 수집하고, 오버레이의 크기, 오프셋, 순서를 설명하는 메타데이터를 추가합니다. 그런 다음 해당 메타데이터에 tar을 적용하여 metadata.tar.gz로 압축합니다.
10. 그리고 tar로 여러 아카이브를 하나로 압축하여 ‘번들’을 만들고 디스크의 bundle/output.tar에 씁니다. 이제 이 번들을 AWS RoboMaker에서 로컬로 사용할 수 있습니다.

번들을 사용하여 애플리케이션 실행

번들 형식은 AWS RoboMaker에서 사용하는 것과 마찬가지로 로컬로도 사용할 수 있습니다. 이 기능은 애플리케이션에서 또는 디버깅 도구로 유용하게 활용할 수 있습니다. colcon bundle 아카이브를 사용하도록 빌드한 GoLang 라이브러리를 서비스에 곧 계시할 예정입니다. 여기서는 현재 colcon bundle 아카이브를 읽고 사용하는 방법을 단계별로 설명하겠습니다.

마무리

저희는 이 형식의 최신 버전에 매우 만족하고 있으며, 앞으로도 계속 개선해나갈 계획입니다. colcon bundle은 더 많은 패키지 유형과 설치 프로그램을 지원하도록 구현 범위를 확장할 수 있습니다. 이 도구의 기능을 확장하는 데 관심이 있는 분은 colcon-bundle 및 colcon-ros-bundle에 대한 문제를 제기하고 도구 제작에 참여해 주시기 바랍니다. colcon을 기반으로 직접 도구를 빌드하려면 colcon 제작 설명서를 참조하십시오.