3조-버저비터

프로젝트 개요

기술개발 과제

국문 : 무정차 방지 및 승객의 안전을 고려한 정류장 승차 시스템

영문 : Smart Bus-Stop System for Passengers

과제 팀명

버저비터

지도교수

성민영 교수님

개발기간

2021년 9월 ~ 2021년 12월 (총 4개월)

구성원 소개

서울시립대학교 기계정보공학과 20XXXXX024 오**(팀장)

서울시립대학교 기계정보공학과 20XXXXX022 유**

서울시립대학교 기계정보공학과 20XXXXX002 고**

서울시립대학교 기계정보공학과 20XXXXX039 한**

서론

개발 과제의 개요

가.개발 과제 요약

무정차 방지 및 승객의 안전을 고려한 사용자 친화적인 정류장 승차 시스템은 버스를 이용하는 이용객과 버스 기사들의 편의성과 안전을 제공하는 시스템이다. 무정차 문제를 해결하기 위해 이용객은 해당 시스템을 이용하며 시스템에 지정된 번호를 통해 가장 가까운 버스에 해당 버스를 이용할 이용객이 있음을 알린다. 또한, 이미지 인식을 통해서 이용객의 안전을 파악하고 가까운 공공기관에 사고 알림을 알리게 된다. 이를 통해서 도심 외곽 쪽에서 계속 대두되는 문제인 무정차 문제와 일반적으로 취약한 치안 문제를 동시에 해결하고자 한다. 시스템은 기준 이하의 전송속도를 가지며 UX를 고려해 직관적이고 간단한 인터페이스를 제공하며 이미지처리를 이용하여 비접촉으로 조작할 수 있게 한다.

나. 개발 과제의 배경 및 기대효과

배경

2015년~2017년 수도권 내 무정차 버스 신고 건수

경기도에서 시행중인 무정차 방지 승차벨 서비스

버스를 이용해본 경험이 있다면 기다렸던 버스가 정차하지 않고 지나가는 경우가 있을 것이다. 경기신문 최근 기사 내의 인터뷰에 따르면, 도민 A씨는 “어두운 정류장에서 긴 시간 기다렸으나 버스가 서지 않고 그냥 지나친 적이 종종 있다. 그런 장소에서 유용하다고 생각한다.” 고 말했다. B씨도 “외곽지역은 버스가 손을 흔들지 않으면 사람이 서 있어도 그냥 지나간다.”며 “’시내버스 승차벨 서비스’가 보편화되면 유용하게 쓰일 것 같다”고 답했다. 실제로 무정차 문제는 과거부터 지속적으로 있었던 문제로, 제대로 된 해결책이나 개선방안이 제시되고 있지 않았다. 최근 경기도 지자체에서 ‘경기 버스 정보’ 라는 모바일 애플리케이션을 통해 무정차 문제를 해결하고자 시도하였으나 제대로 된 홍보 효과가 미비하여 시민들이 존재 여부를 몰라 이용을 못하는 경우가 대다수이며, 스마트 폰이라는 기기에 한정이 되어 스마트 폰 활용이 어려운 연령층의 사용자들에 대한 접근성을 고려하지 못하고 있다. 또한 실제로 대부분의 버스정류장의 치안 시스템은 CCTV 하나에 의존하고 있는 실정이다.
이러한 한계 때문에 도심 외곽 지역에서 시민의 치안 및 안전 관리에는 불리한 점이 존재한다. 도심 외곽에 집중하고 있는 시스템인 만큼 이용객이 혼자 있을 때 발생할 수 있는 범죄 및 사고 예방까지 고려한 시스템이 필요하다고 판단되었다. 따라서 무정차 문제와 안전 문제를 동시에 고려한 기능이 추가된 시스템을 구현하고자 한다.

기대효과

무정차 방지 및 승객의 안전을 고려한 사용자 친화적인 정류장 승차 시스템은 승객이 타고자 하는 버스 번호 또는 가고자 하는 목적지를 선택하여 가장 가까운 버스에 승차하고자 하는 승객의 존재를 알린다. 이를 통해 버스기사는 승객의 존재를 사전에 인지할 수 있어 정류장에 승객을 못 보고 지나치지 않을 수 있고 승객이 없을 경우에는 정류장을 패스하여 원활한 운행을 할 수 있게 된다. 승객은 타고자 하는 버스에 사전에 탑승 의사를 알리기 때문에 무정차로 인한 문제나 불편함을 해소할 수 있다. 기존의 스마트 폰을 이용하는 방식이 아닌 버스 정류장에 직관적으로 인식할 수 있는 인터페이스로 된 버튼/터치스크린을 사용하여 스마트 폰과 같은 기기의 활용이 어려운 연령층도 사용할 수 있게 될 것으로 예상된다. 또한 버스 정류장 내에서 이용객이 혼자 있을 때 발생할 수 있는 안전 및 사고 문제에 대해서 가까운 버스기사 또는 공공기관에 정류장 내의 문제 상황을 인지할 수 있는 이미지 또는 텍스트 정보를 송신한다. 버스기사나 공공기관에서는 해당 데이터를 토대로 사고를 인식할 수 있다. 이것을 통해 안전 및 치안 문제를 보완할 수 있고 발생한 상황에 대해 더 빠른 대응을 할 수 있을 것으로 기대된다.

다. 개발 과제의 목표 및 내용

(가) Bus Stop Interface

 버스 정류장의 인터페이스는 UX를 고려하여 모든 사용자가 쉽게 알아볼 수 있고, 편리하게 사용할 수 있도록 제작한다. 사용자는 도착하고자 하는 정류장 또는 타고자 하는 버스 노선을 입력해 해당하는 버스가 정류장에 도착할 수 있도록 한다.

(나) Fall-Detection

 Fall-Detection 알고리즘은 도심 외곽지역의 이용객이 적은 정류장에 승객의 안전을 보장하기 위해 적용한다. 카메라 모듈을 통해 얻어온 이미지에서 darknet을 이용해 사람을 인식하고, 추가적인 내부 연산을 통해 사람이 쓰러졌음을 판단한다. 이후, 일정 시간동안 쓰러짐이 유지되면 해당 정류장에 가장 먼저 도착하는 버스 기사에게 경고성 현장 이미지를 팝업창으로 띄워준다. 이를 통해 버스기사는 사고 발생 현장을 제일 먼저 목격하고 조치를 취하도록 유도한다.

(다) Bus Driver Interface

 버스에 장착하는 인터페이스는 버스기사가 운전 중에도 한눈에 알아볼 수 있도록 제작한다. 버스 기사용 화면에는 정류장에 탑승할 승객이 있다는 것을 알리는 정차 알림신호와 정류장에서 위급상황이 발생했을 때 정류장의 사진이 전송된다.

(가) 확장성

 목표하는 시스템에서 확장성이란 현재 시스템에 쉽게 추가하여 얼마나 확장할 수 있는지를 의미한다. 시스템에서 새로운 하드웨어 또는 소프트웨어 모듈이 추가될 경우 전체 시스템을 바꿔야 하거나, 추가되는 비용이 커진다면 해결하기 어려운 문제로 커질 수 있기 때문이다. 예를 들어 본 시스템에 적용될 버스 정류장 수가 늘어나는 경우에 하드웨어 또는 소프트웨어의 특정 모듈을 업그레이드와 추가가 필요할 수 있다. 확장성이 좋지 않다면 추가적인 시스템 개발에 어려움이 생기거나, 에러가 발생하였을 경우 모듈 교체 시 유연한 대처가 어려울 것이다. 위와 같은 이유로, 확장성은 목표하는 시스템의 모든 모듈의 평가요소로 적용될 수 있다.

(나) 오류 검출 및 대처

 애플리케이션이 오류가 발생한 경우에 이를 감지하고 해결조치를 취하는 것은 매우 중요하다. 하지만 오류 검출을 어디서 할지와 얼마나 할지는 고려해야하는 사항이다. 예를 들어 오류 검출이 중앙관리 서버에서 할지와 각 하드웨어 수준의 모듈단위에서 검출할지 아니면 모든 모듈 단위에서 검출할지는 중요한 사항이다. 또한, 모듈 단위로 검출을 한다면 각 모듈에는 얼마나 주기적으로 오류를 검출할지도 중요한 부분이 된다. 과도한 오류 검출은 오버헤드를 가져올 수 있으며, 시스템 성능 저하의 원인이 될 수 있다. 평가와 적절한 절충을 통해 효율적인 검출 위치와 횟수를 정하여 진행한다. 또한, 오류가 검출될 경우 프로그램 재부팅 또는 시스템 재부팅을 시도하고, 해결이 되지 않는 경우 관리자에게 해당 오류 내용을 전송하여 조치를 취할 수 있도록 한다.

● 사양 및 성능

(가) 처리 및 전송속도

 목표 시스템에서 처리 및 전송속도란 이미지 데이터 처리가 빠르게 이루어지는가와 사용자로부터 들어온 입력 값(승차하고자 하는 버스 번호)을 얼마나 빠르게 버스 기사에게 전달되는지와 사람이 넘어진 상황에서 fall-detection된 신호가 얼마나 빠르게 처리되고 전달되는지를 의미한다. 이를 만족시키기 위한 충분한 성능의 하드웨어가 필요하다. 따라서 이미지 처리 속도를 높이기 위해 Raspberry Pi 대신 Jetson Nano 보드를 이용해 이미지 처리를 진행한다. 또한 소프트웨어에서는 시스템 처리에 적합한 알고리즘을 사용하여 효율적으로 구성해야 한다.  또한 고려해야할 점은 여러 정류장에서 카메라를 통해 얻어온 이미지 데이터를 서버 한 곳에서 처리한다면, 서버 입장에서 정류장 수가 확장되었을 때 처리할 이미지 처리 수가 많아진다는 것이다. 이는 응답속도저하, 병목현상이 발생시킬 위험이 있기 때문에 local 영역인 정류장에서 Jetson Nano 보드를 사용하여 처리한다.

(나) 경제성

 목표 시스템은 필요에 따라서 수많은 정류장에 설치해야 하기 때문에 경제성을 고려하여 시스템을 설계해야 한다. 그렇지만 경제성을 위해 단순히 저렴한 시스템은 사용자의 편의에 영향을 줄 수 있기 때문에 다음과 같은 상황에서 경제성을 고려해 최종 사용할 하드웨어와 소프트웨어를 결정한다.

1) 사용자의 편의성과 정류장의 이용 상황을 모두 고려한 버스정류장에 설치할 입력 장치의 선택(버튼, 터치스크린) 2) Fall-Detection을 위해 가격과 성능을 고려한 카메라 선택(아두캠, 웹캠) 3) 네트워크를 통해 데이터를 전송할 서버의 선택 (웹서버, 클라우드서버)

다. 설계 사양

모델 설계 사양

모델 설계 사양

UI 및 소프트웨어

UI 및 소프트웨어 설계사양

키오스크

키오스크 설계 사양

개념설계안

가. 개념 설계안 도출을 위한 분석

입력 장치

입력장치 리스트

이미지 처리 위치

이미지 처리위치 리스트

통신 방법

통신방법 리스트

출력 장치

출력장치 리스트

사물인식 알고리즘

사물인식 알고리즘 리스트

서버

서버 리스트

나. 승차 시스템 구체 개념 설계안

터치 스크린을 이용한 승차벨 시스템

터치 스크린을 이용한 승차벨 시스템

해당 모델은 라즈베리파이 10.1인치 터치스크린을 이용한 시스템이다. 파란색 부분의 상자 안에 라즈베리파이가 내장되어있으며, 터치스크린이 연결되어있는 형태이다. 외관 부분은 우드락과 상자로 만들어져있다. 사용자는 라즈베리파이 터치스크린을 터치함으로써 원하는 버스를 호출할 수 있다.

장점

- 입출력 장치 (라즈베리파아 터치스크린 등) 메인 연산 모듈들의 가격이 낮아 저렴하게 구현 가능
- 모듈식으로 만들어졌기 때문에, 전원 공급만 이뤄진다면 어디든 설치 가능

단점

- 저가형 터치스크린은 화면의 크기가 작기 때문에, 사용자 편의성이 떨어짐

버튼을 이용한 승차벨 시스템

버튼을 이용한 승차벨 시스템

해당 모델은 버튼을 이용한 시스템이다. 버스가 많이 다니지 않는 버스정류장에 버튼식 시스템을 설치하여 사용자는 버튼을 누름으로써 해당 버스를 호출할 수 있다.

장점

- 버튼과 라즈베리파이와 같은 저가형 모듈로 떄문에 저렴한 제작 비용
- 높은 직관성

단점

- 확장성이 좋지 않기 때문에 키오스크와 같은 형식에 적용 불가
- 버튼의 내구성 문제 발생 가능

비접촉 승차벨 시스템

비접촉 승차벨 시스템

해당 모델은 카메라 모듈을 이용한 비접촉 형식의 시스템이다. 사용자와 키오스크의 직접적인 접촉이 이뤄지지 않기 때문에 사람과 사람간의 접촉을 최소화할 수 있다. 카메라를 이용해 사람의 손가락을 인식해 터치가 이뤄진다.

장점

- 비접촉 터치를 사용함으로써 사람간의 접촉 최소화
- 버스정류장 뿐만 아니라 키오스크가 이용되는 곳 어디든 사용할 수 있는 확장성
- 사람의 물리적인 조작이 이뤄지지 않으므로 좋은 내구성

단점

- 처음 접하는 사용자들에게 익숙하지 않기 때문에 직관성 문제 발생 가능
- 리소스를 많이 사용하는 S/W를 사용하므로 연산 처리 성능이 우수한 하드웨어 의존적

다. 구체 개념 설계안

전체 시스템 설계 구상도

시스템 설계 구상도

Bus stop

1) Jetson Nano

 버스정류장에서 메인으로 사용되는 하드웨어이다. 사용자가 버튼 또는 터치스크린을 이용해 특정       버스를 탑승하겠다는 의사를 표출했을 때, TCP/IP를 이용해 서버로 승차신호와 버스번호를 전송한다. 사용자가 도착하고자하는 특정 버스정류장을 선택했을 시에는 해당 정류장으로 향하는 버스들 중 가장 먼저 도착하는 버스를 선택해 서버로 보낸다.  또한, Jetson Nano에서 얻은 Fall Detection에 대한 정보를 얻어서 서버로 전송한다. 승차신호나 Fall Detection이 일어났다는 신호가 발생했을 때 작동한다. 라즈베리파이에서는 멀티 쓰레드를 이용해 데이터의 처리, 신호의 전달을 한다.

2) 입력 장치 비접촉 터치 시스템 :웹캠과 모니터를 이용하여 비접촉 시스템을 구현한다. 사용자는 손의 제스쳐를 이용해 특정 버스 노선을 탑승하고자하는 의사를 표현할 수 있다. GUI는 UX를 고려하여 제작한다.

Fall Detection

1) Cam – USB Web Cam 사용

 USB 단자를 사용한다는 점과 장치를 다루기 쉽다는 장점 때문에 Web Cam 사용을 결정했다. CSI 카메라 모듈은 Opencv 라이브러리를 사용할 때 VideoCapture() 함수에 주어야하는 인자가 복잡하며 다루기 힘들다. 하지만 Web Cam은 해당 함수에 장치 번호 (예: 0)만 인자로 주면 자동으로 카메라를 인식하기 때문에 프로그래밍을 할 때 장치 인식에 할애하는 시간을 줄일 수 있다. 또한 USB 형식이기 때문에 장치 교환에도 유리함이 있어 최종적으로 Web Cam을 선택했다.

2) Jetson Nano

 고성능을 요구하는 YOLO 사용하기 위해 Raspberry Pi에서는 지원하지 않는 NVIDIA GPU를 이용하여 CUDA 라이브러리를 사용할 수 있는 Jetson Nano를 사용한다. YOLO와 OpenCV 라이브러리를 활용하여 이미지를 추출해 Fall Detection을 수행하고, 결과를 Raspberry Pi로 전송한다.

3) YOLO – YOLOv3 모델 사용

여러 욜로 모델들의 성능표

출처 : https://pjreddie.com/darknet/yolo/

 위 표는 Pascal Titan X 그래픽카드를 이용해 여러 객체 인식 모델들의 성능을 분석한 표이다. mAP는 Mean Average Precision의 약자로 사물 인식 알고리즘의 평가 지표이다. 또한 FPS도 확인할 수 있다.   우리는 Jetson Nano 보드에서 성능을 확인하기 위해 직접 모델을 실행해보았다. (GPU 사용) mAP 지수는 이미 위의 퍼포먼스 표에서 참고할 수 있기 때문에 따로 분석하지 않는다.

YOLO 모델간 fps 비교표

 표를 통해 초당 이미지 처리 측면에서는 tiny가 가장 빨랐고, spp모델이 가장 느렸다. 그러나 성능표를 참조했을 때 정확도가 높았던 spp와 608모델은 초당 1프레임도 처리하지 못했기 때문에 실시간성과는 걸맞지 않다고 판단했다. 따라서 416, tiny 모델 중에서 수직으로 서있는 사람에 대한 인식의 여부를 기준으로 모델을 선택하기로 했다.  아래 표는 그 실험 결과이다.

YOLO 실험 결과

 누워있는 사람이라고 가정하기 위해 카메라를 눕힌 상태에서 실시간으로 객체인식 알고리즘을 실행했다. 그 결과 YOLOv3-416 모델은 수직으로 서있는 사람의 경우에도 정확도가 50% 밑으로 내려가지 않았다. YOLOv3-tiny 모델은 FPS가 6.4로 처리속도가 훨씬 빨랐지만 사람 2명 중 1명만 29%의 정확도로 인식했다.

 결과적으로 Fall-Detection 알고리즘을 구현하기 위해서 최소 1 FPS 이상이라는 기준과, 임의의 자세의 사람에 대한 정확성을 기준으로 판단해 YOLOv3-416 모델을 사용하기로 결정했다.

Server – 구글 클라우드 서비스 사용

1) 초기구축비용

구글 클라우드 서버는 초기 구축에 필요한 리소스를 무료로 제공한다.

2) 유지비용

  데이터 전송량, 클라우드 데이터 저장량에 따라 주기적으로 기업에 금액을 지불해야 한다. 최근 지불금액이 매우 저렴해진 추세이다. 리소스에 대해서 CPU는 시간당 $0.0728, 1GB Memory는 시간당 $0.0046241, 1GB storage는 시간당 $0.0000702로 제공된다. 데이터 저장 비용은 월 10GB까지 무료이고 쿼리비용은 월 1TB까지 무료로 제공한다. 무엇보다 구글 클라우드의 경우 현재 $300 크레딧을 무료로 제공하고 있으며 해당 무료 금액을 이용하여 데모 시스템을 구축하기에는 충분하다고 할 수 있다.

3) 보안

 구글 클라우드는 인프라, 네트워크, 데이터, ID 및 엑세스, 애플리케이션, 모니터링, 사용자 보호 등 넓은 분야에서 다양한 보안성을 보장한다.

4) 유동적인 리소스

 리소스가 분산되어있기 때문에, 유동적인 리소스를 제공하며 사용된 리소스량에 따라 금액을 지불한다. 데모 시스템에서는 리소스가 변칙적으로 소모되지 않지만, 사용량이 적기 때문에 적은양의 리소스를 사용하는 만큼 금액을 지불하게 된다.

5) 복구

 구글 클라우드 서버는 항상 온라인 상태이고, 복구 서버를 충분히 가용하고 있다. 반대로, 클라우드 서버 전체가 다운되는 경우 클라우드 서버이용자는 대처할 수 없다는 단점이 있으나 기업에서 지속적인 관리와 모니터링, 그리고 분산 서버 형태로 서버 다운을 회피할 수 있다.

6) API

 구글에서 서비스하는 대다수의 플랫폼의 API를 제공한다. 특히 구글 클라우드 관련 API로는 Compute Engine API, Cloud Storage API, Datastore API, Sql API등 다양한 API를 제공하여 효율적인 서버 구축 및 관리가 가능하다.

버스 기사 모니터

1) 정차 신호

 라즈베리파이에서 서버로 버스 정차신호를 보내고, 서버에서 버스의 단말기로 정차신호를 보낸다. 버스의 단말기에 정차신호가 전송되면, 운전 중에도 한 눈에 알아볼 수 있도록 팝업을 띄운다.

2) Fall Detection 신호 및 사진

 버스정류장에서 Fall Detection이 감지되면 서버로 Fall Detection 사진이 전송된다. 서버에서 버스의 단말기로 Fall Detection 사진을 전송해 버스의 단말기에서도 Fall Detection이 일어났음을 알 수 있게 한다.

버스 기사 모니터 예시

라. 시스템 시나리오

시스템 시나리오

조립도

가. 전체 구성도

전체 분해도

나. 상부 조립도

상부 조립도

상부는 주문제작 알루미늄 프레임 업체의 코너블록 (SCB 3030-3U)제품을 이용한다.

다. 프레임 간의 체결 조립도

프레임 간의 체결 조립도

체결부는 주문제작 알루미늄 프레임 업체의 인서트브라켓 (SIB 3030)제품을 이용한다.

라. 스프링 너트 조립도

스프링 너트 조립도

추가적으로 프레임에 부착할 때 필요한 부분은 업체의 스프링 너트를 이용한다.

분해도

가. 알루미늄 프레임(DNF 3030)

알루미늄 프레임(DNF 3030)

나. 알루미늄 프레임 (DNF 3030 – 400, DNF 3030 – 460, DNF 3030 – 1270)

알루미늄 프레임 (DNF 3030 – 400, DNF 3030 – 460, DNF 3030 – 1270)

다. 코너 블록 (SCB 3030-3U)

코너 블록 (SCB 3030-3U)

라. 인서트 브라켓 (SIB 3030)

인서트 브라켓 (SIB 3030)

최종 설계도

가. 구상도(4면)

하드웨어 구상도

나. 상부도

상부도

]

다. 정면도

정면도

라. 측면도

측면도

소프트웨어 설계

가. 버스 정류소 인터페이스

1) 버스 정류소 인터페이스 개요

버스 정류장 인터페이스 예제

 버스정류장에 설치할 터치스크린의 인터페이스를 생성한다. 터치스크린을 통해 사용자는 타고자하는 버스의 번호나 가고자하는 버스 정류장을 UI를 통해 쉽게 알아볼 수 있고, 터치를 통해 편리하게 조작할 수 있다. 터치스크린은 크게 두 가지 부분으로 나뉘어 있다. 버스를 선택할 수 있는 부분과 버스 정류장을 선택할 수 있는 부분이다. 버스 번호를 선택하면 해당 버스에 승차객이 있다는 신호가 전송된다. 버스 정류장을 선택하면 해당 버스 정류장으로 이동할 수 있는 버스들 중 가장 빠르게 현재 정류장에 도착하는 버스에 승차객이 있다는 신호가 전송된다. 버스들의 도착정보나 정류장 정보는 공공데이터 포털에서 제공하는 API를 이용한다.

2) 버스 인터페이스 버튼 구현 가) 버스 인터페이스 버튼 생성

버스 정류장 ID 및 정류장 이름이 담긴 CSV파일

 서울시의 버스 정류장에는 정류장마다 표준 버스정류장 ID가 존재한다. 이 표준 버스정류장 ID를 공공데이터 포털에서 제공하는 서울특별시_버스도착정보조회 서비스 API의 입력값으로 주면 해당 정류장에 도착하는 버스들의 정보들을 얻을 수 있다.

버스정류장 고유 ID

API호출 결과

이를 통해 얻을 수 있는 데이터는 여러 가지가 있는데, 그 중 대표적인 것들을 나열하면 다음과 같다.

API에서 제공하는 정보들

 이 정보들 중 busRouteId 와 rtNm을 이용하면 특정 정류장에 도착하는 버스들의 목록을 얻어올 수 있다. 이 데이터를 이용해 버스 번호 버튼을 생성한다.

코드에서 버스도착정보를 받아오는 부분

해당 버스정류장에 도착할 수 있는 버스들의 목록

나) 버스 번호 버튼 클릭

 이용자가 버스번호버튼을 클릭하면 해당 버스가 선택되었다는 팝업이 생성되었다가 1초 후 사라진다. 또한, 해당 버스 번호 버튼은 눌릴 수 없는 disable상태가 되고 이미지가 바뀌어 사용자가 해당 버튼은 눌린 상태라는 것을 알 수 있게 한다.

버스 번호 버튼 선택 시

 버스도착정보 API를 통해 얻어온 데이터 중 arrmsg1가 곧 도착에서 다른 문자열로 바뀌었을 때 버스가 정류장을 통과한 것이므로 버스 번호 버튼은 버스가 정류장을 통과했을 때 다시 눌릴 수 있는 상태로 변한다.

버스가 정류장을 통과했을 때 터미널에 출력되는 모습

3) 버스 정류장 버튼 구현

 버스 정류장 버튼은 하차 승객이 많고, 분기점이 되는 정류장 5개를 선택해 UI상에 띄운다.

가) 하차 승객이 많은 정류장 선택

 공공데이터포털에서는 서울특별시_버스노선별 정류장별 승하차 인원 정보를 csv파일 형태로 제공한다. 해당 데이터는 한 달 주기로 업로드 되며, 한 달간 정류장에 버스 노선별로 승하차하는 인원의 수를 제공한다.

승하차 인원 정보 csv파일

 해당 파일을 process_csv.py 파일을 이용해 하차객이 많은 순서대로 정렬 후 관리자가 5개의 정류장을 선택해 표준버스정류장 id를  bus_stop.xml파일에 작성한다. 처음에는 하차객이 내림차순으로 정렬된 csv파일을 자동으로 읽어와 버스정류장 버튼을 생성하려했지만, 정렬해본 결과 중복되거나(ex 청량리역환승센터, 청량리역환승센타) 1~2정류장 이내의 정류장이 선택되는 경우가 많이 발생했기 때문에, 관리자가 xml파일에 직접 작성하는 방법을 선택했다.

하차 승객이 많은 순서대로 정렬한 csv파일

정류장 정보가 담긴 xml파일

나) 버스 정류장 버튼 생성

 버스 정류장 인터페이스 생성시 이 xml 파일을 읽어온다.

xml, csv파일 비교 및 배열 추가

 이 때 ,버스 정류장 id와 버스정류장의 이름이 담겨있는 csv파일을 참조해 버스정류장 id와 함께 버스정류장 이름을 읽어와 배열에 저장한 후, 버스정류장 버튼을 생성할 때 이용한다.

표준버스정류장 ID를 바탕으로 그에 맞는 정류장명을 읽어와서 버튼 텍스트에 작성하게 된다.

다) 버스 정류장 버튼 클릭

 이용자가 가고자하는 버스 정류장 버튼을 클릭하면 우선 공공데이터 포털의 서울특별시_노선정보 조회 서비스를 이용해 가고자하는 버스 정류장에 도착할 수 있는 버스의 목록을 출력한다. 서울특별시_노선정보조회 서비스에 버스의 고유 id를 입력하면 다음과 같이 버스가 통과하는 정류소들을 순서대로 얻을 수 있다.

노선 정보 조회 API호출 결과 및 버스 정보 어플

 이 정보를 바탕으로 현재 정류장에서 사용자가 클릭한 정류장까지 갈 수 있는 버스의 목록들을 얻어온다. 버스 목록에는 버스의 고유 id(busRouteId)와 버스 번호(rtNm)이 순차적으로 담긴다.그 다음 버스도착정보 API를 이용해 방금  출력된 버스들이 현재 정류장에 언제 도착하는지 얻어온 후 해당 정보를 바탕으로 가장 빠르게 도착하는 버스가 선택된다. 000버스를 탑승하라는 팝업이 생성된 후 1초후 자동으로 사라진다.

버스 정류장 클릭 시 정류장 인터페이스와 터미널

 만약 운행종료로 인해 탑승할 수 있는 버스가 없다면, 탑승할 수 있는 버스가 없다는 팝업이 생성된 후 사라진다.

탑승할 수 있는 버스가 없을 때 팝업 내용

4) 버스 정류장 알고리즘 순서도

버스 정류장 알고리즘 순서도

나. 웹서버 DB구축

1) GCP 웹 서버 및 데이터베이스 개요

 GCP(Google Cloud Platform)을 이용한 클라우드 웹 서버를 구축하였다. 개념설계보고서에서 설명한것과 같이 GCP를 이용한 웹서버 구축은 경제성, 유지보수성, 보안성, 복구성(Server Recovery)가 유리하다는 장점이 있다. 해당 웹서버는 무정차 방지 전체 시스템에서 필요로 하는 버스 UID(Unique ID), 버스정차 시그널(flag), 쓰러짐 감지 시그널(flag) 데이터들을 관리하는 데이터 베이스를 구축하였다.

2) 웹 서버 인프라스트럭처(Infrastructure) 및 플랫폼(Platform) 구축

 GCP는 인프라스트럭처와 플랫폼 구축이 쉽고 간편하다. 먼저 GCP 컴퓨터 엔진 인스턴스 즉, 인프라스트럭처를 아래 그림과 같이 사용자가 구축하고자하는 시스템 목적에 맞는 리소스에 맞춰 인스턴스를 구축할 수 있다.

GCP 인스턴스 구축

 구축한 인스턴스의 요약은 아래 그림에 좌측에 Summary 섹션에서 확인할 수 있다. GCP는 서버의 물리적인 위치를 의미하는 리전(Region)을 서울을 선택할 수 있어서 네트워크 속도가 비교적 빠르다. 또한, 리전 안에 있는 IDC(데이터센터)여부를 의미하는 가용 영역이 a, b, c 세곳이 존재하여, 물리적 서버의 장애 발생 시 복구에 유리하다. Mysql은 5.7버전으로 2016년 하반기에 Release된 8.0버전 보단 성능이 30%정도 차이가 나지만, 안전성과 커뮤니티 활성화 정도를 고려하여 5.7버전을 선택하였다. 실질적인 데모 테스트에서 데이터처리가 복잡하지 않으므로 고성능에 적합한 하드웨어 리소스가 필요하지는 않지만, 리소스 사용량에 따라 가격이 청구되는 클라우드 서버 특성상 여유로운 하드웨어 스펙으로 구성하였다. 플랫폼 레벨에서는 Ubuntu18.04를 OS로 구축하였다. GCP는 애플리케이션을 효과적으로 개발하고 배포할 수 있는 ‘APP Engine’ PaaS를 제공하지만, 아파치2(Apache2)를 이용하여 구축한 웹 서버에서 Mysql DB만을 사용되기 때문에 플랫폼 레벨은 OS구축까지만 사용하였다.

GCP 인스턴스 구축 설정 및 Summary 섹션

3) 데이터베이스 구축

 데이터베이스는 Mysql 5.7을 사용하여 구축하였다. 데이터베이스의 구성은 bus_info database안에 bus_info table을 가지고 있다. 아래 사진과 같이 bus_info 초기 데이터베이스는 list넘버, 버스번호, 버스 UID, 정차신호 플래그, 데이터 업데이트 날짜순으로 예제 데이터를 가지고 있다.

MySQL 테이블 정보 및 초기 데이터

 bus_info 데이터베이스는 실제 버스UID 정보와 클라이언트들이 요구되는 추가적인 데이터 정보에 따라 수정이 가능하며, 아래 그림과 같이 CSV파일을 통해 얻은 실제 버스들의 정보들을 매크로 형식 dump의 데이터 정보를 불러와 데이터베이스를 새로 구축할 수 있도록 하였다.

초기 데이터베이스 구축

dump형식 데이터 출력 및 데이터 베이스 삽입

4) 웹 데이터베이스 매니저 구축

 웹 DB 비전문가 관리자도 손쉽게 DB를 관리할 수 있도록 웹 데이터베이스 매니저를 구축하였다. 기본적으로 PHP로 구축되어있으며, Mysql API를 통해 데이터베이스에 접근할 수 있도록 하였다. 데이터 기본 처리기능인 CRUD(Create, Read, Update, Delete)기능이 ‘add.php’, ‘list.php’, ‘edit.php’, ‘delete(기능)’형태로 제공되고 있다.

list 세션

edit 과 add 세션

 edit과 add, list 조회는 ‘gcp-ip/bs/login.php’ URI를 통해서 로그인세션을 통과한 후에 접근할 수 있도록 하였고, 로그인이 되지 않은 상태에서 add, edit, list URI를 통해 접근 시 아래 그림과 같은 login 세션으로 리디렉션한다. 또한, edit과 add과정을 거치지 않고 update, insert 메소드 과정에서 URI로 접근시 Wrong access!메시지를 나타낸다.

로그인 세션 및 잘못된 접근에 대한 세션

5) Mysql Database API를 이용한 DB매니징

 각 클라이언트(bus-stop, bus driver, 쓰러짐 감지 모듈)에서는 ‘PyMysql’ 파이썬 클라이언트 라이브러리를 이용하여 웹서버 DB에 접근하여 CRUD 과정을 진행한다.

Python에서 웹서버 DB접근을 위한 API

API는 PyPI https://pypi.org/project/PyMySQL/

에서 제공하는 매뉴얼을 참조하였다.

6) 클라이언트(bus-stop, bus driver, 쓰러짐 감지)와 서버(GCP) 개략도

버스 정류장(bus-stop)클라이언트는 DB에서 BUS UID를 확인하고 STOP SIG를 0에서 1로 업데이트 한다. 이때, STOP SIG값의 업데이트(0에서1, 1에서0) 범위를 정류장에 얼마나 근접한 버스에 한에서 실행할지에 대한 부분은 향후 개발 계획에 있다. 해당 부분에 대한 고민은 본 프로젝트의 동기 중 하나인 ‘경기버스앱’ http://www.cartvnews.com/news/articleView.html?idxno=608380 의 알고리즘에 참조하여 해결할 계획이다. 쓰러짐 감지 클라이언트는 젯슨나노 보드에서 DB에 접근하여 BUS UID를 확인하고 FALL-D SIG를 0에서 1로 업데이트한다. 해당 BUS UID는 가장 가까운 버스 정보를 바탕으로 확인한다. 가장 가까운 버스 정보는 버스정보 API를 사용하고 있는 메인 컨트롤러(라즈베리파이)에서 받아 올지, 젯슨 나노보드에서 중복적으로 버스정보 API에 접근할지는 고려 사항이다.
버스 드라이버(bus driver)클라이언트는 LTE 기반 모바일 클라이언트이기 때문에 IP가 유동적으로 변한다. 그러한 이유로 Bus-stop, 쓰러짐 감지 클라이언트에서 버스 드라이버기기로 바로 통신하기 어렵다. 이를 해결하기 위한 아이디어는 일정 주기로 웹 서버 DB에 접속하는 것이다. 폴링 인터벌(Polling Interval)을 통해 일정 주기로 서버의 DB의 상태를 확인하여 버스 드라이버 클라이언트 데이터를 동기화하는 것이다. 이때, 인터벌(주기)이 너무 짧으면 클라이언트와 서버 모두 오버헤드가 발생한다. 너무 길면, 데이터의 신뢰도가 매우 떨어진다. 그렇기 때문에 절충점을 찾기위해 우선 10초를 폴링 인터벌로 설정하고 휴리스틱 방법을 통하여 완성 데모 제품에서 적합한 폴링 인터벌을 찾아가기로 하였다.

버스 정류장 및 기사님 클라이언트와 서버 아키텍처

다. 승객 쓰러짐 감지

1) 쓰러짐 감지 개요

 도심 외곽지역의 이용객이 적은 정류장을 이용하는 승객의 안전을 보장하기 위해 쓰러짐을 감지하는 시스템을 의미한다. 알고리즘 진행은 다음과 같다. 카메라를 통해 얻어온 이미지에서 인공지능 모델을 이용해 사람을 감지하고, 추가적인 내부 연산을 통해 사람이 쓰러졌음을 판단한다. 그 다음, 일정 시간동안 쓰러짐이 유지되면 FTP 프로토콜을 이용해 서버에 이미지를 전송하고, 버스 API를 이용해 해당 정류장에 가장 먼저 도착 예정인 버스의 정보(UID 등)을 얻은 후, DB에 접근해 해당 버스의 FALL-D SIG 플래그를 올린다. 버스 기사 단말기는 서버에 주기적으로 접속해 FALL-D SIG가 올라가 있다면 서버에 저장된 이미지를 받아와 팝업을 띄운다. 이를 통해 버스기사는 사고 발생 현장을 제일 먼저 목격하고 조치를 취하도록 유도한다.

2) 알고리즘 기초 구현

 쓰러짐 감지 기초 구현과 이미지 전송 과정을 알고리즘 진행 순서대로 설명한다.

가) 객체 인식

 웹캠에서 실시간으로 얻어오는 이미지들을 Yolov3-416 사물인식 인공지능 모델을 이용해 객체들을 인식한다. 최종적으로는 사람, 자전거, 개, 휴대전화 등등 무수히 많은 사물이 인식된다. 하지만 쓰러짐 감지 알고리즘에서 필요한 객체는 사람뿐이므로, 사람 이외에 인식된 모든 객체들은 무시하고, 오직 사람에 대해서만 ROI 박스가 그려지게 수정했다. 아래 사진 중 왼쪽이 수정 전, 오른쪽이 수정 후이다.

객체 인식 결과(좌: 수정 전 객체 인식, 우: 수정 후 사람 인식

나) 쓰러짐 인식

 인공지능 모델을 이용해 얻은 사람의 ROI 박스 크기를 참조해 쓰러짐을 판별한다. 박스의 width를 height로 나눈 값이 1.1보다 크다면 사람이 쓰러진 상태라고 판단한다. 즉, 사람에 그려진 박스가 가로로 넓어진다면 쓰러진 상태라고 판단하는 것이다.

쓰러짐 인식 결과(좌: 쓰러짐 인식, 우: 사람만 인식

다) 쓰러진 이미지 저장

 사람이 쓰러져있는 이미지를 버스 기사 단말기에 보내기 위해서는 먼저 젯슨 보드 내에 이미지를 저장할 필요가 있다. 그러나 쓰러짐이 감지되었을 때 바로 이미지를 저장하고 전송한다면, 넘어진 상태가 아닌데 잘못 인식했을 경우가 있을 수 있다.

잘못된 쓰러짐 감지

 위 사진처럼 사람이 카메라 앞으로 가까이 지나가서 ROI 박스의 가로가 넓게 측정될 수도 있으므로, 쓰러짐이 지속적으로 감지될 때부터 진짜 사고가 일어났다고 인지한다. 따라서 쓰러짐이 6초 이상 감지될 때부터 이미지를 젯슨 보드 내에 저장하도록 하는 기능을 추가했다. 이 때, 이미지는 계속 한 파일에 덮어씌운다. 6초 이상을 기준으로 한 이유는, 한 장의 이미지가 Yolov3-416 모델을 통해 객체 인식이 될 때의 시간이 약 0.6초(평균 fps = 1.67) 걸렸기 때문이다. 즉, 최소 이미지 10장이 처리될 동안 쓰러짐이 유지된다면, 젯슨 보드 내에 해당 이미지가 지속적으로 저장된다.

라) 이미지 전송

 젯슨 보드 내에 저장된 이미지를 서버에 전송하기 위해서 파일 전송 프로토콜(File Transfer Protocol, FTP)을 이용한다. 다만, 중간 발표까지의 구현과정에서 클라우드 서버는 미완이었기 때문에 라즈베리 파이에 ftp 서버를 구축하고 젯슨 보드에서 라즈베리파이로 이미지를 전송하는 기능을 구현해보았다. 그리고 이 기능을 파이썬 코드내에서 구현하기 위해 ftplib를 사용했다.
 기본적인 전송 과정은 다음과 같다. 쓰러짐이 지속되어 이미지가 덮어씌워져 저장된다면, 해당 이미지의 수정시간이 갱신될 것이다. 만약 수정시간이 갱신되었다면, 쓰러짐이  새로 발생했다는 의미이므로, 해당 이미지를 FTP 프로토콜을 이용해 서버 라즈베리파이에 전송한다. 이후, 무한루프에 빠지게 되어 젯슨 내의 이미지 파일의 수정시간이 갱신될 때까지 기다린다. 이 과정을 무한히 반복하게 된다.

마) 서버 라즈베리파이에서의 이미지 팝업

 FTP 서버로 구축된 라즈베리파이에서는 젯슨으로부터 전송된 이미지 파일의 수정시간을 참조해 만약 수정시간이 갱신되었다면, 해당 이미지를 opencv 라이브러리를 이용해 2초 동안 팝업 시킨 후 창을 종료하고, 수정시간이 갱신될 때까지 무한루프에 빠지게 된다.

바) DB 접근 후, FALL-D SIG 플래그 수정

 쓰러짐이 지속적으로 발생해서 이미지를 서버로 전송한 후, 가장 가까운 버스에게 쓰러짐 이미지를 받아가야 한다는 신호를 주어야 한다. 이것을 위해 DB에 FALL-D SIG라는 플래그를 추가한 상태이다.
 젯슨 보드는 쓰러짐 이미지를 서버에 전송한 후, 버스 API를 이용해 해당 정류장에 가장 가까이 있는 버스에 대한 정보(UID 등)을 얻어온다. 이후, DB에 접근해 가장 가까이 있는 버스의 FALL-D SIG를 1로 올린다. 그리고 쓰러짐이 감지되지 않는다면 해당 플래그를 0으로 다시 내린다. 이 기능을 구현한다면, 추후에 버스 기사 단말기가 서버에 접근해서 FALL-D SIG가 1일 때 쓰러짐 이미지를 받아갈 수 있을 것이다.

3) 쓰러짐 감지 알고리즘 순서도

쓰러짐 감지 알고리즘 순서도

라. 버스 드라이버 인터페이스

1) 버스 드라이버 인터페이스 개요

 버스 기사용 스크린에 적용할 인터페이스를 구축한다. 인터페이스는 디스플레이를 통해서 데이터를 출력하는 형태를 통해서 버스 기사가 정류장에서 발생한 신호나 상황을 인지할 수 있게 한다. 현재 버전은 DB에서 필요한 데이터를 가져오고 가져온 데이터의 값에 따라서 출력되는 신호나 이미지를 갱신하도록 하였다. 갱신되는 데이터에 따라서 버스 기사는 신호나 이미지를 보고 정류장의 상황을 확인하도록 한다.

2) 버스 드라이버 클라이언트

파이썬 서버와 주기적 통신

 버스 드라이버는 서버와의 통신을 위해서 클라이언트가 주기적으로 DB의 상태를 확인하여 신호가 발생했을 때 데이터를 가져오는 방식으로 구축하였다. 사진처럼 해당 버스(버스번호 100100132)에 대한 정보를 수신하고 signal이 발생하게 되면 해당 신호를 출력하거나 이미지를 출력하도록 진행하였다. DB 접속 주기는 10초로 했다.

3) 웹서버 DB 통신 기반 버스 드라이버 인터페이스

웹서버 DB통신 버스 드라이버 인터페이스

 웹서버 DB와 통신하는 버스 드라이버 인터페이스는 다음과 같이 구축하였다. 출력되는 정보와 이미지가 팝업 등으로 인해 겹쳐서 보이지 않거나 하는 문제가 발생하지 않도록 사진과 같이 이미지가 따로 출력되는 부분을 만들었다.

먼저 좌측 상단에 시립대 마크가 있는 부분은 신호를 출력하는 부분으로 승차벨이 눌려서 버스가 정차해야 하는 경우에 stop 신호로 바뀌게 된다. 바로 옆에 있는 민트색 칸은 현재 버스의 위치를 나타내준다. 만약 승차벨이 눌리거나 쓰러짐이 감지되어 사진이 전송되면 해당 위치가 어디인지 알려주는 것으로 바뀌게 된다. 우측에 있는 버스 모양은 앞의 두 버스와 뒤의 두 버스의 위치와 시간을 출력해준다. 실제 버스 기사용 화면에 해당 정보가 있어서 출력한다.

4) 버스 드라이버 인터페이스 image 출력

 이미지 출력은 두 가지가 출력이 된다. 하나는 정류장에서 승차벨이 눌렸을 때 정차 신호 표시를 위한 stop 이미지 출력과 정류장에서 쓰러짐이 감지되었을 때 전송된 이미지를 출력하기 위한 이미지 출력이 있다. 이전 계획에서는 수신되는 이미지만 출력할 계획이었지만 팝업에서 출력 형태로 바뀌게 되면서 실제로는 거의 일어나지 않는 쓰러짐 때문에 공간이 낭비 된다고 생각해서 정차 신호를 좀 더 직관적이고 운전 중에도 확실히 인지할 수 있도록 stop 이미지를 출력하도록 추가하였다.

stop_sig에 따라 바뀌는 인터페이스(왼: 평상시, 오: stop_sig 발생)

 DB에 해당 버스의 stop_sig가 1로 바뀌게 되면 특정 정류장에서 승차벨을 눌렀다는 것을 의미한다. 버스 드라이버 인터페이스는 이러한 신호를 기다렸다가 1로 바뀌게 되면 사진과 같이 stop image를 출력해준다. 사진처럼 승차벨 신호가 없는 경우에는 왼쪽 사진처럼 기본 상태를 유지하게 된다. 만약에 stop_sig가 1로 바뀌게 되면 오른쪽 사진처럼 이미지 출력 부분과 신호 출력 부분 모두 stop에 해당하는 이미지를 출력하게 된다.

fall_sig에 따라 바뀌는 인터페이스(fall_sig 발생)

 stop_sig와 마찬가지로 fall_sig가 1로 바뀌게 되면 특정 정류장에서 쓰러짐이 발생했다는 것을 의미한다. 버스 드라이버 인터페이스는 쓰러짐 감지 신호를 기다렸다가 발생하게 되면 사진과 같이 해당 정류장의 이미지를 출력해준다. 현재는 해당 이미지를 출력하는 것이 아니라 신호가 발생하면 정해진 이미지를 출력하는 형태만 구현했다.

5) 버스 드라이버 인터페이스 알고리즘 순서도

버스 드라이버 인터페이스 알고리즘 순서도

마. 비접촉 터치 구현

1) 비접촉 터치 시스템 개요

Google Mediapipe를 이용한 비접촉 터치 시스템을 구축하였다. 비접촉 터치 시스템은 기존의 터치스크린과 같은 접촉이 필요한 입력 시스템이 아닌, 카메라나 적외선 센서 등을 이용하여 입력 장치와의 접촉 없이 입력을 할 수 있는 시스템이다. Mediapipe의 Hands solution을 활용하여 사용자의 손을 인식하고 인식 데이터를 기반으로 비접촉 터치를 구현했다. 해당 시스템은 기존 시스템과 다르게 사람과 사람 또는 물체 사이의 접촉을 최소화할 수 있는 장점을 가지고 있다. 또한 물리적인 접촉이 없기 때문에 내구성면에서도 이점이 있다.

2) Hands solution

Mediapipe의 Hands solution은 이미지 데이터의 손의 모양과 움직임을 감지하고 감지한 손의 3D landmark를 추출하여 데이터를 제공한다. 사진과 같이 손에서 총 21개의 landmark를 추출한다. 추출한 데이터를 통해서 카메라 상에서 손의 landmark의 x, y, z의 추론 값을 얻을 수 있다.

MediaPile Hands solution

3) Hand Tracking Module

Hands solution의 추론 값을 활용하여 이미지 내 손의 데이터를 얻기 위한 Hands Tracking Module을 구축했다. Hands solution에서 제공하는 각 landmark의 x, y, z 추론 값을 통해 총 3가지 함수를 구현했다.

가) findHands

findHands 함수는 입력 받은 이미지에서 추론한 landmark를 이용하여 이미지 내에 추론한 landmark를 그리고 landmark가 추가된 이미지를 반환하는 함수이다.

나) findPosition

findPosition 함수는 입력 받은 이미지에서 추론한 landmark를 이용하여 이미지 내에서 손이 포함된 영역(bbox)과 landmark 리스트(lmList)를 반환하는 함수이다.  bbox는 landmark를 비교해서 손이 포함된 직사각형 영역을 계산하고 이를 x, y 최대/최솟값으로 반환한다. lmList는 추론한 landmark의 x, y, z 값을 이용하여 각 landmark의 위치를 리스트 형태로 반환한다. 이때 각 landmark의 위치는 입력 이미지에서의 상대적인 위치로 변환하여 반환한다.

다) fingersUp

fingersUp 함수는 입력 받은 이미지에서 추론한 landmark를 이용하여 이미지 내에서 손가락의 상태를 나타내는 리스트를 반환한다. 손가락의 상태는 펴져 있는 경우 1, 접혀 있는 경우에 0을 나타내서 리스트에 입력된다. 손가락의 상태는 손가락 끝 landmark와 손가락 마디 부분의 landmark를 비교하여 손가락 상태를 결정하고, 리스트 형태로 반환한다.

4) Virtual Mouse

Virtual Mouse는 Hand Tracking Module에서 처리된 데이터들을 기반으로 현재 손의 상태를 추론하고 이를 기반으로 마우스를 조작할 수 있도록 한다. Virtual Mouse 중에서 마우스 클릭을 인식하는 부분과 마우스 이동을 인식하는 부분으로 구현했다. Virtual Mouse 동작은 총 3가지 동작을 인식하고 각각의 부문에 따라 마우스를 조작하게 된다.

가) Virtual Mouse 활성화

Virtual 마우스 활성화

Virtual Mouse 활성화는 사진과 같이 Virtual Mouse를 활성화하기 위한 동작 단계이다. 다섯 개의 손가락이 모두 보이도록 동작을 취하면 Virtual Mouse가 활성화되고 동작하게 된다. 활성화 이전에는 어떠한 모션이나 손도 인식하지 않고 활성화가 되면 동작을 인식하기 시작한다. Virtual Mouse 활성화는 다섯 개의 손가락, 손의 위치, 손과 카메라의 거리를 조건으로 하여 사용자가 키오스크와 적절한 거리에 있는지 확인하고 동작을 할 것인지 확인한다. 확인 후에는 마우스 조작을 할 수 있는 동작들을 인식한다.

나) 마우스 이동

마우스 이동

Virtual Mouse가 활성화되면 동작에 따라서 Virtual Mouse를 조작할 수 있게 된다. 총 2가지 동작을 인식할 수 있다. 첫 번째 동작은 마우스 이동이다. 사진과 같이 검지 손 하나만 편 상태로 손동작을 취하면 마우스를 이동할 수 있는 상태가 된다. 사진과 같은 상태에서 손을 움직이게 되면 분홍색 박스와 Hand Tracking Module에서 계산된 이미지의 상대적 위치를 계산하여 실제 마우스를 움직이게 된다. 손가락을 접거나 다른 손가락을 펴면 이동 조건을 벗어나게 되고 이를 이용하여 이동과 정지 동작을 취할 수 있다. (사진의 분홍색 박스는 손동작을 인식하는 범위로 박스 내에서 손동작이 이루어진다면 마우스를 이동시킬 수 있다. 실제 서비스 환경에서는 카메라가 보이는 것이 아니라 마우스 커서가 보이는 형태로 진행이 된다. 인식 범위 확인을 위한 박스이다.)

다) 마우스 클릭

마우스 클릭

마우스 클릭 동작은 마우스 이동 중에 할 수 있는 조작으로 이동 중에 클릭 조건을 만족하게 되면 마우스 커서의 현재 위치를 클릭하게 된다. 마우스 클릭 동작 인식은 Hand Tracking Module에서 계산된 상대적 움직임의 변화량, 분산 등을 고려하여 손가락의 움직임을 인식하고, 클릭하는 모션이 인식되면 마우스 클릭을 실행하게 된다.

5) 비접촉 터치 시스템 알고리즘 순서도

비접촉 터치 시스템 알고리즘 순서도

바. 전체 시스템 다이어그램

전체 시스템 다이어그램

사용자가 승차 버튼을 누르게 되면, 버스 정류장에서 서버에 신호를 전송한다. 만약 사용자가 승차 버튼을 취소하게 되면 취소 신호가 버스 정류장에서 서버에 전송되고 서버에 저장된 승차 신호가 취소된다.

서버에 승차 신호가 저장되면, 버스 단말기는 서버에 주기적으로 접근하여 신호를 확인하게 된다. 만약 신호를 확인했을 때 신호가 저장되어 있다면 해당 버스는 서버에서 신호를 받아와서 버스 기사 인터페이스에 출력하게 된다. 사용자가 정류장에서 쓰러지게 되면, 해당 정류장에 있는 쓰러짐 감지 시스템이 이를 인식하고 해당 정류장의 사진을 촬영하게 된다. 촬영된 사진은 마찬가지로 서버에 전송이 되고 저장된다. 저장된 이미지는 버스 단말기가 서버에 접근했을 때 fall_sig가 발생했으면 해당 정류장 정보와 사진을 받아 버스 기사 인터페이스에 출력하게 된다.

자재 소요서

자재소요서

결과 및 평가

완료 작품의 소개

프로토타입 사진 혹은 작동 장면

비접촉 터치 키오스크를 활용한 버스정차 테스트

쓰러짐 감지 시스템 주간 및 야간 테스트

포스터

완료작품의 평가

향후계획

1. 향후 추가적인 하우징 설계 및 분석을 통해 시제품으로 가치를 더욱 기대할 수 있음

- 실제 외부에 설치 시, 하드웨어의 내구성을 보강할 필요가 있음
- 현재는 폼보드를 이용해 외관을 제작했지만, 아크릴이나 철판등으로 제작 필요

2. 본 시스템의 확장성을 이용해 정류장 이외에 범용적으로 사용할 수 있는 시스템으로 확장 가능함

- 본 시스템의 비접촉 터치 시스템을 음식점이나 마트등에 사람의 접촉이 많은 곳에 적용 가능

3. 쓰러짐 감지 시 경찰서/소방서 등 공공기관에 전달 필요

- 현재는 버스기사 모니터에 팝업형태로 출력하지만, 실제 설치 시 낙상 감지했을 때 공공기관에 전파하는 시스템으로 구축 가능