"삼삼"의 두 판 사이의 차이

2021년 6월 18일 (금) 01:37 기준 최신판

프로젝트 개요

기술개발 과제

국문 : 날개를 달다

영문 : UOSWing

삼삼

지도교수

김민호 교수님

개발기간

2019년 3월 ~ 2019년 6월 (총 4개월)

구성원 소개

서울시립대학교 컴퓨터과학부 20179200** 우*은(팀장)

서울시립대학교 컴퓨터과학부 20169200** 최*기

서울시립대학교 컴퓨터과학부 20169200** 유*온

서울시립대학교 컴퓨터과학부 20179200** 김*빈

서론

개발 과제의 개요

개발 과제 요약

서울 시립 대학교에는 ‘양심 생리대 함을 운영하는 소모임 ‘날개’가 있다. ‘양심 생리대 함’이란 여학우들이 생리대를 무료로 가져갈 수 있도록 모아두는 서비스를 뜻하며 현재 서울 시립대 내에는 4개의 양심 생리대 함이 위치 하고 있다. ‘날개’팀이 생리대 함을 관리하는 과정에서 겪는 불편함과 이용자가 겪는 불편함을 파악하여 이를 개선하고자 ‘양심 생리대 함 관리 IoT 시스템’을 구축하여 서비스 애플리케이션인 ‘날개를 달다’를 개발하고자 한다.

개발 과제의 배경

<배경>
- 이용자나 관리자가 생리대 함의 위치를 파악하기 어렵다.
- 이용자나 관리자가 각 생리대 함의 생리대 개수를 파악하기 위해 반드시 직접 현장에 가서 확인해야 한다.
- 관리 인력의 문제로, 생리대 함을 추가로 설치할 때마다 유지비용이 계속 증가한다.
- 평균적으로 사용되는 생리대 양을 파악하여 대비하기 어렵다.
- 이용자와 관리자가 커뮤니케이션할 수 있는 수단이 제한적이다.
- 생리대 함이 설치된 위치를 관리자가 직접 기억하고 있다가 다른 봉사자에게 인수인계해주어야 한다.

<효과>
- 양심 생리대 함 관련 관리자의 수고를 절감한다.
- 양심 생리대 함 이용자의 편리를 증대시킨다.
- 관리자와 이용자의 소통이 증가한다.
- 기존보다 적은 비용으로 생리대 함을 증설할 수 있다.
- 생리대 함뿐만 아니라 다양한 상태 측정으로 응용될 수 있다.

개발 과제의 목표 및 내용

<개발 목표>
- 각 생리대 함의 위치와 상태(생리대의 개수, 온습도)에 대한 정보를 제공한다.
- 이용자, 관리자 간 커뮤니케이션 수단을 확립한다.
- 각 생리대 함의 사용 통계 정보를 제공한다.

<개발 내용>
4차 산업혁명의 중심 기술인 ‘IoT’의 센싱 기술, 유무선 통신 기술, IoT 서비스 인터페이스 기술을 통합한 애플리케이션을 제작한다.

개발과제의 기대효과

기술적 기대효과

적외선 센서를 이용한 효율적인 개수 측정

적외선 거리 측정 센서를 이용하여 생리대까지의 거리를 측정하여 생리대 개수를 파악하는 알고리즘이 실제로도 제대로 수행되는지를 파악한다. 생리대 개수 측정이 정확하기만 하다면 적외선 센서는 무게 측정 센서와 비교하여 가격도 저렴하고 기존 생리대 함의 기능을 훼손하지 않기 때문에 효율적이다.

슬립 모드를 활용한 배터리 지속 기간 연장

아두이노의 슬립 모드를 이용하여 전력 소모를 최소화함으로써 배터리 지속 기간을 늘린다. 보조배터리 10,000mAh 기준 최소 2주의 배터리 유지 기간을 유지하도록 노력한다.

하이브리드 앱을 이용한 확장 가능성 고려

하이브리드 앱을 이용하여 안드로이드 앱뿐만 아니라 IOS 앱까지도 한 번에 개발할 수 있도록 확장 가능성을 열어둔다.

REST API를 통한 통신

낮은 러닝 커브로 인한 빠른 개발과 서버의 부하 감소를 위해 하드웨어와 서버, 서버와 앱 간의 통신을 REST API를 이용한 HTTP 통신으로 처리한다.

경제적, 사회적 기대 및 파급효과

현재 활발히 이루어지고 있는 양심 생리대 함 사업에 이바지하여 더욱 많은 곳에 양심 생리대 함이 설치될 수 있다.
상태 측정이라는 분야에서 다양하게 활용될 수 있으며, 필요한 기능만을 수행하는 단가가 낮은 하드웨어를 사용함으로써 경제적 부담을 줄일 수 있다.
상태 관리에 필요한 인력 소모가 줄어들면서 유지비용이 저렴해지고, 상태에 대한 정확하고 신속한 관리와 통계를 제공할 수 있다.

기술개발 일정 및 추진체계

개발 일정

구성원 및 추진체계

API, DB 설계 및 백엔드 개발 : 유시온, 최문기
프로토타입 디자인 및 프론트엔드 개발 : 김수빈, 우희은
아두이노, 라즈베리 파이, 센서 모듈을 이용한 하드웨어 구현 : 전원

설계

설계사양

제품의 요구사항

양심 생리대 함 이용의 불편함을 파악하기 위해 현장에서 직접 봉사하고 ‘날개’ 팀과 세 차례 인터뷰를 거친 결과 다음과 같은 요구사항을 도출했다.
[D : 필수, W ; 선택]

- 각 생리대 함의 생리대 잔고를 실시간으로 확인한다. (D)
- 각 생리대 함의 상태(온습도)를 실시간으로 확인한다. (D)
- 시각적으로 각 생리대 함의 위치를 확인한다. (D)
- 생리대 함이 신설되었을 시 편리하게 추가, 수정, 삭제한다. (D)
- 관리자 기능에는 관리자만 접근할 수 있다. (D)
- 이용자는 생리대 함에 문제 발생 시 신고할 수 있다. (W)
- 관리자는 신고를 확인하고 처리 상태를 변경할 수 있다. (W)
- 관리자는 공지사항을 남길 수 있다. (W)
- 관리자는 기간별 생리대 소모 통계를 확인할 수 있다. (W)
- Application의 모든 동작에 대해 로딩 시간은 2초를 넘기지 않는다. (D)
- 사용자에게 직관적인 UI/UX를 제공한다. (W)
- 배터리를 약 한 달간 유지한다. (W)

기능 정의 및 기능별 정량목표

F1 : 생리대 함의 생리대 개수를 측정한다.
F2 : 생리대 함의 온습도를 측정한다.
F3 : 생리대 함의 위치와 생리대 개수, 온습도를 지도에 표시한다.
F4 : 사용자는 공지사항을 확인한다.
F5 : 사용자는 생리대 함에 대한 불편사항을 신고한다.
F6 : 관리자는 키로 로그인한다.
F7 : 관리자는 신고를 분류 별로 확인한다.
F9 : 관리자는 해결된 신고를 해결 처리한다.
F10 : 관리자는 측정된 생리대 소모 통계를 확인한다.
F11 : 관리자는 공지사항을 제목과 내용으로 관리(추가, 수정, 삭제)한다.
F12 : 관리자는 생리대 함을 이름과 위치로 관리(추가, 수정, 삭제)한다.

세부기술 선택사항

- 백엔드 : Java Spring, MariaDB, Amazon EC2
- 프론트엔드 : Google Play, React Native
- 디자인 : Adobe Photoshop, Figma
- 협업 도구 : Github, Swagger, dbdiagram.io
- 하드웨어 : 아두이노 wifi rev2, 라즈베리파이 zero w
- 기타 : JWT(보안 토큰), REST API(통신)

시스템 설계

Hardware에서는 주기적으로 생리대함의 상태(온도, 습도, 잔여 생리대 수)를 측정하고 API Server에 측정한 정보를 전송한다. 생리대를 보충한 전과 후에 버튼을 누르면 그 즉시 정보를 전송한다.
API Server에서는 생리대함 상태, 공지, 신고 등의 정보를 DB에 저장하고 Client App에서 요청이 올 때 정보를 전송해주거나, DB의 정보를 갱신하는 등의 역할을 한다. 또한 Hardware에서 생리대함의 정보를 전송해주면 생리대함 상태를 갱신하는 역할을 한다.
Client App은 사용자가 본 서비스를 쉽게 이용할 수 있는 환경을 제공한다. 사용자가 직관적으로 서비스를 이용할 수 있도록 UI를 제공하며, 사용자의 요청에 따라 API Server에 적절한 request를 보내고, response를 수신하여 사용자들이 보기 쉽게 나타내주는 역할을 한다. Client App은 Play Store를 통해 배포된다.

이론적 계산 및 시뮬레이션

1) 생리대 측정 알고리즘
하드웨어는 적외선 센서로 측정한 생리대까지의 거리를 이용하여 생리대의 개수를 측정하고, 온습도 모듈을 이용하여 온습도를 측정한다. 하드웨어는 다음과 같은 과정을 거쳐 생리대의 개수 및 온습도를 서버에 전달한다.
① WIFI 모듈을 사용하여 학교 와이파이에 연결한다.
② login API를 호출하여 관리자 TOKEN을 얻는다.
③ 생리대 함 상태 기록 API에 측정된 생리대 개수와 온습도를 매개변수로 하여 보낸다.
서버에서는 API로 전달되어온 정보를 가지고 바로 생리대 사용량 통계를 업데이트하며, 현재 해당 생리대 함의 생리대 개수를 업데이트한다.
애플리케이션에서는 사용자가 접속할 때마다 서버에서 생리대 함 관련 API를 받아오며, 지도 화면의 새로고침 버튼을 통해서도 해당 API를 재호출할 수 있으므로 갱신된 생리대 함의 상태를 확인할 수 있다.

2) 하드웨어 설치 방법
생리대 함 내부에 하드웨어를 설치하기 위해 포맥스로 틀을 구축하고 생리대 함 벽면에 부착한다.

처음에 생각했던 설치 시뮬레이션은 왼쪽 그림과 같다. 생리대 비축함에 버튼을 설치하고 각 생리대 라인에 적외선 센서, 천장에 빵판과 아두이노를 부착하기로 생각하였다. 하지만, 이렇게 구성하게 되면 연결된 배터리를 놓을 곳이 마땅치 않고 생리대의 진행을 방해할 수도 있기 때문에 오른쪽 그림처럼 구성하게 되었다. 아두이노와 빵판을 생리대 비축함 구석 벽면에 부착하고 적외선 센서는 측정의 정확도를 위해 세로로 부착하였다. 버튼 모듈은 그대로 생리대 비축함 천장에 부착하였으며 보조배터리 또한 생리대 비축함에 위치하게 된다.

3) 슬립 모드 깨우기
아두이노의 전력 소모를 감소시키기 위해 슬립 모드를 구현한다. 슬립 모드는 내부 타이머에 의해 한 시간에 한 번 깨어나게 되며, 버튼 인터럽트에 의해 곧바로 깨어날 수도 있다. 버튼 인터럽트에 의해 깨어나게 되면 1시간 내부 타이머가 재설정된다. 슬립 모드 라이브러리는 라이브러리에 따라 시간 차이가 발생할 수 있으므로 측정하여 최대한 1시간에 가깝게 세팅하도록 한다.

상세설계 내용

<하드웨어 설계>

사용한 부품

1. Arduino Uno WiFi Rev2 : 와이파이 기능을 포함하고 있는 보드이다. Arduino 통합 개발 환경을 이용하여 C언어로 명령어를 작성하고 개발한다.
2. DHT11 미니 온습도 센서 모듈 : 아두이노에 연결되어 생리대 함 내부의 온습도를 측정한다.
3. US-015 고정밀 초음파 거리 센서 모듈 : 아두이노에 연결되어 생리대까지의 거리를 측정한다.
4. 기계식 키보드 버튼 모듈 : 아두이노에 연결되어 슬립모드인 아두이노를 깨우는 역할을 한다.

<소프트웨어 설계>

뷰 설계

사용자 흐름 설계

① 메인 화면 이후 등장하는 지도 화면. 생리대의 개수를 색상으로 직관적으로 알 수 있다.
② 지도 화면에서 마커를 클릭하면 뜨는 모달. 생리대 함의 정보를 표시하며, 생리대 함이 한 건물에 여러 개일 경우 여러 생리대 함이 뜬다.
③ ②에서 생리대 함을 클릭하면 뜨는 신고하기 모달. 사용자가 불편사항을 신고할 수 있다.
④ 지도 화면에서 ⓘ버튼을 클릭하면 뜨는 모달. 관리자가 쓴 공지사항을 볼 수 있다.
⑤ 지도 화면에서 위치 버튼을 클릭하면 표시되는 화면. 자신의 위치를 확인할 수 있는 붉은 마커가 표시되며 학교 내에 있지 않을 경우 “학교 내에 있지 않으시군요!”라는 토스트가 뜬다.

관리자 흐름 설계

① 메인 화면에서 관리자로 로그인하면 등장하는 지도 화면. 생리대의 개수를 색상으로 직관적으로 알 수 있다. 신고가 있는 마커는 !로 표시된다.
② 지도 화면에서 마커를 클릭하면 뜨는 모달. 생리대 함의 정보를 표시하며, 생리대 함이 한 건물에 여러 개일 경우 여러 생리대 함이 뜬다.
③ ②에서 생리대 함을 클릭하면 뜨는 신고 확인 모달. 사용자가 신고한 불편사항을 볼 수 있다. 불편사항은 분류 별로 볼 수 있으며, 해결하였다면 해결 버튼을 눌러 해결할 수 있다.
④ 해결된 신고는 앱에서 보이지 않으므로 모든 관리자에게 신고와 해결 내용을 공유하라는 메시지를 표시한다.
⑤ 아래의 메뉴 탭 중 2번째 통계 탭을 누르면 나타나는 페이지. 주별, 월별로 생리대 함별 사용량이 표시된다.
⑥ 아래의 메뉴 탭 중 3번째 공지사항 탭을 누르면 나타나는 페이지. 관리자는 공지사항을 등록, 수정, 삭제할 수 있으며 긴 공지사항은 말 줄임표로 생략된다.
⑦ 아래의 메뉴 탭 중 4번째 설정 탭을 누르면 나타나는 페이지. 생리대 함의 위치와 이름을 입력하여 새로운 생리대 함을 등록할 수 있고, 기존의 생리대 함 정보를 수정하거나 삭제할 수 있다. 변경된 생리대 함의 정보는 바로 지도 화면에 반영된다.

<DB 설계>

DB 설계는 dbdiagram.io를 통해서 공유하였다. 엔티티는 생리대 함, 생리대 함 이력, 사용자, 사용자 권한, 공지사항, 신고가 존재한다. 하나의 생리대 함은 여러 생리대 함 이력을 가질 수 있으므로 1:N 관계이고, 하나의 생리대 함은 여러 신고를 가질 수 있으므로 1:N 관계이다.
신고는 is_resolved 속성으로 해결 여부를 판단하며, 해결되면 어플리케이션 사용자에게는 드러나지 않지만 DB에서는 삭제되지 않아 추후 확인할 수 있다.

<API 설계>
API 설계는 IntelliJ의 Swagger 플러그인을 이용하였으며, 문서화 된 설계서는 다음과 같다.

결과 및 평가

완료 작품의 소개

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

대표 기능은 위의 4가지로 구성되어있다. 첫 번째로 사용자 및 관리자는 지도 UI를 통해 생리대의 위치 및 현황을 직관적으로 확인할 수 있다. 관리자에게는 신고가 접수된 바 있는지를 나타내기 위해 ! 아이콘이 추가적으로 표시되며, 나머지는 사용자와 같다.
두 번째는 마커를 클릭했을 때 생리대의 개수 및 온습도를 자세히 확인해볼 수 있는 창이다. 같은 건물에 두 개 이상의 생리대 함이 위치해있을 때 한꺼번에 살펴볼 수 있으며 잔량은 범위로 표시되지만 하나도 없을 경우에는 0개로 정확히 표시된다.
세 번째는 사용자가 신고한 내역을 관리자가 보면서 해결하는 장면이다. 관리자는 각 생리대 함 별 사용자의 신고 내역을 분류 별로 볼 수 있으며 해결 시 해결 버튼을 눌러 없앨 수 있다. 마지막으로 공지사항을 작성하는 화면이다. 작성된 공지사항은 사용자 지도 화면의 우측 하단 메뉴를 통해 살펴볼 수 있다.

어플리케이션 링크

플레이스토어 '날개를 달다'

완료작품의 평가

1) 측정 방식 정확도

왼쪽의 사진과 같이 직접 생리대 함에 생리대를 하나씩 꽂아가며 정확도를 측정해보았다. 실제 값보다 측정된 값이 더 적게 나오는 경우는 없었으며 차이는 평균적으로 0.45개 정도 발생하였다. 실험 결과 대부분의 측정 오류는 아래쪽 생리대 측정 센서 때문이었고, 위아래로 막혀있는 구조여서 적외선 센서의 각도를 맞추고 제대로 작동시키기가 쉽지 않았다. 적외선 센서인 만큼 색상을 이용하면 쉽게 조절할 수 있을 듯하여 추후 과제로 남겨두었다.

2) 하드웨어 신뢰성

기존 이용하고자 했던 아두이노 UNO rev3의 LowPower라이브러리를 이용하여 1시간에 한 번씩 API를 호출했다. 시간당 약 2초 가량 부족한 오차가 났으며, 하루종일 API 호출을 진행해도 1분보다 적은 42초의 오차가 난다. 아두이노는 시간당 70mA를 사용한다. 이것은 1분에 1mA를 사용하는 것을 의미하며, 아두이노가 하루에 1mA를 더 사용하여 배터리에 유의미한 성능 차이를 보이지 않을 것이다.

3) 앱 로딩 속도
어플리케이션 동작 영상을 촬영하여, 프레임단위로 분석하여 각 화면 전환 시간을 측정했다.

(단위 : 초)
( 0.19 + 0.14 + 0.17 + 0.03 * 4 ) / 7 = 0.089

4) 서버 처리 속도

서버 처리 속도 항목은 AWS　EC2에 배포된 서버 프로그램을 이용하여 수행했다. 측정 방식은 각 API 별로 10회 호출하여 HTTP request의 실행 시간을 로그로 남겨서 측정했다, 이때 정확한 측정을 위해 저장을 할 때 매번 새로운 엔티티를 생성하도록 해서 캐시 이용을 최소화하고, 조회할 때도 cache를 초기화하도록 했다. 또한, 유저 로그인 API 측정 시에도 매번 세션이 초기화되도록 설정하여 측정 정확도를 높였다. 모든 API의 평균 처리시간은 13.24ms이다.

5) 소프트웨어 신뢰성: 0회
‘서버 처리 속도’를 측정하며 동시에 API 요청 시에 오류 발생 여부도 확인했다. 총 18개의 모든 API를 테스트하는 동안 오류는 단 1회도 발생하지 않았으며, 정상 작동하는 것을 확인할 수 있었다.

어려웠던 내용들

<하드웨어 관련>

1. 생리대 개수 파악 알고리즘

생리대 개수 파악 알고리즘 설명도

생리대의 개수를 측정하는 방법은 두 가지가 있다.

1) 무게로 측정하는 방법
2) 거리로 측정하는 방법

‘날개를 달다’에서는 적외선 거리 측정 센서를 이용하여 거리를 측정하고, 측정된 거리로 생리대의 개수를 파악하기로 하였다. 적외선 거리 측정 센서를 선택한 이유는 다음과 같다.

▶ 가벼운 생리대의 특성상 무게 측정 센서가 정확하지 않을 수 있다.
▶ 기존에 설치되어있는 생리대 함은 생리대를 꽂는 레일이 있으므로 무게 측정 센서를 방해되지 않게 설치하기가 쉽지 않다.
▶ 무게 측정 센서의 가격은 1만원 내외로 1천원 대인 적외선 센서와의 가격 차이가 8배 가량 난다.
▶ 초음파 센서는 센서를 위한 환경 조절이 적외선 센서보다 까다롭다.
▶ 적외선 센서의 경우 색을 이용하여 정확도를 더욱 높일 수 있을 것이라고 예상했다.

다음으로 적외선 센서를 이용하여 측정한 거리를 어떻게 생리대 개수로 변환하는 지에 대한 설명이다. 그림에서의 1번과 2번은 적외선 센서를 부착할 곳이다. 해당 위치에 부착된 적외선 센서는 생리대까지의 거리를 측정하게 된다. 우선 실제 서비스 전 5번(생리대가 하나도 없을 때의 거리)과 4번(하나의 생리대가 있을 때의 거리)을 측정한다. 3번은 실제 측정된 거리를 뜻하는데, 생리대의 개수는 다음과 같이 측정된다.

1) 측정된 거리가 4보다 크면 생리대가 없다. (0개)
2) 측정된 거리가 4보다 작으면 4에서 측정된 거리를 빼준 후 생리대 한 칸의 너비로 나누어준다.

이러한 방식의 측정은 실제 사용 시 생리대가 수직으로 서있지 않으므로 정확한 개수 파악을 보장할 수 없다는 단점 때문에 생리대의 개수를 서비스 측면에서 범위로 표현하기로 했다. 하지만 관리자 및 사용자에게 중요한 정보는 생리대가 아예 없을 때이고 위와 같은 측정 방식은 생리대가 아예 다는 것을 정확하게 인식하여 정보를 제공할 수 있으므로 이러한 측정 방식을 도입하였다.

하드웨어 실시간성, 지속성 확보

본 시스템은 하드웨어의 전력 공급 방법으로 보조배터리를 사용한다. 보조배터리는 방전되면 교체해주어야 하므로 최대한 오랜 시간 동안 유지되어야 한다. 따라서 아두이노를 슬립 모드로 구현하여 전력 소모를 감소하도록 하였다. 아두이노는 슬립 모드를 유지하다가 다음 두 가지 상황에 깨어나게 된다.

1) 한 시간이 지났을 때
2) 사용자가 부착된 버튼을 클릭하였을 때

아두이노는 한 시간 간격으로 슬립모드에서 깨어나 생리대 개수를 측정하고 다시 잠들게 된다. 이러한 방식의 문제점은 관리자가 생리대 함의 생리대를 채웠을 때 해당 상황에 앱에 빠르게 반영되지 못한다는 것이다. 이러한 상황은 예기치 못한 통계 오류를 야기한다. 예를 들어 측정 주기 사이에 생리대를 두 개 소모한 뒤, 열 개를 보충했다면 실제 측정 시에는 생리대 8개가 늘어나게 되는 것이다. 즉, 생리대 소모를 정확히 측정할 수 없다. 따라서 본 시스템은 버튼 모듈을 부착하여 봉사자가 생리대를 채우기 전, 생리대를 가득 채운 후에 한 번씩 버튼을 누를 수 있도록 유도하였다. 생리대를 채우기 전 버튼을 누르게 되면 기존에 소모된 생리대가 집계되며, 생리대를 채우고 난 후에 버튼을 누르게 되면 채워진 생리대의 개수가 앱에 반영된다. 버튼을 누르면 기존에 설정되어 있던 한 시간 타이머가 리셋되며 버튼을 누른 순간부터 다시 작동하게 된다.

WIFI 연동 문제

WIFI의 보안 인증 종류 중 많이 쓰이는 보안 인증은 (SSID와 인증서)를 이용하는 EAP-TLS와 (SSID 와 PASSWORD, 인증서, 이중 인증)을 이용하는 EAP-PEAP가 있다. 서울 시립대학교도 EAP-PEAP 방식의 보안 인증을 사용하는데, 문제는 EAP-PEAP 방식 중 상용화되어있는 MSCHAPv2 방식이 아닌 GTC 방식을 사용한다는 것이다. EAP-GTC 방식의 보안 인증은 시스코에서 자체 개발한 보안 인증 방식으로 하드웨어와의 연동에 대한 제대로 된 예제가 나와 있지 않다.
‘날개를 달다’를 구현하던 중 WiFi와 관련하여 시도해 본 방법들은 다음과 같다.

1) 아두이노 UNO Rev3로 시도
처음에는 아두이노 UNO Rev3 보드를 사서 다른 센서 모듈들을 설치하고 테스트 해보았다. 해당 보드에는 wifi 관련 기능이 탑재되어있지 않으므로 별도로 wifi 모듈(ESP8201)을 사서 연결하고 테스트 해보았는데, ssid와 비밀번호를 사용하여 접속해야하는 MSCHAPv2 방식의 접속이 정상적으로 이루어지는 것을 확인하였다. 하지만 실제 구동 환경인 학교에서 와이파이 연결을 시도했을 때 실패하였고 그 이유는 학교에서 EAP-GTC 방식을 사용하기 때문이라는 것을 알게 되었다. 인터넷 서핑과 연결 시도를 계속해서 해본 결과 아두이노 UNO Rev3 버전으로는 EAP-GTC를 연결할 수 없다는 사실을 발견했다.

2) 아두이노 WiFi UNO Rev2로 시도
다음으로 시도해 본 보드는 아두이노 WiFi UNO Rev2 모델로 wifi 기능이 내부에 탑재되어 따로 모듈을 설치해 줄 필요가 없었다. 기존의 아두이노 UNO Rev3에서 썼던 라이브러리들이 해당 모델에서는 지원되지 않는 경우가 많았기 때문에 새롭게 센서 모듈들을 설치하고 코드를 구성하였다. 해당 모델에서도 MSCHAPv2를 연결하는 라이브러리들은 많지만, GTC 방식을 지원하는 라이브러리는 찾아보기 힘들어 아직까지도 서칭 및 연구 중에 있다.

3) 라즈베리파이 ZERO W
아두이노는 개발 비용을 줄이기 위해 선택한 사안이었지만, 생각보다 라즈베리파이의 가격이 저렴하다는 것을 알게 된 후 라즈베리파이 중 저전력으로 동작하는 ZERO W 모델을 구매하게 되었다. 라즈베리파이 ZERO W는 gpio핀을 따로 부착해주어야 하므로 다음과 같이 납땜해주었다.

그 후, SD카드에 OS를 설치하고 설정 파일을 수정해주었으며 USB를 통해 SSH 연결을 시도하였다. 이 과정에서 다음과 같은 오류가 발생하였다.

▶ 오류1: SD카드에서 config.txt와 cmdline.txt를 제대로 수정하지 않아서 PC에서 usb를 인식하지 못함
▶ 오류2: usb 드라이버(RNDIS 드라이버)가 설치되지 않음. 윈도우에서 자동으로 설치해주지 않아서 인터넷에서 수동 설치 방법을 찾아서 수동으로 설치함
▶ 오류3: WiFi 공유 설정(“다른 네트워크 사용자가 이 컴퓨터의 인터넷 연결을 통해 연결할 수 있도록 허용(N)”)
▶ 오류4: 윈도우에서 mDNS를 지원하지 않아서 애플의 프린터 드라이버를 설치해야함. Bonjour라는 소프트웨어를 설치함

위의 오류를 해결하고 결과적으로 USB SSH 연결에 시도하고 센서 모듈 및 API 통신 구현을 완료하였다. 하지만 라즈베리파이에서도 WIFI를 연결 시 GUI를 통하여 연결할 수 없었으며, raspi-config 파일을 이용해서도 연결할 수 없음을 알아내었다. 따라서 wpa_supplicant.conf 파일을 직접 작성하여 교내 wifi 연결을 시도해보았지만 연결에 실패하였다.

network={

       ssid="Member@UOS"
       scan_ssid=1
       proto=RSN
       mode=0
       key_mgmt=WPA-EAP
       pairwise=CCMP
       eap=PEAP
       identity="XXXXX"
       password="XXXXX"
       phase1="peaplabel=0"
       phase2="auth=GTC"

}

다음은 WIFI 연결을 시도한 캡처본이다.

▲ 라즈베리파이를 통하여 연결하려는 SSID(Member@UOS)를 스캔에 성공

▲ 학교 와이파이에 연결한 경우 실패하는 메세지(SSID: Member@UOS)
(wext 드라이버와 nl80211 드라이버를 모두 시도해봄)

▲ 반대로 간단하게 스마트폰 핫스팟을 이용하여 연결 시 성공하는 메세지

<백엔드 관련>

서버 운영 비용

처음에는 데이터 분산을 위해 서버 프로그램이 작동할 EC2와 DB 서버(RDS)를 분리해서 구성했다. 그러나 다음과 같은 이유로 이를 분리했을 때 얻는 득보다 잃는 것이 많다고 판단했다.

1. EC2 + RDS로 시스템은 구축 비용이 많이 소모된다.
EC2 단일 시스템으로 운용하면 한 달에 약 2만원의 비용이 발생한다. 반면 EC2와 RDS를 따로 분리해서 운영하면 한 달에 4만원의 비용이 발생하는 것으로 추정된다. 따라서 2배의 차이가 발생하고, 이는 실제 운영 시에 큰 부담이 될 것으로 판단된다.
2. AWS RDS에서 제공하는 기능 대부분을 사용하지 않는다.
현재로서는 RDS에서 제공하는 패치, 백업 관련 기능, 스케일링 기능 등 유용한 기능들을 사용할 필요가 없기 때문에 굳이 돈을 더 들여가며 RDS를 사용할 필요가 없다고 판단했다.

이에 따라 DB 서버를 따로 분리하지 않고, EC2에 DB를 설치하여 사용하는 방식을 택했다.

양방향 엔티티 참조로 인한 순환 호출 문제

Report와 PadBox 엔티티는 서로를 참조하는 양방향 참조 관계이다. 그래서 둘 중 한 엔티티를 조회하거나 json으로 변환할 때 순환 호출이 발생했고, 이에 따라 무한 루프에 빠지게 되었다.
이를 해결하기 위해 우선 DTO(Data Transfer Object)를 분리하여 해당 DTO에는 각 엔티티의 참조 정보를 가지지 않게 만들었고, json으로 변환 시 DTO를 이용하여 변환하도록 수정했다. 이러한 문제를 겪으면서 엔티티와 DTO를 구분해야하는 이유를 깨달았다.

<프론트엔드 관련>

Android 버전 오류

React Native로 개발된 어플리케이션 ‘날개를 달다’는 android 11 버전이 사용하는 sdk 30 버전을 지원한다. android 11 버전에서 변경된 요소들이 있어 따로 설정이 필요하다. 먼저, 낮은 버전의 android에서는 잘 동작하는 어플리케이션이 11 버전에서만 팅기는 현상이 발생했다. 이는 android 11 버전이 sdk 30버전을 지원하기 때문인데, compilesdkversion = 30 으로 조정하면 된다. 두 번째로 11버전에서만 Network error가 계속해서 발생하였다. 이는 네트워크 권한이 바뀌었기 때문이므로 INTERNET에 대한 권한을 열어주고 기재한 네트워크 보안 설정 파일이 사용될 수 있도록 조정하면 된다.

마커가 겹치는 현상

어플리케이션의 지도 화면은 ‘react-native-maps’라는 라이브러리를 이용하여 구성하였다. 해당 라이브러리에서 마커를 커스텀하여 표시할 수 있었으므로 기존에는 생리대 함의 생리대 개수와 온습도까지 지도 화면에 바로 표시되도록 구상하였다. 하지만 구현 후에 가까운 건물에 위치하는 마커가 겹치는 이슈를 발견하고 해결 방법을 모색해보았다.

1) 스위치 버튼을 두어 누르면 뒤에 있는 마커가 앞으로 나오게 한다.
=> 해당 방식은 여러 개의 마커가 있을 때 불편함을 초래한다.
2) 자동으로 해당 마커를 클릭하면 뒤에 있는 마커가 앞으로 나온다.
=> 마커를 클릭하면 바로 해당하는 정보가 떠야 하므로 UX 적인 불편함을 초래한다.
3) 마커의 크기를 줄인다.
마커의 크기를 줄이고 기존에 생리대의 개수를 직관적으로 표현하던 마커의 색상이라는 요소를 유지하여 사용에 불편함이 없도록 개선하였다. 마커는 처음에 해당 생리대 함의 이름만 없애는 것으로 개선하려 했지만, 마커 겹침 현상이 해결되지 않아 개수 또한 빼는 것으로 결정하였다. 마커의 변경 흐름은 다음과 같다.

세 번째와 같이 작은 마커로 구현하였으나 가까이에 있는 마커들이 한꺼번에 클릭 되거나 마커가 아닌 위치를 클릭해도 마커가 클릭 되는 문제가 발생하였다. 원인을 분석해보니 react-native-maps 라이브러리가 Google map을 기준으로 지도를 띄우게 되는데, 마커 자체의 최소 크기를 생각보다 크게 고정해둔 것이었다. 이는 라이브러리 사용자로서 조절할 수 있는 사항이 아니었기 때문에 결국 zoom level을 조금 높여 마커 간의 간격을 벌리는 식으로 해결하였다.

향후계획

1) IOS 버전 앱 구현
현재 안드로이드 버전만 배포되어있으므로 IOS 설정 완료 후 IOS 버전 앱을 앱스토어에 배포하려고 한다. 하이브리드 앱인 React Native를 사용하였기 때문에 코드는 크게 변경될 필요 없이 배포 가능할 것으로 예상한다. 추가로 앱스토어 개발자 등록이 필요하다.

2) WIFI 2차 인증방식 해결

PEAP-GTC 보안인증 방식을 가진 WiFi에 아두이노가 접속하지 못하는 문제를 해결하기 위해 모색해 본 방안은 다음과 같다.

① 화장실에 무선 통신 변환기를 설치하여 학교 와이파이에 쉽게 접속할 수 있도록 한다.
② 라즈베리 파이를 이용하여 와이파이를 연결한다. (Network Manager 이용)
③ 아두이노 우노를 이용한 WIFI 연결 라이브러리를 더 찾아서 이용해본다.
④ Member@UOS가 아닌 Welcome@UOS나 Guest@UOS를 사용할 수 있는 방안을 모색해본다.
⑤ 전산과에 문의해본다.

우선 1번의 해결책은 장비 비용이 너무 비싸다는 점과 무선 통신을 증폭하는 역할의 기기는 많으나 무선 통신 방식 자체를 변환할 수 있는 기기를 찾지 못하여서 기각되었다. 두 번째부터 다섯 번째까지의 방법은 계속해서 시도해보고 있다.

3) 생리대 측정 정확도 향상
현재 생리대 함 아래쪽 생리대 라인에 부착되어있는 적외선 센서 때문에 생리대 개수 측정 오차율이 0.45개로 나타났다. 5개 단위의 범위로 나타내기로 하였으므로 허용 가능한 범위의 오차율이지만 적외선 센서의 특성을 이용한 향상 가능성을 염두에 두고 있기 때문에 색상 차이를 이용하여 더욱 정확성을 올리는 방향으로 실험 해보려고 한다.

4) 날개 팀과의 추후 유지비용 협의
해당 앱의 구현이 끝나면 현재 양심 생리대 함과 관련하여 봉사하는 소모임인 ‘날개’ 팀에서 직접 사용할 수 있다. 서버 유지비용과 생리대 함 증설 시 드는 비용을 감당할 수 있는지와 서버 및 UI 문제가 생길 것을 대비하여 관리 인력이 필요하므로 추후 어떤 방향으로 갈지에 대한 협의가 이루어질 것이다.

@@ 274번째 줄: / 274번째 줄: @@
 [[파일:삼삼향후평가1.png]]
 <br/><br/>
-) 측정 방식 정확도
+) 측정 방식 정확도<br/>
 [[파일:삼삼향후평가2.png]]<br/>
 왼쪽의 사진과 같이 직접 생리대 함에 생리대를 하나씩 꽂아가며 정확도를 측정해보았다. 실제 값보다 측정된 값이 더 적게 나오는 경우는 없었으며 차이는 평균적으로 0.45개 정도 발생하였다. 실험 결과 대부분의 측정 오류는 아래쪽 생리대 측정 센서 때문이었고, 위아래로 막혀있는 구조여서 적외선 센서의 각도를 맞추고 제대로 작동시키기가 쉽지 않았다. 적외선 센서인 만큼 색상을 이용하면 쉽게 조절할 수 있을 듯하여 추후 과제로 남겨두었다.<br/><br/>
@@ 438번째 줄: / 438번째 줄: @@
 ) 날개 팀과의 추후 유지비용 협의<br/>
 해당 앱의 구현이 끝나면 현재 양심 생리대 함과 관련하여 봉사하는 소모임인 ‘날개’ 팀에서 직접 사용할 수 있다. 서버 유지비용과 생리대 함 증설 시 드는 비용을 감당할 수 있는지와 서버 및 UI 문제가 생길 것을 대비하여 관리 인력이 필요하므로 추후 어떤 방향으로 갈지에 대한 협의가 이루어질 것이다.
-===특허 출원 내용===
-내용