ICT 융합 프로젝트 공모전 우수상

메카넘휠과 2D lidar를 이용한 자율주행 로봇

글 | 포항공과대학교 이도현

1. 심사평
칩센 자동차의 자율 주행을 위해서도 Lidar와 Radar를 이용한 기술들이 매우 많은 관심과 연구가 이루어지고 있는 것으로 알고 있습니다. 시연 동영상내에서도 경로를 잘 탐색한듯 하지만 마지막에 충돌이 발생하는 부분을 확인 가능한데, 이러한 부분을 개선 가능한 다른 솔루션도 함께 적용하면 시뮬레이션 레벨을 넘어서는 매우 훌륭한 작품이 만들어 질 것으로 보입니다.
펌테크 LIDAR를 활용한 자율주행 로봇 작품으로 전체 하드웨어 및 소프트웨어 시스템 연동을 위한 기획의도, 기술 구현 방안 및 작품의 하우징 구성 등이 인상적이었으며 기술 구현도, 완성도 등에서 상당히 우수한 작품으로 생각합니다.
위드로봇 메카넘 휠을 쓴 부분을 제외하곤 전형적인 이동로봇이라 창의성 부분이 아쉽습니다. 완성도는 높이 평가합니다.
뉴티씨 각종 센서로 장애물 등을 파악하여 회피할 수 있었는데, 비용만 충분하다면, 보다 많은 센서를 사용하여, 아무리 목적지가 벽 안에 있다고 해도 부딪히지 않았을 것 같아 개선의 여지가 보입니다. 만들다보면, 기계적인 부분에서도 많은 비용이 발생하고, 배선 부분이나 통신 부분에서도 어려움이 많은데, 조금 더 노력하면 더 좋은 작품이 탄생할 것 같습니다.

2. 작품 개요
본 프로젝트인 ‘메카넘휠과 lidar를 이용한 자율주행 로봇’ slam기술을 적용하여 자율주행을 구현하였다. slam이란 Simultaneous Localization and Mapping의 약자로, 동시에 로봇의 위치추정 및 주변 환경 지도 작성을 수행하는 기술이다. 본 프로젝트에서는 2d lidar를 통해 주변 환경을 pointcloud 데이터로 받아와, 메카넘휠의 odometry와 결합하여 map을 생성한다. 생성된 map을 바탕으로 출발점에서 목적지까지 최단 경로를 생성하여, 로봇이 그 경로를 따라 이동하는 방식으로 자율주행이 이루어진다.
단순히 로봇 주변에 장애물이 일정 이상 가까워지면 멈추고 다른 방향으로 가는 것이 아니라, lidar가 닿는 전 부분에서 주변의 모든 구조를 인식하고, 그 구조 위에서 목적지까지 장애물을 피해서 갈수 있는 최단 경로를 생성한 후에 그 경로를 따라 로봇이 움직이는 것이다. 이러한 작업이 실시간으로 진행된다.
또한 일반적인 자율주행 플랫폼과 달리, 만들어진 지도를 자율주행에만 사용하고 버리는 것이 아니라. 그 데이터를 TXT파일로 저장해 도출하여 주행이 끝나고 시스템이 종료된 뒤에도 만들어진 지도를 확인할 수 있는 기능을 가지고 있다.
해당 자율주행 플랫폼은 식당 서빙 로봇, 로봇청소기, 물류창고 로봇 등등 바퀴를 사용하는 플랫폼이라면 모두 적용할 수 있으므로, 활용성과 적용성이 매우 높다고 볼 수 있다.

3. 작품 설명
3.1. 주요 동작 및 특징
3.1.1. 전방향 이동 가능
메카넘 휠을 기반으로 플랫폼을 제작하였다. 메카넘휠의 특징 상, 플랫폼(차)이 회전하지 않고도 모든 방향으로 이동할 수 있다는 장점이 있다. 따라서 일반적인 조향장치를 가진 플랫폼이 가지 못하는 경로도 본 프로젝트의 메카넘휠 플랫폼은 따라 갈 수 있다는 장점이 있고, 이는 자율주행에 큰 이점이 될 수 있다.

3.1.2. 주변 환경 인식 후 지도생성 가능

본 프로젝트는 ydlidar X2L을 사용하여 주변 환경을 pointcloud로 받아온다. 받아온 pointcloud들을 메카넘휠의 wheel odometry와 합쳐 주변환경의 지도를 생성한다. 주변환경의 정보를 다음 페이지 테스트 환경과 지도로 수집할 수 있다는 그 자체로 장점이 될 수 있고, 저렇게 실시간으로 제작되는 지도는 자율주행을 위한 경로탐색 알고리즘을 담당하는 python코드로 전송되어 로봇이 목표지점까지 갈 수 있도록 하는 경로를 생성하는 데 이용된다.

3.1.3. 로봇이 갈 수 있는 최단경로 정보 생성 가능
본 프로젝트의 로봇은 얻은 지도 데이터를 바탕으로 로봇이 목표지점까지 갈 수 있는 최단 경로를 실시간으로 생성한다.
최단거리 생성을 우선으로 하되, 벽에 부딪힐 가능성을 줄이고자 벽과는 반드시 일정 거리를 두도록 프로그래밍 하였다. 경로탐색에 쓰인 알고리즘은 A* algorithm이다. 실시간으로 전송되어 오는 지도마다 경로탐색을 새로 실시하기 때문에, 주행 중 이전 지도에는 없던 장애물이나 벽을 감지하게 되면, 그에 따라 새로운 경로를 생성해낸다. 따라서 목표지점까지 장애물과 부딪히지 않으면서 최단 경로로 도달할 수 있다.

3.1.4. 생성된 최단경로를 바탕으로 로봇의 자율 주행 가능
A* 알고리즘을 통해 얻은 경로를 로봇이 그대로 따라갈 수 있는 능력을 가지고 있다. 자세한 원리는 후에 다른 목차에서 설명할 것이다. 현재 로봇의 목적은 자율주행이므로 A*알고리즘이 만든 경로만을 따라가지만, 설정을 바꾼다면 사람이 지도를 보고 그린 경로를 따라가게도 만들 수 있다.
본 프로젝트의 주요 동작은 자율주행이다. 라인트레이서나 트래커와 다르게 어떠한 표식이 없어도 스스로 주변환경을 인식하여 외부의 도움 없이 목적지까지 도달 할 수 있으며, 일반적인 자율주행과 다르게 메카넘휠을 사용하였기 때문에 모든 경로로 이동할 수 있는 장점이 있다. 또한, 주 부품이 스텝모터 4개, 저가형 2d lidar 하나, jetson nano로, 굉장히 저가로 자율주행을 구현할 수 있는 플랫폼을 제작하였다는 점에서 의미가 있다.

3.1.5. 로봇을 직접 조종하여 map data 얻고, 그 데이터를 txt파일로 저장하는 기능
자율주행 뿐 아니라, 사람이 직접 조종하여 환경의 지도 데이터를 얻고, 이를 txt파일로 저장하여 시스템이 꺼진 뒤에도 해당 공간의 지도 데이터를 저장해둘 수 있다. 해당 txt파일은 본 프로젝트에서 만든 파이썬 코드로 시각화할 수 있다.

3.2. 개발 환경
3.2.1. Linux (ubuntu 18.04)
모든 작업은 jetson nano의 ubuntu 18.04 LTS에서 이루어졌다.

3.2.2. arduino
로봇이 Vx, Vy, W만큼 이동하라는 명령을 받았을 때, 이를 메카넘휠 odometry 계산을 통해 각각의 스텝모터가 얼만큼의 각속도로 회전해야 하는지를 계산해주고, 그 계산값을 스텝모터에 적용해 실제로 돌게 하는 부분을 arduino IDE에서 작업하였다.

3.2.3. python
lidar센서에서 pointcloud데이터를 읽어오는 작업과, 로봇이 얼마나 이동했는지를 계산해 mm단위로 그 값을 반환하는 작업, 경로탐색 알고리즘인 A* 알고리즘을 python 코드로 구현하였다.

3.2.4. C++
python 코드에서 생성된 로봇의 Vx, Vy, W값을 받아와 아두이노로 그 값을 넘겨주는 부분을 담당하는 코드를 C++환경에서 구현하였다.

3.2.5. ROS melodic
위에서 언급한 모든 알고리즘들을 ROS를 통해 하나로 연결하여 자율주행이 가능하도록 만들었다. python, C++, arduino(serial) 코드들을 모두 ros node로 만들었으며, python코드에서 생성된 로봇의 Vx, Vy, W값을 ros topic을 통해 C++코드로 넘겨주었고, 마찬가지로 그 값들을 ros topic을 통해 아두이노로 전송하였다.

3.3. 전체 시스템 구성
3.3.1. 하드웨어
4개의 스텝모터에 각각 메카넘휠이 부착되어 있고, 각 스텝모터는 스텝모터 드라이버에 연결되어 있으며, 그 드라이버는 아두이노 우노에 연결되어있다. 아두이노 우노와 2d lidar는 jetson nano에 usb로 연결되어 있다. 그림으로 간단하게 나타내면 다음과 같다.

3.3.2. 소프트웨어
본 프로젝트의 자율주행 기능에는 총 4개 코드로 이루어져 있으며 talker.py, A_star.py, ladarbot_node.cpp, ladarbot_subnode.ino가 그것이다.
talker.py는 로봇이 현재위치를 실시간으로 계산하는 기능, lidar센서에서 pointcloud데이터를 얻어오는 기능, 얻어온 pointcloud데이터와 로봇의 현재위치 데이터를 기반으로 지도를 생성하는 기능, A_star.py내의 함수를 호출해 매개변수로 지도를 전달하여 A_star.py로부터 로봇이 이동해야 하는 경로를 받아오는 기능, 해당 경로를 주행하기 위해 로봇이 움직여야 하는 Vx, Vy, W를 생성하는 기능이 구현되어있다.
A_star.py는 talker.py에서 생성한 map을 받아와 로봇이 이동해야 하는 경로를 생성하여 그 경로를 다시 talker.py로 반환한다. A_star.py는 파이썬 모듈로써, talker.py에서 import하여 사용한다.
ladarbot_node.cpp는 talker.py에서 생성한 Vx, Vy, W를 ROS topic을 통해 받아와, ROS topic을 통해 ladarbot_subnode.ino로 그 값을 전송한다. 통신을 위한 매개코드라고 생각할 수 있다.
ladarbot_subnode.ino는 ladarbot_node.cpp에서 ros topic을 통해 전송해준 Vx,Vy,W를 받아와 로봇이 Vx,Vy,W만큼 움직이기 위해 각각의 스텝모터가 얼마만큼의 각속도로 회전해야 하는지를 계산한다. 그 값을 각각의 스텝모터에게 전달하여 로봇이 움직이도록 한다.
A_star.py와 talker.py간 연결을 제외한 모든 코드들간 연결은 ROS topic을 이용해 서로 통신한다.

본 프로젝트의 지도 저장 기능을 구현하는 코드는 크게 5가지이다. ladarbot_node.cpp, ladarbot_subnode.ino, lidar.launch, lidar_range_node.cpp, slam_map.py 가 그것이다. 이중 ladarbot_node.cpp, ladarbot_subnode.ino는 자율주행에 사용한 코드와 동일하다. lidar.launch는 ydlidar를 제작한 회사에서 lidar의 데이터를 얻을 때 쓰라고 공유한 오픈소스이며, 지도데이터를 얻어와 txt파일로 만드는 데는 직접 짠 talker.py 대신 해당 오픈소스를 사용하였다. lidar_range_node.cpp는 lidar.launch에서 보내오는 map데이터를 읽어와 플랫폼의 odometry정보와 합쳐 지도정보를 만들고, 이를 txt파일로 내보내는 역할을 하는 코드이다. 마지막으로 slam_map.py는 txt파일을 읽어 지도를 시각화하는 코드이다.

4. 단계별 제작 과정
4.1. 하드웨어
하드웨어의 경우 본 공모전을 발견하기 전부터 만들어 오고 있었고, 때문에 만드는 과정에서의 사진이 남아 있지 않다. 본 프로젝트의 하드웨어는 메카넘휠 기반 모바일 로봇이며, 정확한 odometry(자기위치 추정)이 가능할 수 있도록 회전수와 회전속도를 정확히 컨트롤 할 수 있는 스텝모터를 사용하였다. 로봇에 들어가는 컴퓨터는 jetson nano를 사용하였다. 기본적인 하드웨어는 알루미늄 프레임을 기반으로 제작하였고, 배터리 고정하는 부품, lidar고정용 부품, 바퀴 보호개 등은 직접 설계하여 3d프린터로 출력하여 사용하였다. 하드웨어 제작의 난이도는 굉장히 낮고, 본 프로젝트의 핵심은 자율주행 알고리즘 및 ROS시스템 사용이므로 하드웨어는 간단하게 설명하였다.

4.2. 프로그래밍
4.2.1. 자율주행
하드웨어 제어
하드웨어 제어는 ladarbot_subnode.ino라는 arduino IDE코드가 담당한다. 해당 코드는 로봇 몸체가 움직여야할 속도와 방향을 알려주는 Vx, Vy, W값을 받아와서 그 움직임을 구현할 수 있게 각각의 스텝모터가 얼마만큼의 각속도로 회전해야 하는지를 구한다. 그 후 그 값들을 스텝모터들에게 입력하여 모터가 움직일 수 있도록 한다.
본 프로젝트의 로봇은 메카넘 휠을 이용해 이동한다. Vx, Vy, W만큼 로봇이 이동하였을 때, 그 로봇의 4개의 메카넘휠이 얼마만큼의 각속도로 회전하는지를 행렬 계산을 통해 변환 수식을 구해낼 수 있다. 「메카넘휠 기반의 전방향 이동로봇 슬립에 관한 해석 및 실험적 검증」 김설하, 이청화, 주백석, 「메카넘휠 기반의 전방향 이동로봇 슬립에 관한 해석 및 실험적 검증」, 한국정밀공학회지 제 37권 제 1호, 2020.01.35, pp.35-42. 논문을 참고하였다. 4개의 모터의 각속도를 각각 θ1, θ2, θ3, θ4라 하면, 로봇 자체의 속도 Vx, Vy, w와 θ1, θ2, θ3, θ4사이 관계는 다음과 같이 나타나진다.

위 행렬식을 계산하여 아두이노 코드로 작성하면 다음과 같이 나타난다.

motorRF, motorRB, motorLF, motorLB함수는 각각 오른쪽 앞, 오른쪽 뒤, 왼쪽 앞, 왼쪽 뒤 스텝모터를 제어하는 함수이며. w1, w2, w3, w4가 각각 θ1, θ2, θ3, θ4이다.
Stop함수는 스텝모터에 전류를 차단하는함수인데, 멈춰 있을 때에는 모터가 쉴 수 있도록 하기 위해 삽입하였다. motorRF 함수의 형태는 다음과 같다.

motorRB, motorLF, motorLB함수 역시 유사한 형태이다.
float num = ((2*PI)/1600)*(1000000/w); 은 사용하는 스텝모터가 1600스텝일 때 한바퀴 회전하기 때문에, 그리고 스텝간 시간간격이 초단위가 아닌 microsecond 단위이므로 다음과 같이 나타내 주었다. 매개변수로 받아오는 current는 아두이노의 micros() 함수를 통해 측정되는 현재 시간이다.(microsecond단위로 반환한다)
다음은 ROS를 통한 통신 부분이다. ladarbot_node,cpp에서 Vx, Vy, w값을 geometry_msgs/Twist 메시지를 통해 ArduinoTopic이라는 Topic name으로 전달받는다.

ArduinoTopic 토픽으로 값이 전송될 때마다 message함수를 호출한다. message함수의 구조는 다음과 같다.

loop함수 내에서의 함수호출 및 실행은 다음과 같다.

lidar data reading & ploting & 로봇 현재위치 계산
lidar센서에서 데이터를 얻는 작업, 로봇의 현재위치를 계산하고 lidar데이터와 계산된 현재 위치를 바탕으로 지도를 만드는 작업, 그리고 만들어진 지도와 수신한 경로를 ploting 해 주는 작업을 talker.py에서 진행한다. 우선 lidar로부터 센서데이터(pointcloud) 값을 얻는 부분의 코드이다.

사용하는 ydlidar_X2L의 스펙에 맞게, serial통신 baudrate를 115200으로 설정하였다.
다음은 로봇의 현재위치를 계산하고 lidar데이터와 계산된 현재 위치를 바탕으로 지도를 만드는 작업, 그리고 만들어진 지도와 수신한 경로를 ploting 해 주는 작업의 부분이다. 서로가 긴밀하게 연결되어 있어 따로따로 소개하기 힘들어 한번에 소개한다.
우선 로봇의 현재위치를 계산하기 위하여 함수가 돌아가는 시간을 한번의 loop마다 몇 초가 걸리는지를 계산한다. dt = (p.timer – p.current_time), p.current_time = time.time()과 함수 끝의 p.timer = time.time() 부분이다. 한 루프의 걸린 시간을 측정하는 이유는, 로봇이 Vx, Vy, w로 움직였을 때, 이동거리와 회전각도는 각각에 걸린 시간을 곱하는 형태로 구해지기 때문이다. 현재 위치를 계산하는 부분은 다음과 같다.

다음은 로봇 주변 공간을 지도로 만들 때, 그 공간을 격자화시키기 위한 코드이다. 로봇이 이동하는 공간이 격자화 되어 있어야 후에 로봇의 이동경로를 생성할 수 있다. 격자 하나를 10cm로 설정하였다.

다음으로 lidar에서 받아온 pointcloud데이터와 현재위치 데이터를 얻어와 지도를 만드는 코드이다. 이때, pointcloud의 점의 거리가 현재 설정되어있는 격자공간보다 더 큰 거리를 가진다면, 격자공간을 넓히는 작업을 시행한다. 해당 부분의 코드이다.

다음은, 지도를 형성하는 점들이 하나의 격자에 여러 개가 찍힐 때, 그 격자만 벽으로 인식하게 하는 코드이다. 이 부분의 코드를 거치기 전에는 pointcloud데이터에 어떠한 가공도 하지 않은 지도였지만, 이 작업 후에는 격자에 맞게 지도가 그려진다.

다음으로는 A*알고리즘을 구현한 A_star.py 파이썬 모듈에 격자화된 map데이터를 넘겨주어 로봇이 움직여야 할 경로를 받아오고, 그 경로와 격자화된 map을 실시간으로 plot하는 부분이다.

다음으로는 생성된 경로에 맞게 로봇이 움직여야 할 Vx, Vy를 계산하는 부분이다. 경로는 계속해서 업데이트 되기 때문에, 현재 위치의 바로 다음 경로만을 파악하여 그 방향으로 속도를 결정한다. 현재 공간은 모두 격자화 되어있기 때문에, 현재 위치에서 로봇이 이동할 수 있는 방향은 총 8가지(위, 오른쪽, 왼쪽, 아래 오른쪽 위, 오른쪽 아래, 왼쪽 위, 왼쪽 아래)이다. 생성된 경로에서 현재위치와 가장 가까운 경로의 위치를 파악하고, 그 방향으로 속도를 결정한다. ex: 다음 경로가 오른쪽 위라면 Vx = 0.04, Vy = 0.04로 설정(0.04m/s로 로봇이 움직이게 만들어 놓음)
해당 코드이다.

다음으로, 생성된 Vx, Vy, w (메카넘휠이므로 로봇 몸체의 회전 없이도 전 방향으로 이동할 수 있어 w를 따로 계산 하지는 않음)를 ros topic을 통해 ladarbot_node.cpp로 전송하는 코드이다.

이 외 다른 ros 송.수신 관련 코드는 talker.py의 전체 코드에서 확인할 수 있다.

4.2.2. 최단 경로 찾기 알고리즘 – A star algorithm
A* 알고리즘이란 시작점과 도착점이 주어져 있을 때, 그 사이 벽, 장애물 등을 피해 최단 경로를 만들어주는 알고리즘이다. 원리를 간단하게 설명하자면, 격자화되어있는 map이 제공되었을 때 우선 어느 부분이 이동할 수 없는 지역이고 어느 부분이 이동가능한 지역인지를 파악한다. 본 프로젝트는 talker.py에서 격자화된 지도를 만들며 벽이 있는 부분의 격자에는 1을, 그렇지 않는 부분에는 0을 저장하여 구분하였다. A*알고리즘을 통해 어느 사각형(격자)들을 거쳐야 하는지를 파악함으로서 길을 찾는다. 경로가 발견되면 목표 도달때까지 사각형에서 다음 사각형의 중심으로 이동한다. 이 중심점들을 노드라고 부른다.
시작점을 열린 목록이라는 일종의 배열에 저장한다. 시작점에 인접한 이동불가지역을 무시하고, 이동가능한 사각형들을 열린 목록에 저장한다. 그 후 열린 목적에서 시작점을 제거하고, 다시 볼 필요 없는 닫힌 목록에 넣는다. 열린목록에 저장되어있는 사각형들은 부모 노드로 시작점을 가리키도록 한다. 현재 열린 목록에 존재하는 사각형들 중에 하나를 선택하여 위 과정을 반복하는데, 이때 사각형을 선택하는데 기준이 되는 것이 비용함수이다. 비용함수는 다음과 같이 이루어져 있다.

F = G + H

G는 시작점으로부터 현재 사각형까지의 경로를 따라 이동하는데 소요되는 비용이다.
H는 현재 사각형에서 목적지 B까지의 예상 이동 비용이다. 사이에 벽등으로 실제 거리는 알지 못하고, 그들을 무시하고 예상 거리를 산출한다.
F는 현재까지 이동하는데 걸린 비용과 예상 비용을 합친 것이다.
이렇게 구해진 비용함수를 통해 가장 작은 F를 가진 사각형을 선택한다. 이렇게 선택된 사각형을 열린 목록에서 빼고 닫힌 목록에 저장한다. 그 후 현재 사각형에서 인접한 사각형을 확인한다. 벽 등 이동불가사각형은 무시하고, 열린목록에 주변 사각형이 없다면 열린 목록에 추가한다. 이때 열린 목록에 추가된 사각형들은 현재 사각형을 부모로 설정한다. 인접한 사각형이 이미 열린 목록에 존재한다면 그 사각형과 선택된 사각형 중 어느 것의 G비용이 더 낮은지 확인한다. 기존 선택된 사각형의 G비용이 더 낮다면 그대로 두지만, 인접한 사각형의 G비용이 더 낮다면 인접 사각형들의 부모를 새로운 사각형으로 바꾼다. 마지막으로 그 사각형의 F와 G를 다시 계산한다. 이러한 과정을 반복한다. 이렇게 길을 찾는 도중 목표 사각형을 열린 사각형에 추가하였을 때, 또는 열린 목록이 비어있게 될 경우(길을 못찾은 경우) 탐색을 중단하고 목표 사각형으로부터 각각의 사각형의 부모사각형을 향하여 시작사각형에 도달할 때까지 거슬러 올라가 경로를 저장한다.

다음은 이를 파이썬으로 구현한 코드이다. 우선 node를 만드는 클래스를 소개하겠다. 각 사각형(노드)의 F,G,H값, 부모노드를 저장할 수 있는 공간을 만들어 두었다.

다음으로 A*알고리즘의 구현 코드이다.

코드 중간에

Vx, Vy, w 값을 받아와 아두이노로 넘겨주는 코드
원래 Vx,Vy,w를 생성하는 talker.py에서 아두이노로 바로 값을 전달해주는 것이 가장 간편하지만, 그 과정에서 계속해서 오류가 발생해 C++파일을 매개체로 하여 ROS로 연결하였다. 해당 역할을 하는 코드는 ladarbot_node.cpp이며, talker.py에서 Vx, Vy, w값을 ros topic을 통해 받아와 아두이노와 연결을 해주는 serial노드로 값을 전달한다. 다음은 해당 코드이다.

ROS 통한 연결 및 실행
앞서 소개했듯, A_star.py와 talker.py간 연결을 제외하면 모든 코드의 연결이 ROS로 연결되어 있다. talker.py는 ros_python package안에 존재하고, ladarbot_node.cpp는 ladarbot package안에 존재한다. 아두이노와 cpp파일 간 rosserial 연결을 도와주는 serial_node.py는 rosserial_python package안에 존재한다.
실행하는 방법은 다음과 같다. 해당 명령어를 각각의 터미널 창에 입력하면 된다.

· sudo chmod a+rw /dev/ttyACM0 ->포트 사용을 위해 유저에게 읽고 쓰는 권한 제공
· roscore
· rosrun ladarbot ladarbot_node
· rosrun ros_python talker.py
· rosrun rosserial_python serial_node.py _port:=/dev/ttyACM0 _baud:=57600

4.2.3.사용자 조종을 통해 얻는 지도 데이터 txt저장 및 시각화
로봇 현재위치 계산
자율주행을 구현하는데에도 통신 매개체로 쓰인 ladarbot_node.cpp가 여기에서도 사용된다. 이전에는 설명 안 했지만 ladarbot_node.cpp에도 로봇의 odometry(현재위치)를 계산하는 코드 부분이 있다. 코드 실행시간을 받아와 Vx, Vy, w와 곱하여 실시간으로 로봇의 현재 위치를 계산해 ros topic으로 lidar_range_node.cpp로 odometry를 전송한다. ladar_node.cpp의 해당 부분의 코드이다.

mapdata를 저장한 txt파일 도출
ladar_node.cpp와 ydlidar 오픈소스인 lidar.launch에서 각각 전송해준 odometry와 lidar센서값(pointcloud)를 이용해 합쳐 map을 생성하고, 그 맵을 txt파일로 만들어 저장해주는 코드이다. 해당 작업은 lidar_range_node.cpp에서 이루어졌으며, 아래는 우선 odometry를 받아오는 코드이다.

다음은 lidar센서값을 lidar.launch에서 받아오는 부분의 코드이다.

다음은 두 정보를 합쳐 지도로 만든 뒤 txt파일로 내보내는 코드이다.

txt파일을 읽어 지도를 시각화하기
저장된 txt파일을 읽어 파이썬을 통해 시각화해주는 코드이다. 해당 작업을 한 코드는 slam_map.py이며, 설명할 부분이 거의 없는 간단한 코드이기 때문에 후에 전체 코드만 공개하겠다. slam_map.py를 실행하기전, txt파일을 열어 파일의 끝에 end를 추가해주어야 한다.

실행하기
로봇을 조종하고 지도를 만들어 txt파일로 저장하기 위해서는 터미널 창에 다음과 같은 명령어를 입력해야 한다.

roslaunch ladarbot ladarbot.launch

ladarbot.launch는 ladarbot_node.cpp 및 아두이노 코드에 해당하는 ladarbot_subnode.ino, 그리고 로봇을 조종할 키보드 입력을 받아오는 코드를 한번에 실행하는 launch파일이다. 키보드 입력 받는 코드는 ros를 설치할 때 기본적으로 제공되는 파일이기에 따로 코드 설명을 하지는 않는다.
그 다음 다른 터미널 창을 열어 해당 명령어를 입력한다.

roslaunch ydlidar_ros lidar.launch

lidar.launch파일을 실행하는 명령이다.
다음으로 다른 터미널창을 열어 다음 명령어를 입력한다.

rosrun lidar_range lidar_range_node

해당 명령은 lidar_range_node.cpp파일을 실행하는 명령이다. 이 모든 명령을 실행하면 키보드의 I j l , u o m . 키로 로봇을 8방향으로 조종할 수 있게되며, 동시에 slam.txt파일이 생기며 그 파일안에 mapdata가 기록된다.
txt파일을 시각화하고 싶다면 slam_map.py가 있는 경로에 slam.txt 파일을 복사한 다음, 터미널창에 python slam_map.py를 입력한다. 그럼 시각화된 지도를 확인할 수 있다.

5. 실행 결과
5.1. 자율주행
목적지를 출발지로부터 x축으로 2.5m, y축으로 2.5m로 했을 때 동작 사진이다.

5.2. 생성된 지도 txt파일로 저장 및 시각화

5.3. 실행영상
실행영상을 추가 제출파일로 제출하였다. 해당 영상에서는 5.1에서처럼 로봇에 디스플레이를 연결한 것이 아닌, 영상 송수신기(브이젯 HDMI무선송수신기)를 통해 모니터로 화면을 띄웠다. 영상 마지막에 벽에 부딪히는 이유는 목적지를 출발점으로부터 x방향 2.5m, y방향 2.5m로 설정해 두었는데, 그 위치가 벽 속이여서 그러한 일이 발생한 것이다. 자율주행 자체에는 문제가 없다. 다만, 영상에서 보이는 정도의 거리는 문제없이 자율주행이 되지만, 주행시간을 늘리게 되면, 주행 중 zetson nano의 cpu가 다운되며 로봇이 정지하는 경우가 발생한다. A star 알고리즘 및 시각화알고리즘이 무거워 cpu다운이 일어나는 걸로 예상되며, 컴퓨터를 성능이 더 좋은 것으로 교체하면 해결될 문제로 보고 있다. 화면에 뜨는 map과 생성된 경로와, 로봇의 움직임을 함께 확인하면 된다.

6. 사용한 제품 리스트

2021 ICT 융합 프로젝트 공모전 우수상

투명 폐페트병 분리배출 로봇

글 | 숭실대학교 오세찬, 강전완, 윤형섭, 임소현

1. 심사평
칩센 작품을 개발 과정과 결과에도 나와있듯이 개발자들의 정형화된 시연 환경 내에서는 만족할만한 결과를 도출해 낼 수 있지만, 실제 개발 당사자가 아닌 이들이 사용을 한다면 수많은 문제점이 발생할 수 있을 것으로 보입니다. 보고서에 포함된 후속 연구를 통해 작품의 개선을 할 수 있기를 바랍니다.
펌테크 자원재활용 이슈와 기술이 결합된 환경친화적인 작품이라고 생각합니다. 사전조사 및 아이디어가 반영된 제품 기획의 꼼꼼함이 돋보이며 영상처리 기술 구현 등을 효율적으로 접목하여 군더더기 없이 꼭 필요한 기능 위주로 목적에 맞는 최적의 시스템을 기획의도에 맞게 안정적으로 구현하였다고 생각합니다. 전체적으로 기술 구현도, 완성도 등에서 상당히 뛰어나고 훌륭한 작품으로 생각됩니다.
위드로봇 처리 속도가 아쉬습니다. 나머지는 훌륭한 작품입니다.
뉴티씨 투명 페트병만을 수거할 수 있도록하여, 투명하지 않은 페트병은 투명하게 만들어 투입하도록 하는 시스템인데, 매우 잘 제작되었습니다. 다만, 플라스틱이 아닌 금속캔 등을 투입하게 되면, 수거되지 않도록 안내하는 것도 추가하면 좋겠습니다. 검출 및 판별 속도는 개선해야 하는 점으로 보입니다. 또한, 수거되지 않는 것은 다시 가져갈 수 있도록 안내와 함께 기구적으로 문이 열리도록 하면 더 좋을 것 같습니다.
엔티렉스 부설연구소 투명 플라스틱 병 분리 배출로봇 개발은 온전한 플라스틱이 아니면 힘든 것 같습니다. 다만 카메라를 이용하여 페트병을 인식하여 분리 배출하는 기능에 대해서는 많은 생각을 하여 개발 한 것 같습니다. 패트병이 아닌 다른 물체가 왔을 때 일반쓰레기로 처리하는 방식을 적용했으면 합니다.

2. 작품 개요
2.1. 배경 및 목적

환경부에서는 2020년 12월 25일부터 투명 페트병만 분리수거 해 배출하는 정책을 펴고 있다. 하지만 기사를 통해 전용 봉투는 있지만, 그 안에 라벨과 뚜껑이 제거되지 않은 채로 페트병이 버려져 있는 사진이 공개되면서 아직 제대로 된 분리수거가 이루어지지 않음을 알 수 있다. 이러한 문제를 해결하고자 뚜껑과 라벨이 없는 무색의 플라스틱만을 모아서 재활용 효율 상승에 큰 도움을 주는 로봇을 제작하였다.

2.2. 차별점 및 기대효과
재활용 문제를 해결하기 위한 시스템은 여러 가지가 있다. 촉각을 이용해 자동으로 분리수거를 하는 ‘로사이클’, 물건을 넣으면 인공지능이 재활용 가능 여부를 판단해 버려주는 자판기 형태의 ‘네프론’, 어플을 통해 직접 사진을 찍으면 그 물건의 분리수거 방법을 안내하는 ‘스마트사이클’ 등이 바로 그것이다.
작품은 시중에 있는 다른 제품들과 크게 3가지 사항에서 차별성을 보인다. 첫 번째 차별점은 실용적인 면과 교육적인 면이 공존한다는 것이다. 투입구에 물건을 넣으면 로봇이 재활용 가능 여부를 판단하고, 재활용할 수 없다면 문제점과 해결방안을 디스플레이 화면과 음성안내 서비스를 통해 사용자에게 알려준다. 이를 통해 사람들은 본인의 재활용 인식 수준을 판단할 수 있고, 모르고 있었던 사항들을 알게 됨으로써 잘못된 행동을 개선할 수 있다. 두 번째는 로봇이 탈부착할 수 있다는 점이다. 이로 인해 공간의 큰 제약 없이 원하는 크기의 쓰레기통과 함께 사용할 수 있다. 이에 따라 기계를 열어 안에 있는 쓰레기들을 일일이 꺼내는 기존의 다른 제품들과 다르게, 봉투만 교체해서 사용하면 되므로 매우 편리하다. 세 번째는 제작 비용이 상대적으로 적다는 것이다. 값비싼 장치들과 센서들을 사용하지 않고도 필요한 기능들을 무리 없이 잘 구현해낼 수 있다.
투명 폐페트병 분리배출 로봇을 사용함으로써 다음과 같은 기대효과가 예상된다. 우선, 환경부가 마련한 투명 페트병 분리수거 정책의 실행률 증가와 정착에 큰 도움이 될 것이다. 투명 페트병 분리배출의 증가로 불필요한 플라스틱의 폐기가 방지되고, 재활용률이 증가하여 경제적, 환경적으로 큰 공익이 발생할 것이다. 또한, 로봇이 디스플레이와 음성으로 올바른 플라스틱 재활용 방법에 대하여 즉각적으로 홍보함으로써 사람들의 투명 플라스틱 분리수거 및 재활용에 대한 인식이 크게 발전될 것이다.

3. 작품 설명
3.1. 작품 구성도

3개의 디바이스는 ‘감각기관’, ‘동작 기관’, ‘뇌’로 역할이 분담되어 있다. 각 디바이스는 MQTT 통신을 통해 상호작용하며 역할에 맞는 기능을 수행한다.

(1) 감각기관(ESP8266)
센서(무게 센서, 초음파센서)가 연결되어 있다. State에 따라 필요한 센서값을 측정해 동작 기관과 라즈베리파이에 전달해준다.

(2) 동작기관(ESP8266)
동작 기관에는 서보모터가 연결되어 있다. 라즈베리파이에서 검출된 물체 명령에 따라 분리수거와 물체 반환을 하기 위한 모터작동을 수행한다.

(3) 뇌(라즈베리파이)
뇌에는 카메라, 모니터, 스피커가 연결되어 있다. 라즈베리파이에서 구성한 웹서버가 카메라로 찍은 사진을 분석하고 과정을 모니터(웹 클라이언트)와 스피커로 출력해준다.

3.2. 주요 동작 및 특징
3.2.1. 로봇 구동과 물체 진입 확인
감각기관에 해당하는 ESP8266에 설계되어있다. 물체 진입 확인은 5가지 state로 구성된다.

init state(00)
처음 감각기관에 전원이 공급되면 init 상태가 된다. 이 상태에서는 사용하는 센서(무게 센서, 초음파센서)들의 pin을 초기화하고, 와이파이와 MQTT client(sensor)를 연결한다. wait 상태로의 이동은 라즈베리파이의 명령으로 이뤄진다.
라즈베리파이의 웹서버는 서버가 실행되기 전 디바이스 간의 통신상태를 점검한다. 라즈베리파이가 보낸 ’reset’를 확인한 감각기관은 ‘connect’를 답장한다. 연결상태가 확인되면, 라즈베리파이는 ‘wait’를 보내고 서버를 실행한다. 메시지를 받은 감각기관은 ‘wait’ 상태로 이동한다.

웹서버가 MQTT client로 연결되면 raspi를 구독하고, 감각기관과 동작기관에 reset이라는 메시지를 전송한다.

health 변수에 key값인 sensor, motor는 서버 실행 전 감각기관, 동작기관의 통신상태 정보를 담고 있다. 1000(1초)마다 실행되는 함수를 만들어 연결상태를 점검하고 잘 연결되었다면, 웹서버와 동적인 사용자 인터페이스에 필요한 소켓 서버를 실행시키고, 감각기관에게 ‘wait’ 메시지를 보내준다. 연결상태가 올바르지 않다면, 해당 디바이스에 상태를 확인하는 reset 메시지를 재전송한다.

‘-‘를 기준으로 split 하여 감각기관, 동작기관 중 연결상태라 올바른 디바이스에 health 값을 1로 갱신하는 코드이다.

wait state(01)
문이 열리길 기다리는 상태. 물체를 집어넣는 작품 상단에 있는 초음파센서가 문과의 거리를 측정한다. 센서값을 분석(문 열림)하여 문이 열렸음이 확인되면 ‘open’ 상태로 이동한다.

거리를 측정하는 distance()를 전역함수로 작성하여 loop 내에서 필요에 따라 호출하도록 하였다. 문이 열릴 때 반사되는 초음파센서값이 열리기 전의 값(190)보다 값이 작다는 것을 이용하여 문이 열렸음을 확인한다. 추가로 200 이상의 값도 열렸다고 판단하는 이유는 초음파가 반사되어 200 이상의 숫자도 나올 수 있기 때문이다.

open state(10)
문이 열린 상태. 초음파센서는 문과의 거리를, 무게 센서는 물체의 무게를 측정한다. 두 센서값을 분석(문 닫힘, 물체무게감지)하여 정상적으로 물체가 들어왔으면 ‘close’ 상태로 이동한다.

close state(11)
물체가 들어온 상태. 라즈베리파이에게 물체가 들어왔음(input)과 물체의 무게(weight)값을 전송한다. 메시지를 수신한 라즈베리파이는 물체 분석을 시작하고 ‘analysis’ 답장을 보낸다. 답장을 받은 감각기관은 analysis 상태로 이동한다.

초음파센서로 측정한 값이 185 이상 190 이하이고 무게 센서로 측정한 값을 1000으로 나눈 값이 330 이상이면 물체가 정상적으로 들어왔다고 판단하여 ‘close’ 상태로 이동한다. close 상태로 이동 후 라즈베리파이에게 잘 들어왔음을 알리는 ‘input’과 물체의 무게 값인 ‘weight’ 값을 전송한다.

analysis 상태(100)
물체가 분석 중인 상태. 분석이 정상적으로 끝나고, 모터 동작에 대한 메시지가 수신될 때까지 대기한다.

3.2.2. 투명 폐페트병 검출 기능
뇌에 해당하는 라즈베리파이에 투명 폐페트병을 검출하는 모델이 3단계로 설계되어있다. 아래 표는 대략적인 흐름과 각 검출 단계에서 사용되는 분석 도구들을 보여준다.

카메라 촬영
node.js의 pi-camera 모듈을 사용하여 라즈베리용 카메라를 조작한다. 사진 촬영 후 정상적으로 사진이 저장되면, 성분분석 단계로 넘어간다.

웹 클라이언트로부터 /camera 요청을 받으면, snap 함수를 사용해 라즈베리파이용 카메라를 동작시킨다. 사진이 제대로 찍혔으면, 첫 분석방법인 성분 분석 함수를 호출한다.

성분분석
google-cloud에서 제공해주는 vision api를 사용한다. 들어온 물체의 크기, object 무게 등을 측정하여 플라스틱인지 검출하는 단계이다.

ⓐ 크기 검사
이미지 분석 데이터를 분석하여 물체의 유무를 측정한다. 물체의 좌표에 해당하는 픽셀들을 추출하여 만약 추출되지 않았으면 물체가 인식되지 않았다고 판단하고 object_test 변수를 false로 변경한다.
ⓑ 오브젝트 검사
이미지 분석 데이터를 분석하여 해당하는 물체가 플라스틱인지 판단한다. [bottle, drink, plastic, glass]의 키워드가 하나도 나오지 않으면 페트병이 아니라고 인식해 object_test 변수를 false로 변경한다.
ⓒ 무게 검사
esp8266(감각기관)에서 물체 진입 확인과 함께 전달된 물체의 무게를 통해 플라스틱 bottle의 무게인지 검사한다. 이전검사에서 유리와 플라스틱을 구분하지 못했는데, 이 단계에서 분류된다. 추가로 이물질 특히 내용물이 담겨있는 경우도 이 검사에서 걸러진다.
ⓓ label_test 값 확인
ⓐ~ⓒ단계에서 기록된 object_test 값을 확인하여 false이면 물체를 반환하기 위해 모터에게 메시지(up)를 보내고, true이면 다음 단계인 글자 분석 단계로 이동한다.

글자 분석
google-cloud vision API를 사용한다. 폐페트병에 프린팅이 되어있거나 글자가 있는지 판단하는 단계이다.

ⓐ 글자 검사
이미지 데이터 중 text 배열을 선택해 요소가 있는지 확인한다. 만약 요소가 하나라도 존재하면 label이 붙어있거나 프린팅이 되어있는 플라스틱으로 판단하고 text_test 변수를 false로 변경한다.
ⓑ text_test 값 확인
ⓐ단계에서 기록된 text_test 변수의 값을 확인하여 fasle이면 물체를 반환하기 위해 모터에게 메시지(up)를 보내고, true이면 다음 단계인 색깔 분석 단계로 이동한다.
글자 분석 결과를 나타내는 text_test 변수를 false로 초기화하고 분석 결과에 따라 true 값을 할당한다. vision api의 textDetection함수를 이용해 이미지에서의 식별된 글자들을 리턴받고, 이를 분석한다. 분석결과를 text_test 변수에 기록하고, 이를 토대로 모터를 작동시킨다.

색깔 분석
이미지를 RGB matrix로 만들어주는 image-to-rgba-matrix 모듈을 사용해 픽셀 단위로 RGB 값을 분석하여 폐페트병의 이물질 여부를 판단하는 단계이다.
ⓐ 영역설정
성분분석에서 얻은 물체 픽셀 데이터를 이용해 분석 영역을 설정한다. 영역을 설정함으로써 투명 폐페트병과 배경색만 검출된다.
ⓑ 표준편차
각 픽셀의 R, G, B값을 추출해 표준편차를 계산해 1차 분류를 진행한다. 표준편차가 15 초과면 유채색(빨강, 초록, 파랑), 15 이하면 무채색(검은, 흰)으로 분류한다.

ⓒ RGB 연산
1차 분류를 통해 나눠진 데이터를 토대로 각각 RGB 연산을 수행한다. 유채색의 경우 R, G, B값 중 큰 값을 찾아 Red, Green, Blue로 분류하고 무채색의 경우 R, G, B의 평균을 계산하여 40 이하인 것을 검은색. 200 이상인 것을 흰색으로 분류한다. 흰색은 연산하는 과정에서 영역(뚜껑, 몸통)별로 가중치를 부여해 데이터가 저장되는데, 이러한 이유는 백색 조명이 반사되어 나타나는 흰색이 몸통에 주로 위치하기 때문이다.
ⓓ 분류 연산
2차 분류된 데이터를 토대로 각 색깔의 개수를 측정한다. Red, Green, Blue, Black의 경우 10픽셀 이상 있으면 이물질이 있다고 판단한다. White의 경우 보정된 값이 5000 이상이면 흰색 이물질이라고 판단한다. 5000은 여러 번의 테스트를 거쳐 얻은 값이다. 이물질 판단 여부를 통해 color_test 값을 결정한다.
ⓔ color_test 값 확인
ⓐ~ⓓ단계에서 기록된 text_test 변수의 값을 확인하여 false이면 물체를 반환하기 위해 모터에게 메시지를 보낸다. true이면 최종적으로 투명한 폐페트병이라고 판단하여 물체를 분리수거 하기 위해 모터에게 메시지(down)을 전송한다.

색깔분석 결과를 나타내는 color_test 변수를 false로 초기화하고 분석 결과에 따라 true 값을 할당한다. imageToRgbaMatrix로 이미지를 RGBA 성분을 가지고 있는 2차원 배열로 리턴 받는다. 이를 성분분석에서 연산한 area를 토대로 색깔을 분류하고, pal 변수에 key로 지정된 색깔에 count 한다. 분류 작업을 마친 후 foreach문을 통해 색깔의 count 값을 비교하여 분석결과를 color_test 변수에 저장하고 이를 토대로 모터를 작동시킨다.

3.2.3. 분리수거
동작 기관 ESP8266에서는 서보모터를 제어하여 분리수거와 반환 기능을 수행한다.

명령 수신
라즈베리파이에서 투명 폐페트병 검출 기능이 수행된 후 분리수거가 가능 여부에 따라 UP(반환), Down(분리수거) 메시지를 동작기관으로 전송한다.

모터 동작
메시지를 받은 동작 기관은 메시지에 따라 서보모터를 제어해 물체 반환(UP)과 분리수거 (Down)을 수행한다. 그리고 감각기관으로 현재 모터의 상태인 motor_up과 motor_down을 전달한다. 감각기관의 도움을 받는 이유는 서보모터 자체 함수 중 각도를 리턴 받는 함수가 없어, 기능이 제대로 수행되었는지 알 수 없기 때문이다.

감각기관 상태 이동
모터 동작에 대한 메시지를 전달받은 감각기관은 메시지에 따라 analysis 상태에서 motor_up, motor_down 상태로 이동한다.

분리수거 및 반환 완료 검사
서보모터를 통해 틀이 움직이면 감각기관에 무게 센서값이 기준치에서 크게 변화한다. 즉 motor_up(반환), motor_down(분리수거) 상태에서 특정 무게 값을 정하여 기준치에 충족하면 반환, 분리수거가 완료되었다고 판단한다. 추가로 motor_up(반환)의 경우 물체가 가벼워 문을 뚫고 나오지 못하는 것을 고려하여 초음파센서값도 변수로 지정하였다. 초음파센서값을 통해 물체가 감지되지 않으면(물체 반환이 완료되면) 동작 기관에 reset을 명령한다.

‘up’ 메시지를 받으면 반환을, ‘down’ 메시지를 받으면 분리수거를 시작한다.

전역변수로 선언된 3개의 모터제어 함수들. 라즈베리파이에서 분리수거, 반환이 시작되면 현재 수행한 함수를 감각기관에게 메시지로 전달한다. 이는 무게 센서를 통한 서보모터 동작 완료를 확인하기 위함이다.

모터에서 받은 메시지에 따라 각각 motor_up state와 motor_down state로 상태 이동한다.

3.2.4. 사용자 인터페이스
디스플레이

ⓐ 메인화면
메인화면은 2가지 표정으로 구분된다. 재활용을 성공한 경우나 처음 로봇이 구동된 경우 Happy, 재활용에 실패해 물체가 반환된 경우 Angry 캐릭터가 메인화면에 나타난다.

메인화면에서 오른쪽 위 끝에 있는 설명 버튼을 누르면, 재활용 방법과 로봇에서 폐페트병을 검출하는 방법을 소개한다.

ⓑ 분석화면
3단계의 분석 진행 과정과 결과를 우측에 실시간으로 렌더링하여 보여준다.

음성 출력
google TTL 서비스를 통해 음성을 추출하였고, 서버 측에서 음성을 출력하기 위해 play-sound를 사용했다.

play-sound로 재생하는 음성은 서로 독립적으로 재생되어 소리가 겹치는 일이 발생할 수 있다. 전역변수로 audio를 생성하고, 음성 재생이 필요할 때마다 audio.kill()로 현재 재생되고 있는 소리를 제거하고 play를 통해 재생시켰다.

3.3. 개발 환경
· OS : 라즈비안(라즈베리파이), 윈도우10(노트북)
· 개발 언어 : C, javascript(node.js), html, css
· 툴 : brackets, 지니, 아두이노IDE
· 통신 : MQTT, HTTP(Socket.io, GET)

Node.js 주요사용 모듈

4. 단계별 제작과정

4.1. 하드웨어 제작과정
하드웨어 1주차
ⓐ 주제 선정 및 기능 아키텍처 작성을 통한 필요 물품 구매

필요 물품
· 폼보드 : 특별한 장비 없이 가공에 있어 자유롭고 튼튼하다.
· ESP8266 mini : 각 기관의 역할을 나누는 데 필요했다.
· 무게 센서 : 물체의 무게를 측정해 분류하는 데 필요했다.

라즈베리파이, 카메라, 스피커, 모니터, 초음파센서는 기존에 가지고 있던 것을 사용했다.

하드웨어 2주차
ⓐ 역할을 분담하여 센서, 모터, 카메라를 동작(테스트)해보는 학습을 진행하였다.

ⓑ 제작에 앞서 외형도를 제작했다.

대략적인 제품 크기와 부품을 설치할 위치를 그렸다.

하드웨어 3주차

ⓐ 외부 틀 제작 : 2주차에서 작성한 외형도를 바탕으로 문과 틀을 만들었다.

ⓑ 밑판제작 및 부품 테스트

무게 센서와 서보모터를 연결해 물체가 올라갈 밑판을 제작하였고, 모터 동작을 테스트했다.

초음파센서를 입구 상단에 설치하고, 무게센서와 테스트했다.

ⓒ 내벽 제작

좌측에 동작기관, 우측에 감각기관으로 회로를 연결하였다.
회로 정리 후 제작한 내벽을 붙여 선이 보이지 않게 만들었다.

ⓓ 앞면 제작

로봇의 모니터가 들어갈 앞판을 제작하였다.

ⓔ 윗면 제작

조명, 라즈베리파이 카메라, 스피커 등이 놓일 윗면을 제작하였다.

하드웨어 4주차

카메라 선이 길지 않아 동작 테스트에 문제가 발생했다. 윗면에 설치하는 것이 아닌, 윗면에 붙이는 것으로 계획을 변경했다.
쓰레기통의 교체가 쉽고 들어있는 상황을 볼 수 있도록 하단은 오픈형으로 제작하였다.

4.2. 소프트웨어 제작과정
소프트웨어 1주차
하드웨어 제작 1주차 첨부한 기능 구성도를 작성하고, 필요한 기술을 조사했다.

조사내용
· 각 기관 간의 통신은 MQTT 통신을 사용한다.
· 로봇의 얼굴인 디스플레이는 웹사이트 형태로 제작한다.
· 카메라 모듈을 사용해 사진을 찍은 후 구글 API을 사용해서 라벨 및 이물질의 유무 등을 분석한다.
· 분석 결과에 따라, 모터가 작동해 플라스틱을 분리배출할 수 있게 도와준다.

소프트웨어 2주차
ⓐ 필요 기술 학습(물체 검출)

vision API를 사용해 물체의 성분(plastic, glass 등), 텍스트(프린팅, 라벨), RGB 추출(이물질 검사)을 하기 기대했다. 성분 분석과 텍스트 검출에는 문제가 없었지만, 색 추출에서 이질적인 색을 잡는 민감도를 기대할 수 없었다. 다른 방법인 10개의 색 파레트를 추출하는 color-thief 모듈을 사용하여, 뚜껑 등의 이질적인 색 검출에 성공했다.

ⓑ 필요 기술 학습(사용자 인터페이스)

웹 클라이언트 : 로봇의 얼굴에 해당하는 모니터에 HTML, CSS 등으로 캐릭터를 제작하였다. 아직 센서들과 통신을 하지 않기 때문에, 3초가 지나면 사진이 찍혀 ⓐ의 단계로 넘어가도록 코드를 작성했다.
웹 소켓 : 동적인 웹 클라이언트를 만들기 제작하기 위해 웹 소켓을 사용하였다. 서버에서 연산한 결과를 클라이언트로 데이터를 전송해 사용자가 실시간으로 검사 결과를 확인할 수 있다.

ⓒ 모터, 센서 기능 구현
아두이노 IDE를 사용해 물체가 들어오고 나감을 알 수 있도록 초음파센서 관련 함수를 작성하였고, 분리수거 & 반환을 위해 모터 함수를 작성하였다.

소프트웨어 3주차
ⓐ MQTT 통신

MQTT 통신을 사용하여 각 디바이스가 상호작용한다. MQTT 통신을 사용한 이유는 클라이언트-서버 구조로 이뤄진 HTTP, TCP는 주로 클라이언트 요청에 대한 서버에 응답으로 통신하기 때문에 디바이스 간 통신이 어렵다. 반면, MQTT는 broker, publisher, subscriber 구조로 이루어져 있으므로, broker가 중계하고 client 간의 통신이 가능하다. 라즈베리파이에 브로커를 설치하고, 감각기관, 동작기관, 웹서버가 client가 되어 각자 필요한 메시지를 보내고, 받은 메시지를 통해 동작을 실행한다.

ⓑ 사용자 인터페이스 추가(웹 클라이언트)

메인화면 : 분리수거 성공과 실패에 따라서 메인화면의 캐릭터 얼굴이 변화한다.
설명페이지 : 사용자가 재활용 방법과 로봇의 검출 과정에 대해 학습할 수 있다.

ⓒ 사용자 인터페이스 추가(음성)

교육적인 로봇의 목표에 재활용에 관한 피드백을 제공하기 위해 음성 파일을 각 단계별로 출력되게 제작하였다.

소프트웨어 4주차
ⓐ 각 디바이스에 MQTT 통신을 구현하였다.

mqtt://주소를 통해 라즈베리파이에 구축한 브로커에 연결하여 ‘raspi’를 구독하였다.

esp8266 mini에서 MQTT 브로커로 연결하여 감각기관의 경우 ‘sensor’을 동작기관의 경우 ‘motor’을 구독한다.
2주차에서 분담을 통해 구현한 물체 감지, 모터작동 기능들을 MQTT 통신에 맞게 코드를 수정하였다.

소프트웨어 5주차
물체 테스트를 진행 중에 color-thief 모듈을 이용한 rgb검출에 대한 문제점이 드러났다. vision API보다는 작은 이물질에 대해 식별 가능했지만, 더 작은 이물질에 대해서는 검출하기 어려웠고, 결정적으로 배경색과 RGB 값이 비슷한 흰색, 검은색은 검출하기 어려웠다. 대체방법으로 이미지를 RGB matrix으로 변환해주는 모듈인 color-to-rgba-matrix를 사용하여 픽셀 단위의 분석을 진행하였다. 픽셀 단위로 연산량을 줄이기 위해 물체의 위치에 따른 분석하는 방법을 생각하였고, vision API에 위치 정보를 제공해주는 함수를 사용해 경곗값과 크기를 측정했다.

소프트웨어 6주차
ⓐ 사용자 인터페이스(웹 클라이언트)

5주차에서 측정한 경계값을 웹 클라이언트에 전송하여 BOX 형태로 표시하도록 하였다. 이는 사용자가 물체 분석되는 과정을 확인하는데 도움을 준다.

ⓑ 감각기관 코드 수정
감각기관의 변수를 수정하였다. 이전에는 문이 열리고 닫히면, 물체가 들어왔음을 감지했었는데, 조건문을 추가하여 무게 센서값까지 측정하는 방법으로 변경하였다.

ⓒ 연결상태 확인 추가
로봇을 테스트하기 위해 서버를 실행하는 과정에서 통신상태를 확인하지 않고, 실행한 경우, 연결상태를 확인하지 않고 실행해 로봇의 흐름이 섞이는 일이 발생했다. 이러한 문제를 해결하기 위해 처음 서버가 실행되기 전 MQTT 통신상태를 확인하기 위한 메시지를 보낸다. 메시지를 받은 디바이스는 초기화를 진행하고, 답변을 전달한다. 답변을 받은 라즈베리파이는 웹 서버를 실행시킨다.

5. 사용한 제품 리스트

6. 후속연구제안

6.1. 배경 색과 빛 반사
페트병의 투명성 여부를 판단하는 과정은 사진을 촬영하여 배경색과의 유사도를 검사하는 방식으로 진행된다. 이 때, 두 가지 문제점이 발생한다. 만약 라벨이나 이물질 등이 배경색과 유사한 색이라면 로봇은 ‘투명한 페트병’인 것으로 판별하게 된다. 또한 플라스틱 표면에 빛을 비추면 빛이 반사되어 카메라로 사진을 찍으면 반사된 부분이 흰색으로 인식되어 투명성 판별에 장애요소가 될 수 있다. 이는 신뢰도 하락과 재활용률 하락으로 이어지는 문제이므로 주의가 필요하다. 본 작품은 배경색을 회색(카메라로 촬영했을 때 R, G, B 세 값의 표준편차가 15이내, 평균은 40이상 180이하. 이때, 각 값은 0~255사이의 값을 갖는다.)으로 설정하여 라벨이나 이물질의 색과 분명한 차이를 둘 수 있도록 하였다. 그러나 만약 회색으로 이루어진 플라스틱 제품이 나오게 되면 본 작품에서 채택한 투명성 판별법은 신뢰도가 떨어지게 된다. 또한 빛 반사문제는 카메라를 사용한다면 피할 수 없는 문제이므로 해결하기 어렵다. 따라서 후속연구에서는 LPKF TMG 3 등의 광투과율 측정 장치를 이용하여 플라스틱의 투명도를 정확하게 측정할 수 있도록 할 것을 제안한다.

6.2. 플라스틱 압축 기능
플라스틱은 압축하여 배출해야 쓰레기통이나 쓰레기봉투를 효율적으로 사용할 수 있다. 따라서 플라스틱을 쓰레기통에 담는 과정에서 플라스틱을 압축하는 기능이 있으면 좋겠다는 생각을 했다. 이를 위해서는 강한 모터나 압축기가 필요한데 전력소비, 무게, 부피, 예산 등의 측면에서 효율성이 떨어지므로 배제하였다. 대체할 수 있는 기능으로는 페트병이 압축되었는지의 여부를 판단하는 방법이 있다. 이를 구현하려 하였으나, 압축된 페트병을 판별할 수 있는 명확한 기준을 찾기는 힘들었다. 비슷한 크기의 페트병이라면 무게도 비슷할 것이라고 가정하고 압축된 페트병과 압축되지 않은 페트병의 (넓이/무게) 값을 비교하였으나 유의미한 데이터를 얻지 못했기 때문에 페트병이 압축되었는지 판별하는 기능은 구현하지 못했다. 따라서 후속연구에서는 플라스틱 압축 기능이나 압축되지 않은 플라스틱을 구별하는 기능을 추가할 것을 제안한다.

6.3. 처리량
본 작품은 한 번에 1개의 페트병만 검사할 수 있다. 따라서 많은 양의 페트병을 버리려고 한다면 하나씩 천천히 넣어줘야 한다. 이는 굉장히 불편한 작업이므로 본 작품을 일상생활에서 사용하기 위해서는 이 문제를 반드시 해결해야 한다. 그러나 한 번에 검사할 수 있는 페트병의 수는 제한적이다. 따라서 큰 통에 페트병을 담아두고 거기에서 하나씩 꺼내서 검사하는 방법을 생각해볼 수 있다. 그런데, 사진을 찍는 시간은 약 10초, 재활용 가능한 플라스틱인지 분석하는 시간은 약 10초로 한 페트병을 처리하는 것에 평균 20초의 시간이 소요된다. 이는 디스플레이에 분석과정을 보여주고 음성으로 안내하기 위해서 의도적으로 시간을 늘린 것인데, 많은 양의 페트병을 처리하는 것에 방해요소로 작용한다. 따라서 안내하는 것을 간소화하는 것으로 시간을 단축할 수 있다. 또한 여러 개의 페트병을 한 번에 촬영하여 처리시간을 단축하는 방법도 있다. 단, 한 번에 많은 페트병을 처리할 경우, 그 중에서 재활용 되지 않는 패트병을 골라내는 방법에 대한 고찰이 선행되어야 한다.

7. 참고문헌
· 그린피스 김이서(2019년 12월),플라스틱 대한민국- 일회용의 유혹https://www.greenpeace.org
· 투명 페트병 재활용 제품 안내, 환경부 :https://www.newsro.kr
· 최병용(2021.02.19), 투명 페트병 분리배출 현장에 가보니~ : https://www.korea.kr/news/reporterView.do?newsId=148883922

2021 ICT 융합 프로젝트 공모전 우수상

일회용품을 사용하지 않는 친환경 자판기

(Eco-friendly Vending Machine)

글 | 대한상공회의소 서울기술교육센터 한승진, 김연진, 신상우, 유종선, 진민경

1. 심사평
칩센 최근에 여러 가지 형태로 무인음료 자판기가 설치되는 것으로 알고 있습니다. 이러한 무인 자판기는 기존과 같이 컵이 내장된 형태도 있지만, 작품과 같이 개인컵을 이용한 제품도 있는 것으로 알고 있습니다. 이미 기존에 있는 제품이라 하더라도 더 보완된 제품을 가격 경쟁력이 있게 만들 수 있다면 개발의 의미는 충분히 있습니다. 또한, 불편함이 있더라도 작품의 기획의도와 같은 목적을 보여주는 것도 좋은 방법이라 생각합니다. 이왕 echo-friendly라는 가치를 걸었다면 상용화된 1회용 컵을 구분하는 제약을 두어 제품의 목적을 분명히 밝히는 것도 좋은 방향이 아닐까 하는 생각입니다.

펌테크 친환경을 고려한 실생활과 접목된 실용성과 창의성을 지닌 작품으로 생각됩니다. 전체 하드웨어 및 소프트웨어 개발 환경 구성이 작품의 성격에 맞추어 체계적으로 적절하였다. 시스템 구성중 opencv를 사용한 영상처리를 과정 및 필요기능 위주의 심플한 형태로 짜임새 있고 깔끔하게 구성한 스마트폰용 APP은 인상적이었으며 전체적으로 기획의도, 기술 구현도, 완성도 등에서 우수한 작품이라고 생각됩니다.

위드로봇 아이디어를 프로토타입을 통해 개념을 확인한 부분이 훌륭합니다.

뉴티씨 텀블러를 사용하도록 하는 시스템은 조금 불편하더라도 환경을 지킬 수 있는 솔루션 중 하나일 수 있다는 생각이 듭니다. 나의 편리성을 위한 것이 아닌 후세대를 위한 지구 환경을 생각하여, 일회용품 사용을 줄일 수 있는 이와 같은 시스템을 좀 더 연구해야 할 것입니다.

2. 개발 배경

일회용품을 많이 사용하는 요즘, 전 세계적으로 일회용품 사용을 줄이기 위해 여러 가지 정책을 펼치고 있다. EU의 경우 올해(2021년)부터 플라스틱 세를 도입하여 플라스틱 사용 절감에 앞장서고 있다. 우리나라의 경우 커피 전문점 매장 내에서는 플라스틱 컵과 빨대를 사용할 수 없다. 또한, 슈퍼마켓에선 비닐봉지 사용이 불가하며, 대형마트에서는 포장용 테이프를 제공하지 못하게 된 상태이다.
하지만 1인 가구의 증가와 더불어 코로나 바이러스로 인한 배달음식 주문량이 많아지면서 일회용품 사용량 즉, 일회용품 배출량이 나날이 증가하고 있는 추세이다. 서울디지털재단의 ‘1인 가구 증가에 따른 일회용 플라스틱 배출 실태 분석’ 보고서에 따르면 1인 가구가 배출한 일회용품 양은 일평균 30개로 조사되었으며, 이는 다인 가구에 거주하는 1인의 배출량보다 약 2.3배 많은 양이라고 한다. 또, 서울 거주 시민 1000명을 대상으로 실시한 설문에 따르면 배달 음식 주문빈도는 코로나 발생을 기준으로 약 1.4배 증가한 것으로 조사되었다고 한다.
더불어 일회용 플라스틱 배출을 줄일 수 있는 방법에 대한 설문조사(1000명 대상)에서 ‘일회용 플라스틱 사용 저감 유도를 위한 보상체계 필요 여부’에 대해서는 응답자의 91.3%가 보상(인센티브)의 필요성을 공감하고 있는 것으로 나타났다고 한다. 보상방식으로는 ‘현금 지급’이 42.4%로 가장 높았고 이어서 ‘에코-마일리지 지급’(25.6%), ‘지역 화폐 지급’(18.3%) 등이 뒤를 이었다.
위의 보고서 내용과 마찬가지로 팀원들 모두가 일회용품 사용의 심각성과 사용 절감에 대한 필요성 모두 느끼고 있었다. 따라서 우리는 일상 속에서 일회용품을 절감할 수 있고 이에 따른 보상을 지급하는 제품을 만들기 위해 아이디어를 모았다. 그 결과 ‘일회용품을 사용하지 않는 자판기’를 개발하게 되었다.

3. 개발 목표
요즘 일회용품 사용을 절감하기 위한 사회적 움직임의 일환으로 일부 프랜차이즈 카페에서 플라스틱 컵 대신 개인 용기에 음료를 받으면 일정 금액을 할인해주고 있다. 이러한 서비스의 적용 범위를 확대하여 도서관, 스터디카페 또는 대학교, 공공기관 등 특정 사람들이 지속적으로 방문하는 곳에 배치된 자판기에 적용하여 일회용품 사용 절감에 이바지하도록 한다.
해당 자판기를 사용할 때마다 핸드폰 번호 입력을 통해 일정 금액이 에코-마일리지로 적립되며 추후에 실제로 제품이 상용화되는 경우 마일리지를 사용할 수 있도록 한다.

4. 작품 개요
일상 속에서 아두이노와 라즈베리 파이 그리고 젯슨 나노를 활용하였다.
아두이노는 음료 결제, 선택, 추출 등 자판기의 전체적인 동작을 담당하고, 젯슨 나노는 영상처리를 통해 음료 추출 전 사용자의 텀블러가 제자리에 놓여있는지 판단하였다. 라즈베리 파이는 터치스크린을 통해 자판기 내부의 진행상황을 알려주고, 자판기 이용 후 휴대폰 번호를 입력하면 에코-마일리지를 적립함과 동시에 누적된 마일리지를 확인할 수 있도록 하였다.
부가적으로 자판기 관리자를 위한 안드로이드 애플리케이션을 제작하여 자판기 내부 음료의 상태(양)를 확인하고, 음료별 누적 판매량을 통해 어느 음료가 인기가 많은지 확인 할 수 있도록 하였다.

4.1. 개발 환경 및 개발 도구 설명
4.1.1. 아두이노(Arduino)

아두이노는 다양한 스위치나 센서로부터 입력 값을 받아들이고 전자 장치들로 출력을 제어하여 디지털 장치를 만들기 위한 도구로, 간단한 마이크로컨트롤러를 기반으로 한 오픈 소스 컴퓨팅 플랫폼과 소프트웨어 개발 환경이다.

본 제품에서는 Arduino Mega 2560, Uno를 사용하여 전체적인 자판기의 동작을 구현하였다.

4.1.2. 젯슨 나노(Jetson Nano)

젯슨 나노는 엔비디아(NVDA)가 개발한 싱글 보드로 애플리케이션에서 다수의 뉴럴 네트워크를 병렬로 실행하게 해주는 강력한 소형 컴퓨터이다.
본 제품에서는 이와 같은 개발 환경에서 우분투의 vi 문서 편집기를 통해 언어 PYTHON으로 코드를 구현하고 실행 파일을 생성하였다.

4.1.3. 라즈베리 파이(Raspberry Pi)

라즈베리 파이는 영국 잉글랜드의 라즈베리 파이 재단이 학교와 개발도상국에서 기초 컴퓨터 과학의 교육을 증진하기 위해 개발한 신용카드 크기의 싱글 보드 컴퓨터이다.

라즈베리 파이 OS를 실행할 때, 기본 터미널 애플리케이션은 LXTerminal이다. 해당 프롬프트에서 리눅스 명령어를 기반으로 vi 에디터 또는 문서 편집기를 이용해 실행 프로그램을 생성할 수 있다. 본 제품에서는 html과 언어 php를 사용하여 웹 파일을 생성하였다.

4.1.4. 안드로이드(Android)
안드로이드는 휴대전화의 운영체제, 미들웨어, 사용자 인터페이스, 응용프로그램 등을 묶은 소프트웨어 플랫폼이다. 리눅스(Linux)2.6 커널 위에서 동작하며 운영체제, 라이브러리, 멀티미디어 사용자 인터페이스, 애플리케이션 등을 제공한다.
안드로이드 프로그래밍 언어로는 JAVA와 Kotlin이 있다. 또한, 안드로이드 스튜디오는 안드로이드 앱을 빌드할 때 생산성을 높여주도록 다양한 기능을 제공한다. 본 제품에서는 프로그래밍 언어로 JAVA를 사용하였다.

Android Emulator의 각 인스턴스는 Android Virtual Device(AVD)를 사용하여 시뮬레이션된 기기의 Android 버전과 하드웨어 특성을 지정한다. 효과적으로 앱을 테스트하려면 앱이 실행될 각 기기를 모델링하는 AVD를 만들어야 한다. AVD를 만들고 관리하려면 AVD Manager를 사용하면 된다.
4.2. 작품 구성
4.2.1. 부품 리스트

4.2.2. 회로도

4.2.3. 시스템 구성도

4.2.4. 작품 구상도

5. 작품 설명
5.1. 작품 제작 및 동작
5.1.1. 소켓 및 스레드 통신
자판기에 사용되는 장치들 간의 통신을 위해 소켓을 사용하여 서버를 구축하고 각각의 장치(아두이노, 젯슨 나노, 라즈베리 파이)들이 클라이언트가 되도록 하였다. 서버를 구축하는 데 있어서 C, PYTHON, JAVA 등의 언어 중 JAVA를 사용하였다.

스레드를 사용하지 않으면 여러 클라이언트의 접속이 불가하고, 다른 동작을 실행할 수 없다. 따라서 멀티 스레드를 사용하였고 초기에는 서버 하나에 여러 개의 클라이언트가 붙도록 구현하였다.

모든 클라이언트는 접속 시에 자신의 아이디를 서버에 전송한다. 이를 토대로 서버에서는 등록된 아이디 리스트와 접속 아이디를 비교, 검증한 후 클라이언트의 접속을 허용한다. 또한, 접속된 아이디를 기준으로 클라이언트 간 메시지를 보낼 수 있도록 하였다.

5.1.2. 아두이노(Arduino)
음료 결제
자판기의 결제 기능을 구현하기 위해 RFID 리더기 모듈을 사용하여 자판기 사용자의 카드가 인식되도록 하였다. 이후 전체 동작을 위해 RFID 리더기에 카드가 인식되면 ‘음료 선택’ 동작으로 넘어가도록 하였다. Arduino Mega 2560(이후 Mega로 칭함.)에서 Arduino Uno(이후 Uno로 칭함.)로 시리얼 통신으로 일정 값을 보내주고 Uno에서 값을 판단하여 재전송 하도록 한다.

음료 선택
사용자가 상황에 맞게 음료를 선택할 수 있도록 버튼과 LED를 구현하였다. LED는 현재 해당 음료를 선택할 수 있다는 신호이며, 버튼은 음료를 추출하도록 한다. 서버에서 결제가 되었다는 값을 전달 받으면 LED를 점등함과 동시에 버튼 기능을 활성화한다. 그리고 사용자가 버튼을 누를 시 해당 버튼에 맞는 음료의 정보를 Mega에서 시리얼 통신으로 Uno에게 메시지를 전송하여 ‘음료 추출’ 동작이 진행되도록 하였다.

음료 추출
음료를 추출하기 위해서 워터 펌프 모듈을 사용하였다. 워터 펌프 모듈의 불안정한 작동을 보안하기 위해 릴레이 모듈을 추가하였다. Mega에서 사용자가 선택한 음료 정보를 시리얼 통신으로 Uno에게 넘겨주고 음료 정보와 일치하는 워터 펌프를 작동시킨다. 음료 추출이 끝나면 부저를 통해 종료 음을 출력한다.
이후 모든 동작이 완료되면 언제든 사용자의 카드를 읽을 수 있는 초기 상태(결제 대기 상태)로 되돌린다.

음료 잔량 확인
플로트 스위치 센서를 사용하여 음료 잔량을 확인하도록 하였다. 부력으로 음료 표면에 떠 있다가 바닥에 닿으면 음료가 부족하다고 판단하여 LED를 소등한다. 그리고 사용자가 음료 선택 버튼을 눌러도 동작하지 않도록 하였다.
관리자가 애플리케이션을 통해 음료 잔량 정보를 요청하면 현재 모든 음료의 수위 센서 상태를 읽어 서버를 통해 애플리케이션에 전달한다.

매출 관리
애플리케이션에서 자판기 누적 판매량 기능을 구현하기 위해 음료 펌프가 작동된 횟수를 Mega의 비휘발성 메모리인 EEPROM에 저장하도록 하였다.
관리자가 애플리케이션을 통해 누적 판매량 정보를 요청하면 EEPROM에 저장된 값을 읽어 서버를 통해 애플리케이션에 전달한다.

5.1.3. 젯슨 나노(Jetson Nano)
컵 인식
먼저 Window 환경에서 opencv와 tensorflow를 사용하여 자판기 사용자가 놓은 컵을 인식하도록 하였다. 컵이 인식되면 웹캠을 종료하고 사진을 찍도록 하였다.

코드의 정상 동작 여부를 확인하고 젯슨 나노에서 개발 환경을 구축한 후 멀티 스레드를 사용하여 Mega에서 전송한 ‘음료 결제’ 메시지를 받으면 카메라를 동작시켜 컵을 인식하도록 하였다. 컵이 인식되면 Mega로 완료 메시지를 보내 계속해서 자판기의 동작을 수행한다. 컵이 인식되지 않으면 자판기의 동작을 중단하고 환불 페이지로 이동한다.

5.1.4. 라즈베리 파이(Raspberry Pi)
진행 상황 출력
라즈베리 파이에 부착된 터치스크린을 통하여 자판기 동작 진행상황 및 이용 순서에 맞게 웹 페이지를 띄워 사용자에게 알려준다.

에코-마일리지 적립
음료 추출이 종료되면 바로 에코-마일리지 적립 페이지로 이동한다. 자신의 전화번호를 입력하면 일정 금액의 마일리지가 적립된다. 입력을 완료하면 방금 적립된 마일리지와 누적된 마일리지 모두를 확인 할 수 있고 자동으로 페이지가 종료된다.

사용자가 입력한 정보는 MariaDB를 통해 관리한다.

5.1.5. 안드로이드(Android)
하단 탭
BottomNavigationView와 Fragment를 사용하여 하단 탭을 생성하였다. 하단 탭 클릭을 통해 ‘상태’ 페이지와 ‘판매량’ 페이지로 이동한다.

로그인(서버 접속)
메인 화면 상단에 로그인을 위한 옵션 버튼을 추가하였다. 해당 버튼을 선택하면 로그인 창을 띄운다.
해당 창에서 서버 접속(로그인)을 위한 IP, PORT, ID, PASSWORD를 입력한다. 미리 설정한 값이 기본 값으로 입력되어 있어 보다 편리하게 접속할 수 있다.

음료 잔량 확인
자판기 내부 음료의 잔량을 자판기 관리자가 수시로 확인 할 수 있도록 ‘상태’ 페이지 안에 CONDITION 버튼을 추가했다. 버튼을 누르면 서버를 통해 자판기 내부의 MCU에 특정 메시지를 전송하여 음료의 잔량을 요청한다.
자판기 내부의 음료가 충분하다면 아래 사진과 같이 음료 아이콘의 테두리를 강조 해준다.

음료 누적 판매량 확인
‘판매량’ 페이지의 초기 화면은 아래와 같이 ‘?개’로 나타낸다. RENEWAL 버튼을 누르면 서버를 통해 특정 메시지를 전송하여 음료 각각의 누적 판매량을 보여준다.
RESET 버튼을 누르게 되면 서버를 통해 판매량을 초기화 해달라는 메시지를 MCU에게 전송하여 각 음료의 누적 판매량을 모두 0개로 초기화한다.

6. 전체 흐름도

7. 최종구현

8. 시연

9. 결과 및 향후 목표
9.1. 결과
자판기에서 일회용품 사용을 줄이기 위해 초기에 기획한 기능으로 영상처리를 통한 텀블러 인식, 에코-마일리지 적립 등을 모두 구현하였다. 정상적으로 모든 기능이 동작하였지만 몇 가지의 아쉬운 점이 발생하였다.
먼저, 음료의 잔량을 측정하는 플로트 스위치 센서의 동작이 불안정하였다. 무게 센서나 무접점 수위 센서를 사용했으면 보다 안정된 동작을 구현할 수 있을 것이라 생각하였다. 다음으로 영상처리 부분에서 오픈 소스를 활용하다보니 필요 이상의 학습데이터로 인해 프로세서의 부담이 커져 텀블러 인식 속도에 영향을 미쳤다. 머신러닝을 접목하여 직접 필요한 이미지만 학습시킨다면 인식 속도를 개선할 수 있을 것이라 생각한다. 마지막으로 텀블러 크기에 따라 음료 추출량을 조절할 수 있는 방법에 대해 생각해보려 한다.

9.2. 향후 목표

본 제품은 소켓 통신을 하기 위해 와이파이를 사용한다. 하지만 와이파이를 대체할 수 있는 IoT 전용망이 전국적으로 구축되고 있다. 이는 유지비용 측면에서 최소 350원에서 최대 2,000원 정도로 저렴한 요금을 제공한다. 또 넓은 커버리지를 제공하여 본 제품이 상용화된다면 IoT 전용망을 통해 비용을 절감할 수 있다.
현재 애플리케이션은 자판기 관리자용으로 한정적인 기능을 제공한다. 이를 보완하기 위해 다양한 오픈 API를 사용할 수 있다. 예를 들면 구글 MAP API를 통해 자판기의 위치 정보를 제공하여 사용자는 보다 쉽게 자판기 이용이 가능하고, 관리자는 용이하게 유지 보수를 할 수 있다.
해당 자판기는 현재 일회용품을 사용하지 않는 것이 유일한 친환경적인 요소이다. 이를 확장하여 태양열 발전을 통한 전기 사용 등 친환경적인 요소를 추가적으로 접목시켜 환경 보호에 더욱 기여할 수 있다.

10. 참고자료
· 파이낸셜 뉴스, “1인 가구 플라스틱”, https://www.fnnews.com/news/202009181711464621
· 땅오니 로봇 코딩 블로그, “TCP/IP 소켓 통신”, https://ddangeun.tistory.com/31
· 멈춤보단 천천히라도, “파이썬 소켓”, https://webnautes.tistory.com/1381
· IT, 정보보안 자료실, “파이썬 멀티쓰레드”, https://nalara12200.tistory.com/153
· 명월 일지, “소켓통신”, https://nowonbun.tistory.com/315
· 토이메이커스, “아두이노 피에조 스피커“, https://blog.naver.com/yulian/221748202220
· 뤼즈나의 IT 블로그, “아두이노 워터 펌프”, https://in-reason.tistory.com/16
· 하이! 제니스, “아두이노 RFID”, https://m.blog.naver.com/chandong83/220920789808
· 에듀이노 코딩 스쿨, “ESP8266″, https://blog.naver.com/PostView.nhn?blogId=eduino&logNo=221152914869
· 폴나의 공방, “아두이노 시리얼 통신”, https://m.blog.naver.com/darknisia/221234187170
· 몽구스 프로그래밍, “아두이노 인터럽트”, https://m.blog.naver.com/PostView.nhn?blogId=yuyyulee&logNo=220310875023&proxyReferer=https:%2F%2Fwww.google.com%2F
· YouTube, “아두이노 RFID”, https://www.youtube.com/watch?v=SQ IGilMagm0
· 테크월드 뉴스, “젯슨 나노”, http://www.epnc.co.kr/news/articleView.html?idxno=95313
· MANUAL FACTORY, “우분투 설치”, https://www.manualfactory.net/13400
· DoProgramming, “젯슨나노”, https://doprogramming.tistory.com/category/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D/Jetson%20Nano
· 제너럴공국, “젯슨나노 텐서플로우”, https://generalthird.tistory.com/m/15
· 멈춤보단 천천히라도, “opencv”, https://webnautes.tistory.com/1186
· 개발하는 도치, “Seleninum”, https://heodolf.tistory.com/48
· 삶의 향기, “html 창 닫기”, https://lia47.tistory.com/995
· 안드로이드 스튜디오, Android Emulator, https://developer.android.com/studio/run/emulator?hl=ko
· Bugwhale World, 라즈베리파이 라즈비안 APM 설치하기 https://bugwhale.tistory.com/entry/raspberrypi-raspbian-apm-install
· 정재곤, 「Do it! 안드로이드 앱 프로그래밍」, 이지스퍼블리싱, 2020

11. 소스코드
MCU(아두이노) : MAGA

MCU(아두이노) : UNO

2021 ICT 융합 프로젝트 공모전 우수상

스마트 쇼핑 카트

글 | 영남대학교 양성은, 박유나, 이유진, 김형덕

1. 심사평
칩센 작품은 상품의 구매와 위치 측량의 두 가지 큰 목표로 보입니다. 우선 상품 취득과 결제 부분에 있어서는 목표량을 어느 정도 달성한 것으로 보입니다. 또 다른 목표였던 위치측량 관련하여 상품의 위치를 통한 navigating 기능을 구현하기 위하여 사용자의 위치를 측정해야 하는 구조로 이해됩니다. 작품을 개발하며 목표로 한 내역에 대하여는 어느정도 위치 측량을 성공하였다고 볼수도 있지만, 실제로 상용화에 있어서는 위치 측량에 대한 많은 변수들이 존재하여 실내의 Map이 함께 조합되어 정확한 실내 위치를 파악하게 하는 등의 다양한 방식의 알고리즘과 방안이 적용되고 있고, 이러한 부분에 대한 추가적인 연구 검토를 한다면 더욱 개선된 제품을 제작할 수 있을 것으로 보입니다.

펌테크 아이디어와 실용성이 돋보이며 짜임새 있게 잘 구성한 수준급 작품이라고 생각합니다. 실내 위치 측정을 위한 비컨 연동 과정에서의 시행착오가 있었음에도 불구하고 전체적으로 시스템 구성을 위한 각각의 난이도 있는 소프트웨어 구성을 효율적으로 접목하여 기획의도에 맞게 시스템을 안정적이고 완성도 높게 구현된 스마트카트 제품이라고 생각이 듭니다. 추후 작품 완성도를 높인다면 상업적으로도 충분히 활용될 수 있는 상품성을 가진 훌륭한 작품이 되리라 생각됩니다.

위드로봇 학습 용도로는 좋은 주제이지만, 실용적인 측면에서는 위치 측량, 결제 등 해결해야 할 문제가 많은 작품입니다.

뉴티씨 배려심이 느껴지는 작품입니다. 코로나19로 여러 가지로 어려운 상황에서, 같은 작품을 해도 어떤 마음으로 하는 가에 따라서, 의도가 다르므로 전혀 다른 결과가 나올 수 있습니다. 그런데, 몸을 움직이는 것이 불편하신 어르신들을 생각하여, 자동으로 계산이 되는 스마트쇼핑카트를 생각할 수 있었다는 것이 매우 중요한 가치라고 생각됩니다. 스마트 쇼핑카트라는 것은 오래전부터 인기 있는 작품의 주제로 만들어져왔지만, 이 작품은 비콘을 이용한 삼각측량법으로 위치인식까지 고려하여 제작하여 제품을 빠른 경로로 찾으러 갈 수 있도록 하는 부분도 함께 작성되었네요. 매우 좋은 작품을 제작하였습니다. 다양한 분야에서 활용될 수 있을 것 같고, 학생들이 좀 더 힘내서, 좋은 분야로의 응용을 기대하겠습니다.

2. 작품 개요
스마트 쇼핑 카트는 거동이 불편한 사람들에게 편리한 쇼핑 환경을 제공해 주기 위한 보조 장치이다. 이 프로젝트를 생각하게 된 계기는 마트에서 쇼핑을 하다가 물건이 많아 카트를 끌고 계셨지만, 몸이 불편하셔서 카트를 끌기조차 매우 어려워 보이는 분을 보고 ‘거동이 불편하신 분들도 대형마트에서 편하게 쇼핑을 할 수 있게 할 방법이 없을까?’ 라고 생각하다가 개발하게 됐다. 프로젝트의 구현으로는 대형 마트 내에서 실내 측위 시스템을 사용하여 구매하고자 하는 물건의 위치까지 최단 경로를 알려주어 효율적인 쇼핑을 가능하게 한다. 카트에 부착된 바코드 스캐너에 구매 물품의 바코드를 찍으면 데이터베이스 내에 존재하는 물품의 정보를 자동으로 관리할 수 있게 하고, 구매 상품의 행사 정보를 음성으로 알려준다. 결제 버튼을 누를 시, App에서 간단하게 결제할 수 있도록 한다. 현재의 전동 카트는 원하는 상품 코너로 이동하는 것 정도로 발전되어 있는데, 거기에 우리 팀의 프로젝트는 최단거리 알고리즘(Traveling Salesman’s Problem)을 적용하고, 결제 서비스까지 연동하여 사물 인터넷 개념을 적용해 현대에 어울리는 더욱 스마트한 카트로 발전시킨다.

2.1. 개발 목표

거동이 불편한 사람들의 오프라인 쇼핑을 도울 수 있는 카트를 개발하여, 기존 쇼핑 방식보다 쉽고(easy), 편리하고(convenient), 안전한(safe) 쇼핑을 제공하여 더 나은 소비 활동을 할 수 있도록 돕는다. 더 나아가 스마트 카트가 보급화 된다면 거동이 불편한 사람뿐만 아니라, 바쁜 현대인들에게도 최단 경로로 원하는 물품이 어디에 있는지 바로바로 알 수 있고, 결제까지 한 번에 해결하는 효율적인 쇼핑 수단이 될 것이다.

2.2. 개발 작품의 필요성
일반 사람들도 쇼핑을 할 때 원하는 물건이 어디 있는지 자주 구매하는 물품이 아니라면 알기 어려운데, 거동이 불편한 사람들이나 장시간 쇼핑이 어려운 노약자들은 그것으로 인해 불편한 몸을 이끌고 물건을 가지러 갔다가 헤매고 다시 계산하러 계산대까지 이동한다면, 일반 사람들보다 몇 배는 힘들고 제한될 것이다. 하지만 우리 프로젝트를 통해 이동 동선을 최소화하고, 시선이 닿지 않는 곳에 기재된 할인 정보를 음성으로 접할 수 있게 됨과 동시에 결제까지 스마트 카트 하나로 끝낼 수 있어서 보통 사람들처럼 불편함 없는 쇼핑이 가능하여 더 나은 쇼핑이 가능하게 한다.

2.3. 기대효과
· 거동이 불편한 사람들이 쇼핑에서 불편함을 느낄 수 있는 부분들을 지원하여 더욱 나은 쇼핑 생활을 가능케 한다.
· 스마트 쇼핑 카트가 여기에서 더 나아가 발전하고 보급된다면 일반 사람들도 기존의 쇼핑 방식 보다 더욱 효율적인 쇼핑 할 수 있다.
· 탈부착이 가능하도록 구성하여 유연성을 가지고 있으며, 효율적인 활용이 가능하다.
· 실내 위치 측위의 발전 가능성을 기대할 수 있다.

3. 작품 설명
3.1. 주요 동작 및 특징
3.1.1. 주요 기능 소개

전체적 구성은 라즈베리파이에 모니터와 바코드스캐너와 스피커가 연결되어있다. 이는 쇼핑 카트에 탈부착 할 수 있으며 또한 결제 어플과 연동된다.

기능 1(실내 측위): RF모듈의 RSSI 값으로 삼변측량법을 이용한다. Raspberry Pi가 3개의 RF모듈을 통해 얻은 RSSI 값으로 거리를 구하여 마트 내에서 구매자의 위치를 파악한다. 파악한 위치를 통해 구매자와 구매하고자 하는 상품코너와의 거리를 파악할 수 있다.
기능 2(최단 경로 안내): 삽변측량법과 같이 Traveling Salesman’s Problem을 이용하여 사용자가 물품 구매 시 최단 경로로 이동할 수 있도록 한다. 구매하고자 하는 상품들을 선택할 시, 실내 측위 기술을 통해 구매자의 위치를 기준으로 가장 짧고 빠르게 상품까지 도달할 수 있는 경로를 제공한다.
기능 3(장바구니 & 상품 Database 설명): 바코드 스캔을 통해 데이터베이스를 조회하여 상품의 행사 정보를 음성으로 알려주고 장바구니에 담긴 구매 물품들을 자동으로 관리할 수 있게 한다. 또 디스플레이로 장바구니 목록을 보여줌으로써 삭제 또는 추가 등의 자유로운 수정이 가능하다.
기능 4(결제기능): 카트에 부착된 모니터에서 결제버튼을 누르게 되면, 연동된 어플리케이션에서 결제가 가능하다.

3.1.2. RSSI 알고리즘 동작 및 특징

RF 비콘을 3개 생성하여 삼각측량법에 이용할 수 있도록 구성하였다. 비콘의 신호를 감지하기 위해 라즈베리파이를 오른쪽과 같이 비콘 수신기로 구성하였다. 비콘의 신호를 수신하여 rssi값으로 거리를 측정하고 현재의 위치를 추적할 수 있도록 한다.

Raspberry Pi가 RF Beacon에게 Data를 얻어와 TXpower와 RSSI값을 분리하여, RSSI에 따른 거리를 구한다. 3개의 비콘 모두 거리를 구해, 삼변측량법을 사용하여 목표위치를 파악할 수 있다.
비콘의 RSSI 값을 이용하여 직선거리를 구하는 공식을 이용하였습니다. 공식을 적용하기 위 TX Power 와 RSSI 값을 정제하여 거리 공식에 대입하였다.

3개 비콘의 각각의 좌표와 측정한 직선거리를 이용하여 삼변 측량법을 적용해 사용자의 현재 좌표를 출력하였다.

3.1.3. 최단 경로 안내 알고리즘 동작 및 특징

TSP(Traveling Salesperson Problem)을 이용하였다. TSP 알고리즘이란 원래 여러 도시들이 있을 때 한 도시로부터 시작해서 모든 도시를 단 한 번씩만 방문하여 다시 시작점으로 돌아오는데 드는 최단거리를 구하는 문제이다. 여기서 우리는 도시를 상품의 코너로 가정하였다. 입구에서 출발하여 각 선택된 코너들을 거치고 다시 입구로 돌아오는 식으로 최단경로 안내 문제를 해결하였다. 중간에 생각하지 못했던 필요한 물품이 생길 시 코너를 추가 선택한 후 안내를 누르면 다시 그 자리에서 시작하는 최단 경로를 시각화 하여 카트에 부착된 모니터로 안내해 준다. 전수 조사 방식으로 진행하여서 각 경로를 기억하기 위해 스택을 사용했다. 거리를 구하고 스택에서 각 경로의 거리 중 가장 짧은 경로를 선정하여 사용자에게 안내해 준다.

3.1.4. 장바구니 & 상품 Database 알고리즘 동작 및 특징
상품 Database: 먼저 MySql DB를 라즈베리파이에 설치한다. 명령어를 통해 데이터베이스를 생성한 후 데이터베이스 내에서 테이블을 생성한다. 테이블을 생성할 때에 바코드번호, 상품 이름, 상품 가격을 받아오도록 자료형을 지정해주고 테이블을 만들어준다.

장바구니 기능: while문을 통해 항시 입력을 대기하며, 바코드 스캐너로 물품의 바코드를 찍으면 Database Table에서 해당 물품의 정보를 가져와 목록에 저장을 한다. 생성해 놓은 데이터베이스를 파이썬과 연동하여 데이터베이스를 조회할 수 있도록 구성하였다.

연동 방법은 pymysql이라는 파이썬 라이브러리를 설치해주었다.

저장한 목록은 디스플레이에 출력하여 사용자가 구매할 물품이 장바구니에 담긴 것을 시각정인 정보로 제공한다. Pandas를 이용하여 시각화하였다. 아래의 사진을 보면 시각화된 모습을 볼 수 있다.

장바구니에 담긴 물품들 중, 구매하지 않을 물품을 삭제할 때 입력창에 1을 입력하면 delete mode로 바뀐다. 디스플레이에서 제공하는 상품의 목록을 통해 삭제할 물품의 인덱스 번호를 입력하면 쉽게 삭제가 가능하다.

행사 정보 안내 기능: 사용자에게 물품의 행사 정보를 쉽고, 간편하게 제공할 수 있는 방법에는 음성 안내 기능이 있다. 구매하려는 물품의 바코드를 스캔하면, 장바구니 목록에 담김과 동시에 해당 물품의 행사 정보를 음성으로 안내해준다. 음성 안내 기능은 TTS(Text to Sound)로 구현하였으며, 문자열로 넘겨주도록 했다.

3.1.5. 결제기능 동작 및 특징
Application과 Raspberry Pi간의 소켓통신으로 장바구니에 담긴 최종 금액을 APP으로 넘겨준다.(소스코드 [첨부 19] 참고) 통신 방식은 소켓통신을 이용하였다. 라즈베리파이가 클라이언트가 되도록 구성하고 App이 서버가 되도록 구성하였다. App에서 제공해주는 IP를 입력한 후 데이터를 전송하게 된다.

넘겨받은 데이터를 토대로 결제 기능을 제공하며, 해당 결제 기능은 안드로이드 스튜디오에 Bootpay SDK를 연동하여 결제 테스트를 할 수 있도록 구성하였다. 안드로이드용 Application ID를 Bootpay 관리자에서 가져와 연동하였다. 안드로이드 라이브러리는 내부적으로 WebView를 이용하여 구현되어 있다. Javascript SDK를 안드로이드 WebView에서 구현한 방식으로, 결제연동, 결제결과에 대한 라이프 사이클 함수가 제공된다. 따라서 안드로이드 레이아웃에 View를 줌으로써 결제 창을 띄우도록 구성하였다.

3.1.6 프로그램 사용법

처음 모드선택에서 0번을 선택할 시 경로안내 모드로 들어가게 된다.

화면에서 처음에 방문하고자 하는 코너를 선택할 수 있다. 코너를 다 선택하면 최단경로가 시각적 정보로 사용자에게 안내된다.

안내 후 다시 모드선택으로 되돌아온다. 여기서 1번을 선택하게 되면 장바구니 모드로 들어가게 된다. 장바구니 모드에서 바코드 스캔을 통해 장바구니를 추가할지 구성된 장바구니 목록을 삭제할지 결제 할지를 선택할 수 있다.

먼저, 바코드를 스캔하면 TTS(Text to Speech)로 상품의 행사정보를 사용자에게 음성안내를 해준다. 모니터에는 상품이 추가된 장바구니 목록을 볼 수 있다.

다른 상품의 바코드를 찍으면, 장바구니 목록에 새로운 상품이 추가된 것을 볼 수 있다.

같은 상품을 여러 번 찍으면 목록이 새로 추가되는 것이 아니라 해당 상품의 수량만 늘어나는 것을 볼 수 있다.
바코드 스캔 대신 1을 2번 입력하면 삭제 모드로 들어간다. 현재까지 구성된 장바구니 목록을 보여주며 삭제하고자 하는 목록의 인덱스를 입력하면 삭제가 된다. 다음 사진을 보면 삭제가 되는 것을 확인할 수 있다.

마찬가지로 바코드 스캔 대신 2를 2번 입력하면 결제 모드로 들어가게 된다. 앱에서 제공하는 IP정보를 입력하면 결제정보를 App으로 전송하며 결제 가능하다. 다음 사진을 보면 결제가 청구된 것을 확인할 수 있다.

3.1.7 전체 알고리즘 동작 및 특징

3.2. 전체 시스템 구성

3.2.1 하드웨어 구성
· Raspberry Pi
· Barcode scanner
· Speaker
· Monitor

3.2.2 소프트웨어 구성
· MySQL Database
· TSP algorithm source
· 삼변측량 algorithm source
· TTS source

3.2.3 주요 동작 및 특징
· Barcode scan을 통한 상품, 장바구니 database 구성
· Barcode scan을 통한 행사 정보 음성 안내 기능 TTS 구현
· 삼변측량법을 통한 실내 위치 측위
· TSP algorithm을 통한 최단경로 추적

3.3. 개발 환경

4. 단계별 제작 과정
4.1. Hardware
Raspberry PI에 보조배터리, 모니터, 스피커, 바코드 스캐너가 연결하였다. 전동 카트(장바구니)에 Raspberry Pi와 함께 전력을 공급해주는 보조배터리, 경로안내와 장바구니 목록을 시각화해줄 모니터, 해당 상품의 행사 정보를 음성으로 출력해줄 스피커를 부착한다. 또한, 바코드 스캐너를 쇼핑카트에 부착하였고, 스캔 시 UART 통신을 통해 라즈베리로 바코드 정보를 넘겨 상품을 장바구니 목록에 담을 수 있도록 한다. 담긴 상품의 목록은 모니터로 사용자에게 시각화 해줌으로써 사용자가 장바구니를 직접 보며 관리할 수 있도록 한다.

탈부착식 모듈
탈부착 식 모듈로 전동 카트뿐만 아니라 일반 카트에도 부착할 수 있다. 탈부착 식이므로 전동 카트의 개수가 아닌 한 매장에 필요한 개수만 구비해도 됨으로 가격적 부담도 줄어들도록 했다.

실내 측위를 위한 Bluetooth Beacon

위치 추적을 위해 최소 3개의 블루투스 비콘을 마트에 설치함으로써 실내에서의 실제 위치를 추적 가능하다. 각각의 비콘마다 코인건전지 CR2032 3V 2개로 전원공급을 한다. 하지만, 1m 밖의 거리에서 정확도가 떨어지는 RSSI값을 확인할 수 있었다. 짧은 통신 거리의 한계로 Beacon을 이용할 때 1m 내의 범위에서 시연을 진행하였다.

실내 측위를 위한 RF 통신

앞서 언급한 Buletooth Beacon의 짧은 통신 거리의 한계를 대체할 RF 통신을 구현하였다. RF통신은 통신 거리가 100m까지도 가능하기 때문에, 해당 문제점을 보완할 수 있다.
다음과 같이 Beacon을 세 곳으로 설치하여 RF통신 시연을 진행하였다.

시현 위치에서 1분 동안 측정한 데이터의 그래프이다. 그래프를 보면 RSSI값의 변화에서 값이 비교적 일정하게 나오는 것을 볼 수 있어 그 전의 블루투스 Beacon보다는 거리 측면에서나 정확도 측면에서나 뛰어난 성능을 보여주고 있다.

4.2 Software (Raspberry PI, Application)
4.2.1. 라즈베리파이
바코드 스캔 및 행사 정보 안내

상품을 장바구니에 담는 방법은 간단하다. 카트에 부착된 바코드 스캐너로 상품의 바코드를 스캔하면 장바구니에 담긴 것을 모니터로 확인이 가능하다. 같은 상품의 바코드를 여러 번 스캔 할 시 같은 목록이 여러 개 생기는 것이 아니라 같은 상품의 수량만 늘어나게 하였다. 모니터를 통해 장바구니 목록의 삭제, 수정을 제공한다. 또한 행사 중인 물품은 카트에 부착된 바코드 스캐너를 통해 바코드를 찍을 때 TTS(Text to Speech)로 상품의 이벤트 정보를 읽어준다. 해당 바코드에 찍힌 번호는 자료형을 int로 성언하면 오버로드가 되기 때문에 VARCHAR 형으로 자료형을 바꾸어 해결할 수 있다.

최단 경로

해당 매장의 코너의 데이터들은 모두 저장이 되어있다는 가정하에 진행이 된다. 사용자가 방문하고자 하는 코너를 모니터상으로 선택할 시, TSP (Traveling Salesperson Problem) 알고리즘을 이용한다. 실내 측위 정보로 현재 위치로부터 최단거리를 계산하게 된다. 최단의 이동경로를 모니터를 통해 사용자에게 안내해준다.

실내 측위
실내 측위 기능: 사용자에게 현재 어느 위치에 있는지 실시간으로 사용자에게 알려주고 최단 경로 안내에도 쓰인다. 건물에 설치되어 있는 비콘의 신호를 수신하여 삼각측량법을 통해 현재 위치를 계산한다.

장바구니
상품 정보의 관리는 MySQL DB를 이용하여 물품의 Database를 구축하여 상품정보를 등록해 놓았다. MySQL에서 기존에 만들어놓은 table을 삭제하지 않고 같은 이름으로 다시 생성하면 오류가 발생하기 때문에 기존 table을 삭제하고 다시 생성해야한다. Python과 연동하여 바코드 번호로 조회 할 수 있게 구성하였고, 카트에 연결된 모니터에 결제 버튼을 누르면 연동된 App(부트페이)으로 결제정보를 보냄으로써 결제 할 수 있게 하였다.
App은 원래의 마트나 (홈플러스, 이마트 등) 대형마트에서 제공하는 App으로 결제 정보를 보낸다고 가정했지만 실제 App을 수정할 수 없어 결제기능만 있는 어플을 따로 구현하였다.

상품목록 추가 : 상품의 바코드를 스캔할 시, 모니터 상으로 상품이 추가 된 것을 확인할 수 있다.

상품목록 삭제 : 필요하지 않은 상품은 삭제 모드로 들어가 해당 상품의 인덱스를 지정해 삭제할 수 있다.

결제 모드를 통해 어플에서 결제가 가능하다.

GUI
경로 안내 모드에서 기존에 제시한 디스플레이는 텍스트 형식으로만 구성이 되어있었다. 이를 가독성있게 만들기 위해서 Python에서 사용하는 GUI를 이용해 시각화시켰다. 왼쪽의 메인 화면을 통해 모드를 선택할 수 있으며 경로와 장바구니 모드가 있다. 경로안내모드에서는 사용자가 원하는 코너를 선택하고 OK 버튼을 누를 수 있으며 취소하고 싶은 코너가 있다면 다시 한 번 누르고 OK 버튼을 누르면 된다.

장바구니 모드에서는 바코드 스캔이 주를 이룬다. 바코드로 상품을 스캔할 때마다 목록에 상품들이 쌓여간다. 삭제 기능도 제공하여 Check를 눌러 목록에서 삭제를 누를 수 있다.

마지막으로, 결제 버튼을 누르게 되면 사용자의 어플과 통신으로 해당 상품의 가격을 전송하게 된다.

4.2.2 어플리케이션

안드로이드 스튜디오와 부트페이 SDK를 연동하여 가상 결제 기능을 제공한다. 인앱 결제 방식은 구현 시, 유로 모듈 결제가 필요하기 때문에 무료로 제공하는 Bootpay 방식을 사용하였다. Bootpay 사이트에서 결제 연동 시, 필요한 ID를 받아올 때 WEB Application ID로 잘못 받아와 실패하였다. Android Application ID를 제대로 받아와서 연동 문제를 해결할 수 있다. 또한 Android Studio Build.gradle(app)에서 compileSdkVersion은 30으로 설정하고, targetSdkVersion은 27로 설정하여 오류가 발생하였다. targetSdkVersion30으로 수정할 시, 정상 동작하는 것을 확인할 수 있다.

4.3 주요 소스 코드 설명

5. 사용한 제품목록

6. 기타

6.1 기능블록도

6.2 목표 달성 현황
장바구니
목표: 바코드 스캔을 통해 장바구니 목록에 넣을 수 있고, 삭제와 추가의 기능도 구현
달성: 바코드 스캔을 통한 물품 목록 추가와 삭제를 할 수 있음.

최단거리
목표: 실내 측위 정보로 현재 위치로부터 최단거리 계산
달성: 현재 위치로부터 최단거리를 계산할 수 있음.

위치측량
목표: 현재 위치를 작은 오차로 받아오도록 구현
달성: 블루투스 비콘에서 RF 비콘으로 변경하여 측정 반경 거리를 넓혀 사용성을 확대함. 약간의 오차는 개선방법을 추후 적용할 예정.

인터페이스
목표: 작성한 GUI틀과 프로그램 연동
달성: 코너의 위치 정보와 최단경로, 상품목록 등을 볼 수 있도록 구현하였음, 사용자 친화적인 인터페이스 화면 디자인 완성. 추후 프로그램과 GUI를 연동할 예정.

결제 앱
목표: 장바구니 목록에 있는 상품을 앱으로 결제 가능하도록 구현
달성: 장바구니 목록을 구성할 수 있고 결제가 가능함.

6.3 시연영상 주소

6.4 참고문헌
· https://gongdae58.tistory.com/73
· https://ko.wikipedia.org/wiki/%EC%82%BC%EB%B3%80%EC%B8%A1%EB%9F%89
· https://codeanalysis.tistory.com/2
· https://m.blog.naver.com/wlsdml1103/221159758141
· https://m.blog.naver.com/PostView.nhn?blogId=dsz08082&logNo=221852345347&proxyReferer=https:%2F%2Fwww.google.com%2F
· http://pythonstudy.xyz/python/article/408-pandas-%EB%8D%B0 %EC%9D%B4%ED%83%80-%EB%B6%84%EC%84%9D

2021 ICT 융합 프로젝트 공모전 우수상

간호사의 업무 부담을 줄여주는

EMR연동 vital sign계측 시스템

글 | 건양대학교 장건호, 이지훈

1. 심사평
칩센 최근 의료업계 또한 ICT 장비나 시스템 도입이 매우 늘어나고 있고, 개발자가 작품의 기획 중에 고민한 회진을 통한 활력 징후 체크를 대체하기 위한 시스템이 대표적으로 가장 먼저, 그리고 많은 곳에서 검토되고 있는 것으로 알고 있습니다. 의료기 자체의 휴대성 및 전기적 장비로의 변경은 많은 부분에서 이루어진 것으로 생각되고, 그 장비 등에 개발자가 구성한 시스템이나, 솔루션을 적용하면 의료진의 업무가 훨씬 더 효율적이고, 환자의 입장에서도 빠르고 정확한 이상 징후 전달이 가능할 것으로 보입니다. 제품 제작에도 많은 공을 들인 것으로 보이는데, 실제 시연 영상 등이 있었다면 어땠을까 하는 아쉬움이 남습니다.

펌테크 세심한 관찰력이 반영된 실생활과 밀접한 아이디어와 실용성이 우수한 작품이라고 생각합니다. 혈압계에 온도계 기능 부가 구성은 신선했고, 기획의도에 맞게 전체 시스템을 안정적, 효율적으로 구성했으며 완성도 높게 구현하였다고 판단이 되며 전체적으로 기획의도, 기술구현도, 완성도 등에서 우수한 작품으로 판단되며 제출된 문서를 종합적으로 검토해 볼 때 최종 완성은 되진 않은 것을 판단되나 추후 보완을 통해 완성도 높게 구현된다면 상업적으로도 손색이 없는 우수한 작품이 되리라 생각됩니다.

위드로봇 전체 완성도가 높은 작품입니다. 목표와 결과가 일치하는 잘 진행된 작품으로 보입니다.
뉴티씨 매우 실용적인 작품으로 생각되며, 실제로 격무에 시달리는 간호사들의 업무를 줄여줄 수 있을 것으로 생각합니다. 좀 더 콤팩트하게 제작하면 무겁지 않아서 좋을 것 같고, 표시기와 네트웍은 스마트폰에서 제공해도 될 것 같으므로, 같은 아이디어로 센서부만 제작하여 통신으로 데이터를 날려주고, 스마트폰에서 데이터들을 가공 처리한 후, LCD로 표시하여주면 더 가볍고 좋을 것 같습니다. 좀 더 고민하여서, 완성도를 높인다면 사업으로 연결할 수도 있을 것 같습니다.

2. 작품 개요
현재 간호사는 정해진 시간마다 환자의 활력징후(인간의 생명 활력도를 추정할 수 있는 가장 기본적인 생체징후)를 측정합니다. 이는 간호사의 기본 업무 중 하나로써 상당한 시간을 할애하는 것으로 알려져 있습니다. 중증환자가 아닌 일반 환자의 경우 일일이 간호사가 직접 회진을 돌며 측정해야 하는데 이때 개별의 장비를 사용하고 차트에 수기작성을 하는 등 전통적인 방식을 사용하고 있습니다. 측정 장비의 단순화와 자동화로 관리효율을 증대시키며 잘못된 기입을 방지하고 의료진의 업무효율 증대가 해당 작품의 목적입니다.
따라서 혈압계와 체온계를 하나의 패키지로 구성하여 사용자 경험을 고려한 디자인을 채택하였고 RFID태그 및 무선 통신기술을 활용하여 EMR(환자에 관련된 정보를 전산화 한 것) 자동 기입 시스템을 구현했습니다.

3. 작품 설명
최근 병원들은 ‘환자 중심’이라는 키워드에 맞춰 변화하고 있는데 이는 간호사의 서비스 영역까지 포함하고 있습니다. 따라서 현재 간호사의 본래 많은 업무와 더불어 부가적인 서비스까지 요구되고 있어 간호사의 업무 스트레스가 가중되고 있는 상황입니다. IoT 활력징후 시스템을 도입할 경우 활력징후를 측정, 수기로 작성, DB에 입력 등 일련의 과정을 간결화 하여 업무능률을 탄력적으로 높일 수 있습니다. 간호사의 휴게시간 보장 및 업무 만족도 향상 등을 기대하며 결과적으로 환자에게 더 많은 시간을 할애 하는 잠재적인 효과도 예상 할 수 있습니다.

4. 주요 동작 및 특징
4.1. 주요 특징
체온계
1. 체온계를 혈압계에 dock 방식으로 결합하여 휴대성을 강조한 구성
2. 비접촉식 적외선 체온 측정 방식
3. RFID Reader 로 환자 개별 식별 가능
4. 충전 형 배터리 사용
5. Dock 거치 시에는 혈압계로부터 전원을 공급받아 충전하고 분리 시 자동 부팅 후 블루투스 페어링 기능

혈압계
1. 오실로 메트릭 법 혈압 측정 방식
2. 5인치 터치스크린을 활용하여 측정 값 및 환자 정보 표시
3. 충전형 배터리 사용
4. 와이 파이를 이용하여 웹 데이터베이스에 접근, 체온계로부터 받은 RFID값으로 환자 정보를 불러오고 활력징후 측정값을 저장

동작 프로세스

5. 전체 시스템 구성
하드웨어

소프트웨어

그래픽 유저 인터페이스

6. 개발환경
체온계
1. MCU : Arduino Nano
2. 언어 : C Language
3. 사용 모듈 : 적외선체온센서, RFID리더, OLED, 블루투스 모듈

혈압계
1. MCU : Raspberry Pi4
2. OS : Raspbian (linux)
3. 언어 : Python Language
4. 사용 모듈 : 혈압계, 5인치 터치 디스플레이

GUI
1. 개발 툴 : pyqt5
2. 언어 : Python Language

3D모델 외부 케이싱
1. 설계 : SolidWorks 2017
2. 슬라이싱 : CURA, simplify
3. 3D프린터 : Anet a8, moment
4. 출력방식 : FDM
5. 사용재료 : PLA

백엔드
1. DB : Firebase
2. 서버 : Flask
3. 웹 : Jinja2
4. 언어 : Python

통합개발환경
1. 체온계, 혈압계 일부: Sublime Text 3
2. 혈압계, 웹 : Visual studio Code

7. 단계별 제작 과정
7.1. 체온계 제작
체온계 제작에 있어서 가장 중요했던 부분은 전원부입니다. 전원을 상시 켜둘 이유가 없으며 이는 충전을 방해하는 요인이기 때문에 충전 시에는 체온계의 전원을 꺼두고 충전 Dock에서 분리 시에 자동으로 전원이 켜지며 부팅이 완료되는 기능을 구현하고자 하였습니다.

트랜지스터의 디지털 스위치 기능을 활용해서 충전전압을 입력 신호로 판단하였습니다.
하지만 당시에는 쉽게 구할 수 있는 NPN 트랜지스터로 제작을 하였기 때문에 단순한 구조로는 원하는 기능을 구현할 수 없었습니다. NPN TR은 베이스에 양 전압을 가하면 콜렉터에서 이미터로 전류가 흐르게 됩니다. 이때 베이스에 입력되는 전압이 충전 전압이라고 가정할 때 우리는 콜렉터에서 이미터로 전류가 흐르는 것이 아닌 차단되어야 합니다. 반대로 베이스 전압을 제거 했을 때 전류가 흘러야 합니다. 따라서 베이스를 컨트롤하는 TR 스위치를 하나 더 추가하여 이중 TR 스위치를 만들었습니다.
구체적인 전체 회로는 원고 하단에 첨부합니다. 그 중 디지털 스위치의 구조만 확대한 내용은 다음과 같습니다.

Tr1이 1차 스위치 Tr2가 2차 스위치입니다. 1차 스위치에는 늘 항상 5V의 전압이 인가되고 있습니다. (배터리 전압) 하지만 2차 스위치에서 충전 전압이 인가 될 때 1차 스위치에 인가되던 배터리 전압은 GND로 흐르게 되어 전압이 낮아집니다. 결과적으로 1차 스위치는 개방되는 것입니다.
따라서 충전 중에는 2차 스위치에 전압이 인가되어 1차 스위치는 개방 되고 충전을 그만 두었을 때는 2차 스위치가 개방되어 1차 스위치는 배터리 전압에 의해 단락됩니다.

체온계의 핵심 기능은 다음과 같습니다.
1. RFID 리딩 후 블루투스 전송
2. 온도 센서 측정 후 블루투스 전송
3. 위 1,2번이 작동할 시 진동을 발생 할 것
4. 모든 진행 상황을 OLED에 비주얼라이징 할 것

사용 모듈
1. 진동 모듈
2. OLED
3. RFID 리더
4. 비접촉 적외선 온도 센서
5. 블루투스 HC-05
6. 충전 모듈

7.2. 체온계 코드
7.2.1. 진동 발생
진동 모듈은 핀 번호를 지정한 후 특정한 패턴으로 작동하게끔 미리 함수로 써 만들어 줍니다. 이 후 필요한 순간마다 함수를 호출 하는 방식으로 진동을 발생 시켜 햅틱 기능으로서 사용자에게 정보를 전달합니다.

7.2.2. OLED 표시
Oled 역시 디스플레이의 역할로서 늘 갱신되어야 합니다. 따라서 Oled를 리뉴얼하는 코드를 함수로 따로 만들어둔 다음 체온 측정 후, RFID 카드를 읽었을 때, 전원이 켜졌을 때, 등등 필요 시 호출 하는 방식으로 표시합니다.

전역 변수를 사용하여 체온 값과 RFID아이디를 갱신 합니다. 밋밋한 화면을 좀 더 알차게 구성하기 위해 이미지를 삽입하였습니다. 이미지는 흑백 이미지로 알맞은 크기로 제작 한 뒤 비트맵 단위로 변환하여 줍니다.

헥사 코드로 변환된 이미지를 u8g 라이브러리에 포함된 bitmap draw 기능을 활용하여 화면에 그려줍니다. 이미지를 bitmap으로 변환하는 과정과 기능은 http://en.radzio.dxp.pl/bitmap_converter/ 해당 사이트를 참고하였습니다.

7.2.3. RFID 리더
MFRC522 모듈을 사용하는 라이브러리의 예제를 수정하여 사용합니다. RFID 카드에는 여러 가지 정보가 담겨 있으며 그 정보를 읽고 쓰기가 가능합니다. 하지만 실질적인 데이터의 저장은 카드에 담는 것이 아니라 온라인 데이터베이스를 사용할 것입니다. 따라서 RFID의 고유한 ID만 사용합니다. 고유 ID를 주소처럼 사용하여 DB에 접근하고 저장합니다.

ReadNUID예제를 실행 한 후 카드를 읽힌 결과입니다. 여기서 우리는 hex값을 사용하도록 합니다. ID로 사용하기에 dec보다는 짧기 때문입니다. 결과 값을 곧이곧대로 사용하기에는 깔끔하지 않음으로 예제를 적당히 수정하여 핵심만 추려 냅니다.

앞선 그림 [카드의 용량과 id 값이 표시 됨]과 비교했을 때 hex값만 출력이 되며 16진수 한자리를 구별하는 띄어쓰기도 사라졌습니다. 우리는 hex값을 일일이 해석하려는 것이 아닌 하나의 ID로써 문자열을 사용할 것이기 때문에 위와 같이 수정하였습니다.

7.2.4. 비접촉 적외선 온도 센서
Adafruit_MLX90614라이브러리를 사용합니다. 섭씨온도 중 Object온도를 사용합니다. I2C통신을 사용하며 라이브러리 내장 함수를 사용하기 때문에 비교적 간단합니다. 하지만 사용하는 방식에 있어서 문제가 발생합니다. 먼저 온도를 언제 측정할지 시점을 지정할 방법이 필요합니다. 분명하게 신체를 가리키지 않았지만 온도를 측정하게 된다면 그 것은 잘못된 측정입니다. 두 번째로 센서의 민감도에 따라서 보정이 필요합니다. 경우에 따라 한 번의 측정으로는 정확한 값을 얻을 수 없습니다. 따라서 우리는 버튼이라는 물리적인 장치를 통해 외부에서 신호를 보내며 동시에 3초간 측정한 값의 평균으로 온도를 측정합니다.
기본적인 구조는 택트 버튼을 인터럽트 핀을 사용하여 부착하고 버튼이 눌렸을 때 3초에 걸쳐서 온도를 측정합니다. 3번의 측정값이 20도 이상이며 1의 자리가 모두 동일한 경우 평균을 내어 측정을 완료합니다. 해당 조건은 오류를 잡아내고 보다 정확한 측정을 위한 경험적 결과입니다.

타임 인터럽트는 1초마다 count값을 더해줍니다. count에 따라 온도 측정값을 배열에 넣고 그 값을 판단하는 구조입니다. 조건에 부합하면 타임 인터럽트는 종료됩니다. 이 것을 반복합니다.

7.2.5. 블루투스 전송 – 통신 프로토콜
앞서 RFID ID 리더와 온도 측정을 구현하였습니다. 또한 이를 Oled에 표시하기도 하였습니다. 측정값을 Dock(혈압계)에 전송을 해야 합니다. 이때의 통신 방법은 블루투스를 사용하며 모듈은 HC-05를 사용합니다. AT-mode를 통해 미리 사용할 블루투스의 주소를 알아내고 비밀번호와 이름을 설정합니다.
Dock과 통신하는 프로토콜은 string to string을 이용합니다. 센서의 종류와 측정값을 한 string 문자열에 첨부하여 전송하는 방식입니다. ID값은 “BC”, 체온은 “BT”라고 약속합니다. 또한 정보의 구분 또한 특정한 문자를 지정하여 한번 전송한 데이터의 끝을 표시해 줍니다. 사용한 문자는 “Z”입니다.
예컨대 체온을 전송할 땐 “BT36.5Z”의 형식을 맞추어 혈압계로 전송됩니다.

7.3. 체온계 케이싱
7.3.1. 3D 모델링
사용할 모듈을 버니어캘리퍼스로 실측을 합니다. 실측한 값을 토대로 solidwork에서 part를 만들어 줍니다. 만든 part를 assembly를 통해서 적절히 배치를 하고 케이스 모델링을 진행합니다. 이 때 3D프린터로 출력할 것을 고려하여 설계 합니다.

7.3.2. 3D프린터 출력
설계한 모델링을 슬라이싱을 통해 G-code로 변환한 후 3D프린터로 출력합니다. FDM 방식의 프린터기를 사용했으며 재료는 PLA 흰색입니다.

7.3.3. 후가공
FDM 방식의 출력물은 특유의 단층이 존재하게 됩니다. 작품에는 아무런 영향을 끼치지 않지만 완성도를 위해 후가공을 진행하였습니다. 후처리 방법은 사포로 표면을 갉아 내고 퍼티를 발라 틈새를 매우고 다시 사포로 갉아내는 방법을 지속해서 반복합니다. 이 후 흰색 락카를 도포하여 마무리합니다.

7.3.4. 조립
완성된 케이스 내부에 납땜한 회로와 기타 모듈들을 배치하여 조립을 완성합니다. 그 다음 정상적으로 작동하는지 확인 합니다.

7.4. 혈압계 제작
Dock은 혈압계 자체의 기능을 수행하면서 동시에 체온계와 DB를 이어주는 중간 매개체에 해당됩니다. 따라서 수신 받은 RFID ID 값과 체온 측정 값, 혈압 값을 적절하게 처리하여 디스플레이에 표시하고 firebace 데이터베이스에 저장하는 역할을 수행합니다.

혈압계의 핵심 기능은 다음과 같습니다.
1. 그래픽 인터페이스를 사용할 것
2. 체온계를 거치할 수 있는 구조일 것
3. 블루투스, 와이파이 통신할 것
4. firebase DB를 이용할 것

사용 모듈
1. 5인치 터치 디스플레이
2. 라즈베리파이3
3. 혈압계

7.5. 혈압계 코드
그래픽 유저 인터페이스를 제작합니다. 측정값과 환자 정보를 표시하기 위함으로 직관적이고 깔끔한 디자인을 선택합니다. UI는 파이썬언어 기반의 툴킷인 pyqt5를 사용합니다. 또한 pyqt5를 보다 쉽게 사용할 수 있도록 제작된 응용프로그램인 qtDesigner를 사용하여 드롭앤 드랍 방식으로 UI를 제작합니다.

완성된 gui는 저장 시 .ui 파일로 만들어집니다. 파이썬 프로그램 안에서 작동시키기 위해선 .py파일로 바꿔줄 필요가 있습니다. 변환 방법은 pyqt5 툴킷에서 제공된 변환기를 사용합니다.

UI 파일을 파이썬 파일로 변환
-> pyuic5 -x hello.ui -o hello.py

qrc 리소스 파일을 파이썬 파일로 변환
-> pyrcc5 hello_image.qrc -o hello_image_rc.py

이때 ui파일 뿐만 아니라 qrc파일도 .py파일로 변환해야 합니다. qrc 파일은 UI를 만들 때 사용했던 이미지가 저장된 파일입니다. 변환된 .py파일을 열어 보면 pyqt5문법을 활용해서 UI 코드가 변환되어 있습니다. 메인 코드에서 사용할 땐 import하여 불러옵니다.

7.5.1. GUI 작동 구조
절차적 프로그래밍과 다르게 GUI를 사용하는 환경에서는 GUI 따로 연산처리 따로 실행하는 쓰레드를 활용해서 프로그래밍 해야 합니다. GUI에 독립성을 부여해야 화면이 멈추지 않으며, 어떤 상황에서도 화면을 조작할 수가 있습니다. GUI 쓰레드를 기본적으로 동작하면서 필요시에 이벤트를 발생시킵니다. 이벤트 발생 시 GUI를 업데이트하는 함수만을 실행시켜서 화면을 수정하면 보는 이로 하여금 자연스러운 모니터링이 가능합니다.
이 후 부가적인 처리는 블루투스 통신과 GPIO를 이용한 혈압계 작동 파트입니다. 역시나 각각 개별로 쓰레드를 만들어서 작동시키고 화면을 갱신하는 방식으로 구현합니다.

7.5.2. 블루투스 소켓 통신
블루투스 통신을 위해 라즈베리파이에 제공되는 Bluetooth 라이브러리를 활용합니다. 기본적으로 소켓 통신을 기반으로 작성되었습니다. 매번 새로운 장치를 찾을 필요가 없기 때문에 사전에 알아두었던 체온계 블루투스 모듈의 주소 값을 지정합니다. 앞서 블루투스 통신 프로토콜에서 언급한 내용대로 전송 문자열의 앞의 문자는 정보의 종류를 뜻하며 맨 뒤 문자는 정보의 끝을 의미합니다.

아두이노와 통신 중에 모종의 이유로 데이터 중간에 개행 문자가 섞여서 전송되는 현상이 있었습니다. 수신된 문자열을 처리하기에 굉장히 까다롭기 때문에 “Z”문자를 한 개의 데이터를 구분하는 지점으로 지정하였습니다. 개행 문자를 기준으로 문자열을 나누지 않고 지정문자를 받을 때까지 모든 수신된 데이터를 차곡차곡 하나의 변수에 저장하였습니다.

이 후 통신 프로토콜에 따라서 수신된 데이터의 종류를 구분하고 실제 데이터만 추출하여 적재적소에 사용합니다.

온도와 RFID ID로 구분함. 또한 데이터를 추출한다.

7.5.3. DB 연동
환자정보 및 측정값은 내부저장소가 아닌 외부 클라우드 저장소를 사용합니다. 무료로 리얼타임 저장소를 서비스하는 firebase를 이용합니다. 저장소는 key와 val로 구성되어 있으며 초기화하는 방법과 데이터를 읽고 쓰는 방법은 관련 라이브러리인 pyrebase의 내장 함수를 참고합니다. 이는 git hub에서 찾을 수 있으며 데이터의 구성은 다음과 같습니다. 가장 상위 key는 RFID ID이며 아래에 이름, 성별, 나이 등 정보가 담겨 있습니다.

위 정보는 사전에 이미 기입되어 있습니다. 체온계에 RFID 카드를 태그하면 ID 값이 혈압계로 전송되고 이는 다시 firebase에 접근하여 관련 정보가 있는지 확인합니다. DB에 존재하는 id 값이라면 해당 환자 정보를 다시 혈압계로 전송하여 모니터에 표시합니다.

7.5.4. DB 자동 저장
사용자 경험을 고려하여 동작 순서에 따라 자동으로 측정값이 저장되도록 하였습니다. 모든 절차의 접근 key는 RFID카드의 ID를 사용합니다. 먼저 A 카드를 태그한 이후에는 몇 번이고 다시 측정할 수 있습니다. 체온계로부터 체온을 측정하고 혈압계는 라즈베리파이의 GPIO 기능을 사용하여 모터와 센서를 제어합니다. 혈압계 측정은 GUI화면의 버튼을 눌러 동작합니다. 측정이 끝난 후 B 카드를 태그하면 A를 측정했던 값이 자동으로 DB에 저장되는 방식입니다. 따라서 사용자는 자연스럽게 환자별로 인식표 태그 후 측정 순으로 진행하면 별다른 조작 없이 자동 저장되는 시스템을 설계하였습니다. 측정값은 날짜별로 묶고 다시 시간별로 묶어서 저장합니다.

7.6. 혈압계 케이싱
7.6.1. 3D모델링

5인치 디스플레이와 라즈베리파이를 고정하기 위해 적절히 배치하고 지지대를 세워 안정적으로 조립할 수 있도록 설계하였습니다.

또한 우측에 Dock을 배치하여 체온계를 거치하고 또한 중앙에 충전 단자를 위한 구멍을 내어 체온계를 단단히 고정함과 동시에 충전기능을 구현하였습니다.

7.6.2. 3D Printer 출력
설계한 모델링을 슬라이싱을 통해 G-code로 변환한 후 3D프린터로 출력합니다. FDM 방식의 프린터기를 사용했으며 재료는 PLA 흰색입니다. 크기와 구조 때문에 한 번에 모든 파트를 출력하는 것은 불가능하였습니다. 따라서 몸체, 덮개, 손잡이, 거치대, Dock으로 나누어서 출력 후 이어 붙이는 방식으로 제작하였습니다.

7.6.3. 후가공
후가공은 체온계 과정과 동일하게 퍼티와 락카 스프레이를 이용하여 표면 처리를 하였습니다.

7.6.4. 조립

체온계, 혈압계 프로그래밍 및 케이스 제작, 조립까지 마무리하였습니다. 혈압계의 디스플레이에 여러 가지 정보가 표시되며 터치를 통해 혈압계를 동작하거나 프로그램을 reboot할 수 있습니다. DB를 이용하여 정보를 불러오기는 물론 측정값을 저장할 수도 있습니다. 하지만 key와 val로 이루어진 DB그 자체로 정보를 열람하거나 처리하는 것은 상당히 불편합니다. 따라서 웹을 통해 DB에 저장된 정보를 보기 좋기 표시하는 벡엔드 파트를 구현하여 본 프로젝트를 마무리합니다.

7.7. 웹 모니터링 시스템

웹 모니터링을 위해서 플라스크(Flask)를 사용합니다. 플라스크(Flask)는 파이썬 웹 어플리케이션을 만드는 프레임 워크이며, Werkzeug 툴킷과 Jinja2템플릿 엔진에 기반을 둡니다. 플라스크는 프레임워크들 중에서 매우 심플하고 가볍지 만 중요하고 핵심적인 내용과 기능을 갖고 있기에 많이 사용되고 있습니다. 이 Flask를 통해 각 환자의 이름과 데이터를 구분하여 하나의 웹에 표기할 수 있도록 만듭니다.

7.7.1. DB에 저장된 데이터 불러오기
웹을 통해서 데이터를 띄우기 전 DB에서 데이터를 불러오는 작업을 수행합니다. 이렇게 DB에 환자의 RFID 카드를 통한 ID 값을 불러오게 되면 ID값 속에 저장되어 있는 모든 데이터가 불러집니다. 이를 통해 DB에 저장되어있는 모든 환자 데이터를 받아올 수 있습니다.

7.7.2. DB데이터 가공
불러온 데이터를 웹으로 불러오기 전 환자별로 날짜와 시간을 구분하여 데이터를 사용가능하도록 데이터를 가공합니다. 불러온 데이터는 Dict 형태로 모든 데이터는 원하는 데이터를 뽑아 가공하여 사용이 가능합니다. 이를 통해 각 리스트에 날짜와 시간, 시간에 따른 환자 데이터를 각각 모두 구분하여 데이터를 불러올 수 있습니다.

저장된 데이터를 Flask에 전달하여 웹상에 표시가 가능하도록 데이터를 넘깁니다.

7.7.3. 웹 디자인
웹디자인은 python Flask의 기본 웹 템플릿 엔진인 jinja를 사용합니다. jinja 템플릿 엔진은 태그, 필터, 테스트 및 전역을 사용자 정의가 가능해 자유롭게 사용이 가능합니다. 또한 디버그에 용이하며 최적의 python 코드로 컴파일이 가능하여 많이 사용됩니다. main코드에서 각 분할하여 각각 저장된 데이터를 불러와 웹으로 표현하기 위한 Flask의 html을 사용합니다. 상단의 이름과 함께 table을 나누어 데이터를 구분지어 데이터의 가시성을 더해줍니다.

7.7.4. 웹 데이터 추가
웹 main코드에서 가공한 이름, 날짜, 시간, 체온 등등 데이터를 각 테이블에 순차적으로 나열하게 됩니다. 이를 통해 DB에 저장된 데이터를 모두 날짜 시간순서대로 나열 가능하여 한눈에 확인 가능하도록 합니다.

이를 통해 여러 데이터가 생겨날 경우 같은 날짜에 대해 시간에 대한 측정값을 하나의 덩어리로 묶고, 날짜가 달라지면 그래프를 한 칸 밀어내어 데이터 구분을 지어 각 날짜별로 쉽게 확인이 가능합니다.

7.7.5. 웹 refresh를 통한 주기적인 데이터 업데이트

웹에 데이터를 추가한다고 하더라도 웹페이지는 실행된 시점의 하나의 장면만 보여주기 때문에 DB에 새로 추가된 데이터가 있더라도 웹상에 곧바로 표기되지 않습니다. 따라서 데이터가 추가되는 경우 바로 확인할 수 있도록 지정 초마다 웹 화면을 새로 고침 하여 데이터가 웹상에 반영되도록 합니다.

체온계, 혈압계에서 온 데이터를 저장한 DB에서 데이터를 다시 불러와 날짜와 시간에 따라 구분해 웹상에 정리하여 시각적으로 도출하며, 시간마다 새로 고침 하여 실시간으로 추가된 데이터도 바로 반영할 수 있도록 하였습니다. 이를 통하여 하나의 디바이스에서 지정된 ID를 통해 환자 데이터에 접근하여 상태를 측정한 데이터를 저장하고 저장된 DB를 통해 웹상으로 표기하여 주기적인 체온과 혈압의 데이터를 자동으로 저장 확인이 가능합니다.

8. 사용한 제품 리스트

9. 작품사진

9.1. 회로도

10. 소스코드
체온계 Arduino

혈압계 RaspberryPi

웹 모니터링(서버)

웹 모니터링(서버)

2021 ICT 융합 프로젝트 공모전 대상

딥러닝을 결합시킨 임베디드 기구 오목 AI : 베타오’

글 | 호서대학교 박정준, 김진우, 박정섭, 김선혁, 장서윤, 이성용, 이준용

1. 심사평
칩센 Vision을 활용한다고 했을 때 바둑판과 바둑돌은 매우 명확하게 구분이 가능한 환경이라 볼 수 있겠습니다. 따라서 작품의 완성도는 AI의 성능과 robot의 움직임을 포함한 성능이 될 것으로 보여졌습니다. 동영상 및 보고서상으로 확인한 바로는 프로파일을 LM 가이드로 움직임에 따라 상부에 설치된 카메라에 간섭이 자주 발생하게 되는 부분이 구조적인 아쉬운 느낌이 들었습니다. 향후 실제 경기용으로 적용을 하기 위해서는, 현재의 작품은 사람과 AI 데이터를 기반으로한 로봇간의 대결이나, 로봇간의 대결을 통한 머신/딥러닝 과정을 진행함으로써 쌓인 데이터 축적으로 난이도와 완성도를 높일 수 있을 듯합니다.

펌테크 딥러닝, AI로봇, 영상처리 등의 난이도가 있는 기술을 효율적으로 접목하여 기획의도에 맞게 시스템을 안정적이면서 완성도 높게 구현한 인상적인 작품으로 작품의 아이디어와 창의성이 돋보이며 전체적으로 기획의도, 기술 구현도, 완성도 등에서 상당히 뛰어나고 우수한 작품으로 생각됩니다.

위드로봇 영상처리, DNN 학습 및 응용, 로봇 제어가 모두 포함된 완성도 높은 작품입니다.

뉴티씨 요즘 핫이슈이고 AI를 배워서 나오게 되면 연봉도 많이 받을 수 있다고 하죠? 어딜가도 AI가 대세입니다. AI를 접목하고 CNC 등을 동작시켜 오목을 둘 수 있도록 한 아이디어가 참 좋습니다. 로봇도 학습하고 AI도 학습하고. 교육 목적으로도 참 좋은 작품 같습니다. 비슷한 기술로 생각해보면 카메라로 사진을 찍고, 그것을 영상처리하여 스케치한 것처럼 만들고, 그것을 그리는 로봇도 쉽게 만들 수 있을 것 같습니요. 수고많으셨습니다.

2. 작품 개요
제작 동기
로봇자동화공학과에 재학 중 ‘AI 인공지능과 AI 인공지능을 직접 눈으로 볼 수 있는 하드웨어를 구상하던 중 오목 AI와 오목을 둘 수 있는 하드웨어를 구상해보자’는 아이디어를 얻어 Omok AI 베타오를 제작하게 되었다.

제작 목적
알파고와 이세돌의 경기 후, 공학계에서는 인공지능의 중요도가 급부상했다. 하지만 교육적으로 임베디드에 AI를 활용한 사례는 극히 드물다. SW 교육과 AI 활용에 도움이 될 수 있는 AI 오목 게임 로봇이다.

작품 요약
Omok AI는 gomocup의 데이터를 이용하여 CNN 기반으로 최적의 다음 수를 둘 수 있는 AI이다. 이를 통해 openCV로 검은돌(사용자)가 돌을 둔 곳의 위치를 인식 받아 아두이노와 하드웨어가 3D 프린터, CNC 가공 기계와 같이 움직여 오목의 돌을 옮겨주는 로봇이다.

3. 작품 설명
작품 주요 기능
작품 주요 기능은 크게 하드웨어, 소프트웨어, 임베디드 시스템 3가지로 구성되어 있다.
하드웨어는 카메라가 고정되어 달리고 모터가 x, y, z 3차원 직교좌표계를 따라 움직이는 본체이다. 서보, 리니어, 스텝 모터 3종류를 제어해 3D 프린터와 비슷하게 일정 높이에서 돌을 이동시킨다. 이로써 플레이어가 손을 대지 않아도 컴퓨터와 게임에 참여할 수 있는 것을 확인할 수 있다.
소프트웨어는 크게 오목 경기를 화면 GUI상에서 확인하고 게임에 참여할 수 있도록 짜인 모듈의 집합체인 GUI 프로그램, 경기를 할 수 있는 Ai 학습 과정 전체에 대한 학습 코드, 파이썬과 아두이노를 통신, 아두이노를 제어하는 코드 세 가지로 나뉜다.
GUI 프로그램은 게임에 참여하는 플레이어가 오목 경기를 하는 도중 사용할 오목판 GUI의 색과 좌표, 돌의 크기 등을 속성값으로 변환할 수 있다. 또 오목의 룰을 정의해 게임의 승패 조건을 판단하고 정의한다. 이때 사용되는 오목의 룰은 Freestyle(자유룰)로 오목돌이 5개 이상 모였을 경우에 승리하는 룰을 사용한다.
학습 코드는 gomocup에서 2020년 결과 데이터를 얻어 CNN으로 학습한다. 오목 경기가 이루어진 수많은 데이터를 전처리해서, 컴퓨터-사람 간의 경기가 이루어질 수 있도록 게임의 룰을 이해하고 학습할 수 있도록 한다.
임베디드 시스템은 영상처리 과정을 거친 좌표값을 받아 하드웨어를 구성할 수 있는 제어 보드 및 프로세스이다. 모터제어를 위해 아두이노 우노를 사용해 시리얼 통신으로 PC로 좌표값을 보낸다. 메인 제어기인 아두이노 우노는 총 2개를 사용하며 각각 x축 스텝모터, y축 스텝모터와 리니어, 서보모터를 제어한다.

작품 활용 방안
카메라를 활용해 바둑판을 인식하고 원하는 좌표값을 받아 알맞은 위치에 돌을 두고, 오목 경기를 진행할 수 있도록 하는 작품이다. 실제 오목 경기를 연습할 수 있는 AI 심판을 제작하는 셈이지만, 임베디드에 AI를 적용시키는 프로젝트로써 관련 컨텐츠가 교재 및 강의와 함께 교육용 작품으로 활용할 수 있다.

3.1. 주요 동작 및 특징

3.2. 전체 시스템 구성
전체 시스템 구성도

시스템은 다음과 같이 구성되어있다. 하드웨어와 임베디드 시스템은 PC를 통해 영상 처리 결과 정보 및 좌표값을 시리얼 통신을 통해 수신받는다. 웹캠-PC간에 영상처리 정보 결과가 양방향으로 전달되며, 파이썬 IDE 파이참이 시리얼 통신을 통해 아두이노에 좌표값을 전달한다. 사람과 AI가 플레이를 하는 동안 파이썬은 지속해서 게임의 룰을 지키며 다음 돌의 최적의 위치를 예측하여 두게 된다. 최종적으로 위의 세 구성 요소가 상호작용함에 따라 시스템이 동작한다.

세부 구성도

세부 구성도는 [그림 4]와 같이 크게 HW, Embedded 시스템, PC/CAM, SW로 구성되어 있다.

하드웨어 구성도

Embedded system 회로도

소프트웨어

3.3. 개발 환경
소프트웨어
파이썬 IDE 파이참, 학습을 위한 jupyter notebook

모터 제어를 위한 Arduino IDE

개발 환경

Python 3.7.10 환경과 jupyter 가상환경 구축 및 실행

Tensorflow 2.4.0 version & GPU RTX 2060 SUPER

영상 인식(openCV)

아두이노와 파이참 통신

임베디드 시스템
임베디드 시스템 제작 시 준비물

하드웨어
사용 시스템 및 Tool
솔리드웍스, DP103, 3DWOX, 레이저 커터, 3D 펜 등을 가지고 작품을 제작하였으며 각각의 세부 설명은 다음과 같다. 솔리드웍스는 3D CAD 설계 Tool로 스텝 모터 고정 대, LM 가이드라인, 바둑돌 사출기, 스위치 고정 등에 사용되었으며 설계 파일 및 도면은 최종 원고에 사용한 자료에 포함되어 있다. 솔리드웍스의 버전은 Solidworks 2019 버전을 사용하였다.
3D 프린터는 Sindoh 사의 DP103을 사용하여 프린팅하였으며 stl 파일을 Gcode로 변환해주는 Tool은 3DWOX를 사용하였다. 또한 3D 펜을 사용하여 3D 프린터 출력물을 수정 보완하였으며 스위치 고정 지지대 출력 및 프로파일 고정대 출력 등에 사용하였다.

HW 제작 시 준비물

4. 단계별 제작 과정
하드웨어(컨셉 설계도 및 설계도)

초기 컨셉 설계도로 x, y축의 초기 설정과 베타오의 기본 베이스가 되는 설계도이다.

베타오의 최종 완성된 사진이다. 최종 완성되기까지의 과정은 아래와 같은 과정을 거처 진행된다.

사진과 같이 오목판의 크기를 측정하여 측정된 크기에 맞게 프로파일을 가공하여 연결한다. 모든 단계의 기초이자 가장 중요한 부분이므로 프로파일과 프로파일을 연결하는 알루미늄 다이캐스트 브라켓과 렌치볼트를 사용하여 단단하게 고정해야 한다.

y축이 x축 위에서 움직일 수 있도록 해주는 LM 가이드 라인을 프로파일과 연결할 수 있도록 설계한 것이다. LM 가이드의 수평과 고정을 동시에 고려하며 설계한 설계 부품이다. 스테인레스 재질의 LM 가이드 라인DMF 사용하려 계획했었지만, 프로파일과의 정교한 고정과 비용적인 측면에서 어려움을 겪어 기존에 있는 스테인레스 재질의 LM 가이드 라인을 역설계하여 베타오에 맞게끔 설계하였다.

스위치는 스텝 모터의 x, y축의 양단에 한계점의 신호를 받기 위해 2개를 장착한다. 각각의 스위치를 고정하는데 3D 펜을 사용하여 보다 정밀하게 제작하였다. 스위치의 위치가 바로 원점의 위치가 되므로 정밀하게 제작되어야 한다. [그림 50]와 같이 카메라를 고정하였는데 이는 openCV에서 바둑판의 전체를 인식 받아야 하기 때문에 중앙에 설치하게 되었다.

임베디드 시스템
아두이노 통신

리니어 모터와 서보 모터를 활용하여 z축의 바둑돌 사출기를 만들기 전 테스트를 위해 두 개의 모터만 따로 제어한 것이 [그림 61]이다. 리니어 모터를 통해 z축의 높이를 조절하며 서보 모터를 통해 바둑돌을 하나씩 바둑판으로 사출시킨다.

소프트웨어
알고리즘 및 코드 진행 과정

알고리즘 및 코드 진행 과정을 간략화한 순서도이다. 각 과정을 통해 학습된 결과와 그 학습된 결과를 활용한 오목 GUI와 openCV 영상처리를 통한 좌표값이 서로 상호작용하며 아두이노 제어 보드에게 좌표값을 정제하여 전달한다.

파이참 환경 및 외장 함수 import

numpy, glob, tqdm, os, ursina, tensorflow, pythonopenCV, serial 파이썬 외장 함수를 다운로드한다. 다운로드된 외장 함수를 이용하여 함수를 불러와 필요함수를 사용한다.

데이터 전처리 과정(데이터셋 생성 과정)

create_dataset.py를 실행하여 gomocup2020results 폴더에 저장 되어 있는 ‘.psq’ 파일의 데이터를 바둑판의 크기와 돌의 위치를 받아온다. 전처리하기 전 데이터를 위와 같은 ‘.psg’ 파일로 저장되어 있는데 Fastgame, Freestyle, Renju, Standard와 같이 게임에 적용되는 룰이 다양하다. 그 중 Freestyle과 같은 게임 룰을 가지고 데이터셋을 만든다. ‘.psq’ 파일 중 학습에 필요한 데이터만을 ‘.npz’파일로 저장한다.

openCV(영상 인식)
먼저 바둑알 사진을 불러온다. 불러온 사진을 이진화하여 노이즈를 제거한다. 다음으로 실시간 영상을 불러온다. 실시간 영상 또한 이진화 처리하여 노이즈를 최대한 줄인다. 그 후 검은색을 인식하기 위해 픽셀의 값이 임계값(threshold) 이하이면 하얀색으로, 일정값 이상이면 검은색으로 픽셀의 값을 바꾼다. 이 과정을 통해 검은 바둑돌만 검정색으로, 다른 배경은 흰색으로 칠한다. 그 이후 처음 불러왔던 바둑돌과 비교하여 임계값(threshold) 이상의 정확도를 가질 경우 그 좌표를 불러온 사진의 크기만큼 초록색 사각형(컨투어)을 칠한다. 또한 사각형의 중심에 파란색 점을 찍는다. 그 점 값을 전처리를 통해 기존 검은돌의 좌표를 저장한 배열에 존재하지 않을면 값을 추가한다. 또한 새롭게 추가된 좌표값만 출력한다.
[그림 75]과 같이 검은돌을 바둑판에서 인식받아 정해진 임계값에 따라 컨투어를 생성하고 좌표를 생성한다.

좌표값을 인식해서 gui상에서 돌을 둠

5. 작품 결과

6. 피드백 및 발전 방향
6.1. 피드백
베타오의 특징점은 PC가 사람과 직접 오목 게임을 플레이까지 할 수 있다는 점이다. 하지만 실제 경기에 활용할 수 있도록 하기 위해서 다음과 같은 부분이 해결되어야 한다.

난이도 조절이 필요하다.
학습 결과가 높을수록 컴퓨터가 이길 확률이 높기 때문에 정확도를 조절할 수 있는 학습 모델을 따로 생성해야 한다. .h5파일을 활용해 좀 더 낮은 수준의 인공지능을 적용할 수 있도록 수정할 예정이며, 경기에 적용했을 때의 난이도까지 테스트할 것이다.

33 규칙을 적용해야 한다.
실제 오목 경기에서는 한 번에 두 줄이 3, 3이 되는 경우는 이겼다고 규정하지 않는다. 승패가 무효가 되는 중요한 규칙이므로 이 점에 대해 보완할 것이다.

흑돌이 유리하다
오목은 확률론적으로 흑돌이 무조건적 우위를 선점한다. 현재 흑돌은 사람을 기준으로 선언되어있기 때문에 유저의 기호에 맞춰 턴을 바꿀 수 있도록 사전 UI를 구성하여 선택할 수 있도록 수정할 것이다.

6.2. 발전방향
1) 일반인이 직접 활용할 수 있는 딥러닝 교육용 제품으로 사용할 수 있다. 영상처리, 시리얼 통신, 임베디드 시스템, 딥러닝을 결합한 교육용 SW로써 각 분야를 하나의 시스템으로 구성하는 경험을 할 수 있다.
2) 자율주행 및 자동화 공정과 같은 실제 시스템에 응용해서 사용할 수 있다. 영상처리 기반으로 좌표 값을 추출하여 스텝 모터를 기반으로 정밀하게 좌표값 위치로 이동시킨다. 이는 정밀공정과 같은 다양한 시스템에 적용이 가능하다.
3) 오목 경기 연습 AI 및 학습 연구 대상이 될 수 있다. 또한 현재 개발된 모델과 매우 흡사한 바둑과 체스 등 다양한 시스템에 적용할 수 있다. 알파고의 출범 이후, 프로 바둑 기사들은 인공지능의 수와 흡사하게 두는 방법으로 실력을 키우고 있다. 이와 비슷한 맥락으로 본 프로젝트로 개발된 오목 AI도 오목 프로 기사를 양성하는 과정에서 사용될 수 있다.
4) 이벤트성 행사 및 공공일정에서 사용할 수 있다. 베타오는 소프트웨어가 하나의 압축 디렉토리로 송수신이 가능하기 때문에 하드웨어만 준비될 수 있다면 충분히 전시회 및 박람회에서 사용할 수 있는 행사 기구로 발전할 수 있다.

기술적 측면에서의 발전 방향
본 프로젝트는 기술적으로 크게 MUC 기반의 임베디드 제어 시스템, 바둑알을 인식하기 위한 영상처리, 오목 알고리즘 구현을 위한 CNN 기반 AI 등의 SW 부분과 리드 스크류, LM가이드를 이용한 오목 로봇의 좌표 이동, 리니어 모터를 이용한 바둑알 사출 시스템 등의 HW 부분으로 구분할 수 있으며 각 분야별 발전 방향은 다음과 같다.

소프트웨어
영상 인식
고사양 GPU를 사용해 처리 속도를 향상시킨다. 이는 영상 인식과 모델 생성 속도에도 영향을 주며 GPU의 성능에 따라 증가한다. 또한 사용하고 있는 openCV 정적라이브러리(static library)를 동적 라이브러리의 사용으로 변환하면 최소한의 프로그램 사용으로 같은 수준의 영상 인식을 사용할 수 있어 간단해진다.

오목 AI
생성된 모델을 모델로 학습하는 GAN(Generative Adversarial Network)을 사용한다. GAN을 사용하게 되면 생성 모델의 성능을 압도적으로 향상시킬 수 있다.

임베디드 시스템
컴퓨터와 메인 제어 보드를 함께 사용할 수 있도록 아두이노 우노를 라즈베리파이로 변경한다. 라즈베리파이 환경에 SW와 임베디드 시스템을 합쳐 베타오의 크기를 줄일 수 있다.

하드웨어
교육기관 도입 및 대량생산을 목표로 할 시, 하드웨어의 장치적 단순화 및 경량화가 가능해진다면 좀 더 유동적이고 용이한 작품으로 발전할 수 있다.

7. 사용한 제품 리스트

8. 참고문헌
· 미니츄어 LM가이드 표준 블록/경예압.”미니츄어 모델의 정확한 치수 “.https://kr.misumi-ec.com/vona2/detail/110302586530/?KWSearch=lm%ea%b0%80%ec%9d%b4%eb%93%9c&searchFlow=results2products.(2021.03.13)
· 라즈이노 iOT.”[ 아두이노 기초 ] #31 스텝(Step Motor)모터의 이해.”스텝모터의 원리”.https://rasino.tistory.com/149.(2021.03.17)
· a4988 스텝 모터 드라이버 알아보기 ( 스테퍼 / 스테핑 / 모터 / 드라이버 / 초퍼 모터드라이버 / 설정 ).”스텝모터의 정격전압과 회로 구성 방법”.https://m.blog.naver.com/PostView.nhn?blogId=roboholic84&logNo=221142584042&proxyReferer=https:%2F%2Fwww.google.com%2F.(2021.03.18)
· 아두이노로 NEMA17 스텝모터 제어하기, 스텝수 계산 (A4988 스텝모터드라이버).”스텝모터의 분주 제어방법”.https://blog.naver.com/chrkwlq1208/221562820510.(2021.03.25)
· 오목을 두는 인공지능을 만들어 겨뤄봤습니다.오목인공지능 구현 방법.https://www.youtube.com/watch?v=xigPAOl3v7I&ab_channel=%EB%B9%B5%ED%98%95%EC%9D%98%EA%B0%9C%EB%B0%9C%EB%8F%84%EC%83%81%EA%B5%AD(21.03.10)
· GOMOCUP.”전처리데이터 다운로드”.https://gomocup.org/.(21.03.12)
· [아두이노 -> 파이썬]시리얼 통신으로 문자열 보내는 방법].”파이썬에서 아두이노로 시리얼 통신하는 방법”.https://doomed-lab.tistory.com/4.(21.03.20)
· 정성환, 배종욱(2005).OpenCV-Python으로 배우는 영상 처리 및 응용.생능출판사

9. 소스코드
아두이노 하드웨어 X축 방향 구동 코드

데이터 전처리 코드

Execute_GUI.py

영상인식 코드

Omok.py

모델 학습 코드

2021 ICT 융합 프로젝트 공모전 최우수상

메타버스를 이용한 문서 보안 시스템

글 | 광운대학교 최예지, 최혁순

1.심사평
칩센 우선 Leap Motion과 unity을 통한 가상현실을 이용하는 것이 실제로는 처음 보고, 매우 흥미로웠습니다. 일반적인 실제 사용의 단계라면 어쩌면 번거로울 수도 있겠으나, 작품의 기획 의도인 강화된 보안이 필요한 경우에는 매우 유용한 기술로 판단됩니다. 다단계의 보안 단계를 만들고, AWS를 이용하여 떨어져 있는 다중의 사용자들 간에 보안 적용된 특정 정보 (작품에서는 문서)의 접근 권한을 만들어주는 것 또한 익숙하지 않은 저에게는 매우 놀라웠습니다. 세부적인 기술 내역에 대하여 저도 검토해봐야겠다는 생각이 드는 작품입니다. 다만 소프트웨어적인 구현만으로 이루어진 점은 개인적으로 조금 아쉽고, 동일한 보안 해제 방식을 통해 특정 목적을 가진 기기를 컨트롤할 수 있는 형태라면 기술의 범위가 충분히 확장될 수 있지 않을까 합니다.

펌테크 날로 중요시되는 컴퓨터 보안에 메타버스 개념을 접목한 독창적이고 색다른 형태의 작품으로 핵심요소인 소프트웨어 개발에 따른 각각의 SDK, 개발툴 등을 작품의 성격에 맞게 효율적으로 구성하였으며 전체적으로 작품의 기획의도, 기술 구현도, 완성도 등에서 우수한 작품이라고 생각됩니다.

위드로봇 Leap motion을 이용한 제스처로 보안을 처리한 아이디어가 돋보이는 작품입니다. 공모전의 성격을 감안하여 LeapMotion을 대치할 수 있는 기술까지 같이 연구가 진행되었다면 더욱 훌륭한 연구가 되었을 것 같습니다.

뉴티씨 매우 독특한 발상으로 잘 만들어진 작품입니다. 스마트폰에만 의존하는 보안 시스템에서 발전하여 Cloud server를 활용하여 보다 높은 수준의 보안 시스템을 구현한 예가 될 수 있습니다. 작품의 모양이나 시스템의 표현 방법이나 사용 방법 등을 대폭 개선하면, 좋은 제품으로 탄생할 수도 있을 것 같습니다. 아파트 현관이나 특정 사무실의 보안 시스템도 그런 식으로 만드는 것도 방법인 것 같습니다. 앞으로 기대가 됩니다.

2. 작품 개요
개인 휴대폰을 이용한 문서 공유, 개인 정보 저장, 신상 정보를 이용한 거래 등의 서비스들이 늘어나고 있다. 등본이나 각종 증명서, 회사 기업 자료 등 중요한 문서 파일을 휴대폰에 저장하기도 하고, 회원가입 정보나 여러 사이트의 비밀번호, 개인 정보를 휴대폰에 저장하기도 하며, 인터넷 뱅킹, 휴대폰 결제와 같은 개인정보를 이용한 서비스들을 휴대폰을 통해 사용한다. 이러한 휴대폰 속 개인정보를 이용한 서비스들과 휴대폰에 저장하는 개인정보, 주요 문서들이 늘어남에 따라 이를 악용한 범죄 또한 늘어나고 있다. 이러한 범죄에 우리가 노출됨에 있어 가장 큰 문제는 오직 핸드폰의 보안에만 의존하고 있다는 점이다. 휴대폰에 저장된 대부분의 주요 문서나 개인 정보가 오직 핸드폰의 보안 또는 어플 자체의 보안에만 의존하고 있다. 우리는 이러한 문제점을 인식하고 더욱 함양된 보안성을 갖춘 문서 보안 시스템을 구축하기 위해 메타버스를 이용해보기로 했다. 메타버스를 이용한 보안 시스템의 취약성은 아직 발견된 것이 없으며, 컴퓨터와 휴대폰 두 개의 디바이스를 이용하여 보안 시스템을 구축하기 때문에 더 높은 보안 장벽을 갖는다는 장점이 있다. 이러한 장점을 가진 메타버스 중 우리는 Leap Motion과 Unity를 이용해 시스템을 구축하기로 했다. Leap Motion은 손의 움직임을 인식하는 장치로 이를 이용하면 오직 손의 움직임만을 이용하여 잠금을 해제하는 보안장치를 만들 수 있기 때문에 잠금을 해제하는 기록을 데이터로 남기기 어려워 보안에 유리하다. 또한 Unity를 이용한 3D 가상현실을 만들어 여기에 Leap Motion을 적용한다면, 보안 장치를 사용하는 사용자가 아닌 이상 보안 장치 해제 방식을 파악하기 어려워 보안에 유리하다. 우리는 이러한 장점을 이용하여 Leap Motion, Unity를 이용한 메타버스 문서 보안 시스템을 제작하기로 했다.

3. 작품 설명
3.1. 주요 동작 및 특징
시스템은 Leap Motion을 이용한 1차 보안과 Unity와 앱을 이용한 2차 보안, 1차 보안과 2차 보안 사이의 서버 통신으로 이루어져 있다.
Leap Motion을 이용해 손의 동작을 감지하고 정해진 동작이 수행되면 웹 서버인 AWS DynamoDB로 동작이 수행됨을 알리는 정보가 넘어간다. 서버 통신을 통해 Leap Motion을 이용한 1차 보안이 해제됨을 감지한 AWS DynamoDB는 이 정보를 핸드폰에 설치된 어플로 넘긴다. 어플에서 정보를 받으면 Unity와 앱을 이용한 2차 보안이 실행되고, 2차 보안에서 정해진 순서대로 번호를 터치하게 되면 문서의 잠금이 해제된다.

Leap Motion을 이용한 1차 보안
Leap Motion에 정해진 동작을 수행하면 그 동작에 해당하는 마법진이 생성되고, 정해진 손짓을 통해 생성된 마법진을 뒤로 보낼 수 있다. 정해진 동작을 순서대로 수행하면 그 동작에 해당하는 4종류의 마법진이 순서대로 생성되고, 이 4종류의 마법진을 정해진 손짓을 통해 순서대로 뒤로 보내 circle에 통과시키면 보안이 해제된다. 이때 4종류의 마법진을 정해진 순서대로 circle에 통과시키지 않으면 보안 잠금이 해제되지 않는다.

그림 가-1과 같이 양 손을 pinch 후 떼어내면 마법진이 생성된다.

왼손 grab 후 오른손 pinch 한 번 할 때마다 object, 즉 마법진이 변경된다.

왼손 grab 후 오른손 흔들면 object, 즉 마법진이 앞으로 이동하다가 circle에 닿으면 사라지게 된다. 이때, 마법진 4종류가 정해진 순서대로 circle에 닿아야만 잠금이 해제된다.

Object, 즉 마법진은 계속해서 회전하고 있다.

코드 가-5에 의해 object, 즉 마법진이 circle에 닿으면 사라지게 된다. 또한 4종류의 마법진이 정해진 순서대로 circle에 닿아야만 보안이 해제된다.

1차 보안과 2차 보안 사이의 서버 통신

Leap Motion을 이용한 1차 보안이 해제됨을 알리는 정보가 AWS DynamoDB로 넘어간다. AWS DynamoDB는 받은 정보를 다시 2차 보안에 사용되는 앱에 넘기고, 앱은 정보를 받으면 보안 해제 시스템이 작동된다. 2차 보안 앱은 1차 보안이 해제되기 전까지는 실행되지 않고, 로딩창에 머무르게 된다. 1차 보안이 해제되었다는 정보를 넘겨받아야 실행이 되는 구조이다.
[그림 나-2]는 DynamoDB에서 leapmotion의 데이터가 초기설정 값인 0000이었지만, 1차 보안을 해제한 후 1234로 바뀐 모습이다.
private void Start() //AWS에서 계정에 대한 인증과 권한을 부여받는 코드이다.

Unity와 앱을 이용한 2차 보안
AWS DynamoDB로 전달된 1차 보안이 해제됨을 알리는 정보는 만들어둔 핸드폰에 전달된다. 정보를 받은 핸드폰은 앱을 실행시킨다. 실행된 앱에서 정해진 물체에 카메라를 가져가면 키패드가 생성되고, 생성된 키패드에 비밀번호를 순서대로 입력하면 2차 보안이 해제되어 문서를 열람할 수 있게 된다.

AR 키패드 화면으로 넘어왔지만, 지정된 물체를 비추지 않아, 키패드가 나타나지 않는 모습이다.

지정된 물체를 비추고 나서, 키패드가 나타나는 모습이다.

3.2. 전체 시스템 구성
위 시스템은 Leap Motion을 이용한 1차 보안과 Unity와 앱을 이용한 2차 보안, 1차 보안과 2차 보안 사이의 서버 통신으로 이루어져 있다.
Leap Motion을 이용해 손의 동작을 감지하고 정해진 동작이 수행되면 웹 서버인 AWS DynamoDB로 동작이 수행됨을 알리는 정보가 넘어간다. 서버 통신을 통해 Leap Motion을 이용한 1차 보안이 해제됨을 감지한 AWS DynamoDB는 이 정보를 핸드폰에 설치된 어플로 넘긴다. 어플에서 정보를 받으면 Unity와 앱을 이용한 2차 보안이 실행되고, 2차 보안 앱에서 지정된 물체를 비추게 되면 키패드가 나타나고, 키패드에 비밀번호를 입력하게 되면 2차 보안이 해제되면서 문서의 잠금이 해제된다. 따라서 키패드를 거치기 전, 지정된 물체를 알고 있어야 하고, 그것을 비추어야만 비밀번호를 입력할 수 있다는 점에서 2차 보안 속에 한 단계의 보조 보안단계가 더 있다고 볼 수 있다.

3.3. 개발 환경
위 시스템은 Leap Motion을 이용한 1차 보안과 Unity와 앱을 이용한 2차 보안, 1차 보안과 2차 보안 사이의 서버 통신으로 이루어져 있다. 먼저 Leap Motion을 이용한 1차 보안에서 Leap Motion과 Unity를 이용하며, 이를 위해 Leap Motion SDK와 개발 Tool로 Unity 2D, Unity 3D를 사용하였다. 또한 Unity 개발 언어로 C#을 이용하였으며 3D 가상 현실 환경을 구축하기 위해 Asset store를 사용하였다. 또한 개발 언어를 위한 Tool로 Visual Studio를 사용하였다. 다음으로 1차 보안과 2차 보안 사이의 서버 통신을 위한 시스템으로 AWS와 DynamoDB를 사용하였다. 마지막으로 App과 Unity를 이용한 2차 보안에서 App 개발과 보안 환경 구축을 위해 개발 Tool로 Unity 2D, Unity 3D를 사용하였다. 또한 Unity 개발 언어로 C#을 이용하였으며 3D 가상 현실 환경을 구축하기 위해 Asset store와 Vuforia를 사용하였다. 또한 개발 언어를 위한 Tool로 Visual Studio를 사용하였다.

Leap Motion을 이용한 1차 보안
생체 움직임 감지를 위해 Leap Motion을 사용하였으며, Leap Motion을 사용하기 위해 Leap Motion SDK를 사용하였다. Leap Motion 이용을 위한 증강 현실을 구현하기 위한 개발 Tool로 Unity 2D와 Unity 3D를 사용하였으며, Unity 개발 언어로 C#을 사용하고, 개발 언어를 사용하기 위한 Tool로 Visual Studio를 사용하였다. 3D 증강 현실 구현을 위해 Asset Store를 사용하였으며, AR엔진으로 Vuforia를 이용하였다.

1차 보안과 2차 보안 사이의 서버 통신
1차 보안에서의 정보를 서버로 옮기고, 서버에 저장된 정보를 다시 휴대폰 앱으로 전송하기 위한 웹 서버를 구축하였다. 이때 AWS를 사용하여 웹서버를 구축하였다. 웹 서버로 통신한 정보를 저장하기 위해 DynamoDB를 데이터베이스로 사용하였다.

Unity와 App을 이용한 2차 보안
증강 현실을 이용한 App 개발을 위한 개발 Tool로 Unity 2D와 Unity 3D를 사용하였으며, Unity 개발 언어로 C#을 사용하고, IDE로 Visual Studio를 사용하였다. 3D 증강 현실 구현을 위해 Asset Store를 사용하였으며, AR엔진으로 Vuforia를 이용하였다.

4. 단계별 제작 과정
시스템은 ‘Leap Motion을 이용한 1차 보안’과 ‘Unity와 앱을 이용한 2차 보안’, ‘1차 보안과 2차 보안 사이의 서버 통신’으로 단계를 나누어 제작하였다.

4.1. Leap Motion을 이용한 1차 보안
이 단계에서는 먼저 Leap Motion을 Unity와 연동시킨 뒤 Leap Motion의 동작 인식 감도를 확인하였다. 이후 Unity를 이용해 Leap Motion을 이용하기 위한 3D 가상 현실과 보안 시스템을 구축하였고, 가상 현실과 보안 시스템을 제어하기 위한 코드를 작성하였다.

그림 4-1-1과 같이 Leap Motion을 이용하기에 앞서 Leap Motion을 Unity에 연동시키고, Unity에서의 Leap Motion 작동 여부와 실제 작동 환경을 테스트하였다. 이후 Leap Motion의 손동작 인식 감도를 확인하였다.

다음으로 그림 4-4-2와 같이 Leap Motion이 사용되는 가상 현실을 Unity를 통해 구축하였다. 배경과 바닥을 3D object와 asset을 이용하여 구현했으며, 손동작에 따라 생성되고 작동될 3D object를 만들었다. 마지막으로 코드 3-1-가-1,2,3,4,5와 같이 Leap Motion에 감지된 동작에 따라 실행될 기능에 대해 코드를 작성하였다. 왼손 grab 후에 pinch 한 번 할 때마다 object가 바뀌고, 양손을 pinch 후에 떼면 object가 생성되는 코드, 왼손 grab 후 오른손을 흔들면 object가 앞으로 이동하는 코드, 양손 grab시에 object가 사라지는 코드, object가 회전하는 코드, object가 circle에 닿으면 사라지는 코드, object가 정해진 순서대로 circle에 닿으면 그 정보를 관리자 object에 전달하는 코드를 작성하였다.

4.2. 1차 보안과 2차 보안 사이의 서버 통신
이 단계에서는 먼저 1차 보안을 담당하는 노트북과 2차 보안을 담당하는 핸드폰 App사이의 서버 통신을 위한 웹서버를 구축하였다. 이후 노트북의 정보가 구축한 웹서버로 전달되는지 여부를 확인하였다. 다음으로 웹서버에 저장된 데이터 베이스가 휴대폰 App으로 전달되는지 여부를 확인하였다. 마지막으로 1차 보안이 해제됨을 알리는 정보를 웹 서버에 전달하고 웹 서버는 이를 데이터 베이스에 저장하여 2차 보안을 담당하는 휴대폰 App으로 전달하는 코드를 작성하였다.

그림 4-2-1과 같이 웹서버를 구축하였다. DynamoDB에 leapmotion 데이터가 저장되어 있는 모습을 볼 수 있다.

그림 4-2-2와 같이 1차 보안과 웹 서버 사이의 서버 통신이 원활하게 이루어지는지 확인하였다.

그림 4-2-3과 같이 웹 서버에 저장된 데이터 베이스가 2차 보안을 담당하는 휴대폰 App으로 잘 전달되는지 여부를 확인하였다. DynamoDB의 데이터 leapmotion의 정보를 잘 받았는지 확인하는 콘솔로그 창이다.
코드 4-2-1과 같이 1차 보안이 해제됨을 알리는 정보를 웹 서버에 전달하고 웹 서버는 이를 데이터 베이스에 저장하여 2차 보안을 담당하는 휴대폰 App으로 전달하는 코드를 작성하였다.

4.3. Unity와 App을 이용한 2차 보안
이 단계에서는 노트북에서 Unity를 이용하여 2차 보안의 가상 현실을 만든 뒤, 순서대로 정해진 비밀번호를 입력하면 문서 보안이 해제되는 코드를 작성하였다. 이후 제작한 App을 휴대폰에 복제하였다. 마지막으로 제작한 App이 구축한 웹 서버를 통해 1차 보안이 해제됨을 알리는 데이터 베이스를 전달하면 App이 실행되도록 하는 코드를 작성하였다.

그림 4-3-1과 같이 Unity를 이용하여 2차 보안에 사용할 가상 현실을 제작했다.
그림 4-3-2와 같이 앞서 노트북으로 만든 App을 휴대폰에 빌드하여 휴대폰으로 App이용이 가능하게 만들었다.

 5. 사용한 제품 리스트

‘Leap Motion을 이용한 1차 보안’과 ‘Unity와 앱을 이용한 2차 보안’, ‘1차 보안과 2차 보안 사이의 서버 통신’으로 나누어져 있다. 이 중 Leap Motion을 이용한 1차 보안 단계에서 Leap Motion Controller제품을 사용하였다.

6. 회로도
작품의 전체 회로도는 그림 6-1과 같다. Leap Motion과 노트북이 1차 보안을 위해 연결되어 있으며, 2차 보안인 휴대폰 App과 웹 서버를 통해 연결되어 있다.

7. 소스코드
7.1. Leap Motion을 이용한 1차 보안 코드
Leap Motion Hand model 코드

Leap Motion New Behavior 코드

Leap Motion 관리자 object 코드

7.2. 1차 보안과 2차 보안 사이의 서버 통신 코드
Leap Motion 서버 통신 director 코드

7.3. Unity와 App을 이용한 2차 보안 코드
서버와 통신을 하는 direc코드

입력한 비밀번호를 확인하는 director 코드

어떤 키패드가 눌렸는지 확인하는 interaction1 코드

8. 참고 문헌
[1] https://bit.ly/3wcnOow
[2] https://bit.ly/2QNPyjk
[3] https://bit.ly/31u0aWz
[4] https://amzn.to/39rTzQU
[5] https://bit.ly/3wfrber
[6] https://amzn.to/3dneDJx
[7] https://bit.ly/31y7Abi

2021 ICT 융합 프로젝트 공모전 최우수상

LoRa 통신 기반의 오픈소스 IoT 플랫폼을 활용한 스마트 공원 관리 : 스마트 파크(Smart Park)

글 | 숭실대학교 김성호, 이경주, 이하늘

1. 심사평
칩센 사용한 센서의 용도, 센싱 된 데이터의 전송 방법인 LoRa 무선 통신, 컨트롤을 위한 시나리오 등등이 모두 IoT 센서 솔루션을 위한 구성이 잘 되어 있는 듯합니다. 또한 목적 사용자와 적용 환경에 대한 부분도 타겟을 명확히 하여 개발의 목적과 필요한 조건의 한도를 구분한 기획 의도가 돋보입니다. 센서 환경 변화에 대하여 알림이 발생하였을 때 메일로 발송하여 확인하기 보다는 서버로 직접 전송하여, 관리 시스템의 UI 등으로 즉시 보여주면 더 좋았을것 같습니다.

펌테크 실용성, 아이디어, 창의성이 아주 돋보이는 작품으로 LoRa 통신을 기반으로 스마트 공원관리에 꼭 필요한 핵심적 요소를 효율적이면서도 최적의 시스템으로 구현했으며 전체적으로 작품 기획, 기술 구현도, 완성도 면에서 상당히 뛰어나고 훌륭한 작품이라고 생각됩니다.

위드로봇 다양한 센서와 IoT 적용에 유리한 테마파크를 현장으로 설정하여 구현한 재미있는 작품입니다.
뉴티씨 매우 훌륭한 작품입니다. 실용화가 가능한 아이디어라고 생각되며, 디자인만 좀 개선하고 프로그램 등을 좀 개선하면 좋은 제품이 될 수 있다고 생각합니다. 공원에 적용하면, 환경미화원님들이 편리하게 이용하여, 깔끔하면서도 꼭 필요할 때만 환경미화원님들이 쓰레기를 비우고, 자동으로 공원의 식물에 물을 줄 수 있고, 가로등도 제어할 수 있어서, 매우 좋은 시스템으로 생각됩니다.

엔티렉스 부설연구소 오픈소스를 이용하였지만, 시스템 구성에 맞게 시설물관리(쓰레기통, 통행량에 따른 조도 제어등)을 제어하며 관리를 할 수 있으며, 네트워크를 이용하여 여러 개의 공원을 관리할 수 있게 개발을 진행했던것 같습니다. 전체적으로 공원관리에 맞게 개발이 잘 이루어져 있으며, 웹을 통해서 사용자가 육안으로 쉽게 관리할 수 있을 것 같습니다. 그리고 시제 제작 데모를 이용하여, 각 기능을 잘 구현 하였으며, 데이터 수집 등을 잘 처리한 것 같습니다.

2. 작품 개요
2.1. 배경 및 목적
급격한 도시화, 인구 밀집, 자산 및 자원 낭비 등 도시화로 인해 발생하는 각종 문제에 대응하기 위해 도시 패러다임으로 ‘스마트 시티’가 등장하였다. 그중 행복의 질에 큰 영향을 미치는 도시 공간 중 하나인 공원은 ‘스마트 파크’로 진화하고 있다. 스마트 파크는 다양한 첨단 기술을 활용하여 이용자의 공원 체험 향상, 공원 운영·관리의 효율성을 높이며 도시가 직면한 사회 및 환경문제를 해결하는 지속 가능한 공원이다.
스마트 파크의 국내 사례로 대구에 도입된 ‘IoT See Park’는 4차산업혁명 핵심기술을 공원에 접목하여 인공지능 CCTV, 전역 무료 WiFi, 스마트 휴게시설(태양광 벤치), 스마트 방향 표지판 등의 서비스를 제공하고 있다. 또한 세종시 호수공원에는 체험존 AR(GPS 기반 방향 안내 앱）, VR 체험관 등 AR/VR을 사용한 공원 체험 향상 관련 서비스를 제공한다. 이처럼 대부분의 스마트공원은 이용자 중심 공원 서비스 제공에 초점이 맞춰져 있다. 반면에 스마트공원 관리 측면에서는 서비스 구축이 미비하다. 이에 본 작품은 관리를 목적으로 한 IoT 중심의 지능형 스마트 공원관리시스템인 스마트파크를 구현하였다. 스마트파크는 공원 내 시설 및 자연생태환경에 대한 관리를 웹을 통해 손쉽게 할 수 있고, 공원관리에서 수집되는 정보를 바탕으로 데이터 시각화를 제공한다.

2.2. 오픈소스 IoT 플랫폼 개선 및 활용
스마트파크은 스마트 공원의 센서 데이터를 수집, 전처리, 관리, 시각화, 데이터에 따른 명령수행 등의 기능이 있다. 이를 구성하기 위해 본인이 참여했던 IoT 오픈소스를 스마트파크을 위한 기능 및 서버를 추가·개선하여 사용하였다.

데이터 수집
Kafka를 사용하여 스마트 공원의 센서 네트워크로부터 방대한 양의 센서 데이터를 수집할 수 있도록 하였다. 수집한 데이터를 전처리 서버로 보내기 위한 브로커 역할을 한다.

데이터 전처리
서버 프레임워크로 제작한 서버를 이용하여 데이터 전처리, 로직 검사 작업을 수행한다. 센서 데이터의 등록정보(공원이름, 서비스이름 등등) 추가 및 현재 데이터가 등록된 명령(액추에이터 동작, 이메일전송 등등)수행 조건을 만족하는지에 대한 검사하는 역할을 한다.

관리 및 시각화
전처리된 데이터를 NoSQL데이터 베이스인 ElasticSearch에 저장하여 관리한다. 수많은 센서 데이터값이 계속해서 추가되므로 Write 기능에 강점을 가진 데이터 베이스를 선택하였다. 또한, Kibana를 사용하여 ElasticSearch에 저장된 데이터들을 분석, 시각화할 수 있도록 하였다.

2.3. 스마트파크 IoT 플랫폼으로 관리하는 3가지 스마트 기기(센서노드)
본 프로젝트에서는 인체감지를 통해 보행량에 따른 밝기 조절이 가능한 스마트 가로등 관리, 쓰레기통 적재량 확인·알림, 센서를 이용한 수목 관리 등 IoT 중심의 지능형 스마트 공원관리시스템인 스마트파크(Park)를 구현하였다.
스마트파크에서 활용이 가능한 스마트 기기 총 세 가지를 제작했다.
구현한 세 가지 스마트기기는 모두 공통적으로 LoRa통신을 한다. LoRa는 LPWAN(저전력 장거리 무선통신)기술로, LoRa통신을 통해 저전력으로 광범위한 통신을 가능하게 했다. LoRa의 데이터 전송속도가 빠른 편은 아니지만, 공원 관리를 위해 이용되는 센서 데이터들은 실시간 처리보다는 아주 천천히 변화하는 센서 데이터들이며 장거리 통신이 요구되기 때문에 LoRa통신은 본 공원관리 시스템에 적합한 통신이다.

스마트 가로등
크게 세 가지 기능이 있다.
(a) 평균적으로 보행자 수가 많은 시간대에 밝기를 밝게 하고 적은 경우에는 밝기를 낮춤으로써 전력소비를 줄일 수 있다
(b) 자동 점소등 시스템이 가능하다. 가로등 상단 부분에 장착된 조도센서를 통해 어두워질 경우 자동으로 점등이 가능하다.
(c) 부점등 알림 기능이 있다. 가로등 하부(바닥) 부분에 부점등 확인을 위한 조도 센서가 장착되어 가로등이 켜져있는 밤에 조도센서(바닥 위치)에서 받은 값이 어두운 값이면 조명이 제대로 안 켜진 상태로 자동적으로 판단하여 관리자에게 알림을 줄 수 있다.

쓰레기 관리
스마트 쓰레기통 관리의 경우에는 쓰레기통의 적재량을 주기적으로 알 수 있으며, 로직 등록 기능을 통해 쓰레기가 많이 쌓이면 이메일과 같은 알림을 줄 수 있다. 쓰레기통에 쓰레기가 완전히 채워지기 전에 미리 알림을 주어 쓰레기 수거에 도움을 줄 수 있다. 따라서 공원의 더 나은 청결을 기대할 수 있다.

스마트 수목 관리
수목 관리의 경우, 토양센서를 통해 토양의 수분을 측정하고 수분이 부족하면 수중모터를 통해 물을 주도록 한다. 로직 등록 기능을 이용한 자동화로 공원의 수목 관리를 더 편리하게 할 수 있다는 장점이 있다.

3. 작품 설명
3.1. 주요 동작
스마트 쓰레기통
공원 내 비치된 쓰레기통의 적재량 정보 파악
쓰레기통에 쓰레기가 가득 차면 쓰레기통을 비워주기 위해 알림을 줄 수 있다.
쓰레기통의 적재량은 쓰레기통의 뚜껑에 부착된 초음파 센서를 통해 거리를 탐지하여 알 수 있다. 이를 통해 얻은 값은 LoRa통신을 통해 LoRa Gateway로 전송된다. LoRa Gateway는 네트워크 서버(싱크 노드)로 전달을 해주어 최종적으로는 백엔드 서버로 값이 전달된다.

적재량 모니터링 및 알람
쓰레기통의 적재량을 모니터링하며 일정 수준 이상의 쓰레기가 쌓이면 쓰레기가 넘치기 전에 쓰레기를 수거할 수 있도록 알림을 줄 수 있다. 사용자는 프론트엔드 웹에서 직접 조건을 추가하여 적재량이 몇 프로 이상일 경우에 이메일과 같은 알림을 주도록 설정이 가능하다.

데모
다음은 쓰레기통 전면이다.

위 사진은 뚜껑 내부에는 초음파 센서가 부착된 모습이다. 거리 측정으로 적재량을 판단한다.

위는 쓰레기통 적재량 변화값을 시각화한 그림이다. 이와 같이 각 공원 쓰레기통의 적재량을 한 눈에 확인할 수 있다.

쓰레기통 적재량이 90프로 이상일 경우, 이메일을 전송하도록 로직을 등록한 것이고 그림 6은 이메일 수신 화면이다.

마트 가로등

보행자 통행량 측정
시간별/요일별/계절별/지역별 유동인구 측정 및 분석을 하여 유동인구가 많은 가로등만 점등하여 에너지 절약할 수 있다. 결과적으로 유동인구에 따라 가로등의 밝기를 조절하여 에너지를 절약한다.

PIR 센서를 통한 통행량 측정
유동인구(보행자 통행량)은 가로등에 PIR 모션감지 센서를 부착하여 지속적으로 움직임을 감지한다. 모션 감지가 오랫동안 일어날수록 유동인구에 대한 누적값이 증가한다. 이와 같은 방법으로 센서노드에서 얻은 모션감지의 수치를 백엔드 서버까지 전달하게 된다.

데모
가로등 유동인구에 따른 밝기 조절
다음 사진과 같이 가로등의 상단 부분 LED 옆에 PIR 모션 감지 센서가 부착되어 있다. 모션 감지 센서에서 움직임이 감지되는 시간이 증가할수록 통행량에 대한 값이 증가하게 된다.

방문자 수 변화

위 그림은 방문자 수 데이터를 시각화한 자료이다. 직접 센서로 측정해 테스트하고 있는 sangdo의 방문자 수 변화를 볼 수 있다.

위는 보행량에 따라 led 밝기 조절 로직이다. 스마트파크(park)에서는 실질적인 데이터를 수집할 수 없기에 value 범위를 임의값으로 설정하였고, 실제로는 대시보드에 나타난 방문자 수를 참고하여 value 범위를 설정해야한다.

보행량에 따른 밝기 조절

위와 같이 유동인구에 따라 가로등 LED 밝기가 달라진다.

가로등 부점등 검사 (고장 알림)
가로등 하부의 조도 센서를 통해 가로등의 전구의 조도를 측정 후 LED ON이어야 하는 상태에서 조도가 측정되지 않으면 가로등이 부점등 상태임을 이메일로 알린다.

그림 14는 부점등 상태일 경우 이메일을 전송하도록 로직을 등록한 것이다. illuminance는 가로등 상단에 있는 조도센서(낮과 밤 판별)의 데이터이고, Lampilluminance는 가로등 하부에 위치한 조도센서(부점등 판별)의 데이터이다. 이때 조도센서의 값이 90 ~ 100 이하라면 어두운 것으로 판단한다. illuminance < 90 인 경우 LED가 ON되어야 하고, 이때 LED는 아래의 조도센서를 향해 빛을 쏘기 때문에 Lampilluminance는 LED 불빛을 감지해 100 이상이어야 한다. LED가 정상적으로 켜지지 않아 Lampilluminance의 값이 100 이하라면 부점등 상태로 판단한다. 따라서 0 < illuminance < 90 이고 0 < Lampilluminance < 100일 때 부점등 상태라 판단해 이메일을 보내도록 로직을 등록했다. 오른쪽 그림은 어두운 상태에서 LED가 정상적으로 켜졌으나, 가로등 하부 조도센서를 손으로 가려 부점등 상태를 조성한 것이다.

밝기에 따른 가로등 자동 점·소등

밝을 경우에는 로직에 등록된 LED 액추에이터 명령을 통해 LED가 자동으로 꺼지고, 어두울 경우 액추에이터 명령을 통해 자동으로 켜질 수 있도록 로직을 등록했다.

가로등 상단의 조도센서를 통해 어두워지거나 밝아질 경우 자동 점/소등한다.
두 번째 그림에서 볼 수 있듯이 밝을 경우 LED를 OFF하고, 세 번째 그림에서 조도센서를 가려 인위적으로 어두운 환경을 만들었을 때 LED가 ON되는 것을 확인할 수 있다.

스마트 수목 관리
온도, 습도, 토양 등 측정센서 설치 및 생장 환경 관련 데이터 측정한다. 공원 내의 수목주변의 온도와 습도, 일조량, 토양내 습도 등을 측정 분석하여 알릴 수 있다. 실외의 온도와 습도 일조량, 등을 컨트롤하기는 힘들어 보이므로 모니터링 및 알림 기능을 통해 관리를 도울 수 있다.

관수 기능 자동 제어
토양 센서를 이용해 습도를 측정하여 필요할 경우 관수 시설을 제어하는 기능을 갖고 있다.
토양 수분 센서를 이용하여 토양의 수분이 부족할 경우 액추에이터 명령을 통해 수중모터(펌프)를 작동시켜 토양에 물을 준다. 센서노드는 토양 수분 센서의 값을 일정 주기로 게이트웨이로 전송한다. 센서 데이터는 센서노드 -> 게이트웨이 -> 싱크노드 -> 백엔드 순으로 전달된다.

데모

첫 번째 그림에서 볼 수 있듯이 수중모터 제어를 위해 액추에이터로 pump를 등록했다. 토양수분 값이 일정 값 이상이면 사용자가 등록한 액추에이터 값에 따라 수중모터가 동작하도록 로직을 등록했다.
백엔드는 토양수분 센서가 일정 값 이상인지 조건을 확인하여 조건에 부합하면 액추에이터 신호를 싱크노드에 전달하여, 싱크노드->게이트웨이->센서노드 순서로 액추에이터 명령이 전달된다.

왼쪽 사진은 등록된 로직에 따라 사용자가 설정한 범위 내 습도값이 해당될 시 액추에이터를 작동시켜 수중모터로 물을 공급하는 모습이다. 오른쪽은 토양수분을 그래프로 시각화한 자료이다.

데이터 시각화
의미가 없거나 혹은 단순한 의미만을 지닌 데이터로부터 실시간으로 의미있는 정보를 찾는 것 자체가 가치를 창출하는 일이다. 스마트파크는 단순한 센서데이터 들을 이용해 여러 가지 의미 있는 정보를 대시보드에 시각화 하였다.

공원 검색기능
원하는 기간, 원하는 공원을 선택하면 선택된 데이터만을 필터링하여 볼 수 있다.

공원 별 센서값 시각화 보드
공원의 모든 센서값을 시각화한 보드를 통해 센서값의 비교 및 확인하여 공원 별 기상정보 비교분석이 가능하다.

공원 별 방문자 수 비교 분석 기능
공원 별 방문자 수 데이터 시각화를 통해 비교 분석이 가능하다. 각 공원 별 방문자 수를 한 눈에 알아볼 수 있고, 어느 시간대, 어느 요일에 유동량이 많은지를 쉽게 알 수 있어 이를 이용해 방문자 수에 따른 가로등 제어, 공원 내 행사 일정 선택 등 다양한 방면의 활용이 가능하다.

공원 별 쓰레기통 적재량 비교분석 기능
원하는 공원의 쓰레기통 적재량을 실시간으로 체크할 수 있으며, 요일 날짜별 쓰레기통 적재량을 한 눈에 볼 수 있어, 쓰레기통 추가 배치, 수거 등에 유용한 활용이 가능하다.

서비스 유지보수의 용이
IoT서비스 플랫폼에서 지속적으로 안정적인 서비스가 제공되기 위해서는 센서를 비롯한 하드웨어들의 헬스 체크가 필요하다. 스마트파크에서는 서비스 노드의 헬스 정보를 수시로 체크하여 웹 UI상에 나타내 주므로 헬스 정보 확인이 가능하며 문제 발생 시 빠른 유지보수가 가능하다.

유연한 확장성
플랫폼의 운영자가 스마트파크이 관리할 새로운 공원을 하거나, 새로운 IoT서비스를 추가할 경우 웹상에서 몇 가지 조작만으로 공원 및 서비스 등록이 가능해, 유연한 확장성을 보여준다.

3.2. 주요 특징
UI에서 IoT 디바이스 관리, 데이터 시각화

네비게이션 바

MANAGEMENT 탭의 구성요소로 Sensor, Node, Sink, Actuator가 있다. SERVICE 탭의 구성요소로 LogicCore가 있다. 사용자는 LogicCore에서 로직을 등록할 수 있다. Kibana 탭의 구성요소로 Dashboard가 있다. Dashboard에서 데이터 시각화를 제공한다.

등록(register)

센서 : register sensor 버튼을 클릭하면 그림 33과 같이 등록 페이지가 나타나고, 사용자는 센서 정보 (센서 이름, 종류, value)를 입력해 센서 등록을 할 수 있다.

싱크 : register sink를 클릭 후 싱크 정보 (싱크 이름, topic, ip:port)를 입력해 싱크를 등록할 수 있다. 스마트파크(park)에서는 싱크를 한강 공원 단위로 설정해 진행하였다.
노드 : 노드 등록은 그림 32와 사진과 같이 노드 이름, 위치 (지도를 클릭하면 해당 위치의 위도 경도를 얻음), 노드의 종류(가로등, 쓰레기통, 수목), 해당 노드에서 사용할 센서, 싱크를 선택해 등록할 수 있다.

이때 노드는 가로등, 쓰레기통, 수목을 의미한다.
액추에이터 : register actuator를 클릭 후 액추에이터 이름을 입력해 등록할 수 있다. 본 프로젝트에서는 토양 습도를 토대로 관수 제어를 하기 위한 pump 액추에이터와 조도에 따라 led 밝기를 조절하기 위한 led 액추에이터를 등록하였다.
각 정보를 입력후 submit 버튼을 클릭하면 센서, 싱크, 액추에이터, 노드의 정보를 서버로 POST한다.

table

센서, 싱크, 액추에이터 : 위와 같이 사용자가 등록한 센서, 싱크, 액추에이터의 정보를 table의 형태로 확인 가능하고, 휴지통 img를 클릭하여 삭제할 수 있다.

노드 : 노드는 table을 볼 수 있는 두 가지 옵션 (All, Map)이 있다.

· All 옵션 : default로 설정되어있는 노드 table이며 사용자는 싱크별 노드 table을 볼 수 있다. 스마트파크(park)에서는 한강 공원별 가로등, 쓰레기통, 수목 노드가 table로 나타나 있다.

· Map 옵션 : 마지막 사진과 같이 지도상에서 마커 형태로 노드 위치를 나타낸다. 각 노드의 종류가 마커 이미지로 구분되어 있고, 마커를 클릭하여 해당 노드의 정보를 볼 수 있다. 이때 사용자는 지도를 움직이며 마커 위치를 확인할 수 있다. 마커 이미지 색상은 가로등 : 파란색 / 쓰레기통 : 노란색 / 나무 : 초록색이다.

· 노드 헬스체크 : 사용자는 색상별로 노드의 상태를 확인할 수 있다. 웹 소켓으로 서버와 통신하기 때문에 실시간으로 확인이 가능하다.

· 노드의 상태

회색 : 알 수 없는 상태
초록 : 연결된 상태
노랑 : 직전에 연결이 끊긴 상태 (초록과 빨강의 사이)
빨강 : 연결이 끊긴 상태

로직코어 (LogicCore)

· Logic 등록 : 사용자는 LogicCore table에서 register logic 버튼을 클릭해 로직을 등록할 수 있다.

Logic 정보

· 로직 이름
· 센서 : 센서에 로직 등록
· 시간 범위 : 해당 로직이 작업을 수행할 시간 설정
· value 범위 : 해당 로직이 동작할 value 설정
· action :  사용자가 설정한 시간과, value 범위 내 센서값이 해당할 때 실행할 작업
◎ email : 해당 이메일로 알림 메시지 발송
◎ actuator : value, sleep 값을 받아 해당 액추에이터 작동
register logic에서 각 요소(시간, value, action)를 카드라 할 때 value 카드와 action 카드는 왼쪽 하단 Add ~ 버튼을 통해 추가할 수 있고, value 카드와 시간 카드는 Add scope 버튼을 통해 범위를 추가할 수 있다.
· Logic table : 아래 왼쪽 사진과 같이 등록한 logic을 table의 형태로 볼 수 있고, 휴지통 img를 클릭하여 삭제할 수 있다.
· Show logic : table에서 show logic 버튼을 클릭하면 아래 오른쪽 사진과 같이 로직의 구조를 볼 수 있다.

이처럼 스마트파크(park)은 웹에서 센서, 노드, 싱크, 액추에이터를 등록하고, 사용자 맞춤 로직을 생성할 수 있기에 스마트공원 관리에 용이하다.

kibana dashboard

home 또는 kibana dashboard 메뉴를 통해 시각화된 데이터 확인이 가능하다.

LPWAN 통신 방법인 LoRa 통신, 직접 구현한 LoRa WAN 프로토콜로 작동
날씨 상태, 토양 수분 레벨 또는 가로등과 같이 이러한 응용 분야에서 측정되거나 제어되는 크기/양은 모두 확장된 시간 범위에 걸쳐 매우 느리게 변화한다. 또한, 센서 노드가 서로 멀리 떨어져 있는 경우가 많고 배터리로 구동되는 경우가 많으므로, 최적의 무선 프로토콜은 최소한의 전력 소비로 긴 거리에 걸쳐 작은 데이터 패킷을 효율적으로 전송할 수 있어야 한다.
따라서 대표적인 LPWAN(저전력 무선 장거리 통신) 기술 중 비면허 대역 주파수를 이용하는 LoRa 통신을 선택했다. 1Ghz 이하의 대역은 다른 주파수에 비해 서로 간섭력이 낮아 무선 파장 및 효율적 측면에서 좋기 때문에 원거리 통신을 위해서 적합하다. End-Device(센서노드)와 LoRa 게이트웨이, 싱크노드를 구현하여 LoRaWAN 프로토콜을 따르도록 구현했다. End-Device의 LoRaWAN 프로토콜은 C언어로 구현하였으며, LoRa Gateway의 LoRaWAN은 Python으로 구현했다. LoRaWAN의 모든 Mac Command가 구현된 것은 아니지만 필요한 몇가지 Mac Command가 작동하도록 구현했다. DevStatusReq와 DevStatusAns의 Mac Command를 통해 센서노드의 배터리와 수신신호의 수치를 파악할 수 있다. 또한 RFU의 예약된 공간에는 ActuatorReq와 ActuatorAns의 Mac Command를 구현하여 이 명령을 이용하여 액추에이터 작동이 가능하도록 했다. Actuator는 백엔드 서버에서 오는 명령을 End-Device에서 처리하는 기능을 말한다. 예를 들면 백엔드에서 모터를 작동시키거나 LED의 밝기를 조절하는 등의 명령을 센서노드에 전달할 수 있다.

백엔드 서버 특징
5G 시대가 도래하면서 IoT(사물 인터넷) 관련 데이터의 가치가 더욱 커질 전망이다. IoT 기술의 특성상 수많은 데이터와 로그를 빠르게 적재, 분석하는 것이 필수적이다. 스마크파크는 Kafka – DataLogic서비스 – ElasticSearch로 데이터 파이프라인을 구성하여 방대한 센서 데이터의 준 실시간 처리가 가능하다.

3.3. 전체 시스템 구성

3.3.1. 프론트엔드
컴포넌트 구조

위 그림은 컴포넌트 구조를 간단히 map으로 표현한 것이다, App에서 모든 컴포넌트를 route한다.

· ‘~ Management’ : sensor, node, sink, actuator를 관리하는 컴포넌트이다. 각각의 resigter 컴포넌트를 호출해 정보를 등록하고, 각 table 컴포넌트에서 해당 list를 table 형태로 출력한다.
· Register Logic : 로직 등록 컴포넌트이다. 하위 컴포넌트 InputCards에서 사용자가 입력한 time, sensor, value, action, actuator card의 정보 넘겨주고 이를 바탕으로 로직을 등록한다.
· LogicTable : 등록된 로직을 list로 나타내는 컴포넌트이다.
· showLogic : logic table에서 show logic을 클릭할 시 호출되는 컴포넌트이다. 하위 컴포넌트 showCards에서 사용자가 등록한 정보를 가져와 해당 로직의 정보를 출력한다.
· kibanaDashboard : 데이터 시각화를 제공하는 컴포넌트이다.

3.3.2. 백엔드
데이터 파이프라인
개요

그림 48처럼 센서데이터가 라즈베리파이(Sink Node, 공원)에서 최종 저장소로 바로 전송되는 경우 라즈베리파이 내에서 측정값과 등록정보(metaData)를 모두 관리해야 하기 때문에 센서 네트워크에 매우 큰 부담을 준다. 또한 스마트파크의 매우 많은 라즈베리파이가 하나의 저장소로 데이터를 전송하는 경우 Elasticsearch에게 매우 높은 가용성과 처리량을 요구하게 된다.

따라서 그림 49와 같이 우리는 최종 저장소 이전에 데이터를 처리할 수 있는 DataLogic서비스를 추가하였다. 센서 네트워크에서는 측정값과 각 Node의 고유ID만 관리하고 DataLogic서비스에서 데이터 처리 서비스(데이터에 등록정보를 추가)를 지원한다. 해당 서버는 측정값을 이용해 등록된 이벤트를 처리하는 기능도 지원하는데, 이는 다음에 설명하겠다.

여러 공원의 데이터 값을 하나의 데이터 처리 서비스로 전송하는 것 또한 데이터 처리 서비스에 너무 많은 부담을 준다. 그렇다고 여러 개의 데이터 처리 서비스를 구현하기에는 구성이 너무 복잡해지며, 특정 서버에 요청이 몰릴 경우 몇몇 요청은 처리하지 못하고 누락될 수 있다.
따라서 센서네트워크와 서버 사이에 Kafka를 배치해주었다. Kafka는 데이터를 임시로 저장하는 Queue역할을 하며 기본적으로 클러스터 환경을 제공하여 높은 처리량과 고가용성을 보장한다. DataLogic서비스는 자신이 필요할 때만 Kafka에 데이터를 요청하기 때문에 과부하로 문제가 될 가능성이 배제된다.

구성

Kafka
producer – Broker(Kafka) – Consumer 구조의 스트림 처리 플랫폼이다. 여러 공원으로부터 데이터를 저장받아 임시저장한 후 DataLogic서비스에 안정적으로 데이터를 제공한다.
라즈베리파이에서 카프카로 전송되는 데이터의 예시는 오른쪽 그림과 같다.

DataLogic
서버 세부설명 파트에서 자세히 설명한다.

엘라스틱서치
방대한 센서데이터를 지속적으로 저장하기 위해서 Write능력이 뛰어난 데이터 베이스가 필요하다. 따라서 Write 효율에 중점을 둔 NoSQL데이터베이스인 Elasticsearch를 데이터 베이스로 사용하였다.
Elasticsearch에 준 실시간으로 저장된 센서 데이터는 비교/분석을 위한 시각화와 공공데이터 배포를 위해 사용된다.

Kibana
Paul Brunet의 InfoWorld 칼럼에 따르면 요즘 시대는 더 많은 데이터에 접속할 수 있는 상태지만, 이런 수많은 데이터에서 효과적으로 인사이트를 획득하는 능력은 감소했다고 한다. 이제 우리가 고민해야 할 지점은 ‘데이터를 어떻게 잘 활용할 것인가?’이다. 많은 양의 데이터를 한눈에 볼 수 있고, 데이터 분석에 대한 전문 지식이 없어도, 누구나 쉽게 데이터의 패턴을 알아낼 수 있도록 시각화된 데이터 대시보드를 구현하였다.

서버 상세설명

서버 아키텍쳐
클린 아키텍처를 적용하여 특정 계층에 대한 수정이 다른 계층에 거의 영향을 주지 않도록, 그리고 같은 계층 내에서는 일관되고 응집력 있는 결합을 제공할 수 있도록 서버의 계층을 구분하였다. 상당히 분량이 많은 앱이더라도 소스코드 전반을 쉽게 파악할 수 있고 복잡한 수정 사항이 생겼을 때라도, 어떤 부분들을 고치면 되는지 금방 파악할 수 있도록 하였다.

Application – Registration
개요
등록 정보를 관리하기 위한 API Server이다. 프론트엔드에서 등록한 메타데이터, 로직데이터 등을 백엔드의 데이터 베이스에 저장하고, 이 데이터 베이스를 읽어서 프론트엔드, DataLogic, HealthCheck 등의 서비스에 정보를 제공 및 컨트롤하는 역할을 수행한다.

구성
모든 서비스는 이용자가 어떤 기능을 요구하거나, 개발자가 어떤 아이디어를 생각해내 서비스를 확장시켜야 하는 상황이 생기기 마련이다. 이때를 대비해 유연하게 확장이 가능하도록 서버를 구성하여야 한다. 스마트파크의 모든 서버는 각 기능 단위로 서비스를 만들어 큰 서비스를 구성하는 방식인 마이크로 서비스 아키텍처로 구성하였다.

기능
스마트파크를 구성하는 마이크로 서비스들을 컨트롤하는 역할을 한다. Registration은 센서 데이터 스트림 처리를 담당하는 마이크로서비스(DataLogic)와 센서 데이터 스트림 노드(아두이노)의 헬스 상태 처리를 담당하는 마이크로서비스(HealthCheck)에게 등록정보를 제공한다. 이후 등록정보의 변경이 발생할 경우에도 마이크로 서비스 들에게 등록 정보를 제공해준다.

DB

스마트파크의 데이터베이스는 위 사진과 같이 스키마가 정의되어있다. 싱크 노드, 센서 노드 등의 메타데이터를 구조적으로 저장 및 조회한다. 데이터베이스로 쓰인 애플리케이션은 mySql이다.

LogicCore – DataLogic
DataLogic서비스는 Kafka에서 데이터를 읽어온 뒤 등록정보를 바탕으로 메타데이터를 추가한다. 보강된 데이터를 기반으로 사용자가 지정한 이벤트의 처리동작과 Elasticsearch로의 데이터 저장을 수행한다.

등록정보 추가

DataLogic서버는 처음 실행될 때 Registration 서버에 등록정보를 요청한다. Registration서버는 요청한 DataLogic서비스를 자신의 서버 내에 등록한 후 서버 내 DB에 저장된 Sink node와 Sensor node의 등록정보들을 반환해 주고 DataLogict는 이 등록정보를 서버의 메모리 내에 보관한다.
DataLogic서비스가 실행되고 있는 도중에 등록정보가 변경될 경우 Registration서버는 업데이트된 정보를 등록된 모든 DataLogic서비스에게 알려주어 등록정보를 동기화할 수 있도록 한다.

센서 데이터마다 적절한 메타데이터를 얻기 위해 DataLogic서비스에서 DB에 접근할 수 없기 때문에 등록정보를 메모리에 동기화시킨다. 이후 Kafka에서 읽어온 센서 데이터에 sensor-id, node-id에 해당하는 메타데이터를 추가한다.

이벤트 처리
수집한 센서 데이터에서 프론트엔드에서 유저가 미리 지정해둔 특정한 이벤트를 검사하기 위한 기능이다. JSON 형식의 센서 데이터의 특정 필드 값을 기준으로 조건을 검사하는 filter기능과 actuator동작신호 전송, Email전송 등 특정 이벤트를 수행하는 action기능으로 구성되어있다.

Elastic search저장

DataLogic서비스 내에서 수많은 (보강된)센서 데이터들이 생성된다. 이 데이터 하나당 Indexing(Write) API를 호출하면 네트워크에 과부하가 걸리므로 이를 방지하기 위해 데이터를 효율적으로 저장하여야 한다.
따라서 저장할 데이터를 적재하다가 특정 byte 이상이 쌓이면 한 번에 Bulk Indexing(배치 처리)하도록 구현하였다. 또한, Elastic search의 Sharding기능을 통해 자체적으로 쓰기 성능을 향상시켰다.

HealthCheck

그림 60과 같이 수많은 노드의 정상 작동여부와 배터리 잔량을 전송받아 각 노드의 헬스 상태를 결정한 후 헬스 상태가 변경된 노드의 헬스 정보와 배터리 잔량을 프론트엔드로 전송하는 역할을 수행한다.
먼저 라즈베리파이로부터 연결된 모든 아두이노의 상태 정보를 bool 형태로 전달받는다. 전달받은 상태정보를 이용해 헬스 정보를 업데이트한 후 그림 61과 같이 헬스 정보가 기록된 Map 자료구조에 저장한 후, 업데이트 내역이 있는 아두이노의 헬스정보를 추려내어 웹소켓을 통해 프론트엔드로 전송한다. 배터리 잔량은 받은 값을 그대로 전송한다.

헬스 정보 업데이트 기준은 전달받은 상태정보와 가장 최근의 상태를 위 사진과 같은 기준으로 비교해서 결정한다.

3.3.3. 도커(Docker)

플랫폼 서비스는 고객(서비스 운영자)이 플랫폼의 모든 실행 환경을 손쉽게 사용자의 환경으로 가져올 수 있어야 한다. 이를 위해 스마트파크의 모든 서버는 도커 컨테이너 위에서 실행가능하게 도커 이미지로 변환하여 배포한다. 도커 컨테이너(단일 컨트롤 호스트 상에서 여러개의 고립된 리눅스 시스템들을 실행하기 위한 운영 시스템 레벨 가상화 방법)를 이용하면 서버 환경을 재구축하는 부가적인 작업 없이 개발 당시의 환경(라이브러리, 설정값, 종속성 및 파일)을 로컬에서 애뮬레이션할 수 있다. 다시 말해 큰 수정 없이 어느 환경에서든 모든 서버가 작동되도록 배포할 수 있다.

3.3.4. 센서 네트워크(NodeMCU-Raspberry Pi-싱크노드)
백엔드에 데이터가 도달하기 전까지의 상세구조 그림

오픈소스 사용 (Flask와 MQTT통신 설명)
싱크노드-Flask 사용
싱크노드가 웹서버를 운영함으로써 서버로부터 HTTP요청을 받을 수 있다. 서버는 특정 싱크노드에 HTTP 요청을 하여 액추에이터 명령을 내리게 된다. 싱크노드(네트워크 서버)에서 웹서버를 운영하기 위해 Flask 오픈소스를 이용했다.

Paho MQTT Client 사용
IoT 통신은 경량화와 유연성을 갖추어야 한다. 여러 통신 방법 중 MQTT는 M2M, IoT를 위한 프로토콜로서, 최소한의 전력과 패킷량으로 통신하는 프로토콜로 IoT통신에 적합하다. MQTT 통신을 위해서는 Paho client 오픈소스를 이용했다. 따라서 우리는 게이트웨이와 싱크노드간에 Mosquitto 브로커와 MQTT 통신을 이용해서 경량화된 통신을 이용한다.

LoRaWAN 프로토콜 이용
Class A와 C
LoRaWAN 프로토콜에는 세 가지 A, B, C 클래스의 디바이스 유형이 있다.
센서 네트워크에서 끝단에 위치한 센서노드들의 클래스를 이 세 가지 A, B, C 유형 중 하나를 지정하여 사용하게 된다. 현재 구현하여 이용이 가능한 센서노드의 클래스는 A와 C 두가지다.
A Class 통신 방식은 LoRa Device와 LoRa Gateway 사이에서 LoRa Device가 Gateway에게 메시지를 전송한 이후, 잠시 동안 두 번에 걸쳐 메시지 수신이 허용되는 방식이다. 송신하기 전에는 송신과 수신 모두 동작을 하지 않다가 송신이 진행되면, 그 순간에 잠시 동안 두 번에 수신 윈도우를 허용할 기회를 제공한다. 즉 A Class는 수신을 위해서 송신이 진행되어야 하며 송신 위주의 서비스에 주로 사용된다. 상시전원을 사용하지 않고 배터리로 운영하는 경우에 사용되기 때문에 가장 적은 전력을 사용하는 Class이다.
C Class 통신 방식은 수신 가능 상태를 유지하기 위해 다른 Class에 비해 최소 지연시간을 갖는다. 송신 시간을 제외하고는 수신을 계속 대기하는 상태가 지속되므로 세 가지 Device Class 중에서 가장 많은 전력을 소비한다. 그 때문에 충분한 전력 공급이 가능한 상황에서 이용되는 Device Class이다. 대부분의 순간 수신상태를 유지하기 때문에 수신이 중요한 서비스(예를 들면 Actuator 기능 및 원격제어)에 이용된다.

OTAA 활성화 방법(Join과정 및 암호화 방법)
새로운 최종 장치 (LoRa 장치)가 LoRa 네트워크에 추가되려면 활성화 프로세스를 거쳐야 한다. LoRaWAN 프로토콜에는 ABP 통신과 OTAA통신 두가지 활성화 방법이 존재한다. 현재 OTAA모드를 기준으로 작동되도록 구현되어있다.
센서노드가 가입 요청 메시지를 보내 가입 절차를 시작한다. 참여 요청에 DevEUI, AppEUI 및 DevNonce가 포함된다. DevEUI 및 AppEUI는 각각 Global End Device 및 Application Identifier를 나타내며 IEEE 나타내며 EUI-64 주소 공간 형식을 따른다. 우리 프로젝트에서는 센서노드의 EUI 주소값은 Arduino 코드에 하드코딩하여 지정한다. Join 활성화 과정에서는 App Key를 이용하여 AES-128 암호화하며, NwkSKey와 App_SKey가 활성화 과정으로 인해 생성된 이후에는 이 둘 중 하나를 이용하여 메시지를 AES-128 암호화한다.

위 그림은 OTAA모드 활성화 프로세스 과정을 나타낸다. AppKey는 최종 장치와 서버간에 미리 공유되는 Key값이다.

왼쪽 그림은 Join Request 메시지의 구조이다. End Device는 다음의 요청을 보낸다.
Join Request 메시지는 암호화되지 않는다. Dev Nonce는 엔드 장치에서 랜덤하게 생성된 값으로 이전에 수신한 요청의 DevNonce 값과 중복되는 Dev Nonce의 요청은 받아들이지 않아 공격을 방지한다.
오른쪽 그림은 Join Accept 메시지의 구조이다. 메시지를 App Key로 AES-128 암호화한다.

메시지의 프레임 구조

구현한 MAC Command
LoRaWAN은 다음과 같은 Mac Command, Command ID를 갖도록 되어있다. DevStatusReq와 DevStatusAns 명령을 이용하여 End-Device의 배터리 수준과 SNR 수신 신호 상태 값을 얻을 수 있다.
우리 프로젝트에서는 RFU 영역인 CID 0x0E를 액추에이터 작동을 지시하는 명령(ActuatorReq, ActuatorAns)으로 따로 구현하여 사용하도록 했다.

Network Server(Sink Node) 동작 및 기능
데이터 전송
싱크노드는 여러 게이트웨이에서 mosquitto 브로커를 통해 mqtt통신으로 들어온 센서노드별 데이터를 취합하여, 이를 백엔드 측의 데이터 큐인 Kafka로 전송해주는 역할을 한다.

헬스체크를 위한 센서노드 상태체크 명령 전달
또한 센서노드들의 상태를 체크하는 것은 IoT플랫폼의 기능에 있어서 필수적이다.
싱크노드에서는 주기적으로 센서노드들에게 DevStatusReq요청을 보내도록 “command/downlink/ActuatorReq/<센서노드ID>”토픽으로 MQTT 메시지를 발행하여 게이트웨이에서 센서노드들에게 DevStatusReq Mac Command를 전달하도록 한다. DevStatusAns을 정상적으로 답장한 센서노드들의 상태를 “정상”으로 판단하고 이를 백엔드의 헬스체크 서버에 알려준다.
이러한 상태 체크 과정에서 배터리 상태와 SNR 수신 신호에 대한 정보를 알 수 있으며, 백엔드 서버에는 각 센서노드의 상태와 배터리 수준을 함께 알려준다.

액추에이터 명령 수신 및 게이트웨이로 전달
백엔드 서버로부터 오는 명령으로 LED 또는 모터들을 제어할 수 있어야 한다. 싱크노드에서는 백엔드로부터 오는 명령을 Flask 웹서버에 들어온 HTTP요청으로 수신한다.
Flask 웹서버로 수신한 HTTP 액추에이터 요청을 json 데이터와 함께 수신하면 싱크노드는 이를 “command/downlink/ActuatorReq/<센서노드ID>”토픽으로 MQTT 메시지를 발행한다. 센서노드 측에서는 명령을 받기 위해 “command/downlink/+/<센서노드 ID>”를 구독했기 때문에 MQTT프로토콜을 통해 액추에이터 명령을 받을 수 있다.

3.4. 개발 환경
3.4.1 개발언어 및 라이브러리

3.4.2. 포트 포워딩

4. 단계별 제작 과정
4.1. 센서네트워크 구축
4.1.1. 싱크노드 구현
싱크노드의 메인코드에서의 동작 순서이다.

1. Flask 웹서버 실행
2. Kafka Producer 생성
3. mqtt 클라이언트 생성
4. HealthCheck를 담당, 관리하는 클래스 생성
5. Actuator관련 동작을 담당하는 클래스 생성
6. MQTT Callback함수 등록 및 MQTT Client의 Loop 시작
7. HealthCheck를 위한 TCP 소켓 생성
8. 쓰레드 생성->쓰레드 핸들러로 HealthCheck를 담당하는 함수 등록
9. 헬스체크 쓰레드 시작

4.1.2. NodeMCU LoRa 연결
사용하는 LoRa 모듈(SX-1278)의 Pin 구성은 다음과 같다.

ANT에는 안테나를 연결한다. SCK는 SPI-Clock Input을 담당한다. MISO는 SPI-Data Out을 담당한다. MOSI는 SPI-Data In을 담당한다. NSS는 SPI-Chip Select를 담당한다.
LoRa 통신 모듈과 NodeMCU간의 연결은 다음의 표와 같다.

나머지 디지털 핀과 아날로그 핀들은 센서나 LED, 모터제어를 위해 사용한다.

4.1.3. NodeMCU
LoRaWAN 코딩
NodeMCU의 LoRaWAN은 https://git.antares.id/lorawan-loraid/arduino-loraid의 코드를 뼈대로 하여 개선하였다. (지원가능한 주파수 채널 확장, MacCommand처리기능 추가, 수신이 되지 않는 문제 수정.)

다음은 LoRaWAN통신 코드이다.

현재 타이머 시간과 과거에 측정한 타이머 시간이 interval보다 크다는 것은 interval만큼 타이머 시간이 흘렀다는 것을 의미한다. 따라서 interval만큼의 시간을 주기로 하여 메시지를 송신하는 것이다.
QOS 변수는 사용자가 설정하는 값으로 1이상일 때, ACK를 수신해야지만 다음 새로운 메시지를 전송하도록 한다. QOS==0 이라면, ACK 수신여부와 관계없이 새로운 메시지를 계속 전송한다.
앞으로 센서노드는 위 LoRaWAN 통신코드를 베이스로 한다. 센서, 액추에이터에 대한 코드를 이 코드에 추가하여 가로등, 수목관리, 쓰레기통을 구현한다.

4.1.4. 싱글채널 게이트웨이 제작과정
기존의 LoraWAN 게이트웨이를 국내에서 접하기는 어렵게 되어 있어서 접하기 쉽도록 라즈베리 파이를 이용한 싱글채널 게이트웨이를 직접 구현하기로 했다.
LoRa 통신을 가능하게 해주는 LoRa 통신 모듈을 연결하기 위해 왼쪽 사진과 같이 납땜 작업을 했다. 오른쪽 사진과 같이 안테나를 통신 모듈에 연결하고 각 핀을 라즈베리파이에 연결했다.
Lora 모듈과 라즈베리파이는 아래와 같이 연결했다.

4.1.5. LoRa 게이트웨이(라즈베리파이) LoRaWAN 코딩
게이트웨이의 LoRaWAN 프로토콜을 다음과 같이 구조화하여 파이썬으로 구현했다.

LoRaWAN 프로토콜 전체적인 코드 구성
다음은 Python으로 구현한 LoRaWAN프로토콜의 라이브러리 구조이다.
· AES_CMAC.py: AES-128 암호화를 위한 함수들을 정의했다.
· CID.py: Mac Command들의 Command ID를 정의했다. MacCommand처리를 위한 함수들을 정의했다.
· Channel.py: 사용할 주파수 채널을 선택할 수 있도록 채널에 대한 정보들을 정의했다.
· DataPayload.py: 데이터 페이로드(FRM Payload)를 처리하기 위한 클래스와 메소드를 정의했다.
· Direction.py: Mac Header(MHDR)의 각 메시지들이 어떤 방향으로 향하는 메시지인지 정의하는 클래스와 메소드이다. (UP: 센서노드->게이트웨이 / DOWN: 게이트웨이->센서노드)
· FHDR.py: Frame Header에 대한 클래스와 메소드를 정의한다.
· JoinAcceptPayload.py: JoinAccept에 대한 메시지를 생성하거나 읽기 위한 Payload 처리코드
· JoinRequestPayload.py:JoinRequest에 대한 메시지를 생성하거나 읽기 위한 Payload처리코드
· LoRaMAC.py: 작업 상태를 정의하는 코드. (수신상태, 송신상태, 대기상태)
· MHDR.py: Mac Header 정보들을 정의하는 클래스와 메소드
· MacCommandPayload.py: MacCommand를 Frame Payload에 넣어서 전달하기 위한 코드
· MacPayload.py: Mac Payload를 생성하거나 읽기 위한 코드
· MalformedPacketException: 패킷 예외 처리에 대한 코드
· PhyPayload.py: Physical Payload를 생성하거나 읽기 위한 코드

LoRa WAN 프로토콜 코드 주요동작 순서
일반적인 데이터 수신과 송신의 Payload 처리는 다음과 같은 순서로 동작한다.
PhyPayload.py->MacPayload.py->DataPayload.py (주요 코드 순서, 다른 코드는 생략) : 전원이 켜진 센서노드는 네트워크에 접속하기 위해 주기적으로 JoinRequest 신호를 전송한다.
JoinRequest를 수신하게 되어 읽는 경우에는 다음과 같은 순서로 동작한다. : PhyPayload.py->MacPayload.py->JoinRequestPayload.py
JoinAccept를 송신하는 경우에는 다음과 같은 순서로 동작한다. : PhyPayload.py->MacPayload.py->JoinAcceptPayload.py
MacPayload를 송신하는 경우에는 다음과 같은 순서로 동작한다. : PhyPayload.py->MacPayload.py->MacCommandPayload.py

센서노드(NodeMCU)와 게이트웨이간 LoRa통신 확인

위와 같이 센서노드와는 LoRaWAN통신을 하고 싱크노드와는 MQTT 통신을 한다.

4.1.6. 헬스체크 구현
헬스체크는 센서노드의 상태를 체크하는 기능이다. 싱크노드(네트워크 서버)는 LoRaWAN 프로토콜의 Mac Command인 DevStatusReq를 센서노드로 주기적으로 전송하게 한다. 이를 주기적으로 처리하기 위해 HealthCheck 담당 쓰레드를 하나 만들어서 주기적으로 게이트웨이에게 명령을 전달해주고 TCP소켓을 열어 백엔드 측의 헬스체크 서버와 통신하도록 했다. 센서노드로부터 DevStatusAns의 응답을 정상적으로 수신하면 센서노드의 상태를 정상으로 판단하고 그렇지 않으면 불량으로 판단한다.

4.1.7. 액추에이터 구현
센서노드가 액추에이터 명령인 ActuatorReq를 수신하면 받은 액추에이터 ID를 타켓으로 동작시켜야 한다. 액추에이터 명령 패킷은 다음과 같은 Payload를 갖는다.
명령 메시지 구조 : Actuator ID, Sleep, Value, Sleep, Value, …
Actuator ID는 동작시킬 액추에이터의 ID를 의미한다.(각각의 액추에이터는 자신의 ID를 갖는다.)
Sleep은 액추에이터에 값을 넣어 실행시키기까지의 대기시간을 의미한다.
Value는 액추에이터를 동작시키기 위한 값을 의미한다.
아래는 액추에이터를 관리하기 위한 Actuator 구조체 정의부이다.

위에서 받은 액추에이터 명령 메시지를 위와 같은 구조체에 입력하여 관리하게 된다.

액추에이터에서 delay가 발생하더라도 LoRa통신에는 영향이 없도록 하기 위해 다음과 같이 루프문과 타이머를 이용하는 구조로 코드를 작성했다. 위의 코드에서 interval은 대기시간이다. previousMillis는 전에 저장한 타이머 시간을 의미한다. Millis() 함수는 현재 타이머 시간을 의미한다.
즉, 위의 코드는 타이머 시간을 측정하여 interval에 저장된 시간만큼 지났을 때, if문 내부의 코드가 실행되는 구조이다. 액추에이터 동작 함수에도 LoRa에 지장이 가지 않도록 하기 위해 위의 구조를 적용했다.
액추에이터의 경우 각자의 구조체 안에 자신만의 대기시간을 저장하는 interval 변수를 갖도록 하여 개별적으로 동작할 수 있다.

4.1.8. 가로등 제작 과정

먼저 가로등의 뼈대가 되는 모형에 4×2 LED를 부착하고 LED의 밝기를 조절했다. LED의 밝기는 analogWrite()함수로 아날로그 신호를 주면 조절할 수 있다. 위 사진과 같이 밝기 조절을 테스트했다.
다음으로 보행자 통행량을 측정하기 위한 PIR모션센서를 테스트했다. PIR 센서를 다음과 같이 LED 옆에 부착하고 NodeMCU와 연결하여 테스트했다.

일정 간격의 시간동안 모션이 감지되면 위와 같이 Welcome!이 출력된다.
보행자 통행량 측정에 이 PIR 센서를 활용하기 위해서 주기적으로 이 모션이 감지되는 횟수가 얼마나 많은지 카운트를 누적하여 누적한 카운트 값을 백엔드 서버에 전해준다.

위는 바닥과 상단에 부착된 조도센서 사진이다. 왼쪽 사진은 부점등 확인을 위해 조도 센서를 가로등 바닥부분에 부착하였다. 기판에 저항과 cds센서를 납땜하여 연결했다. 오른쪽 사진은 밝기를 측정하기 위해 상단에 조도 센서를 부착하였다. 상단의 조도센서는 밤에 자동 점등, 아침에 자동 불을 끄기위해 달았다.

아날로그 핀에 연결하여 조도 센서값을 확인했다.
다음은 가로등 센서노드의 메인 코드이다.

세 가지 부품(LED, PIR센서, 조도센서)과 LoRa SX1278 모듈을 NodeMCU와 연결하고 위의 코드로 데이터가 잘 전달되는지 확인한다. LED 밝기 조절을 위해 LED를 액추에이터로 등록하여 액추에이터 ID를 2번으로 설정해주었다.

4.1.9. 수목관리 시스템 제작 과정

먼저 시연을 위해 다음의 화분을 준비하였다. 토양수분을 측정하기 위한 센서를 NodeMCU보드와 연결이 편하도록 다음과 같이 기판에 부착하였다. NodeMCU는 LoRa통신 모듈과 연결돼있다.

물을 주기 위해서는 수중모터와 수중모터를 제어하는 L9110s 모터드라이버를 사용했고, 수중모터를 LoRa통신으로 제어할 수 있도록 액추에이터로 등록했다. 코드 부분에서는 수중모터를 제어하기 위한 Actuator 구조체를 선언했다.
액추에이터 신호가 왔을때 수중모터가 작동하여 물을 주는 것을 확인했다. 다음은 수목관리 센서노드의 코드이다.

4.1.10. 쓰레기통 제작 과정

다음과 같이 뚜껑에는 초음파 센서를 접착제를 이용해서 부착하였다.

Echo Pin은 디지털 핀 D1에 연결, Trig Pin은 디지털 핀 D3에 연결했다.
다음은 쓰레기통 센서노드의 메인코드이다. 초음파 센서로 측정한 적재량 백분율 계산, LoRa통신 기능을 한다.

수직으로 쓰레기통 바닥을 향해 거리를 측정하여 값이 작아질수록 쓰레기가 쌓인 것이다.

하지만 이 거리값을 cm단위로 그대로 전달하지 않고 적재된 양을 100분율로 계산하여 서버에 전달한다. 계산은 다음과 같다. (쓰레기 적재량 데이터의 단위는 %.)
Value = (쓰레기통 바닥까지의 거리 – 측정된 거리) / (쓰레기통 바닥까지의 거리) * 100

4.2. 데이터 스트리밍 시스템 구축
4.2.1. Data Logic 서비스
Kafka에 적재된 데이터를 DataLogic서비스로 consume후 Unmarshal하여 DataLogic내의 구조체에 저장할 수 있도록 consumer를 생성한다.

메모리에 저장되어있는 등록정보를 데이터에 추가 할 수 있도록 한다.

해당 센서값이 설정된 이벤트 조건을 만족하는지 검사한다. 로직을 만족할 경우 이벤트를 실행한다.

등록정보가 포함되어 완성된 데이터를 엘라스틱 서치에 인덱싱 한다.

4.2.2. Health Check 서비스
각 Sink로부터 헬스 정보를 받는다.

받은 헬스 정보 중 변경 사항이 있는 노드의 헬스 정보만을 버퍼에 추가하여 웹소켓을 통해 front-end로 보낼 수 있도록 한다.
버퍼에 담긴 헬스 정보를 프론트 엔드로 전송한다.

4.3. 웹 프론트 환경 구축
4.3.1 노드 마커

카카오맵 api를 사용해 지도 및 지도 위 마커를 나타냈다. addMarker 함수의 파라미터로 받은 position는 노드 이름, 종류, 정보(싱크, 센서, id), 지도 내 좌표를 포함하고 있다. 따라서 노드의 종류에 따라 마커 이미지를 다르게 했고, 해당 노드의 지도 내 좌표에 마커를 생성했다.

4.3.2. rest api

위는 백으로부터 센서 리스트를 GET해오는 코드이다. component DidMount는 컴포넌트가 화면에 나타나게 됐을 때 호출된다. 여기서 fetch()를 통해 해당 url로부터 노드 리스트, 센서 리스트 등의 정보를 GET한다. 백으로부터 얻은 데이터는 해당 구조체에 저장해 사용한다. 위 코드와 같이 REST API를 통해 백으로부터 정보를 얻어오고, 센서, 노드 등을 등록할 시 REST API (POST)를 사용해 백으로 정보를 보냈다.

4.3.3. 헬스 체크

위는 웹소켓을 통해 헬스와 배터리 상태를 얻어오는 코드이다. ‘const client = new W3CWebSocket(HEALTHCHECK_URL);’ 를 통해 새 웹소켓 오브젝트를 생성하고, onopen 핸들러로 연결이 수립되었는지 확인한다. WebSockets는 event-driven API로써 메시지가 수신되면 “message” 이벤트가 onmessage 함수로 전달되게 된다. 따라서 백으로부터 받은 노드 id, health, battery 정보가 onmessage 함수로 전달되고, 이를 nodeState에 저장한다. 그 후 getHealthStateMap(), getBatteryStateMap() 함수에서 nodeState를 바탕으로 각각 health, battery 정보가 저장되어 있는 map을 업데이트 한다. 각 map에 저장된 health, battery 정보를 토대로 nodeTable, MapNodeTable에서 상태를 나타낸다.

5. 회로도

6. 임시 데이터 프로듀싱 서버

6.1. 기능
실제로 모든 공원에 센서를 설치하여 데이터를 얻는 것은 매우 어려우므로 실제 공공 통계 데이터를 처리 및 프로듀싱 하여 데이터 실시간 스트리밍 및 시각화, 매니지먼트 기능의 데모를 구현한다.

6.2. OPEN DATA
서울 열린 데이터 광장
· 스마트서울 도시데이터 센서(S-DoT) 환경정보
· 미세먼지, 온도, 습도, 조도
· 서울시 한강공원 이용객 현황 통계
· 월별 한강공원 이용객

기상자료개방포털
· 농업기상관측 정보
· 토양수분

7. 참고문헌 및 출처
· 카카오맵 api : https://apis.map.kakao.com/web/sample/multipleMarkerEvent2/
· 서울 열린 데이터 광장 – 스마트서울 도시데이터 센서(S-DoT) 환경정보 https://opengov.seoul.go.kr/data/20303041
· 서울 열린 데이터 광장 – 서울시 한강공원 이용객 현황 통계 https://data.seoul.go.kr/dataList/10798/S/2/datasetView.do
· 기상자료개방포털 – 농업기상관측(AAOS) https://data.kma.go.kr/data/grnd/selectAgrRltmList.do?pgmNo=72
· 대구 스마트공원 기사 : http://news.khan.co.kr/kh_news/khan_art_view.html?art_id=201709151701001
· 세종 스마트공원 기사 :https://www.korea.kr/news/visualNewsView.do?newsId=148850085
· LoRaWAN v1.0.4 Alliance-Specification 문서 : https://lora-alliance.org/resource_hub/lorawan-104-specification-package/
· LoRaWAN Alliance-Specification 문서 : https://lora-alliance.org/wp-content/uploads/2020/11/lorawantm_specification_-v1.1.pdf
· LoRaWAN Alliance-What-is-lorawan 문서 : https://lora-alliance.org/wp-content/uploads/2020/11/what-is-lorawan.pdf

2020 ICT 융합 프로젝트 공모전 장려상

20대 주거환경을 위한 외·내부 환기 제어 시스템

글 | 항공대학교 이종민

1. 심사평
칩센 우선 보고서를 통하여 작품에 대하여 조금 더 설명해주었으면 좋았겠다는 생각은 들지만, 주제로 삼은 작품명의 “20대 주거 환경을 위한~”으로 시작하는 부분이 매우 인상적입니다. 공기 청정이 필요한 이유를 단순히 외부에서 발현한 공기질의 저하가 아닌, 20대가 사는 주거환경에서는 왠지 실내의 공기질이 더 나쁠 수도 있겠다는 생각이 들었습니다. 작품명을 아주 잘 정하신거 같습니다. 그리고 다른 유사 작품들과의 차이점, 두 개의 장치(실내/외)가 서로 통신하여 연동하도록 한 부분은 매우 기발한 발상으로 보입니다. 스마트폰 또는 인터넷을 통해 추출된 지역의 정보보다는 실제로 필요한 것은 내가 머무르고 있는 실내 공간과 외부 공간의 공기질의 차이가 더 중요하다는 생각이 들기 때문입니다. 전반적으로 데모 작품이 구성이나 제작이 매우 깔끔하게 된 듯 합니다.

펌테크 실생활과 접목된 실용성을 지닌 작품으로 생각됩니다. 전체적으로 꼼꼼하게 잘 기획되었고, 간결하게 잘 구성한 완성도 높은 작품이라고 생각합니다.

위드로봇 아이디어가 좀 더 추가되면 좋은 작품이 될 것 같습니다.

2. 배경

미세먼지 농도가 심각하다는 것은 아마 우리 모두가 알고 있을 것이다. 그리고 실제로 미세먼지로 인한 두통, 기침, 폐암, 그리고 직업 능률 감소로까지 이어지고 있다. 네이버 키워드 검색량을 확인해보면 미세먼지라는 것이 큰 문제이고 많은 사람들이 관심을 가지고 있다는 것을 확인할 수 있다.

2.1. 현재상황

미세먼지 문제를 해결하기위한 공기기청정기는 2018년 기준으로 2조원 시장을 가지고 있고 미니 공기청정기 시장은 약 1000억원의 시장을 형성하고 있다. 하지만 미니 공기청정기는 단지 필터와 펜으로 이루어진 공기청정기로 사람들이 어느정도 공기가 오염되었는지 확인할 수 없다. 또한 미니 공기청정기를 분해해보면 공기청정기의 필터가 역할을 제대로 하지 못하고 펜이 약한 경우가 대부분이다. 배경에서 말했듯이 대부분의 사람들은 초미세먼지로 인해 창문을 열고 살지 않고 있다 하지만 기사에 따르면 집안의 먼지농도와 밖의 미세먼지 농도를 비교 했을 때 밖의 미세먼지 농도가 높다고 한다. 이러한 상황에는 공기청정기를 계속 틀기보다 창문을 여는 것이 더 효과적인 방법이 될 수 있다. 그래서 저는 이 두가지 문제점을 해결하기 위한 제품을 만들려고 했다.

2.2. 제품의 특징
집안의 미세먼지 농도를 확인할 수 있고 내부의 미세먼지가 외부보다 높은 경우 자동으로 창문을 열 수 있는 시스템을 만들었다. 그렇게 함으로써 20대의 주거환경에 필수적인 공기 오염도를 현저히 줄일 수 있고 전기료 감소로 인한 경제적 이익을 취할 수 있다고 생각한다.

2.3. 제품 상세 특징 및 스펙

아두이노 나노 기반인 PCB를 제작하려고 한다. 이 공기청정기는 여러가지 특징이 있다. 브레드 보드를 사용하지 않고 PCB 형태로 제작 되기 때문에 회로가 안정화되어 있고 LED, 미세먼지, 온습도 센서를 통한 정보를 LCD에서 바로 확인을 할 수 있다.
또한 다양한 센서 정보를 다른 쪽 아두이노에 블루투스 통신을 통해서 정보를 보내 내부와 외부의 미세먼지 농도를 비교하여 창문 개폐를 위한 서브모터를 작동시킨다.

2.4. 제품 작동 알고리즘

미세먼지에 따른 LED표시, 미세먼지에 농도에 따라 AUTO 펜 제어, 그리고 미세먼지 농도 심각 시 부저가 울리는 것이다. 그리고 그러한 정보를 LCD에 표현하는 것이다.

외부장치와 내부장치를 구성하여, HC-06 두개를 페어링하여 외부 미세먼지 농도에 대한 정보를 아두이노에 블루투스 통신을 통해서 보내 창문을 개폐여부를 결정하는 것이다.

블루투스 통신의 경우 일련의 String 형식으로 값이 전달이 된다. 따라서 여러가지 정보를 보내기가 매우 어려운 사항이다. 따라서 이번 프로젝트에서는 미세먼지 농도를 포함해서, 온도, 습도, 조도의 정보를 블루투스 통신을 통해서 받아야하기 때문에 센서값별로 일련의 String을 파싱하는 소프트웨어 알고리즘이 필요하다. 그 부분을 코딩으로 구현

미세먼지 센서의 값은 정확한 농도를 표현을 하는 것이 아닌 전압을 읽어서 가져오는 것이다. 시리얼 통신을 통해 고정밀 미세저측정기를 통해서, 캘리브레이션 할 수 있는 이동평균 개념을 적용해서 센서값 기복에 대한 부분을 해결했다.

2.5. 회로도 및 부분별 하드웨어 원리

캐패시터는 다양한 용도로 사용된다. 노이즈를 막기위해서 맥류신호를 평활하기 위한 평활용으로 사용되었다.

전원 순단 시 및 IC의 구동 스피드가 급격히 빨라짐에 따라, 부하전류가 증가한 경우, 전원으로부터의 라인 전압이 강하하여, IC의 오동작을 초래하는 경우가 있다. 이를 방지하기 위해, 전원 라인 정상 시에 콘덴서가 축적해 놓은 전기를 IC 측에 공급하여 전원 라인 전압을 일시적으로 유지한다.

아두이노에 전원을 공급하기위해서는 5v전원을 공급해주어야한다. 하지만 모터의 경우 5v를 공급하게 되면 최대 파워를 낼 수 가 없다 그래서 12v전원은 모터에 아두이노에는 전압을 강압시켜 5v를 공급 시켜주기 위해 레귤레이터를 사용하였다. 전원 공급의 경우 12v로 일정한 정전압을 보내므로 스위칭 레귤레이터가 아닌 리니어 레귤레이터를 사용하였다.

12v와 0.7A가 사용되는 모턴팬을 동작시키기 위해 Mosfet을 사용하여, 아두이노 신호에 따라 입력된 12V 전원부에서 전류를 공급할 수 있도록 구성을 하였다

경고음을 알리기 위한 용도로서 부저를 사용하였다. 부저 또한 코일성분을 가지고 있기에 직접적으로 아두이노에 연결을 하는 것은 좋지 않으며, 아두이노에서 출력하는 전류의 한계로 소리가 매우 작은 측면을 가지고 있다. 따라서 부저의 경우에는 트랜지스터를 사용하여 전류증폭을 통해 더 큰 경고음을 울릴 수 있도록 회로를 구성하였으며, 다이오드(FLYING WEEL 다이오드)를 사용하여, 역기전력를 방지하고자 구성하였다.

3. 최종 결과물

4.아두이노 소스코드