클라우드 연동을 위한 ROS2 on Yocto 기반의 Thin Client 로봇 개발

2.1 Ubuntu와 Yocto

리눅스는 전체 시스템을 구성하는 각 개별 파트가 아닌 OS 커널을 의미하며, 리눅스 배포판은 부트로더, 리눅스 커널, 루트 파일시스템으로 구성된다. Yocto는 리눅스 배포판을 만들 수 있는 툴이며, 리눅스 배포판 자체를 의미하지 않는다. 반면 Ubuntu는 Debian을 기반으로 오픈 소스 소프트웨어로 구성된 리눅스 배포판이며, 리눅스 배포판을 만들 수 있는 툴이 아니다. 즉, Yocto와 Ubuntu는 성격자체가 다르기 때문에 임베디드 기반의 리눅스 시스템을 개발하고 유지보수 하는 데 있어서, 각각의 장단점을 가지고 있다.

2.2 Ubuntu와 Yocto의 장단점

Ubuntu는 리눅스 배포판을 사용하여, 시스템을 구성하기 때문에 빠른 프로토타이핑, Proof of Concept에 장점을 가지고 있다. 그러나 Ubuntu를 지원하는 하드웨어가 있어야 하고, 많은 메모리가 필요하다. 또한 하드웨어 이식성, 이력관리를 통한 유지보수가 어려운 단점을 가지고 있다. 반면 Yocto는 다양한 하드웨어를 지원하는 맞춤형 임베디드 환경에 적합하며, 하드웨어 이식성, 유지보수, 이력관리에 장점이 있다. Ubuntu와 Yocto의 장단점에 대해서는 [Table 1]에 상세히 기술하였다^[7].

[Table 1]

Comparison of Yocto and Ubuntu Debian

결론적으로 Ubuntu는 빠른 프로토타이핑, Proof of Concept에 장점을 가지고 있다. 그러나 다양한 form factor의 로봇지원, 하드웨어 이식성, 부팅시간, 메모리, 라이센스 관리 및 유지보수 측면을 고려하여, bottom-up 방식의 맞춤형 설계로 OS의 경량화가 필요하며, 클라우드와의 연동을 통해 로봇의 자원을 효율화하고, 성능을 극대화할 수 있는 ROS2 on Yocto 기반의 Thin Client 로봇 개발이 요구된다.

4.1 가정용 청소로봇

ROS2 on Yocto 기반의 가정용 청소로봇을 위한 functional block diagram은 [Fig. 2]와 같으며^[8], Rockchip PX30K board의 device 제어를 위한 BSP device driver, device를 운용하기 위한 device engine, 자율주행을 위한 navigation engine, Gazebo 기반의 simulator 구동을 위한 robot simulator 및 ROS2 message handler로 구성된다. 모든 engine들은 ROS2 node로 구현되었으며, ROS2 message handler는 ROS2의 node간 통신을 위한 topic, service의 interface를 API로 제공한다. 각 node의 역할은 아래 [Table 2]에 상세히 기술하였다.

[Fig. 2]

Functional Block Diagram for Cleaning Robots

[Table 2]

Nodes and Responsibility of Cleaning Robots

4.2 상업용 실내배송로봇

ROS2 on Yocto 기반의 상업용 실내배송로봇의 functional block diagram은 [Fig. 3]과 같으며, Nvidia TX2 board의 device 제어를 위한 BSP device driver, device를 운용하기 위한 device engine, 자율주행을 위한 navigation engine, 장애물 인식 및 docking/undocking을 위한 perception engine, Unity 기반의 simulator 구동을 위한 robot simulator 및 ROS2 message handler로 구성된다. 청소로봇과 동일하게 모든 engine들은 ROS2 node로 구현되었으며, ROS2 message handler는 ROS2의 node간 통신을 위한 topic, service의 interface를 API로 제공한다. 마지막으로 cloud bridge는 클라우드 연동을 위한 bridge node로서 ZeroMQ를 통해 로봇과 서버를 연결한다. 각 node의 역할은 아래 [Table 3]에 상세히 기술하였다.

[Fig. 3]

Functional Block Diagram for Delivery Robots

[Table 3]

Nodes and Responsibility of Indoor Delivery Robots

5.1 Memory 사용량 개선

임베디드 환경에서의 RAM 사용량 개선을 위해 본 연구에서는 binary 기반 ROS2 node의 launch 방식을 적용하여, Python 기반 방식 대비 memory 사용량을 개선하였다^[9]. [Fig. 4]는 ROS2에서 제공하는 Python 기반 node 실행방식에서의 physical RAM 사용량을 보여준다. 그림과 같이 Python 관련 library, ROS2의 library process와 함께 folk를 통해 child process가 추가로 생성되어 실행되는 것을 확인할 수 있다. 즉, 2개의 process가 실행되 어 RAM 점유율이 증가되는 문제점을 가지고 있다.

[Fig. 4]

ROS2 launch method based on Python

이에 대한 개선을 위해 본 논문에서는 binary 기반의 ROS2 node 실행방식을 적용하여 RAM 사용량을 개선하였다. [Fig. 5]와 같이 shell 기반의 binary 실행방식 적용을 통해, RAM상에 상주하는 Python code들을 모두 제거하여 저용량의 RAM에서도 ROS2가 동작할 수 있는 가능성을 검증하였다.

[Fig. 5]

ROS2 launch method based on Python

아래는 Python, binary node 실행 방식 및 이에 대한 예로motion node 실행 방법에 대해 각각 설명하였다.

Python 기반 실행방식ros2 launch [NODE_NAME] [NODE_NAME].launch.pyros2 launch motion motion.launch.pyBinary (Shell) 기반 실행방식[BIN_PATH] __node:=[NODE_NAME] __ns:=[NAME_SPACE] __params:=[YAML_PATH]/usr/lib/motion/motion __node:=motion __ns:=/manager_ns __params:=/usr/share/motion/launch/motion.yaml

[Table 4]는 각각 Python 기반의 실행방식, binary 기반의 실행방식을 적용하여, 청소로봇으로 zigzag 주행검증 시의 RAM 점유율을 보여주고 있다.

[Table 4]

RAM usage of python and binary launch method

Python 기반 실행 방식의 경우, 7개의 node (data access, navigation, motion, SLAM, planning, media, 3D sensing) 실행 시, free RAM이 9,960 KB (9.7 MB) 수준으로 측정되었다. 반면 Binary 기반 실행방식 적용 시에는 free RAM이 149,632 KB (146 MB) 수준으로 Python 실행방식 대비, 약 140 MB 이상의 RAM 사용량을 절감하였으며, 충분한 free RAM 용량을 확보하였다고 판단할 수 있다.

5.2 Network I/O 개선

ROS2의 node간 통신은 bus가 아닌, TCP/UDP를 통한 network 통신으로 이루어진다. 1 KB 이상의 huge data topic의 빈번한 통신은 network 부하 및 message loss를 유발할 수 있으며, 이에 대한 처리를 위해 IPC (Inter-Process Communication) 적용이 필요하다. 본 논문에서는 huge data 처리를 위한 IPC를 구현함으로써 network I/O에 대한 개선을 진행하였다. 빠른 속도처리를 위해서 일반적인 파일 R/W의 storage를 사용하지 않고, DRAM에만 임시 저장하는 mmap 방식을 적용하였다.

huge data topic으로는 3D sensing, image data를 선정하였으며, [Fig. 6]은 3D sensing에 적용한 mmap의 동작방식을 나타내고 있다. Mmap의 정보(ipc_mmap_info)는 기존과 같이 DDS 통신으로 data가 처리되며, 3D sensing data인 depth_sensing_data 구조체는 mmap을 이용한 shared memory방식으로 huge data를 전달하게 된다. 이때 동기화 문제를 최소화 하기 위해, data를 mmap으로 생성한 file path에 write하고, physical memory에 바로 sync 하도록 구현하였다.

[Fig. 6]

The operation flow of IPC (mmap)

Mmap 적용 전후의 개선효과를 확인하기 위해 free memory와 network I/O 성능검증을 진행하였다. free memory 검증에는 ‘free’shell command를, network I/O 검증에는 ‘cat /proc/net/dev’ shell command로 사용하였으며, packet에 대한 transmit, receive의 bytes값으로 계산하였다.

[Table 5]는 mmap 전용 전후의 free memory, network I/O의 성능검증 결과를 보여주고 있다. Free memory는 mmap 적용 전후의 유의차가 없으나, network I/O는 mmap 적용으로 80 KB~100 KB의 개선효과가 확인되었다.

[Table 5]

Free RAM and network I/O before and after mmap

6.1 소프트웨어 및 하드웨어 사양

ROS2 on Yocto 적용에 따른 성능개선 및 memory, network I/O 개선효과를 실증하기 위해 LG전자 청소로봇 및 실내배송로봇을 활용하였다. 적용한 청소로봇 및 실내배송로봇의 Yocto, ROS2 및 kernel의 소프트웨어 버전은 [Table 6]와 같다.

[Table 6]

Software version of the cleaning and delivery robots

실기 검증을 위해 제작한 청소로봇 및 실내배송로봇의 하드웨어 사양은 [Table 7], [Table 8]과 같다.

[Table 7]

Hardware specification of the cleaning robots

[Table 8]

Hardware specification of the delivery robots

6.2 청소로봇의 자율주행 검증 및 성능평가

개선된 사항을 청소로봇 실기에 적용하여, [Fig. 7]과 같이 zigzag 주행기반으로 자율주행 및 회피주행을 검증하였다^[10]. 로봇은 전방에 위치한 3D sensing 하드웨어 모듈에 의해 장애물을 인식한다. 해당 모듈은 상방 laser, 하방 laser 및 camera로 구성되며, camera를 통해 적외선을 detection하여 장애물을 감지한다. 해당 모듈의 운용을 위한 3D sensing ROS2 node는 IR laser line을 상방과 하방에 주사하여 camera에 맺히는 영상으로 추출한 2차원의 IR line 좌표를 3차원의 실제 좌표로 변환하여 거리데이터를 추출하여 장애물과의 거리를 산출하여 navigation node로 전달한다. [Fig. 7]은 zigzag 주행 중 3D sensing에 의한 장애물 감지 및 이에 따른 회피주행 동작을 보여주고 있다.

[Fig. 7]

Autonomous driving verification of cleaning robots

또한 로봇의 현재 주행상태를 파악하기 위해 [Fig. 7]의 좌우측 상단과 같이 Rviz를 활용한 visualization tool을 구현하였다. 로봇은 주행 중 corrected pose, SLAM node 좌표, coverage map을 publish 하는데 동일 network domain내의 proxy server (remote PC)를 활용하여 해당정보를 subscribe후 Rviz로 출력할 수 있도록 구현하였다.

청소시작, docking, 청소재시작, kidnap recovery, docking의 시나리오로 10분 동안 반복주행을 하면서, 1초주기로 CPU사용량, memory 사용량을 측정한 결과는 [Table 9]과 같다. 측정결과 CPU 사용량은 64%, RAM 사용량은 378 MB로 저사양의 임베디드 환경에서도 추가적인 기능들을 탑재할 수 있는 성능을 확보하였다고 판단할 수 있다.

[Table 9]

The performance verification result of cleaning robots

6.3 배송로봇의 Nav2 자율주행 검증 및 성능평가

Nav2 Project는 ROS2에서 공개한 Navigation Stack으로서^[11], 모바일 로봇이 A지점에서 B지점으로 안전하게 이동할 수 있는 방법을 제공하는 ROS2 node들의 집합이다. Navigation Stack의 목적은 로봇의 현재위치, 목표위치, 경로계획을 완료하고, odometry 데이터, 센서 데이터를 입력 받아, 모터의 속도를 계산하고, 장애물을 회피하며, 길을 잃지 않게 목적지로 이동하는 것이다. 본 논문에서는 [Fig. 8], [Fig. 9]과 같이 실내배송로봇에 Nav2를 적용하여, ROS2 on Ubuntu와 ROS2 on Yocto 기반의 자율주행을 검증하고, 각각의 성능평가를 진행하였다. [Fig. 8]은 SLAM toolbox^[12]를 이용한 mapping, [Fig. 9]는 Nav2를 이용한 목적지 자율주행을 나타내고 있으며, 각 그림의 좌측상단은 리눅스에서 지원하는 ‘htop’ 명령어에 따른 memory 사용량 및 CPU 점유율을, 우측상단은 Rviz를 활용한 현재 로봇의 위치, 맵과 장애물 정보, 주행상태를 보여주고 있다.

[Fig. 8]

Mapping of delivery robot using SLAM toolbox

[Fig. 9]

Autonomous driving using Nav2

Ubuntu 및 Yocto 기반의 실내배송로봇으로 move to goal(목적지 주행)을 반복하면서, 1초주기로 CPU사용량, memory 사용량을 측정한 결과는 [Table 10]과 같다. 측정결과 Yocto 적용 시, Ubuntu 대비 CPU 점유율을 약 30%, memory 사용량은 약 1.1 GB의 성능개선이 확인되었다.

[Table 10]

The performance verification result of delivery robots after applying Nav2 open source package

6.4 배송로봇의 자사 Navigation 적용에 따른 자율주행 검증 및 성능평가

본 논문에서는 [Fig. 10], [Fig. 11]과 같이 실내배송로봇에 자사 navigation을 적용하여 mapping 및 목적지 주행을 통해 자율주행 및 성능을 검증하였다.

[Fig. 10]

Mapping of delivery robot using LG navigation

[Fig. 11]

Autonomous driving using LG navigation

로봇은 위치인식을 위해 LiDAR node에서 주기적으로 scan data를 입력받고, micom으로부터 dead reckoning pose (odometry)를 받는다. 로봇이 일정 거리 이동하거나 일정 각도 이상 회전하였을 경우 realsense node에 영상을 요청하여 영상을 수신한다. 전방 영상을 이용하여 특징점을 추출하며 3D point를 생성하고 pose-graph 통하여 최적화를 수행하며 global pose를 보정한다.

로봇은 목적지 주행을 위해 DWA (Dynamic Window Approach) 알고리즘을 기반으로 목적지까지 자율주행을 한다. 현재 위치와 주변 장애물 정보를 고려하여 목적지에 도달하기 위한 경로를 생성하고, 생성된 경로를 기반으로 속도 명령을 생성한다. 주행 간 사람 및 장애물을 만나면 회피하며, 별도의 종료 명령이 없으면 최종 목적지까지 주행을 완료한다.

Ubuntu 및 Yocto 기반의 실내배송로봇으로 move to goal을 반복하면서, 1초주기로 CPU사용량, memory 사용량을 측정한 결과는 [Table 11]과 같다. 측정결과 Yocto 적용 시, Ubuntu 대비 CPU 점유율을 약 35%, memory 사용량은 약 1.15 GB의 성능개선이 확인되었다.

[Table 11]

The performance verification result of delivery robots