오늘의 주제는 바로 AWS이다.

예전에도 AWS를 공부해보고 싶어 이것 저것 시도해보았지만 악랄한 아마존의 요금 폭탄과 EC2 생성에서 마주치는 알아들을 수 없는 설정값 때문에 잠시 거리를 두기로 했었다. (저 로고의 웃는 모습이 약오른다.)

그러던 중 최근 비용 걱정 없이 AWS를 사용해 볼 기회가 생기게 되었다. 이 포스팅에서는 내가 AWS 인프라를 E2E로 구축하며 공부하고 배운 것을 누군가에게 나누어 보려고 한다.

AWS가 뭔지부터 설명하지는 않을 것이다.

제목에서도 나타나듯이 EC2 생성하다가 머리아파서 잠시 AWS와 멀어진 사람들을 위한 포스팅이니 기본적으로 AWS와 EC2가 뭔지는 알고 오면 좋을 것 같다.

공부를 시작한지 1주일 밖에 지나지 않아 부족한 점도 많겠지만 최대한 내가 이해한 대로 설명해보도록 하겠다.

네트워크와 인스턴스

내가 처음 AWS를 접했을 때 가장 어렵고 복잡했던 것은 무수히 많은 서비스들과 설정 지옥이었다.

간단한 EC2 하나 띄우는 데에도 설정해줘야 하는 것들이 뭐 그리 많은지.. 그리고 참고한 블로그 글들과 현재의 GUI 버전이 달라 너무 헷갈렸다.

이 포스팅에서는 단순히 EC2를 생성하는 것이 아닌 전체 인프라를 이해하고 구축하는 것을 목표로 하기 때문에 네트워크부터 먼저 설명해보고자 한다.

1. VPC

가장 먼저 알아야 하는 키워드는 Virtual Private Cloud (VPC)이다.

VPC에 대한 설명을 먼저 하는 이유는 이 서비스가 가장 바깥쪽의 그릇 역할이기 때문이다. 큰 개념부터 시작하여 점점 세부적으로 들어가보자.

VPC는 퍼블릭 클라우드 내에 존재하는 논리적으로 격리된 프라이빗 네트워크이다. 쉽게 말해 AWS에서 제공해주는 개인 가상 내부망이라고 이해하면 된다.

기본적으로 사용자가 생성하는 리소스는 대부분 VPC 안에 들어가게 된다. 물론 예외는 있긴 하지만 그건 뒤에서 설명하도록 하겠다.

만약 당장 이해가 가지 않는다면 EC2 같은 리소스를 담을 가장 바깥쪽의 보따리라고 생각하고 넘어가자.

Region과 Availability Zone 개념에 대해서도 연관되어 있지만 이 글에서는 논리적인 개념을 이해하는 것을 목표로 하기에 따로 설명하지 않겠다. 만약 관심이 있으면 개인적으로 찾아보길 바란다.

위 사진은 AWS Docs에서 VPC를 설명할 때 나오는 그림이다. VPC 안에 Subnet들과 Instances들이 들어가 있는 것을 볼 수 있다.

2. Internet Gateway (IGW)

아까 VPC는 프라이빗 네트워크라고 이야기했었다. 이 말은 기본적으로 외부 인터넷과 격리된 상태라는 것이다.

이 VPC와 그 안의 EC2들이 인터넷과 연결되기 위해서는 Internet Gateway (IGW)가 필요하다. IGW는 가장 쉽게 말해 구멍을 뚫어주는 것이다.

아까 VPC를 보따리에 비교한 것을 기억하는가?

보따리 안(VPC)에서 바깥 세상(인터넷)과 상호작용을 하려면 입구를 열어야 하는 것과 같이 VPC도 인터넷에 접근하려면 입구가 필요하다.

그러나 여기서 주의할 점은 IGW가 생긴다고 해서 자동으로 인터넷으로 연결이 되는 것은 아니다. 실제로 인터넷에 연결하기 위해서는 몇 가지 조건이 더 필요하다. 이건 밑에서 설명하겠다. 지금은 그냥 입구 혹은 구멍 정도로 이해하면 된다.

IGW는 VPC에 붙이는 것이다. 당연한 이야기다! 구멍은 보따리에 뚫는 것이니까.

여기까지의 결론

AWS 인프라를 생성하려면 먼저 VPC부터 만들면 된다. 그리고 인터넷 통신이 필요하다면 그 VPC에 IGW를 만들어서 붙여라!

3. Subnet

VPC를 생성하고 IGW를 붙였다면 이제 Subnet을 만들 차례다. 서브넷은 VPC의 IP 주소 범위를 더 작은 단위로 분할한 논리적 네트워크 세그먼트이다.

쉽게 말해 VPC라는 보따리 안의 짐들을 비닐봉지로 서로 묶는 것이다.

사실 서브넷이란 개념은 네트워크에서 중요하고 유명한 개념이다. 네트워크를 공부했던 사람이라면 익숙한 서브넷 마스크부터 시작하여 CIDR 개념까지 모두 다루려면 끝이 없기에 이건 네트워크 시간에 따로 공부하기로 하고 지금은 AWS의 네트워크 구조에서의 서브넷을 다뤄보자.

서브넷을 생성하는 이유에는 몇 가지가 있지만 가장 큰 목적은 네트워크 분리이다. 외부(인터넷)에서 접근할 수 있는 네트워크와 외부에서 접근할 수 없는 네트워크를 분리하거나 역할별로 네트워크를 분리할 수 있다. 또한 위에서 넘어갔던 AZ 분리도 중요한 목적 중 하나다.

서브넷은 크게 2가지로 나눌 수 있다. 바로 Public Subnet과 Private Subnet이다. 정확한 정의로는 Public Subnet은 IGW가 존재하는 VPC상에 있고 라우팅 테이블에 0.0.0.0/0 -> IGW 규칙이 있는 서브넷이고 Private Subnet은 그 규칙이 없는 서브넷이다.

아까 위에서 IGW를 생성한다고 자동으로 인터넷에 연결되는 것이 아니라고 말한것을 기억하는가? 인터넷에 연결되기 위해서는 IGW가 존재해야 하고 Public Subnet 즉, 라우팅 테이블에 0.0.0.0/0 -> IGW 규칙이 있어야 한다. 그러나 아직 인터넷에 연결되기 위해서는 몇 가지 조건이 더 필요하다. 이건 밑에서 차차 설명하도록 하겠다.

여기까지의 결론

VPC 내부에는 Subnet을 설정할 수 있다! Subnet에는 Route Table을 연결할 수 있다! Route Table의 0.0.0.0/0 -> IGW 규칙 유무에 따라 Public/Private 서브넷이 나눠진다.

4. EC2와 Public IP

외부에서 접근 가능한 인스턴스를 만들기 위해서는 그 인스턴스를 식별할 수 있는 Public IP가 필요하다.

어떤 인스턴스가 Public IP를 가지는 방법은 2가지가 있다.

첫 번째는 EC2 생성 시 설정을 통해 부여하는 것이다. 두 번째는 Elastic IP(EIP)를 연결하는 것이다.

여기서 Elastic IP (EIP)는 고정된 공인 IP라고 보면 된다. 기본 Public IP는 인스턴스를 중지/재시작하면 변경될 수 있지만, EIP는 계속 유지된다.

그렇다면 이제 EC2를 인터넷에 연결시키기 위한 준비가 모두 끝났다.

1. VPC에 IGW가 연결되어 있고
2. Subnet에 0.0.0.0/0 -> IGW 규칙이 있고 (=Public Subnet이고)
3. EC2에 Public IP가 존재한다.

(보안 설정도 필요하지만 여기서는 제외하겠다. 보안 설정은 추후 설명하겠다.)

위 3개의 조건이 만족한다면 이제 외부에서 접근 가능한 인스턴스를 생성한 것이다.

여기까지의 결론

인스턴스에는 Public IP를 붙일 수 있다! EC2 생성 시 설정하거나 EIP를 연결하여 붙이는 방법이 있다!

5. NAT Gateway

이제 Public Subnet에 있는 EC2는 인터넷을 사용할 수 있게 되었다. 그렇다면 Private Subnet은 인터넷을 사용하지 못하는 것일까? Private Subnet에서도 Docker Hub에서 이미지를 pull하거나 apt install로 패키지를 설치하는 경우가 있을 수 있다.

이때 사용하는 것이 NAT Gateway이다. NAT Gateway는 Private IP를 Public IP로 변환해서 외부와 통신하게 해주는 장치이다. 이를 이용하면 외부에서 내부로의 접근은 불가능하지만 내부에서 외부로 요청하고 응답을 받는 것은 가능한 시스템을 만들 수 있다.

즉, 아웃바운드만 가능한 구조라고 이해하면 된다.

Private Subnet에 있는 EC2가 외부로 요청을 보낼 때, NAT Gateway를 통해 트래픽이 나가게 된다.

NAT Gateway는 Public Subnet에 생성되어야 하며, Elastic IP를 가진다.

그리고 Private Subnet의 Route Table에는 0.0.0.0/0 → NAT Gateway 규칙이 필요하다.

이렇게 설정하면 Private Subnet에 있는 인스턴스도 NAT Gateway를 통해 외부로 나갈 수 있게 된다.

여기까지의 결론

Private Subnet에서 인터넷을 사용하려면 NAT Gateway를 사용하면 된다! NAT Gateway는 Public Subnet에 생성해야 한다! 인터넷을 사용하려는 Subnet의 Route Table에는 0.0.0.0/0 → NAT Gateway 규칙이 필요하다.

정리하며

지금까지 기본적인 네트워크 설정과 인스턴스 접근 방법을 설명했다. 만약 여기까지 잘 따라왔다면 아래의 개념들을 이해하고 있을 것이다.

• VPC의 개념과 IGW 개념
• Public Subnet과 Private Subnet
• Public IP 설정과 각 Subnet에서의 인터넷 트래픽 흐름

이제 기본적인 트래픽의 흐름을 알았으니 다음 글에서는 흐름을 제어하는 보안 설정에 대해 알아보겠다. 원래 하나의 글로 작성하려 했지만 생각보다 내용이 많아져 분리하게 되었다.

다음 글에서는 보안 설정과 SSM, Route53, S3 등을 설명할 예정이다.

프로젝트에서 LIO-SAM 기반의 3D SLAM 알고리즘을 사용해야 하는 일이 생겼다.

ROS를 거의 처음 다뤄보는 나로써는 상당히 막막한 일이었지만 개발자라면 자고로 머리부터 들이밀어야 한다는 마음으로 프로젝트를 시작해 보았다.

혹시 나처럼 고통받고 있는 누군가에게 이 글이 도움이 되길 바라며 LIO-SAM을 설치하고 데이터를 수집하는 과정에서 일어난 우여곡절을 함께 나눠보고자 한다.

개발환경 구축하기

1. Linux 개발환경 구축 (Ubuntu 20.04)

이번 프로젝트에서는 ROS noetic 버전을 사용하여야 했기 때문에 Ubuntu 20.04 버전을 사용하기로 하였다.

Docker를 사용하여도 되지만 우리는 LG그램 노트북에 Ubuntu를 바로 올려서 사용하기로 하였다.

우분투를 설치하는 방법은 구글에 검색해 보면 많이 나오기에 따로 설명하지는 않겠다.

만약 나와 같은 환경에서 시작하고 싶은 사람은 Ubuntu 공식 홈페이지에서 20.04 버전 이미지를 다운받고 부팅 USB를 만들어 원하는 PC에 설치하면 된다.

부팅 USB는 잘 보관해 두자. 나중에 사용할 일이 있을지도 모른다..

2. ROS 설치 (ROS1 noetic)

상술한 것처럼 이번 프로젝트에서 ROS1 noetic 버전 사용이 필수적인 상황이었다.

돌아보면 이게 비극의 시작이었던 것 같지만 프로젝트에서 사용하는 모터 드라이버가 지원하는 버전이 noetic 뿐인지라 어쩔 수 없는 일이었다. (만약 Noetic 버전을 사용할 필요가 없는 사람이라면 LIO-SAM github에서 명시하는 테스트 된 버전으로 진행하는 것이 정신건강에 좋을 수 있다. 그렇다면 이 글도 읽을 필요가 없을 것이다..)

ROS는 공식문서를 참고하여 설치하였다.

1. 패키지 저장소 등록

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'

여기서 주의할 점이 있다.

위에서 Ubuntu 이미지를 설치하는 방식으로 시작하였다면 lsb_release 패키지가 설치되어 있지 않아 오류가 날 것이다. 만약 위의 코드를 먼저 실행시켰고 오류가 났다면 축하한다. 이제 당신의 Ubunru에서는 어떤 apt install 명령어도 작동하지 않을 것이다.

아마 이를 복구하는 방법이 있을 것 같긴 한데 나는 그냥 우분투를 새로 까는 방법을 선택하였다. 아까 보관해 둔 부팅 USB를 다시 꺼내보자...

위 명령어를 무사히 실행시키려면 먼저 저 lsb 패키지를 설치하여야 한다. 참고로 lsb_release는 현재 우분투의 버전 이름을 확인하는 명령어이다.

sudo apt-get install lsb

이제 위 패키지를 다운로드하고 다시 패키지 저장소를 등록해 주자.

2. 키 셋업

sudo apt install curl # if you haven't already installed curl
curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo apt-key add -

3. 설치

sudo apt update

sudo apt install ros-noetic-desktop-full

4. 환경변수 설정

설치가 이제 끝났다. 설치 이후에 환경변수를 추가해 주기 위해

source /opt/ros/noetic/setup.bash

위 명령어를 실행시켜 주자. 이 명령어는 ROS 환경을 현재의 셀 세션에 등록해 주는 명령어이다. 매번 터미널을 열 때마다 실행해 줘야 하지만 상당히 귀찮기 때문에 .bashrc 파일에 등록하여 자동화하는 방법도 있다.

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

위 명령어를 입력하였다면 터미널을 열 때마다 자동으로 ROS 환경이 등록될 것이다. 혹여 여러 ROS 버전을 동시에 사용해야 한다면 위 자동화 명령어를 입력하면 안 된다.

LIO-SAM 설치 및 빌드하기

1. 작업공간 설정하기

LIO-SAM을 설치하기 전에 작업공간을 만들어 주자. 방법은 공식문서에도 잘 설명되어 있다.

mkdir -p ~/catkin_ws/src/

꼭 위 명령어로 작업공간을 만들 필요는 없다. 원하는 경로에 원하는 이름으로 설정하여도 된다. 다만 폴더 내에 src 폴더는 꼭 만들어주자.

mkdir -p {원하는 경로와 폴더 이름}/src

그리고 해당 폴더로 이동 후 기본 세팅을 해주자.

cd ~/catkin_ws/
catkin_make

여기서 catkin_make 명령어는 사실 빌드 명령어이다. 그래서 지금 꼭 실행시켜야 할 필요는 없지만 공식문서에서 하라고 하니 한번 실행해 보자. 빌드가 되면서 다양한 결과 폴더가 생기는 것을 확인할 수 있다. (코드가 없기 때문에 별 의미는 없다)

2. LIO-SAM 설치 및 빌드하기

이제 LIO-SAM을 설치해 보자. 설치 방법은 github 레포지토리에 잘 설명되어 있다.

1. 의존성 설치 (ros 패키지)

sudo apt-get install -y ros-noetic-navigation
sudo apt-get install -y ros-noetic-robot-localization
sudo apt-get install -y ros-noetic-robot-state-publisher

공식 문서에는 kinetic으로 설정되어 있기에 noetic으로 변경하여 설치해 준다.

2. 의존성 설치 (gtsam)

sudo add-apt-repository ppa:borglab/gtsam-release-4.0
sudo apt install libgtsam-dev libgtsam-unstable-dev

나의 경우 이 gtsam 패키지는 추후 빌드 시에 많은 문제를 일으켰었다. 당신이 운이 좋거나 깨끗한 우분투에서 설치를 진행하고 있다면 별일은 없을 것이다.

3. 코드 다운로드 및 빌드

모든 코드는 src 폴더 안에 있어야 하므로 src 폴더로 이동 후 git clone을 해준다.

cd ~/catkin_ws/src
git clone https://github.com/TixiaoShan/LIO-SAM.git

이후 다시 워크스페이스 폴더로 돌아가 빌드를 해준다.

cd ..
catkin_make

여기까지 잘 진행했다면 아마 빌드가 진행되는 듯하면서 에러가 발생했을 것이다.

아주 정상적인 현상이니 괜찮다. 에러는 뜨지 않는데 되는 게 아무것도 없는 경우보다는 낫지 않은가?

지금부터 하나하나 고쳐 나가보도록 하자.

에러 해결

1. OpenCV 에러

아마 첫 번째로 뜨는 에러는 opencv 에러일 것이다.

In file included from /home/ubicomp/Desktop/woojin-main-ws/src/LIO-SAM/src/imuPreintegration.cpp:1:
/home/ubicomp/Desktop/woojin-main-ws/src/LIO-SAM/include/utility.h:18:10: fatal error: opencv/cv.h: No such file or directory
   18 | #include <opencv/cv.h>
      |          ^~~~~~~~~~~~~
compilation terminated.
make[2]: *** [LIO-SAM/CMakeFiles/lio_sam_imuPreintegration.dir/build.make:63: LIO-SAM/CMakeFiles/lio_sam_imuPreintegration.dir/src/imuPreintegration.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:812: LIO-SAM/CMakeFiles/lio_sam_imuPreintegration.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

이 에러는 LIO-SAM이 테스트 된 버전(Ununtu 18.04)에서는 OpenCV 3.x 버전을 사용하지만, 현재 버전(Ubuntu 20.04)에서는 OpenCV 4.x 버전을 사용하여 생긴 문제이다.

다행스럽게도 이 에러는 이 이슈에서 다루어졌기 때문에 우리는 그저 앞선 사람들을 따라가기만 하면 된다. (오픈소스 만세)

에러 해결을 위해서는 LIO-SAM/include/utility.h 파일을 수정해야 한다. #include <opencv/cv.h> 구문을 #include <opencv2/opencv.hpp>로 변경해 주게 되면 에러가 해결되는 것을 볼 수 있다.

2. C++14 에러

opencv를 고치고 신나게 catkin_make 명령어를 다시 입력해보면 말 그대로 에러가 뿜어져 나오는 것을 보게 될 것이다.

In file included from /usr/include/pcl-1.10/pcl/pcl_macros.h:77,
                 from /usr/include/pcl-1.10/pcl/PCLHeader.h:10,
                 from /usr/include/pcl-1.10/pcl/point_cloud.h:47,
                 from /home/ubicomp/Desktop/woojin-main-ws/src/LIO-SAM/include/utility.h:20,
                 from /home/ubicomp/Desktop/woojin-main-ws/src/LIO-SAM/src/imageProjection.cpp:1:
/usr/include/pcl-1.10/pcl/pcl_config.h:7:4: error: #error PCL requires C++14 or above
    7 |   #error PCL requires C++14 or above
      |    ^~~~~

PCL Requires C++14 or above 로 시작하는 이 에러는 위의 에러와 동일하게 개발 환경 버전 차이로 발생하는 것이다.

다시 말해 CMakeLists.txt에 설정된 C++ 표준이 과거 PCL 버전으로 맞춰져 있어 오류가 발생한 것이다.

에러 해결을 위해서는 LIO-SAM/CMakeLists.txt에서 set(CMAKE_CXX_FLAGS "-std=c++11") 구문을 set(CMAKE_CXX_FLAGS "-std=c++14") 로 변경해 주면 된다.

3. no member named ‘serialize’ 에러

이 에러는 어떨 때는 발생하지 않고 어떨 때는 발생하는 이상한 에러였다.

/usr/include/flann/util/serialization.h:34:14: error: ‘class std::unordered_map<unsigned int, std::vector<unsigned int> >’ has no member named ‘serialize’
   34 |         type.serialize(ar);
      |         ~~~~~^~~~~~~~~

정확한 발생 원인과 해결 방안은 정의하지 못하였다. 다만 위의 이슈 페이지에 비슷한 내용이 있었기에 해당 지시를 따라보았다.

에러 해결을 위해서는 LIO-SAM/include/utility.h 파일을 수정하면 되는데 #include <opencv2/opencv.hpp> 구문을 라인 33번(#include <pcl_conversions/pcl_conversions.h> 밑)으로 옮기게 되면 정상적으로 빌드되는 것을 확인하였다.

이를 바탕으로 의존성 순서 문제로 패키지가 정상적으로 불러와지지 않아서 발생하는 것이라고 추측하였다.

여기까지 문제없이 진행되었다면 이제 알고리즘을 돌리기 위한 기본 설정은 끝난 것이다.

번외 1. DSO missing from command line 에러

빌드 과정에서 프로젝트 초기에 발생하여 나를 4일동안 삽질하게 만들었던 에러이다. 패키지의 경로 설정이나 버전 충돌 문제인 듯한데 구글링 결과 너무나도 다양한 방법이 있었지만, 해결되는 방법은 없었다. 나의 경우 우분투를 새로 설치하는 것으로 문제를 해결하였다. (부팅 USB를 다시 꺼내보자..)

번외2. Could not found tf 에러

사실 이 에러는 대부분의 사람에게 발생하지 않을 것이다. 나도 도대체 왜 발생한 줄 모르겠는 에러로 그냥 ros 설치가 날아간 건지 모든 ros 명령어가 인식되지 않았다. 간단히 ros 재설치로 해결하였다.

LIO-SAM 테스트

이제 빌드된 코드가 정상적으로 작동하는지 확인해 보려고 한다.

Github 레포지토리를 확인해 보면 다양한 샘플 데이터를 제공하고 있다. 이 데이터를 가지고 테스트를 진행해 보자.

테스트는 3가지의 데이터셋을 가지고 진행해 보려고 한다. 사용할 데이터셋은 여기서 다운로드 받으면 된다.

0. 기본 설정

테스트를 시작하기 전에 처음 ROS 설치 후에 source 명령어를 입력하였던 것을 기억할 것이다. 이와 마찬가지로 빌드한 소스와 경로를 시스템에 적용하기 위해서는 동일하게 source 명령어를 작성하여야 한다.

cd ~/catkin_ws
source devel/setup.bash

해당 명령어를 작성하게 되면 빌드한 파일과 경로가 시스템에 적용되어 실행할 수 있게 된다.

1. Velodyne Park Dataset

처음으로 실행해 볼 데이터셋은 Park Dataset이다.

roslaunch lio-sam run.launch

데이터셋을 다운로드한 후 LIO-SAM을 실행시킨다.

rosbag play {파일 경로}/park_dataset.bag -r 3

이후 위 명령어를 실행시키면 LIO-SAM이 정상적으로 동작하는 것을 확인할 수 있다.

(비록 테스트 데이터지만 뭔가 작동하니까 행복하지 않은가? 소소한 행복을 함께 느껴보자.)

2. Velodyne Campus Dataset (small)

다음으로는 Campus 데이터셋이다. 이 데이터셋은 실행해 보기 전 약간의 설정 수정이 필요했다.

위에서 실행한 데이터셋은 IMU 데이터가 정확한 포맷으로 들어오지 않아 내부적으로 변환이 필요하였지만, 이 데이터셋은 IMU 데이터를 ROS REP105 standard 포맷으로 보내주어 따로 내부적인 변환이 필요 없다고 한다.

따라서 데이터셋을 실행하기 위해서는 LIO-SAM/config/params.yaml 에서 imuTopic 값을 imu_correct 로 변경하고 extrinsicRot 와 extrinsicRPY를 단위행렬로 변경해 주어야 한다.

이후 위에서와 동일하게 LIO-SAM을 실행시키고 데이터셋을 재생해 주면 된다.

roslaunch lio-sam run.launch

rosbag play {파일 경로}/campus_small_dataset.bag -r 3

그러면 이렇게 결과가 나올 것이다!

3. Ouster Rooftop Dataset

마지막으로 실행시켜 볼 데이터셋은 Ouster 라이다로 측정된 Rooftop 데이터셋이다.

위의 두 데이터셋은 Velodyne으로 측정 되었지만 이 데이터셋은 Ouster 라이다로 측정되었다.

이 데이터셋을 실행시켜보기 위해서는 LIO-SAM/config/params.yaml 에서 라이다 설정을 변경해 주어야 한다.

먼저 sensor 값을 ouster 로 변경하고 N_SCAN 값을 128, Horizon_SCAN 값을 1024로 변경해준다.

이후에 위에서 2번째 데이터셋을 테스트할 때 변경하였던 설정을 다시 원상복귀 해주어야 한다. 만약 2번 데이터셋을 실행하지 않았다면 넘어가도 된다.

다 수정하였다면 이제 실행해보도록 하자.

roslaunch lio-sam run.launch

rosbag play {파일 경로}/rooftop_ouster_dataset.bag -r 3

그럼 이런 결과가 나온다.

LIO-SAM 데이터 수집

이제 제공되는 데이터셋만 돌리던 안락한 생활은 끝났다. 이제 실제 센서로 데이터를 수집할 차례이다.

0. 센서 드라이버 설치

나는 이 프로젝트에서는 Ouster 라이다, iAHRS IMU 센서를 사용하였다.

이 센서들을 사용하기 위해서는 ROS 드라이버 설치가 필요하다.

1. Ouster LiDAR

먼저 Ouster LiDAR이다. 라이다를 컴퓨터에 연결하고 데이터를 받아오는 부분은 이미 많은 사람들이 다루었기 때문에 따로 설명하지는 않겠다. 나는 이 블로그 글을 참고하였다. 자세한 부분까지 잘 설명되어 있어 쉽게 할 수 있을 것이다.

마찬가지로 설치를 완료하고 센서가 잘 돌아가는지 확인하려면 아래 명령어를 입력해보면 된다.

roslaunch ouster_ros sensor.launch

그럼 자동으로 rviz가 실행되면서 PCD 데이터를 시각화 해줄 것이다.

위의 LIO-SAM에서 처럼 새로운 터미널을 열었다면 source 명령어를 입력하는 것을 잊지 말자.

cd ~/catkin_ws
source devel/setup.bash

2. iAHRS IMU

다음으로는 IMU 센서의 드라이버를 설치하여야 한다. 마찬가지로 드라이버 github에 잘 정리되어 있다. 절대 귀찮아서 설명하지 않는 것은 아니다.

1. Ouster LiDAR + iAHRS IMU

드라이버 설치가 끝났다면 이제 실제 데이터를 수집해보도록 하자.

데이터를 수집하기 위해서는 LIO-SAM의 설정 파일을 변경해주어야 한다. 여기서 변경하는 값들은 개인의 센서에 따라 달라질 수 있으니 확인 후 변경해주어야 한다.

먼저 pointCloudTopic을 ouster/points로 변경해 주었다. 그리고 imuTopic을 imu/data로 변경하였다.

다음으로는 sensor를 ouster로 변경하였다. 우리는 OS1-32-U 모델을 사용하고 있었기 때문에 N_SCAN은 32로 Horizon_SCAN은 1024로 설정하였다.

실행하기 전에 위에서 설치한 ouster_ros의 sensor.launch 파일에서도 동일하게 설정해주자.

이제 두근거리는 마음으로 SLAM을 돌려보자. 과연 성공적으로 작동할까?

에러1 : Point cloud is not in dense format

당연하게도 한 번에 될리가 없다. 에러 메세지를 한 번 확인해보자.

[lio_sam_imageProjection-2] restarting process
process[lio_sam_imageProjection-2]: started with pid [17045]
[ INFO] [1743588602.428283737]: ----> Image Projection Started.
[ERROR] [1743588602.844451925]: Point cloud is not in dense format, please remove NaN points first!

ouster 라이다에서 내보내는 is dense 항목이 false라고 한다.

rostopic echo /ouster/points/is_dense -n 30

위 명령어를 실행하면 현재 발행중인 ouster 라이다의 토픽을 볼 수 있다.

안타깝게도 정말 False가 뜨고 있다. 테스트 데이터도 확인해보자.

rosbag play -r 3 dataset/rooftop_ouster_dataset.bag

rostopic echo /points_raw/is_dense -n 3

테스트 데이터에서는 정상적으로 True가 뜨는 것을 확인할 수 있다.

해당 오류를 일으키는 코드를 확인해보면 imageProjection.cpp 파일에서 해당 예외를 처리하고 있다. 코드대로라면 들어온 데이터에서is_dense 값을 뽑아서 처리한다는 것을 알 수 있다.

그렇다면 저 is_dense 값은 라이다에서 생성하여 토픽으로 넘겨준다는 것이다. 해당 값을 생성하는 코드를 찾아보자.

ouster_ros 패키지의 point_cloud_compose.h파일을 확인해보면 코드가 있다. is_dense는 포인트 측정 간에 값 중 NaN 값이 들어있으면 false로 판단되는 것이다.

그렇다면 측정값에서 NaN을 없애면 되는 것 아니겠는가? 사실 공식 SDK를 수정하는 것이 맞는 선택일지는 잘 모르겠지만 지금 당장은 다른 방법이 없으니 한 번 해보도록 하자. 일단 돌아가면 장땡 아니겠는가?

for (int i = 0; i < 3; ++i) {
    if (std::isnan(xyz(i))) {
        xyz(i) = 0.0f;
    }
}

위와 같이 값에 필터를 씌워 NaN 값을 강제로 0으로 대체했다.

글로 보았을 때에는 금방 해결한 것 처럼 보이지만 사실 엄청난 삽질이 있었다. 하지만 반쯤은 뻘짓이었으니 넘어가도록 하겠다. 어쨌든 돌아가는 하나의 경우를 발견하였지 않은가?

에러2 : IMU 센서 축 설정 문제

이후 코드를 돌려보면 rviz 화면에 뭐가 뜨기 시작한다!

여기서부터는 사용하는 장비에 따라 정상적으로 코드가 실행되는 사람도 있을 것이고 나와 같이 별자리마냥 요상한 그림이 그려지고 있는 사람이 있을 수도 있다. 혹은 뭔가 뜨긴 하는데 공간이 뒤틀리고 있는 사람도 있을 것이다.

만약 한 번에 정상적으로 뜨는 사람들은 축하한다. 더 이상 글을 읽을 필요가 없다. 성공을 자축하며 떠나길 바란다.

그러나 그렇지 않은 사람은 나와 함께 조금 더 달려가보자.

참고로 아래는 나의 결과 화면이다. 별자리가 하나 생겼다.

엄청난 삽질 끝에 알아낸 원인은 imu 설정 문제였다. 위 화면에서 정상적인 결과가 나온 사람들은 운이 좋게도 imu 센서의 축 정렬이 설정된 값과 동일하였던 것이다.

깃허브에 보면 IMU 센서 축 관련 내용이 있다.

바로 이 화면이다.

여기서는 라이다의 축과 부착된 IMU 축이 달라서 따로 설정을 해줬다. 위에서 2번 데이터셋을 실행할 때 extrinsicRot와 extrinsicRPY를 설정한걸 기억하는가? 그것이 IMU 센서의 축을 라이다와 동일하게 맞춘 것이다.

그래서 우리는 extrinsicRot와 extrinsicRPY를 우리 IMU 센서에 맞게 축을 수정해주어야 한다. 만약 IMU 센서와 라이다의 축이 동일하다면 아래와 같이 단위행렬로 변경하면 된다.

그리고 실행해보면 별자리가 사라지고 나름 맵의 형태를 띄는 것을 볼 수 있다.

에러3 : IMU 센서 드리프트 현상

그러나 나의 경우에는 IMU 센서의 성능 문제로 지속적인 드리프트가 발생하였다. 위 사진이 약간 이상한 것도 드리프트가 발생해서 그렇다. 이 문제는 imu_utils 툴을 사용하여 imu 센서의 노이즈 값을 찾은 후 파라미터를 수정해주어야 한다.

자세한 적용 방식은 위의 깃허브 페이지에 자세히 설명되어 있으니 현재는 설명하지 않고 추후에 기회가 된다면 추가하도록 하겠다.

결론

결론적으로 나는 노이즈 값을 찾아서 적용하였지만 센서의 성능 문제인지 계속 드리프트가 일어나 IMU를 사용하는 SLAM 알고리즘을 포기하고 KISS-SLAM을 사용하였다. 이건 파이썬 기반이라 버전 탈 염려도 없고 잘 돌아간다... 만세! ROS와 연동하는 문제가 있긴 하지만 이건 KISS-ICP를 사용하거나 직접 ROS 패키지를 만들면 해결되는 문제이다.

이렇게 LIO-SAM을 적용해보려던 시도를 한 번 적어보았다. 결론적으로는 다른 알고리즘을 사용하게 되었지만 시도한 과정을 정리할 겸 누군가에게 도움이 될까 하여 포스트를 정리해본다. 다들 즐겁고 막힘없는 코딩 생활 되길 바란다.

탐욕 알고리즘, 다른말로 그리디 알고리즘이란 각 분기마다 현 상황에서 최적의 선택을 고르는 알고리즘을 말합니다. 완전 탐색 알고리즘과 비슷하지만 모든 선택지를 고려하여 그 중 최적해를 찾는 방법이 아닌 지금 당장 가장 좋은 방법만을 선택하는 것입니다.

그리디 알고리즘의 사용

그리디 알고리즘은 많은 경우 최적해를 찾지 못합니다. 그러나 2가지의 경우에서는 그리디 알고리즘을 사용하는 것이 좋은 방법일 수 있습니다.

1. 탐욕법을 사용하도 항상 최적해를 구할 수 있는 문제를 만난 경우, 탐욕법은 다른 알고리즘에 비해 수행 시간이 월등히 빠르기 때문에 유용
2. 시간이나 공간적 제약으로 인해 다른 방법으로 최적해를 찾기 어려운 경우 최적해 대신 근사해를 찾는 것으로 타협하는 경우

깊이 우선 탐색(DFS, Depth-First Search)

DFS는 Depth-First Search, 깊이 우선 탐색이라고도 불리며 그래프의 한 노드에서 시작하여 해당 분기의 노드를 완전히 탐색하고 다음 분기로 넘어가는 방식을 말합니다.

쉽게 말해 루트 노드에서 시작하여 한 방향으로 갈 수 있을 때까지 계속 가다가 더 이상 갈 수 없게 되었을 떄 가장 가까운 분기로 돌아와 다시 탐색하는 방법입니다. 보통 모든 노드를 방문하여야 하는 경우 사용하게 됩니다.

DFS의 시간복잡도는 V를 정점의 수, E를 간선의 수라 할 때 $O(|V| + |E|)$이다.

너비 우선 탐색(BFS, Breadth-First Search)

BFS는 Breadth-First Search, 너비 우선 탐색이라고도 불리며 그래프의 한 노드에서 시작하여 인접한 노드를 먼저 탐색하고 그 후에 멀리 떨어져 있는 노드를 탐색하는 방식을 말합니다.

루트 노드에서 시작하여 해당 노드의 이웃 노드를 모두 방문하고 그 후 다음 노드로 넘어가는 방법입니다. 보통 최단경로를 구하거나 임의의 경로를 구하는 상황에 사용하게 됩니다.

BFS의 시간복잡도는 $O(|V| + |E|)$로 DFS와 동일합니다.

정렬 알고리즘은 원소들을 번호순이나 사전 순서와 같이 일정한 순서대로 열거하는 알고리즘을 뜻한다. 정렬 알고리즘에는 다양한 종류가 있지만 시간 복잡도와 공간 복잡도를 고려하여 올바른 알고리즘을 선택하는 것이 중요하다.

선택 정렬

시간복잡도(최악/최선/평균) : $O(n^2)$

선택 정렬은 아직 처리되지 않은 데이터들 중 가장 작은 데이터를 골라 맨 앞의 데이터와 변경하는 방식으로 다음과 같은 순서로 이루어진다.

1. 주어진 리스트에서 최솟값을 찾는다.
2. 그 값을 맨 앞에 위치한 값과 교체한다.
3. 맨 처음 위치를 뺸 나머지 리스트를 같은 방법으로 교체한다.

삽입 정렬

시간복잡도(최악/평균) : $O(n^2)$ 시간복잡도(최선) : $O(n)$

삽입 정렬은 자료 배열의 모든 요소를 앞에서부터 차례대로 이미 정렬된 배열 부분과 비교하여, 자신의 위치를 찾아 삽입하는 방식으로 다음과 같은 순서로 이루어진다.

1. 주어진 리스트에서 2번째 요소와 앞의 요소를 비교한다.
2. 해당 요소를 적절한 위치에 삽입한다.
3. 앞의 리스트를 제외한 나머리 리스트를 같은 방법으로 삽입한다.

버블 정렬

시간복잡도(최악/평균) : $O(n^2)$ 시간복잡도(최선) : $O(n)$

버블정렬은 기본적으로 배열의 두 수 $(a, b)$를 선택하여 만약 그 두 수가 정렬되었다면 놔두고 아니라면 두 수를 바꾸는 방식으로 다음과 같은 순서로 이루어진다.

1. 배열의 첫 두 요소를 비교한다.
2. 만약 정렬되어 있다면 그대로 두고 아니라면 위치를 바꾸어 정렬한다.
3. 이를 배열의 처음부터 끝까지 여러 번 반복한다.
4. 만약 배여르이 변화가 없으면 정렬된 것으로 정의한다.

병합 정렬

시간복잡도(최악/최선/평균) : $O(nlogn)$

병합정렬은 다음과 같은 순서로 이루어진다.

1. 정렬되지 않은 리스트를 각각 하나의 원소만 포함하는 n 개의 부분리스트로 분할한다.
2. 부분리스트가 하나만 남을 때까지 반복해서 병합하며 저렬된 부분리스트를 생성한다.
3. 마지막으로 남은 부분리스트가 정렬된 리스트이다.

퀵 정렬보다는 느리고 공간을 많이 잡아먹지만 안정 정렬에 속하여 동일 값일 때 기존의 순서가 보장된다는 장점이 있다.

퀵 정렬

시간복잡도(최악) : $O(n^2)$ 시간복잡도(최선/평균) : $O(nlogn)$

퀵 정렬은 다음과 같은 순서로 이루어진다.

1. 리스트 가운데서 하나의 원고를 고른다. 이렇게 고른 원소를 피벗이라고 한다.
2. 피벗 앞에는 피벗보다 값이 작은 모든 원소들이 오고, 피벗 뒤에는 피벗보다 값이 큰 모든 원소들이 오도록 분할한다.
3. 분할된 두 리스트에 대해 위 과정을 반복한다.

이 시리즈는 개발 도중 알게 된 간단한 정보들을 정리하는 시리즈입니다.

생성자에서 예외가 생기면 어떻게 해야할까?

생성자는 return값이 없기 때문에 예외를 사용하여 처리하여야 한다. 기본적으로 자바에서 유효하지 않은 데이터가 전달되면 자동으로 예외를 발생시켜 객체가 인스턴스화 되지 않도록 방지한다.

그러나 예외가 발생되기 전 생성자가 데이터에 엑세스 한 경우, 부분적으로 생성된 생성자가 남아있을 수 있으므로 try-with-resources 등을 사용해 리소스를 해제하는 것이 좋다.

아래의 코드는 생성자 처음 부분에 데이터를 검사하여 예외를 처리하는 코드이다.

public Item(ItemStack item) throws IllegalArgumentException {
    if (!isItem(item)) {
        throw new IllegalArgumentException("Invalid item");
    }

    this.material = item.getType().toString();

    ItemMeta itemMeta = item.getItemMeta();

    this.name = itemMeta.getDisplayName();
    this.lore = itemMeta.getLore();
    this.customModelData = itemMeta.getCustomModelData();
}

SOLID 원칙이란 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 말한다.

• SRP(Single Responsibility Principle): 단일 책임 원칙
• OCP(Open Closed Priciple) : 개방 폐쇄 원칙
• LSP(Listov Substitution Priciple) : 리스코프 치환 원칙
• ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
• DIP(Dependency Inversion Principle) : 의존 역전 원칙

좋은 소프트웨어란 확장성이 뛰어난 것을 의미한다. 뛰어난 확장성을 가지려면 좋은 설계가 필요하다. 그렇다면 좋은 설계란 무엇인가? 좋은 설계는 소프트웨어에 변경점이 있을 때 영향을 받는 범위가 적은 설계를 뜻한다.

SOLID 객체 지향 설계 원칙을 적용하면 코드의 확장성이 높아지고 유지 보수가 쉬워진다. 또한 코드의 복잡도가 줄어들어 생산성을 높일 수 있다. 다만 모든 원칙을 다 지키는 것은 쉬운 일이 아니며 꼭 모든 원칙을 지켜야 하는 것은 아니다.

SRP(Single Responsibility Principle)

클래스는 단 하나의 책임만 가져야 한다

어떠한 클래스가 단 하나의 책임만 가져야 한다는 것은 코드를 변경해야 하는 이유가 단 하나여야 한다는 의미이다. 하나의 클래스가 하나의 기능만 담당하고 있으면 코드를 변경해야 하는 이유가 '해당 기능을 수정할 때' 하나뿐이니 단일 책임 원칙을 준수하고 있다고 볼 수 있다.

OCP(Open Closed Priciple)

확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다

어떠한 기능을 추가할 때 기존 클래스를 확장하여 쉽게 구현하면서도 기존의 코드는 수정을 최소화해야 한다는 원칙이다. 즉 기존의 코드를 수정하지 않고도 기능을 추가할 수 있도록 설계해야 한다는 의미이다.

LSP(Listov Substitution Priciple)

하위 타입 객체는 상위 타입 객체에서 가능한 행위를 수행할 수 있어야 한다

서브 타입(자식)은 언제나 상위 타입(부모)으로 교체할 수 있어야 한다는 원칙이다. 즉, 부모 타입으로 메서드를 실행해도 의도대로 실행되도록 구성을 해줘야 한다는 것이다. 이러한 원칙을 잘 지키려면 부모 메서드의 오버라이딩을 할 때 주의를 기울여야 한다.

ISP(Interface Segregation Principle)

자신이 사용하는 메소드에만 의존해야 한다

인터페이스를 각각 사용별로 분리해야한다는 설계 원칙이다. 이는 SRP와 비슷한 데 SRP가 클래스를 분리하는 것이라면, ISP는 인터페이스를 분리하는 것이라고 보면 된다. 결국 필요로 하는 인터페이스들을 분리함으로써, 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않도록 만들어야 하는 것이 핵심이라고 볼 수 있다.

DIP(Dependency Inversion Principle)

고수준의 코드는 저수준의 코드에 의존해서는 안 된다

의존 관계를 맺을 때, 구체화된 클래스에 의존하기 보다는 추상 클래스나 인터페이스에 의존해야 한다는 원칙으로 저수준 모듈이 변경되어도 고수준 모듈은 변경이 필요없는 형태로 만들어야 한다는 것이다.

프로그램을 설계할 때 발생하였던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 규약 형태로 만들어 놓은 것

디자인 패턴이란 프로그램을 설계할 때 발생하였던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 규약 형태로 만들어 놓은 것을 의미한다. 즉 과거의 소프트웨어 개발 과정에서 반복적으로 일어나는 문제를 해결하는 설계 방안을 정리하고 이름을 붙여 이후에 재사용하기 좋은 형태로 정리한 것이다.

2. 디자인 패턴의 종류

생성 패턴, 구조 패턴, 행위 패턴

디자인 패턴은 크게 3가지로 나눌 수 있다.

먼저 생성 패턴(Creational Pattern)이다. 객체의 생성에 관련된 패턴으로 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.

다음은 구조 패턴(Structural Pattern)이다. 구조 패턴은 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴이다. 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.

마지막으로 행위 패턴(Behavioral Parrern)이다. 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴으로 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 두는 방식이다.

3. 생성 패턴

객체의 생성에 관련된 패턴

• 싱글톤 패턴 : 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴

  4. 구조 패턴

  클래스나 객체를 조합해 더 큰 구조를 만드는 패턴

5. 행위 패턴

객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴

• 전략 패턴 : 실행 중에 알고리즘 전략을 선택하여 객체 동작을 실시간으로 바뀌도록 할 수 있게 하는 패턴

이후 공부하며 추가 예정