2.1 모델 제작 및 제원

본 논문에서는 제안하는 시스템에 대하여 실현 가능성에 대한 실증을 보이기 위해서 먼저, 실제 로봇을 제작한다. 그림 1에는 제작한 셀프 밸런싱 로봇 모델과 실제 구현한 실물 사진을 나타내었다. 그림 1과 같이 제작된 로봇은 바퀴, 모터 구동부(Driver), 센서부, 배터리, 응용 프로세서 (Application Processor) 등으로 구성되며, 알루미늄 샷시(Chassis)로 전체 조립한 로봇의 유동이 없도록 고정하였다.

그림 1. 셀프 밸런싱 로봇

Fig. 1. Self-Balancing Robot

셀프 밸런싱 로봇 모델링 및 제어는 많은 논문에서 다루어져 왔는데 본 논문에서는 ^[8]에서 제안한 방법을 기반으로 수학적 모델링을 수행한다. 본 논문에서 실험에 사용하기 위하여 제작한 셀프 밸런싱 로봇의 하드웨어 기구 사양을 표 1에 정리하여 나타내었다. 실제 관성값 (Inertia value)은 측정이 불가하여 ^[8]의 내용을 참조하였으며, 제어기의 비례이득과 미분이득을 조정하여 보정하는 방법을 사용하였다.

2.2 클라우드 기반 네트워크 제어 시스템 구성

클라우드 기반 네트워크 제어 대상으로 제작한 셀프 밸런싱 로봇 시스템의 구성은 그림 2 와 같다. 먼저, 로봇의 위치 측정을 위해서는 ^[9]와 같이 관성 측정 장치 (Inertial Measurement Unit: IMU)를 장착하여 직각을 기준으로 기울어진 Pitch (각도)와 Pitch rate (각속도) 값을 측정하고, 이를 범용으로 많이 사용하는 아두이노 메가 (Arduino Mega)를 통하여 측정값을 수집한다. 이렇게 측정하고 획득된 값을 통신 네트워크를 통해 퍼블릭 클라우드 상에 있는 제어기에 송신하여 셀프 밸런싱 로봇에 피드백 되어 입력될 제어 명령을 계산한다.

이 때, 모터 2개를 직접 구동하는 제어 보드에는 56V까지 지원하는 ODriver v3.6 을 사용하였다 ^[10]. 제작된 셀프 밸런싱 로봇은 클라우드 상의 원격 제어 시스템으로 부터 제어 입력을 수신하고, 이를 젯슨 자비어 (Jetson Xavier)를 통해 직접 모터 구동부에 입력하여 모터를 제어한다 ^[11].

한편, 하드웨어 운용을 위한 소프트웨어 구성은 다음과 같다. 먼저, 셀프 밸런싱 로봇의 두뇌라 할 수 있는 응용 프로세서의 운용체제는 범용성을 위하여 리눅스 우분투 (Ubuntu) 20.04 를 사용하였다. 셀프 밸런싱 로봇과 서버 사이의 센서 메시지 송수신, 제어 명령어 송수신은 ROS2 플랫폼을 사용하였으며 ^[12], 셀프 밸런싱 로봇과 클라우드 서버는 일반 와이파이(WiFi)를 통해 공중망으로 연결되도록 설계하였다. 셀프 밸런싱 로봇이 연결된 서브 네트워크와 클라우드 서버가 연결된 서브 네트워크는 서로 다른 네트워크로서 일반적으로 ROS2 통신을 할 수 없다. 이를 위해 본 논문에서는 오픈소스인 클라우드 브리지(Cloud Bridge)를 이용하여 셀프 밸런싱 로봇이 연결된 서브 네트워크와 클라우드 서버가 연결된 서브 네트워크 간에 ROS2 메시지를 송수신 할 수 있도록 구현하였다 ^[13].

그림 2. 셀프 밸런싱 로봇 시스템 구성도

Fig. 2. Block Diagram of Self-Balancing Robot System

3.1 제어기 구현

클라우드 상의 비례미분 제어기를 고려한 셀프 밸런싱 로봇의 폐루프 피드백 제어 시스템은 그림 3과 같이 나타낼 수 있다. 그림 3에서 기준 입력 신호 r(t)는 0 으로 가정하여 로봇으로 측정되어 받은 센서값을 그대로 오차(error)로 가정하고 비례이득(Kp) 값과 미분이득(Kd) 값을 조정한다. 또한, 퍼블릭 클라우드에서 제어기를 운영하기 위해 다음과 같은 두가지를 추가로 구현한다. 첫 번째는 쿠버네티스 시스템을 직접 퍼블릭 클라우드에 구축하고, 두 번째는 여기에 제어기를 실행하기 위해 우분투 20.04를 운영체제로 하고 Foxy를 ROS2 버전으로 하여 제어기 모듈을 도커 컨테이너 이미지로 구성한다. 제어기를 포함한 제어 시스템에 대해서는 다음 절에서 보다 상세히 다루도록 한다.

그림 3. 클라우드 기반 폐루프 피드백 제어 시스템 구성도

Fig. 3. Block Diagram of Cloud-based Closed-loop Feedback Control System

3.2 클라우드 기반 네트워크 제어 시스템

그림 4에는 클라우드 기반 네트워크 제어 시스템의 대략적인 구성도를 나타낸다. 그림 4에서 퍼블릭 클라우드로 구글 클라우드 플랫폼 (Google Cloud Platform: GCP)을 활용하였으며, 해당 클라우드 서버에 컴퓨트 인스턴스 (Compute Instance)를 생성하여 직접 쿠버네티스 플랫폼을 구축한다.

그림 4. 클라우드 기반 네트워크 제어 시스템 구성도

Fig. 4. Block Diagram of Cloud-based Networked Control System

그림 5에는 구글 클라우드의 컴퓨트 인스턴스를 구성하고, 이를 쿠버네티스로 구축한 결과를 캡처하여 나타내었다. 그림 5에서 controller-1 은 마스터 노드(Master Node)로 쿠버네티스 내부 컨테이너 운영 (Orchestration)과 외부 통신을 관리하는 마스터 역할을 하며, worker-1은 워커 노드(Worker Node)로 쿠버네티스에서 실제 컨테이너를 실행한다. 마스터 노드와 워커 노드는 클라우드 플랫폼 내에서 독립적인 컴퓨팅 자원으로 각각의 인터넷 주소 (Internal IP)를 클라우드 플랫폼으로부터 할당 받는다.

성능 검증 실험을 위한 컴퓨팅 자원 2개의 하드웨어 사양은 중앙 연산 처리 장치의 코어 2개, 속도는 2.2GHz, RAM은 8GB 에 해당하는 머신 타입(Machine type)으로 e2-standard-2 를 설정하였다. 또한, 컴퓨팅 자원의 지역적인 위치는 구글 클라우드 서비스 지역(Zone) 내에서 실험하는 곳과 가장 가까운 서울 지역을 선정하여 해당 지역인 asia-northeast3-a 로 설정한다.

그림 5. 구글 클라우드 플랫폼의 쿠버네티스를 구성하는 컴퓨트 인스턴스

Fig. 5. Compute Instance on Google Cloud Platform for Kubernetes

그림 6에는 구글 클라우드 컴퓨팅 자원 상에서 운영되는 네트워크 제어 시스템의 소프트웨어 구조 블록도를 나타내었는데 그림 6에서 클라우드 기반 제어 시스템 운영을 위해 필요한 구성은 다음과 같다. 컨테이너 레지스트리는 제어 시스템의 컨테이너 이미지를 버전별로 저장하고 관리하며, 쿠버네티스 플랫폼에서 지정된 버전의 다운로드 요청에 응답하여 버전을 선택하여 다운로드 할 수 있도록 한다. 쿠버네티스 플랫폼은 마스터 노드와 워커 노드로 구성되며, 마스터 노드는 제어기 컨테이너와 클라우드 브리지 컨테이너의 시작, 종료, 상태 관리 등을 수행하고 제어기 이미지와 클라우드 브리지 이미지를 지정된 워커 노드에 실행하도록 요청한다. 워커 노드는 마스터 노드의 요청에 따라서 제어기와 클라우드 브리지 이미지를 컨테이너 레지스트리로 부터 다운 받아 직접 실행하는 역할을 한다.

이후, 이들 컨테이너가 실행되면서, 각각 제어기 파드 (Pod)와 클라우드 브리지 파드가 생성되고, 각 파드는 내부 인터넷 주소 (Pod IP)를 부여받으며, 통신을 위해 인터넷 주소를 사용한다. 로드 밸런서는 쿠버네티스 내부와 외부에 각각 인터넷 주소와 포트를 부여하여, 내부 데이터 송신과 외부 데이터 수신을 통제하며, 셀프 밸런싱 로봇과 직접 통신한다. 특히, 직접 데이터를 처리하여 제어기에 ROS2 메시지로 송수신하는 기능은 클라우드 브리지에서 담당하며, 이때, 센서와 제어 명령의 데이터 흐름은 제어기 – 클라우드 브리지 – 로드 밸런서 – 셀프 밸런싱 로봇과 같은 흐름을 갖는다.

그림 6. 퍼블릭 클라우드 기반 네트워크 제어 시스템 상세 구조도

Fig. 6. Detailed Block Diagram of Public Cloud-based Networked Control System

4.1 실험 조건 및 방법

본 절에서는 제안한 방식에 대하여 제작한 셀프 밸런싱 로봇을 대상으로 상세 실험 내용과 결과에 대해 기술한다. 본 논문에서 제작한 셀프 밸런싱 로봇은 와이파이를 활용하여 공중망에 연결하여, 쿠버네티스 로드 밸런서에서 제공한 인터넷 주소와 포트를 통해 네트워크 제어 시스템에 접속한다.

그림 7에는 셀프 밸런싱 로봇과 제어 시스템 사이의 센서 및 제어 명령어 송수신 과정에 대한 시간 절차를 나타내었다. 여기서, 제어기에서 센서값을 받아 제어 명령을 계산하는 시간 csn – can 은 CPU, RAM 등의 클라우드 연장 자원을 충분히 사용하기 때문에 네트워크의 시간 지연에 비하여 매우 작아서 실험에 큰 영향을 미치지 않는다고 가정한다. 그림 7에서 송신측 센서값을 측정해서 제어기로 송신하는 주기 rs2 – rs1 은 10ms (100Hz) 이며, 이것은 실제 셀프 밸런싱 로봇의 센서에서 피치값을 측정하는 주기와 같도록 설정한다. 마찬가지로 클라우드 상의 제어기도 rc2 – rc1 의 주기를 갖고 있으며, 실험에서는 센서 주기와 같이 10ms 로 설정한다. 그림 7에서 ra1 > rs2 인 경우에는, 로봇에서 센서값을 측정하여 원격 제어기에 송신하고, 그에 해당하는 제어 명령을 수신하는 왕복시간 (Round Trip Time)이 10ms 를 초과한다는 의미이다. 이러한 네트워크 지연이 지속되어 누적된다면, 로봇의 동작이 불안정해지고, 회복 불가능한 상태가 지속되어 최종적으로는 균형을 잃고 넘어지게 된다. 따라서, 이를 방지하기 위해서는 지연에 따른 센서값을 예측하여 제어 명령을 계산하여 셀프 밸런싱 로봇에 송신하는 절차가 있어야 하며 ^[14], 본 논문에서는 비례이득과 미분이득을 상황에 맞추어 휴리스틱(Heuristic)하게 조정한다.

보다 현실적인 실험을 위해서 로봇과 제어기가 위치한 서버 사이 시간 동기화를 위해 네트워크 타임 프로토콜 (Network Time Protocol: NTP)을 서버 및 셀프 밸런싱 로봇에 설치하고, NTP 서버는 asia.pool.ntp.org 로 세팅하여 같은 위치의 시간으로 동기화 한다. 셀프 밸런싱 로봇이 위치한 장소에서 퍼블릭 클라우드 기반 제어 시스템까지의 통신 속도를 측정하기 위해서 핑(ping)을 통하여 64 바이트 패킷의 왕복 시간을 측정하여 왕복 시간을 기반으로 비례이득과 미분이득을 휴리스틱 하게 조정한다. 특히, ROS2 플랫폼에서 제공하는 API (Application Programming Interface)를 활용하여 피치, 피치율, 토크의 주기를 측정한다. 또한 셀프 밸런싱 로봇의 균형 유지 여부를 실증을 통해 확인하고, 클라우드 네트워크 제어 시스템의 실현 가능성을 확인한다.

그림 7. 센서와 제어 명령 송수신 시간 절차

Fig. 7. Time Sequence for Communication of Sensor value and Control command

4.2 실험 결과

셀프 밸런싱 로봇에서 클라우드 네트워크 제어 시스템까지의 왕복 시간을 측정하기 한 결과, 530개의 패킷(packet)을 송신했을 때, 100% 수신율을 보여 패킷 손실은 0% 였다. 표 2에는 왕복 시간에 대하여 최대, 최소, 평균 시간 측정값을 나타내었다. 표 2에서와 같이, 왕복 시간의 평균은 5.667ms 로서 셀프 밸런싱 로봇 센서 송신 주기와 제어 명령어의 송신 주기 10ms 보다 작아서, 셀프 밸런싱 로봇이 균형을 유지하는 조건을 만족함을 알 수 있다.

이를 보다 더 자세히 살펴보기 위하여 그림 8에는 셀프 밸런싱 로봇으로부터 클라우드 제어 시스템까지의 각 패킷 별 왕복 시간을 나타내었다. 그림 8에서와 같이 총 530개 패킷 중에서 10ms를 초과하는 패킷은 14개로 약 2.4%였으나, 10ms 이하의 패킷이 516개로 약 97.6%에서 셀프 밸런싱 로봇이 균형을 유지하는 조건을 만족함을 확인할 수 있다. 본 논문에서는 이러한 실험 환경에 적합하도록 최대한 휴리스틱하게 제어기 이득을 조정하였다.

그림 8. 패킷별 왕복 시간

Fig. 8. Round Trip Time for Packet

셀프 밸런싱 로봇과 클라우드 네트워크 제어 시스템간의 연결을 통해 셀프 밸런싱 로봇 균형 유지를 제어하는 실제 실험 시간은 총 530초 동안 진행 되었다. 셀프 밸런싱 로봇이 작동 시작부터 약 175초까지 균형을 잘 유지함을 확인한 후 로봇에 인위적으로 충격을 가해서 고의적인 외란을 발생시켰는데, 이때 약 2초 동안 로봇에 앞뒤 진동이 있었으나, 이후 바로 균형을 유지하며 530초 동안의 실험을 성공적으로 마쳤다.

그림 9에는 시간별 피치값과 피치율에 대한 결과를 나타내었다. 그림 8에서 피치와 피치율이 로봇에 인위적으로 충격을 가해서 고의적인 외란을 발생시킨 175초 부근에서 외부 충격으로 크게 변화하는 것을 볼 수 있다. 한편 그림 9에는 모터에 가해지는 토크를 시간별로 측정한 결과를 나타내었다. 그림 10에서도 같은 이유로 175초 부근에서 토크값이 크게 변화하는 것을 볼 수 있는데 이는 셀프 밸런싱 로봇이 앞뒤로 크게 진동하는 것에 대해서 균형을 유지하기 위해 모터에 가해지는 힘이 증가했기 때문이다.

한편, 셀프 밸런싱 로봇이 피치값와 피치율값을 송신하는 주기는 평균 10.15ms (98.5Hz) 이었고, 셀프 밸런싱 로봇에서 수신하는 토크값의 주기는 평균 10.10ms (99Hz)로 측정되었다. 따라서 센서값의 전송 주기 보다 모터의 전송주기가 더　작기 때문에 특이한 통신상의 외란이 없다면 퍼블릭 클라우드 기반 네트워크 제어 시스템은 충분히 실현가능 할 것이다.

위에서 살펴본 바와 같이, 본 논문에서 제작한 셀프 밸런싱 로봇과 구글 클라우드 기반 네트워크 제어 시스템의 실험 결과를 통해 셀프 밸런싱 로봇이 클라우드 네트워크 제어 시스템을 통해서 균형을 유지하며 제어 가능한 것을 확인 할 수 있다.

그림 9. 피치(pitch), 피치율(pitch rate)의 시간별 측정

Fig. 9. Pitch(°) and Pitch Rate(°/sec) according to Time (ms)

그림 10. 모터에 가해지는 토크의 시간별 측정

Fig. 10. Torque (N·m) according to Time (ms)