무야호(그만큼재밌다는거지) - 무정차 방지 및 승객 안전을 고려한 정류장 시스템
프로젝트 소개
프로젝트 명
무정차 방지 및 승객 안전을 고려한 정류장 시스템 (Smart Bus Stop System for Passengers)
프로젝트 기간
2021.3~2021.6
팀 소개
서울시립대학교 기계정보공학과 (20164300**) (한*우) (팀장)
서울시립대학교 기계정보공학과 (20164300**) (고*준)
서울시립대학교 기계정보공학과 (20164300**) (유*신)
서울시립대학교 기계정보공학과 (20144300**) (오*규)
오픈 소스 코드
프로젝트 개요
1. 프로젝트 요약
- 본 프로젝트에서 무정차 방지 및 승객의 안전을 고려한 사용자 친화적인 정류장 승차 시스템을 설계한다. 해당 시스템은 버스를 이용하는 승객과 버스 기사들에게 편의성과 안전을 제공한다. 승객이 버스정류장에 설치된 인터페이스에서 특정 버스 번호를 선택하면, 현재 버스정류장에 가장 먼저 도착하는 버스에 탑승할 승객이 있음을 알린다. 또한, 인터페이스는 하차객이 많은 5개의 정류장들을 표시하며 승객이 정류장 버튼을 클릭하면 해당 버스정류장에 도착하는 버스들 중 현재 정류장에 가장빨리 도착하는 버스에 승차신호가 전달된다. 또한, 정류장에 설치된 카메라로 이미지 인식을 진행하여 통해 정류장에서 낙상사고(이하 Fall-Detection)가 발생했는지 여부를 파악한다. 만약 사고가 발생했을 때는, 가까운 버스에 현재 정류장의 상황사진을 보내게 된다. 이를 통해서 도심 외곽 쪽에서 대두되는 무정차 문제와 일반적으로 취약한 치안 문제를 동시에 해결하고자 한다. 시스템은 UX(User Experience)를 고려해 정류장을 이용하는 승객들이 직관적이고 쉽게 알아볼 수 있도록 제작한다.
2. 프로젝트의 배경 및 기대효과
가. 프로젝트의 배경
- 버스를 이용해본 경험이 있다면 기다렸던 버스가 정차하지 않고 지나가는 경우가 있을 것이다. 경기신문 최근 기사 내의 인터뷰에 따르면, 도민 A씨는 “어두운 정류장에서 긴 시간 기다렸으나 버스가 서지않고 그냥 지나친 적이 종종 있다. 그런 장소에서 유용하다고 생각한다.”고 말했다. B씨도 “외곽지역은 버스가 손을 흔들지 않으면 사람이 서 있어도 그냥 지나간다.”며 “’시내버스 승차벨 서비스’가 보편화되면 유용하게 쓰일 것 같다”고 답했다. 실제로 무정차 문제는 과거부터 지속적으로 있었던 문제로, 제대로 된 해결책이나 개선방안이 제시되고 있지 않았다. 최근 경기도 지자체에서 ‘경기 버스 정보’ 라는 모바일 애플리케이션을 통해 무정차 문제를 해결하고자 시도하였으나 제대로 된 홍보 효과가 미비하여 시민들이 존재 여부를 몰라 이용을 못하는경우가 대다수이며, 스마트 폰이라는 기기에 한정이 되어 스마트 폰 활용이 어려운 연령층의 사용자들에 대한 접근성을 고려하지 못하고 있다. 또한 실제로 대부분의 버스정류장의 치안 시스템은 CCTV 하나에 의존하고 있는 실정이다. 이러한 한계 때문에 도심 외곽 지역에서 시민의 치안 및 안전 관리에는 불리한 점이 존재한다. 도심 외곽에 집중하고 있는 시스템인 만큼 이용객이 혼자 있을 때 발생할 수 있는 범죄 및 사고 예방까지 고려한시스템이 필요하다고 판단되었다. 따라서 무정차 문제와 안전 문제를 동시에 고려한 기능이 추가된 시스템을 구현하고자 한다.
나. 프로젝트의 기대효과
- 무정차 방지 및 승객의 안전을 고려한 사용자 친화적인 정류장 승차 시스템은 승객이 타고자 하는 버스 번호 또는 가고자 하는 목적지를 선택하여 가장 가까운 버스에 승차하고자 하는 승객의 존재를 알린다. 이를 통해 버스기사는 승객의 존재를 사전에 인지할 수 있어 정류장의 승객을 못 보고 지나치지 않을 수 있고 승객이 없을 경우에는 정류장을 그냥 통과하여 교통 흐름에 방해가 되지 않는 원활한 운행을 할 수 있게 된다. 승객은 타고자 하는 버스에 사전에 탑승 의사를 알리기 때문에 무정차로 인한 문제나 불편함을 해소할 수 있다. 기존의 스마트 폰을 이용하는 방식이 아닌 버스 정류장에 직관적으로 인식할 수 있는 인터페이스로 된 터치스크린을 사용하여 스마트 폰과 같은 기기의 활용이 어려운 연령층도 사용할 수 있게될 것으로 예상된다. 또한 버스 정류장 내에서 이용객이 혼자 있을 때 발생할 수 있는 안전 및 사고 문제에 대해서 정류장에서 가장 가까운 버스기사에 정류장 내의 문제 상황을 인지할 수 있는 이미지가 팝업된다. 따라서 버스기사는 정류장에서 발생한 문제를 빠르게 파악하고 상황에 맞는 조치를 취할 수 있다. 이를 통해 안전 문제를 보완할 수 있고 발생한 상황에 대해 더 빠른 대응을 할 수 있을 것으로 기대된다.
3. 프로젝트 개발 목표
가. Bus Stop Interface
- 버스 정류장의 인터페이스는 UX를 고려하여 모든 사용자가 쉽게 알아볼 수 있고, 편리하게 사용할 수 있도록 제작한다. 사용자는 도착하고자 하는 정류장 또는 타고자 하는 버스 노선을 선택해 해당하는 버스가 정류장에 도착할 수 있도록 한다.
나. Fall-Detection
- Fall-Detection은 도심 외곽지역의 이용객이 적은 정류장에 승객의 안전을 보장하기 위해 적용한다. 카메라 모듈을 통해 얻어온 이미지에서 YOLO를 이용해 사람을 인식하고, 추가적인 알고리즘을 통해 사람이 쓰러졌음을 판단한다. 이후, 일정 시간동안 쓰러짐이 유지되면 해당 정류장에 가장 먼저 도착하는 버스 기사에게 경고성 현장 이미지를 팝업창으로 띄워준다. 이를 통해 버스기사는 사고 발생 현장을 제일 먼저 목격하고 조치를 취하도록 유도한다.
다. 버스 드라이버 인터페이스
버스에 장착하는 버스 드라이버 인터페이스는 버스기사가 운전 중에도 한눈에 알아볼 수 있도록 제작한다. 버스 기사용 화면에는 정류장에 탑승할 승객이 있다는 것을 알리는 정차 알림신호와 정류장에서 위급상황이 발생했을 때 정류장의 사진이 팝업된다.
동작 시나리오
1. 전체 동작 시나리오
2. 모듈별 동작 시나리오
가. Bus-Stop GUI(정류소 그래픽 유저 인터페이스) 시나리오
나. Bus-Driver GUI(버스기사 그래픽 유저 인터페이스) 시나리오
다. Fall-Detection(낙상 감지) 시나리오
구현 내용
1. 역할 분담
2. 시스템 구성
가. 전체 시스템 개략도
- Bus Stop GUI (버스 정류소 그래픽 유저 인터페이스)
- 버스정류장에 설치할 터치스크린의 인터페이스를 생성한다. 터치스크린을 통해 사용자는 타고자하는 버스의 번호나 가고자하는 버스 정류장을 UI를 통해 쉽게 알아볼 수 있고, 터치를 통해 편리하게 조작할 수 있다. 터치스크린은 크게 두 가지 부분으로 나뉘어 있다. 버스를 선택할 수 있는 부분과 버스 정류장을 선택할 수 있는 부분이다. 버스 번호를 선택하면 해당 버스에 승차객이 있다는 신호가 전송된다. 버스 정류장을 선택하면 해당 버스 정류장으로 이동할 수 있는 버스들 중 가장 빠르게 현재 정류장에 도착하는 버스에 승차객이 있다는 신호가 전송된다. 버스들의 도착정보나 정류장 정보는 공공데이터 포털에서 제공하는 API를 이용한다.
- Bus Driver GUI (버스 기사 그래픽 유저 인터페이스)
- 버스 기사용 스크린에 적용할 인터페이스를 구축한다. 인터페이스는 디스플레이를 통해서 데이터를 출력하는 형태를 통해서 버스 기사가 정류장에서 발생한 신호나 상황을 인지할 수 있게 한다. 주기적으로 웹서버에 접근해 DB에서 필요한 데이터를 가져오고, 가져온 데이터의 값에 따라서 출력되는 신호나 이미지를 갱신하도록 하였다. 갱신되는 데이터에 따라서 버스 기사는 승차 신호나 이미지를 보고 정류장의 상황을 확인하도록 한다.
- Fall-Detection (낙상 사고 감지 모듈)
- 도심 외곽지역의 이용객이 적은 정류장을 이용하는 승객의 안전을 보장하기 위해 쓰러짐을 감지하는 시스템을 의미한다. 알고리즘 진행은 다음과 같다. 카메라를 통해 얻어온 이미지에서 인공지능 모델을 이용해 사람을 감지하고, 추가적인 내부 연산을 통해 사람이 쓰러졌음을 판단한다. 그 다음, 일정 시간동안 쓰러짐이 유지되면 SFTP 프로토콜을 이용해 웹서버에 이미지를 전송하고, 버스 API를 이용해 해당 정류장에 가장 먼저 도착 예정인 버스의 고유 ID을 얻은 후, DB에 접근해 해당 버스의 FALL-D SIG 플래그를 올린다. 버스 기사 단말기는 서버에 주기적으로 접속해 FALL-D SIG가 올라가 있다면 서버에 저장된 이미지를 받아와 팝업을 띄운다. 이를 통해 버스기사는 사고 발생 현장을 제일 먼저 목격하고 조치를 취하도록 유도한다.
- Web Cloud Server Database (웹 클라우드 서버 데이터베이스)
- GCP(Google Cloud Platform)을 이용한 클라우드 웹 서버를 구축하였다. 개념설계보고서에서 설명한것과 같이 GCP를 이용한 웹서버 구축은 경제성, 유지보수성, 보안성, 복구성(Server Recovery)가 유리하다는 장점이 있다. 해당 웹서버는 무정차 방지 전체 시스템에서 필요로 하는 버스 UID(Unique ID), 버스정차 시그널(flag), Fall-Detection 시그널(flag) 데이터들을 관리하는 데이터 베이스를 구축하였다.
나. 모듈별 시스템 개략도
- Bus Stop GUI (버스 정류소 그래픽 유저 인터페이스)
- - 버스 버튼 구현
- i) 버스 버튼 생성
- 서울시의 버스 정류장에는 정류장마다 표준 버스정류장 ID가 존재한다. 이 표준 버스정류장 ID를 공공데이터 포털에서 제공하는 서울특별시_버스도착정보조회 서비스 API의 입력값으로 주면 해당 정류장에 도착하는 버스들의 정보들을 얻을 수 있다. 이를 통해 얻을 수 있는 데이터는 여러 가지가 있는데, 그 중 대표적인 것들을 나열하면 다음과 같다.
- 이 정보들 중 busRouteId 와 rtNm을 이용하면 특정 정류장에 도착하는 버스들의 목록을 얻어올 수 있다. 이 데이터를 이용해 버스 번호 버튼을 생성한다.
- ii) 버스 번호 버튼 클릭
- 이용자가 버스번호버튼을 클릭하면 해당 버스가 선택되었다는 팝업이 생성되었다가 1초 후 사라진다. 또한, 해당 버스 번호 버튼은 눌릴 수 없는 disable상태가 되고 이미지가 바뀌어 사용자가 해당 버튼은 눌린 상태라는 것을 알 수 있게 한다. 버스도착정보 API를 통해 얻어온 데이터 중 arrmsg1가 곧 도착에서 다른 문자열로 바뀌었을 때 버스가 정류장을 통과한 것이므로 버스 번호 버튼은 버스가 정류장을 통과했을 때 다시 눌릴 수 있는 상태로 변한다.
- - 버스 정류장 버튼 구현
- 버스 정류장 버튼은 하차 승객이 많고, 분기점이 되는 정류장 5개를 선택해 UI상에 띄운다.
- i) 하차 승객이 많은 정류장 선택
- 공공데이터포털에서는 서울특별시_버스노선별 정류장별 승하차 인원 정보를 csv파일 형태로 제공한다. 해당 데이터는 한 달 주기로 업로드 되며, 한 달간 정류장에 버스 노선별로 승하차하는 인원의 수를 제공한다.
- i) 하차 승객이 많은 정류장 선택
- 해당 파일을 process_csv.py 파일을 이용해 하차객이 많은 순서대로 정렬 후 관리자가 5개의 정류장을 선택해 표준버스정류장 id를 bus_stop.xml파일에 작성한다. 처음에는 하차객이 내림차순으로 정렬된 csv파일을 자동으로 읽어와 버스정류장 버튼을 생성하려했지만, 정렬해본 결과 중복되거나(ex 청량리역환승센터, 청량리역환승센타) 1~2정류장 이내의 정류장이 선택되는 경우가 많이 발생했기 때문에, 관리자가 xml파일에 직접 작성하는 방법을 선택했다.
- ii) 버스 정류장 버튼 생성
- 버스 정류장 인터페이스 생성시 이 xml 파일을 읽어온다. 이 때 ,버스 정류장 id와 버스정류장의 이름이 담겨있는 csv파일을 참조해 버스정류장 id와 함께 버스정류장 이름을 읽어와 배열에 저장한 후, 버스정류장 버튼을 생성할 때 이용한다. 표준버스정류장 ID를 바탕으로 그에 맞는 정류장명을 읽어와서 버튼 텍스트에 작성하게 된다.
- ii) 버스 정류장 버튼 생성
- - 버스 정류장 버튼 클릭
- 이용자가 가고자하는 버스 정류장 버튼을 클릭하면 우선 공공데이터 포털의 서울특별시_노선정보 조회 서비스를 이용해 가고자하는 버스 정류장에 도착할 수 있는 버스의 목록을 얻어온다. 버스 목록에는 버스의 고유 id(busRouteId)와 버스 번호(rtNm)이 순차적으로 담긴다. 그 다음 버스도착정보 API를 이용해 방금 얻어온 버스들이 현재 정류장에 언제 도착하는지 얻어온 후 해당 정보를 바탕으로 가장 빠르게 도착하는 버스가 선택된다. 000버스를 탑승하라는 팝업이 생성된 후 1초후 자동으로 사라진다.
- Bus Driver GUI (버스 기사 그래픽 유저 인터페이스)
- - 실제 버스 단말기와 유사한 디자인 구현
- 실제 버스 기사들이 쓰는 단말기를 구할 수 없으므로, 그와 유사한 GUI를 구현했다. 인터페이스에 출력되는 주요 요소는 현재 시간, 다음 도착할 정류장 이름, 앞선 버스의 위치, 뒷선 버스의 위치, 주요 시그널 이미지 출력 공간이다. 이 때 버스가 다음으로 도착할 정류장 이름을 얻어오고, 다른 버스들의 위치 정보를 얻어오기 위해서 '버스 위치 정보 API'를 사용한다.
- - 승차벨 출력
- 버스 정류장에서 승차 버튼을 누르면 웹서버 DB에 Stop Sig라는 항목이 해당 정류소의 고유 ID 번호로 올라간다. 이 때, 정류소의 고유 ID로 올리는 이유는 어느 정류장에서 승차벨이 눌렸는지를 API를 통해 판단하기 위해서이다. 운행중인 버스는 주기적으로 웹서버 DB에 접근해 해당 버스에 관한 내용중 Stop Sig가 올라가있으면 버스 기사 인터페이스에 Stop이라는 이미지가 팝업되어서 다음 도착할 정류장에 승차할 승객이 존재한다는 것을 알려준다.
- - Fall-Detection 이미지 출력
- 버스 정류장에서 일정시간 이상 쓰러짐이 감지된다면 웹서버에 해당 정류장의 상황 이미지가 저장되고, DB에 Fall Sig가 해당 정류장에 가장 빨리 도착하는 버스의 고유 ID번호로 올라간다. 이 때, 가장 빨리 도착하는 버스의 고유 ID번호로 올리는 이유는 웹서버에 올라간 여러 장의 이미지 중에서 버스가 다운로드 해야하는 사진을 구분하기 위해서이다. 운행중인 버스는 주기적으로 웹서버 DB에 접근해 해당 버스에 관한 내용중 Fall Sig가 올라가있으면 버스 기사 인터페이스에 해당 Fall-Detection 이미지가 팝업되어 낙상 사고가 발생했다는 것을 버스 기사에게 알려준다.
- Fall-Detection (낙상 사고 감지 모듈)
- - 객체 인식
- 웹캠에서 실시간으로 얻어오는 이미지들을 Yolov3-416 사물인식 인공지능 모델을 이용해 객체들을 인식한다. 최종적으로는 사람, 자전거, 개, 휴대전화 등등 무수히 많은 사물이 인식된다. 하지만 Fall-detection 알고리즘에서 필요한 객체는 사람뿐이므로, 사람 이외에 인식된 모든 객체들은 무시하고, 오직 사람에 대해서만 ROI 박스가 그려지게 수정했다. 아래 사진 중 왼쪽이 수정 전, 오른쪽이 수정 후이다.
- - 쓰러짐 인식
- 인공지능 모델을 이용해 얻은 사람의 ROI 박스 크기를 참조해 쓰러짐을 판별한다. 박스의 width를 height로 나눈 값이 1.1보다 크다면 사람이 쓰러진 상태라고 판단한다. 즉, 사람에 그려진 박스가 가로로 넓어진다면 쓰러진 상태라고 판단하는 것이다.
- 카메라 1대로는 쓰러짐이 인식이 안되는 경우가 있었다. 이를 해결하기 위해 다음과 같이 각각 다른 높이, 각도로 설치된 2대의 카메라를 통해 쓰러짐을 감지하도록 구현했다.
.png)
.png)
- - 쓰러진 이미지 저장
- 사람이 쓰러져있는 이미지를 버스 기사 단말기에 보내기 위해서는 먼저 젯슨 보드 내에 이미지를 저장할 필요가 있다. 그러나 쓰러짐이 감지되었을 때 바로 이미지를 저장하고 전송한다면, 넘어진 상태가 아닌데 잘못 인식했을 경우가 있을 수 있다.
- 위 사진처럼 사람이 카메라 앞으로 가까이 지나가서 ROI 박스의 가로가 넓게 측정될 수도 있으므로, 쓰러짐이 지속적으로 감지될 때부터 진짜 사고가 일어났다고 인지한다. 따라서 쓰러짐이 6초 이상 감지될 때부터 이미지를 젯슨 보드 내에 저장하도록 하는 기능을 추가했다. 이 때, 이미지는 계속 한 파일에 덮어씌운다. 6초 이상을 기준으로 한 이유는, 한 장의 이미지가 Yolov3-416 모델을 통해 객체 인식이 될 때의 시간이 약 0.6초(평균 fps = 1.67) 걸렸기 때문이다. 즉, 최소 이미지 10장이 처리될 동안 쓰러짐이 유지된다면, 젯슨 보드 내에 해당 이미지가 지속적으로 저장된다.
- - 이미지 전송
- 젯슨 보드 내에 저장된 이미지를 웹서버에 전송하기 위해서 SSH 파일 전송 프로토콜(Secure File Transfer Protocol, SFTP)을 이용한다. 기본적인 전송 과정은 다음과 같다. 쓰러짐이 지속되어 이미지가 덮어씌워져 저장된다면, 해당 이미지의 수정시간이 갱신될 것이다. 만약 수정시간이 갱신되었다면, 쓰러짐이 새로 발생했다는 의미이므로, 해당 이미지를 SFTP 프로토콜을 이용해 웹서버에 전송한다. 이후, 무한루프에 빠지게 되어 젯슨 내의 이미지 파일의 수정시간이 갱신될 때까지 기다린다. 이 과정을 무한히 반복하게 된다.
- - DB 접근 후, FALL-D SIG 플래그 수정
- 쓰러짐이 지속적으로 발생해서 이미지를 서버로 전송한 후, 가장 가까운 버스에게 쓰러짐 이미지를 받아가야 한다는 신호를 주어야 한다. 이것을 위해 DB에 FALL-D SIG라는 플래그를 추가한 상태이다. 젯슨 보드는 쓰러짐 이미지를 서버에 전송한 후, 버스 API를 이용해 해당 정류장에 가장 가까이 있는 버스에 대한 정보(UID 등)을 얻어온다. 이후, DB에 접근해 가장 가까이 있는 버스의 FALL-D SIG를 현재 정류장 고유 ID번호로 올린다. 그리고 쓰러짐이 감지되지 않는다면 해당 플래그를 0으로 다시 내린다. 이 기능을 구현한다면, 추후에 버스 기사 단말기가 서버에 접근해서 FALL-D SIG가 올라갔을 때 쓰러짐 이미지를 받아갈 수 있을 것이다.
- Web Cloud Server Database (웹 클라우드 서버 데이터베이스)
- - 웹 서버 인프라스트럭처(Infrastructure) 및 플랫폼(Platform) 구축
- 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구축까지만 사용하였다.
- - 데이터베이스 구축
- 데이터베이스는 Mysql 5.7을 사용하여 구축하였다. 데이터베이스의 구성은 bus_info database안에 bus_info table을 가지고 있다. 아래 사진과 같이 bus_info 초기 데이터베이스는 list넘버, 버스번호, 버스 UID, 정차신호 플래그, 데이터 업데이트 날짜순으로 예제 데이터를 가지고 있다.
- bus_info 데이터베이스는 실제 버스UID 정보와 클라이언트들이 요구되는 추가적인 데이터 정보에 따라 수정이 가능하며, CSV파일을 통해 얻은 실제 버스들의 정보들을 매크로 형식 dump의 데이터 정보를 불러와 데이터베이스를 새로 구축할 수 있도록 하였다.
- - 웹 데이터베이스 매니저 구축
- 웹 DB 비전문가 관리자도 손쉽게 DB를 관리할 수 있도록 웹 데이터베이스 매니저를 구축하였다. 기본적으로 PHP로 구축되어있으며, Mysql API를 통해 데이터베이스에 접근할 수 있도록 하였다. 데이터 기본 처리기능인 CRUD(Create, Read, Update, Delete)기능이 ‘add.php’, ‘list.php’, ‘edit.php’, ‘delete(기능)’형태로 제공되고 있다.
- edit과 add, list 조회는 ‘gcp-ip/bs/login.php’ URI를 통해서 로그인세션을 통과한 후에 접근할 수 있도록 하였고, 로그인이 되지 않은 상태에서 add, edit, list URI를 통해 접근 시 아래 그림과 같은 login 세션으로 리디렉션한다. 또한, edit과 add과정을 거치지 않고 update, insert 메소드 과정에서 URI로 접근시 Wrong access!메시지를 나타낸다.
- - Mysql Database API를 이용한 DB매니징
- 각 클라이언트(bus-stop, bus driver, fall-detection 모듈)에서는 ‘PyMysql’ 파이썬 클라이언트 라이브러리를 이용하여 웹서버 DB에 접근하여 CRUD 과정을 진행한다.
3. 하드웨어 설계 및 구현
가. 정류장 버스 정차 호출기
- 버스정차 호출기 CAD 모델링
- 하부 받침대: 400mm x 330mm x 280mm
- 기둥 : 지름130mm, 높이 550mm
- 신호기 : 305mm x 210mm x 100mm
- 버스정차 호출기 하드웨어
프로젝트 결과
1.최종 결과물
가. 최종 시스템 사진
나. 테스트 동영상
- 테스트 동영상 모음
- 야간 테스트 동영상 QR코드
프로젝트 협업 과정
1. 모듈별 소스 분산 버전 관리(GIT)
1. 깃허브 무야호팀 레포지토리 메인화면(1) 무야호 팀은 각 s/w개발 파트가 모듈단위로 분리되어있기 때문에, 브랜치 별로 개발을 나눠 진행했다. 버전관리는 모듈별로 진행하며, 최종 버전은 master브랜치에 통합된다.(2) 브랜치(모듈)별 README.md가 모두 존재하며 master README는 각각의 README통합 본이다. 마크다운언어로 기술되어있으며, 시스템 개략도와 각 모듈별 구성, 예시, 설치법등이 담겨있다.(3) 공동개발 참여자는 protoc***(오*규), DongJun***(고*준), han45***(한*우), ckdr***(유*신)으로 구성되어있다.(4) 시스템의 대부분은 파이썬을 기반으로 작성되었으며, 약 20%정도 웹 DB 매니저 구축에 이용된 PHP언어가 존재한다.
2. 정보 및 아이디어 공유(GIT Discussions)
초기 아이디어 구상 및 개발에 도움이 되는 데이터 및 정보를(img, text, video, url..) 디스커션을 이용하여 공유하였으며, 특정 주제의 discussion을 열고, 참여자들이 reply를 달면 등록된 이메일로 해당 내용이 전송이 되어, 효율적인 자료공유와 피드백이 가능하였다.
3. 계획 설정 및 공유(GIT Project)
(6)번 사진처럼 주차에 맞게 계획을 설정하고 각 주차 프로젝트에는 파트별 또는 단체 계획이 기술되어있다. To Do, In Progress, Done파트로 나누어서 계획, 개발 중, 완료를 markdown언어를 통해 표현이 가능하고 Drag and Drop으로 이동이 가능하다. 해당 기능을 통해 효과적으로 팀 내 진행상황을 공유할 수 있었다.
프로젝트 평가
평가항목
- 정류장 UI 편리성 평가
- 설문조사를 통한 UI 편리성을 평가한다. 설문조사 대상은 거주지역과 연령층이 다양하게 설정한다.(20명)
- 가장 먼저 도착하는 버스에 신호가 전달되는가
- 버스 기사 모니터를 준비한 후, 알맞은 버스에 승차신호나 Fall-Detection 신호가 잘 전달되는지(40회 반복) 확인한다.
- 사용자 입력으로부터 버스 기사 모니터 출력 시간
- 버스 정류장 인터페이스와 버스 기사 인터페이스 모듈에서 반복실험(100회)을 한 후, 평균 시간을 기록한다.
- Fall-Detection 정확도
- 사람이 쓰러진 방법을 다르게해가며 다양한 상황에서 Fall-Detection이 잘 인식되는지 반복실험(20회)을 진행한다.
- Error Detection
- 장치 호출 통신 간에 Error Detection을 적절한 곳에서 진행하는지 확인한다.
평가결과
- GUI 편리성 설문조사 평가
- 구글폼을 이용하여 5명에게 초기버전 버스정류장 GUI평가를 받은 후, 해당 내용을 바탕으로 15명에게 개선된 GUI를 평가받았다.
- 평가결과 평균 8.3이며 최고점수 10점과 최저점수 6점이 존재한다.
- 공통적인 요구 개선점은 버튼의 기능에 대한 설명부족, 버튼의 눌림상태에 대한 직관성 부족이였다.
- 최종 버전 GUI는 해당내용을 바탕으로 버튼의 색상과 눌림상태 표시, 도움말 추가와 사용자 액션에 대한 소리를 추가하였다.
- 가장 먼저오는 버스에게 신호가 전달되는지 테스트
- 각 버스번호 버튼을 눌렀을때, 해당 정류소로 다가오는 버스중에 정차신호를 보낸 버스번호에 해당하고 해당 정류소와 거리가 가까운 버스에게 신호가 정확히 가는지 확인하였다.
- 해당 테스트 서울시 공공 데이터 포털의 버스정보 API에 기반하기 때문에, API 오류가 없고, 서울시 공공 데이터 포털의 버스정보가 정확하다는 가정하에 진행되었다.
- 총 40회의 테스트를 시도하였고 40회 모두 성공하였다.
- 버스기사 모니터 출력시간 측정 자료
- 파이썬 time 라이브러리를 사용해 승차벨을 누른 후, 버스기사 모니터에 Stop 이미지가 뜨기까지의 시간을 타임스탬프 로그로 출력했다. 아래 사진은 총 100회 측정한 결과를 종합해 평균을 낸 결과이다.
- 측정에 사용된 기기(라즈베리파이와 노트북)의 시간 동기화는 WindowOS에서 제공하는 시계동기화를 각 디바이스에 적용 후에 진행되었다. 디바이스간 동기화 시간 차(offset)이 약 0.5초 이내로 나는것을 확인후, 결과 값을 보정하였다.
- Fall-Detection 정확도 확인
- 실내,야외,야간 상황등 다양한 상황에서의 낙상감지(Fall-Detection) 정확도 테스트를 진행하였다.
- 측정을 실패한 4가지 케이스는 사용자가 웹캠에 너무 가까이 있는 경우, 빛이 없는 어두운 환경, 웹캠 두개의 각도에서 벗어난 사각지대 경우들이다.
- 모듈별 Error Detection 구현
- 각 모듈은 try & except 함수를 통해 서버 연결을 시도하고, 연결실패시 에러문을 출력한다.
느낀점
한*우 - 어려웠던 점은 주제 선정과 개발 과정에서 새로 접하는 플랫폼에 대한 오류에 대응하기였습니다. 하지만 팀원 모두 열정적으로 참여를 하고 서로 도와주려는 태도를 가지고 있었기 때문에 문제들을 좋은 방향으로 해결해나갈 수 있었습니다. 프로젝트에서 실제 시스템을 구현한 것이 처음이었기 때문에 뿌듯하지만, 한편으로는 아쉬운점이 있습니다. 제가 개발했던 Fall-Detection에 대해 카메라 1대를 이용해서 완벽히 구현하지 못하고, 마지막에 2대로 설게를 변경하여 타협을 했습니다. 추후에 1대로도 쓰러짐 감지가 잘 이뤄질 수 있도록 개발을 하면 더 보람이 있을 것이라고 생각했습니다. 마지막으로 함께했던 팀원들과의 협업을 통해 효과적인 의사소통 과정, 의견 조율, 일정의 추진, 발표 자료 구성, 소프트웨어적인 기술 팁 등등 정말 많은 지식을 경험하고 쌓을 수 있었습니다.
오*규 - 무야호(그만큼재밌다는거지)팀명 뜻처럼 정말 즐기고자하는 뜻에서 팀명을 선정한것입니다. 주제 선정을 위한 아이디어 회의 및 프로젝트 진행 전략 회의만 4주동안 진행하며, 팀원들이 제시하는 아이디어에 감탄하는 한편 아이디어의 한계를 마주했을 때 안타까움도 컸었습니다. 하지만 4주라는 긴 시간을 투자한 만큼 기초가 튼튼했고, 원하는 결과를 최종적으로 얻을 수 있었습니다. 중간마다 있는 발표를 위한 준비때문이 아니더라도 매주 2회 이상 만나서 밤을 새가며 개발과 회의를 진행했습니다. 그럼에도 불구하고 모든 팀원이 시간을 쪼개서라도 참여하여 모든 회의에 참여도 100%를 달성하였습니다. 100%로 참여도 바탕으로 모든 팀원이 함께 개발하고 프로젝트를 진행해 나간것은 저희 팀 스스로 칭찬할만한 점이라고 보입니다. 처음 시스템 아키텍처를 구성할때 의견이 맞지않아 충돌도 있었지만, 그러한 충돌로 더 많이 조사하고 절충하여 보다 나은 방향으로 시스템 아키텍처를 구성할 수 있었습니다. GIT을 평소에 자주 사용한다고 생각했지만, 이번 프로젝트를 통해 GIT의 협업을 위한 기능들(issue, discussion, projects)을 추가적으로 사용하게되었으며 해당 기능등을 통해 효율적인 분업을 진행할 수 있었습니다. 새로운 도전을 하기위해 구글 클라우드 서버로 웹 서버 DB를 구축했다가 무료에서 유로로 전환되면서 유료 결제라는 예상치 못한 폭탄도 맞아보고, 평소에 궁금했던 php언어를 사용해 웹사이트도 구성해보게 되어 다양한 경험을 역동적으로 느낄수 있었던 기회였습니다. 마지막까지 최선을 다해주는 팀원들에게 감사를 돌리며, 많은 조언를 주신 교수님과 조교님들에게 감사인사를 올립니다.
유*신 - 프로젝트를 진행하는 매 주가 도전이었습니다. 기존에 사용해보지 않은 여러 가지 지식들과 기술들을 사용하면서 프로젝트가 진행되었는데 처음 하는 일들이 많아 뜻대로 되지 않았고 여러 가지 시행착오를 거쳐가는 과정이 매 주 새로운 도전을 하는 것 같았습니다. 처음에는 이러한 이유로 부담감만 잔뜩 가지고 시작했지만 프로젝트를 진행하고 기술들을 습득하는 과정에서 발생한 문제들을 팀원들과 고민하고 공유하면서 해결해 나아가는 과정을 통해서 이전과는 또 다른 새로운 경험들을 하게 되었다고 생각합니다. 돌아보면 매 주가 힘든 도전의 연속이었지만 좋은 강의를 통해 많은 것을 배울 수 있는 기회여서 뿌듯한 한 학기를 보낸 것 같습니다.
고*준 - 주제선정에서부터 많은 시행착오를 겪어가며 프로젝트를 진행했습니다. 주제선정 과정에서 팀원들이 적극적으로 참여해서 많은 좋은 아이디어들이 나왔고, 팀원들의 피드백과 교수님, 조교님들의 피드백을 통해 최종 주제를 선정한 후 프로젝트를 진행해나갈 수 있었습니다. 프로젝트의 최종 목표를 세우고 목표 달성을 위해 역할분담을 진행했습니다. 팀원들 모두 주어진 역할을 열심히 수행했습니다. 특히 서로의 모듈개발 과정에서 어려움을 겪거나, 선택해야할 사항들이 생겼을 때 팀원 모두가 적극적으로 참여하여 발생한 문제들을 해결할 수 있었습니다. 이번에 버스 정류장 인터페이스 부분을 맡아 pyqt5를 이용해 GUI도 생성해보고, 개발 과정에서 공공 데이터 포털에서 제공하는 API를 이용해 버스의 정보들을 실시간으로 받아와서 처리하는등 처음 경험해보는 일들을 많이 진행했던 것 같습니다. 특히 UX를 고려해 GUI를 만들 때, 사용자의 입장에서 생각해보고 실제 사용자들의 피드백을 받아보는 과정에서 모든 사용자를 만족하는 디자인은 만들기 쉽지 않다는 것을 느꼈습니다. 이번 프로젝트를 통해 git이나 pyqt5 사용법 등 많은 지식들을 얻게 되었고, 마지막으로 프로젝트 진행과정에서 가장 중요한 것은 무엇보다도 팀원들 간에 협동이라는 것을 느꼈습니다.
