Technical FEATURE
Technical FEATURE
[연재] 제 9회 임베디드 소프트웨어 공모대전 수상작 - 대상
안드로이드 기반의 스마트 내비게이션"Well-Ving" ①
글 장성훈, 김상민, 어유경, 최재용, 임동훈 / 경기대학교 전자공학과
자료제공 임베디드소프트웨어산업협의회(www.kesic.or.kr)
1 개요
1.1. 작품 제목_" Well-Ving"
"Well-Ving"은 Well과 Driving이 합쳐진 단어로써 건강한 운전, 즉 좋은 운전습관 및 안전한 운행을 하자는 의미이며 또한 우리말로는 건강한 인생 또는 행복추구라는 뜻이 담겨있다.
1.2. 작품 개요
매년 차량이 증가하고 그에 따라 교통사고 또한 증가하고 있으며 사용자들에겐 보험료 증가라는 부담으로 돌아오고 있다.
미국 고속도로 안전 보험 연구소 IIHS에서 다양한 안전시스템(자동 주차, 차선 이탈 경고, 충돌 경고 시스템 등)이 장착된 V사의 한 모델의 소유주들에게 조사한 결과 74%가 오작동에 의해 잘못되거나 불필요한 경고를 받았던 적이 있다고 대답했음에도 불구하고 94%가 그와 같은 시스템을 계속 원한다고 답했다. 사용자들은 몇 번 오작동을 한다고 해도 위험한 상황에서 한 번 도움이 된다면 만족하고 이 시스템이 교통사고 예방에 도움이 된다고 생각하는 것이다.
또한 우리나라에서도 증가하는 교통사고와 도로 곳곳의 정체 등을 해결하기 위해 국가 R&D 사업으로 "스마트 하이웨이"라는 도로와 차량 간, 차량과 차량 간의 통신을 이용한 교통사고 예방 및 운전자 편의를 위한 사업을 추진하고 있다.
이처럼 심각해진 문제를 별도의 장비 없이 요즘 흔히 가지고 있는 스마트폰을 사용하여 조금이라도 더 해결할 수 있다면 많은 사용자들에게 도움이 될 것이다.
Well-Ving은 안드로이드 OS기반의 스마트폰이나 태블릿 PC에서 실행시킬 수 있으며 기존의 테이타화 되어 있는 지도를 이용한 길 안내 시스템이 아닌 실제 운전자가 주행하고 있는 도로의 영상을 기반으로 도로 위에서 가야 할 길, 위험지역 등을 표시해주는 내비게이션이다.
또한 사용자에게 위험 알림 등의 기능들은 기존의 방식이 아닌 실시간 도로의 상황에 대해 알려줌으로써 불필요한 경고 알림을 없애고 정보가 필요할 때만 경고메세지, AR기능을 이용하여 사용자에게 보다 보기 쉽게 제공해준다는 장점이 있다.
1.3. 개발 목적
기존 2D를 사용한 내비게이션은 우리에게 많은 편의성을 주었지만 사용자들에게 정확한 길안내를 하기엔 다소 무리가 있었다. 길이 조금 복잡한 경우 몇 미터 앞에서 좌·우회전을 하도록 안내를 하지만 사용자가 직접 그 거리를 눈으로 가늠하는 것이 힘들었고 조금 더 자세한 내비게이션의 경우, 맵을 통해 알려주지만 연속되는 좌ㆍ우회전들의 경우에는 그 방식에도 한계가 있었다.
그러한 문제점들로 인해 최근에는 3D 내비게이션까지 등장했다. Map상에 도로뿐만 아니라 실제의 빌딩 및 기타 건축물까지 똑같이 그려줌으로써 현실 세계와 거의 비슷하게 만들어 기존의 불편함과 단점을 모두 해결해 보려 하였다. 하지만 막상 사용해 보았던 사용자들은 너무 UI가 복잡하여 '적응이 필요하다', '사용료를 내야한다', '서울 외각을 벗어나면 3D가 의미가 없다' 등의 단점을 집어냈다.
또한 개발자 입장에서는 건물의 모양이나 높이까지 고려한 많은 양의 데이터를 관리한다는 것이 쉽지 않은 일이라 생각이 된다.
따라서 이러한 문제점들을 해결하고자 실제와 비슷한 모습의 데이터를 만들어 사용하는 방식이 아닌 운전자들이 직접 보는 실제의 배경을 사용하고자 하는 목적으로 만들어진 프로그램이 Well-Ving이다. 다음 시나리오를 살펴보자.
#시나리오 1. 기존의 일반 내비게이션을 사용하는 경우
여름 방학을 맞아 친구들과 여행을 가기로 한 동훈이와 친구들은 2대의 차량으로 여행을 가려고 계획을 세웠다. 처음 가는 곳이라 걱정은 됐지만 중간 지점에서 만나기로 하고 기존 내비게이션의 안내를 따라 출발을 했다. 운전을 해본 경험이 많은 동훈이는 자신 있게 운전대를 잡았다. 중간 중간 '안개 잦은 구역' 및 '사고다발 구간' 이라는 경고 표지판이 있지만 '안개? 이렇게 맑기만 한데?' 라는 생각을 하며 신경 쓰지 않고 놀 생각에 들떠 있다.
얼마 가지 않아 동훈이는 당황하게 되었다. 경고 표지판이 있었던 곳에서 부터 먼 곳까지 왔는데 도로에 안개가 자욱하게 꼈으며, 심지어 고속도로 중간에서 교통사고가 난 것이다. 내비게이션 음성안내에만 집중한 동훈이는 갑작스러운 사고로 추가적인 사고가 날 뻔 한다.
마음을 가라앉히고 동훈이는 다시 운전에 집중한다. 드디어 다른 차량과 만나기로 한 중간지점에 다다른다. 하지만 20분이 지나도 오지 않는 다른 차량 때문에 동훈이는 걱정을 하게 된다. 걱정 끝에 전화를 해보지만 운전이 서툰 다른 차량 운전자는 자신들의 차량이 어디쯤인지 파악하지 못 한다. 동훈이는 답답한 마음으로 그냥 도착지에서 만나기로 하고 다시 출발을 한다.
여행지에 거의 도착할 때 쯤 동훈이는 고속도로를 빠져 나가기 위해 길을 찾는다. 하지만 초행길 일뿐만 아니라 빠져나가는 곳이 여러 갈래 길 이어서 내비게이션 음성만으로 길을 찾는 것이 쉽지 않다. 결국 다른 길로 나온 동훈이는 그저 내비게이션의 음성 안내를 기다릴 수 밖에 없다. 고속도로를 빠져 나와 시내를 주행하던 동훈이는 물건을 사기 위해 마트를 찾는다. 이미 운전에 힘이 빠진 동훈이는 마트를 찾기 위해 고개를 돌려가며 안간힘을 쓰고 있다. 한참을 헤매고 다닌 후 마침내 마트를 찾아낸 동훈이는 돌아갈 길을 걱정하며 깊은 한숨을 쉰다.
#시나리오 2. "Well-Ving"을 사용하는 경우
여름 방학을 맞아 친구들과 여행을 약속한 동훈이와 친구들은 2대의 차량으로 여행을 가려고 계획을 세웠다. 처음 가는 곳이라 걱정은 됐지만 일행과 중간 지점에서 만나기로 하고 출발을 한다. 운전을 해본 경험이 많은 동훈이는 자신 있게 운전대를 잡고 자신의 스마트폰에 있는 Well-Ving을 실행시킨다.
여행을 가고 있는 도중에 Well-Ving 화면에 안개지역 주의 문구가 뜬다. 그리고 얼마 지나지 않아 교통사고 구간이라는 문구가 뜨게 된다. 동훈이는 속도를 줄이며 조심스럽게 운전을 한다. 조금을 더 가다보니 고속도로 중간에 교통사고가 난 것이 보였고 동훈이는 예상했다는 듯이 조심스럽게 그곳을 지나간다.
동훈이가 맵을 통해 친구의 위치를 확인하며 속도를 맞춰 온 덕분에 다른 친구들도 길을 헤매지 않고 잘 따라왔고 중간에 약속했던 장소에 같이 도착해 일행들과 즐겁게 점심을 먹는다. 여행지에 거의 도착할 때쯤 동훈이는 고속도로를 빠져 나가기 위해 길을 찾는다. Well-Ving의 실제 화면 위에 띄워져 있는 화살표를 보며 동훈이는 빠져 나가는 길을 쉽게 찾아낸다.
고속도로를 빠져 나와 시내를 주행하던 동훈이는 물건을 사기 위해 마트를 찾는다. 동훈이는 Well-Ving의 증강현실 기능을 이용한 주변의 마트 검색을 시작한다. 카메라로 찍어지는 실제 영상화면 위에 마트의 위치가 마커로 표시가 된다. 동훈이는 손쉽게 마트를 찾아낸다. 동훈이는 돌아갈 길 걱정은 접어두고 재밌게 여행을 즐기려는 생각에 들뜨게 된다.
여행지에 도착할 무렵 길 양 옆으로 나무가 우거진 아름다운 풍경의 도로가 나온다. 동훈이는 다음 기회에 여자 친구를 데리고 다시 와야겠다는 생각에 쉽게 찾을 수 있도록 재빨리 포토 앨범에 풍경을 담는다. 여행에서 돌아온 동훈이는 Well-Ving 덕분에 이번 여행을 알차게 보낼 수 있었다.
고속도로에서 사고가 나면 대형 추돌사고로 이어지기 십상이다. 도로 특성상 주행속도가 빠르고 제동거리가 길기 때문이다. 더불어 안개와 같은 기상조건까지 좋지 않다면 사고 피해는 배 이상이 될 것이다. 하지만 사고구간과 같은 도로 위의 위험요소를 운전자가 미리 알 수 있다면 어떨까?
또 다른 문제로, 복잡한 서울 시내도로에서 운전을 경험해 본 운전자라면 복잡한 도로 구조에 오히려 내비게이션의 안내가 더욱 혼동을 주는 것을 한번쯤은 겪어 봤을 것이다. 뿐만 아니라 고속도로에서도 출구가 하나가 아닌 두 개 이상인 경우나 출구가 연속으로 붙어있는 경우 출구를 잘못 찾아 빠져나온 후 다시 고속도로를 타야하는 경험도 해봤을 것이다. 또한 고속도로에서 출구를 지나친 경우에는 다음 출구까지 꽤 먼 거리를 갔다가 다시 돌아와야 하기 때문에 운전자에게 상당히 피해를 가져다준다.
곧 좌회전하라는 지시에 따라 제일 좌측차선을 이용하다가 막상 그 전 사거리에서 직진을 못해 좌회전하여 다시 돌아가는 등 현재 도로 위에서는 많은 차들이 기름을 낭비하고 있다.
본 프로그램 Well-Ving은 정부사업으로 내세울 정도로 심각해진 교통사고 문제와 운전자의 불편함을 해결하기 위해 제작된 프로그램이다.
기존의 내비게이션에서 제공되는 기능들은 단순한 길 안내 기능에 음악 및 DMB와 같은 운전과 상관없는, 오히려 자칫하면 교통사고를 유발 할 수 있는 기능들이었다. 하지만 차량에 오디오 시스템이 거의 있기 때문에 비싼 돈을 주고 산 내비게이션을 대부분 길 안내용으로만 사용해 왔다.
스마트 폰, 스마트 TV 등 모든 것들이 말 그대로 스마트해지고 사용자에게 더욱 많은 정보를 제공하고 있는 스마트 시대에 발맞춰 내비게이션 또한 당연히 스마트해져야 한다고 생각한다.
※ 이에 본 프로그램은 다음과 같은 목표를 추구 한다.
1) 데이터화 되어있지 않은 도로를 주행 시에도 기본적인
정보를 바탕으로 도로를 인식하여 운전자에게 상황에 맞는 길 안내
2) 단체 이동시 사고 및 지체를 줄여주고 운전자가 동행 차량들이 아닌 주행에만 신경 쓸 수 있도록 안내
3) 주행 중 주변 건물을 찾기 위해 운전자 및 동승자(보조석)가 정확한 위치를 찾지 못하여 불안정한 주행을 함으로써 생기는 위험을 방지하기 위해 방향센서, GPS센서 등을 이용한 증강현실 기능
4) 실시간 도로상황 안내를 통한 교통사고 방지 및 원활한 교통상황 구현
2 작품내용
2.1. 구성
2.1.1. 하드웨어 구성
2.1.1.1. 단말기 구성
단말기는 [그림 1]과 같이 크게 메인 보드와 GPS 모듈, 카메라 모듈, Wi-Fi/3G가 가능한 통신 모듈로 나뉜다. 메인 개발 디바이스는 듀얼 코어 CPU를 장착한 GalaxyS2를 사용하였다. 듀얼 코어 CPU와 고사양의 메모리로 연산양이 많은 본 시스템을 원활하게 작동하게 할 수 있으며, 고화질의 후방 카메라로 좀 더 정확한 영상처리를 할 수 있다. 또한 Wi-Fi/3G가 가능한 디바이스 중에서 높은 해상도와 정전 터치 방식의 큰 LCD를 제공하고 있다. 추가적으로 증강현실을 사용하기 위해 필요한 GPS 모듈이 탑재되어 있다.
2.1.1.2. 인프라 구성
Well-Ving의 인프라 구성은 [그림 2]와 같이 본 시스템이 작동할 수 있는 안드로이드 디바이스(Android Device)와 웹 서버(Web Server)로, 안드로이드 디바이스는 GPS 위성으로부터 GPS 위치정보를 받고 웹 서버로부터 Wi-Fi/3G 통신을 통해 받아오는 데이터와 비교해 작동 하도록 구성되었다.
2.1.2 소프트웨어 구성
[그림 3]을 통해 Well-Ving의 소프트웨어 구성을 한눈에 알 수 있다. 메인 시스템은 임베디드 보드에서 동작할 수 있도록 임베디드 리눅스 기반으로 안드로이드를 사용하였다.
차선인식 모듈에서의 영상 처리는 OpenCV 라이브러리를 이용하였으며 JNI를 사용하여 JAVA 보다 속도가 빠른 C/C++ 를 이용하였다. OpenCV를 통해 검출 된 차선의 정보는 JNI변환을 통해 안드로이드에서 전달 받아 OpenGL를 이용하여 좀 더 고수준의 그래픽 작업을 한다.
위치 인식 모듈인 GPS를 통해 얻어진 위치 정보를 이용해 사용자가 원하는 경로를 안내하고 증강현실 기능을 이용한 주변검색 기능까지 가능하다. 여기서 얻어진 경로 정보와 OpenCV를 통해 얻어낸 차선검출정보를 이용하여 OpenGL ES의 그래픽효과로 실제영상 위에 보다 정확한 길안내를 구현하였다.
통신 모듈은 HTTP를 사용하여 웹서버를 구축하였고 메인 시스템의 HttpClient를 이용하여 통신하며 정보의 송수신은 XML형식의 데이터로 전송된다.
서버는 아파치 서버를 사용하였으며 PHP와 MySQL를 사용하여 사용자 데이터 및 도로 데이터를 관리한다.
2.2. 소프트웨어 기능
2.2.1. 차선검출 및 안내 기능
Well-Ving의 핵심적인 기능으로써 그림과 같이 가야 할 경로와 비교하여 현재 주행 중인 차로의 양쪽 차선을 인식하고 주행을 안내 한다.
기존의 내비게이션은 데이터화된 맵(Map)과 GPS 수신기만을 이용한 길 안내로써 길이 약간 이라도 변한 경우 단말기에 맵 데이터의 최신 정보가 필요했고 사고 방지를 위한 위험 구간과 같은 데이터 또한 업데이트가 필요했다. 또한 SD Card를 리더기에 연결하여 컴퓨터로 업데이트를 해야 됨으로써 컴퓨터를 쉽게 다루지 못하는 사용자들은 업데이트를 하지 못한 상태로 사용하고 있는 실정이다.
Well-Ving을 사용할 경우 사고 구간이나 공사 구간 등과 같은 위험 구간을 서버에 손쉽게 등록 해줌으로써 사용자들이 별도의 업데이트 과정 없이 위험 정보를 받아 사고를 예방 할 수 있으며 또한 별도의 돈을 들여 기기를 구입할 필요 없이 안드로이드 OS기반의 태블릿이나 핸드폰만 있다면 단말기를 통해 간단하게 다운로드 및 설치하여 사용할 수 있다.
2.2.1.1. 영상처리
[그림 4]의 이미지에서 보면 좌측차선의 녹색 점들과 우측차선의 적색 점들은 영상처리를 통해 카메라로 들어오는 이미지로부터 차선의 좌표를 검출하여 나타낸 것이다.
기존까지의 차선검출 방식은 이미지를 받아와 그레이 변환 → Gaussian 스무딩 필터링 등과 같은 잡음 제거 작업 → 특정 임계값을 이용한 차선과 배경 사이의 명확한 분리 → 미분을 통한 Edge 축출 작업 → 많은 Edge들 중에서 차선 검출하기 위한 Hough 변환이었다. 이러한 과정을 통해 진행한 결과 시스템에 무리가 가는 것은 물론 속도면에서도 상당히 무리가 있을 수밖에 없었다.
그래서 기존의 방식이 아닌 새로운 방식( * 4.4 기술적 차별성 참고)을 사용하여 속도문제를 해결하였고 이를 JNI의 기능을 이용하여 안드로이드에서 제어 할 수 있도록 구현하였다.
처음 카메라를 통해 이미지를 가져오는 작업부터 좌표검출까지의 과정을 나타내면,
① 영상 입력 및 Gray 변환
카메라로부터 최초에 입력받는 영상은 3채널의 칼라영상 [그림 5]이다. Gray영상 [그림6]은 1채널의 흑백 영상이기 때문에 같은 계산을 하더라도 3채널인 칼라영상보다 약 1/3만큼 연산횟수를 줄이는 이득이 있으며, 임계값을 통하여 이진화 하기 용이하다. 이렇게 변환된 이미지는 영상처리 작업을 위해 cpp에서 제작된 함수로 전달된다.
② 차선 검출
이미지의 원점(영상의 정중앙 하단)으로부터 픽셀마다 좌·우 각각 인접 3픽셀간의 차이를 이용하여 차선을 인지하고 상수를 사용하지 않아 날씨의 밝고 흐림과 같은 이미지에 따른 제한도 없어졌다.
위의 방식으로 최 하단의 차선검출 지점을 시발점으로 y축 상으로 따라 올라가면서 정해진 범위 내에서 좌·우 픽셀들의 RGB값을 비교해가면서 차선을 찾아가며, 못 찾을 경우엔 바로 직전에 검출한 y축의 x값과 이전 프레임의 동위치의 x값을 비교하여 이전 프레임의 동위치의 x값에서 좌로 혹은 우로 1픽셀 이동한다.
[그림 7]은 위 방식대로 y값을 미량씩 올리면서 주변보다 높은 RBG값을 가진 부분을 찾아내어 좌측차선은 녹색, 우측차선은 빨간색으로 점을 찍어 나타낸 결과 사진이다. 그림을 보면 왼쪽 차선이 끊어져 있음에도 전에 검출된 값들과의 비교를 통하여 현재의 차선과 비슷한 기울기로 그려져 있는 것을 확인 할 수 있다. 이렇게 검출된 차선들의 좌표들은 프로그램 상에서 사용자에게 안내를 해주기 위해 필요한 고정 y축에서의 좌표들만을 다시 JNI를 이용하여 안드로이드에서 함수 호출을 통해 사용할 수 있다.
③ 전체(①+②) 과정
포맷 변환 후 실행되는 외각선 검출, 노이즈 감소, 관심영역 설정 등과 같은 전처리 작업은 본격적인 영상처리 과정을 수행하기 전에 필요한 것으로 이를 분리, 다중프로세싱을 함으로써 전체처리 소모시간을 줄여줄 수 있다. 전처리 작업이 완료된 이미지 데이터는 영상처리 단계를 위해 대기 상태에 들어가며, 처리 중인 데이터가 존재하지 않는다면 해당 함수로 전달되어 차선 검출 과정을 수행하게 된다. 이 작업은 쓰레드에 할당되어 다중프로세싱되며, OpenCV 라이브러리와 JNI를 이용한다. 검출 과정을 통해 축출해낸 좌우 차선 좌표와 차량의 진행방향, 좌우 차선의 존재유무는 JAVA의 객체를 이용해 저장하게 된다. 이는 JNI를 이용한 것으로 JAVA로 반환 시 연결리스트에 저장하여 그래픽 처리를 요할 경우 사용된다. 콜백함수를 등록하여 영상처리 진행상황을 수시로 파악, 각 단계별로 진행상황에 해당하는 메소드를 호출한다.
2.2.1.2. OpenGL ES
Well-Ving의 주 기능 중에 하나는 바로 원하는 목적지를 정확하게 안내하는 기능이다. 그러기 위해선 화면에 무엇인가를 나타내야 하는데, 이를 위해서 View를 필요로 한다. View에 속하는 SurfaceView의 하위 클래스인 GLSurface View를 사용했다. 일반적인 View는 화면에 뷰를 표시하는 연산과 기타 연산, 사용자와의 상호작용 처리 등이 모두 하나의 쓰레드에서 처리하지만, Well-Ving에서는 실시간으로 카메라 영상을 통한 영상처리가 이루어져 쓰레드의 부하가 생겨서 정상적인 동작이 어렵기 때문에 독립적인 쓰레드를 지니고 있는 SurfaceView가 그 해결책이라 할 수 있다.
다음으로 View위에 무엇인가를 그려야 하는 과정이 필요하다. 이 작품의 주 기능 중에 하나인 영상처리 파트의 Open CV에서 제공하는 함수를 통해 차선의 위치좌표를 검출하여 화살표를 그려줌으로써 사용자에게 보여주는 것이 가능하다. 그러나 그릴 수 있는 것들이 단순하고 색상도 기본적인 RGB색이기 때문에 실제 영상과는 어울리지 못하는 문제점이 발생했다. 이러한 문제점을 해결하기 위한 방안으로 생각한 것이 OpenGL ES라는 그래픽 라이브러리다. 2차원 및 3차원 그래픽 이미지를 정의하기 위한 API로 여러 명령어들을 통해 그림을 그리는 동작이나 특수효과 등을 나타낼 수 있으며, 이를 통해 OpenGL ES는 Well-Ving에서 차선 인식을 통한 도로 위에 화살표를 그려주고, 텍스트 출력을 통해 사용자에게 여러 정보를 제공하는 역할을 하며, 무엇보다 앞에서 언급했던 GLSurfaceView는 OpenGL의 요청을 처리하기 위한 여러 기능들이 존재하기 때문에 OpenGL을 사용하였다.
2.2.1.3. GLSurfaceView에서의 OpenGL 실행구조
GLSurfaceView 클래스의 역할은 다음과 같다.
- OpenGL ES와 View 시스템의 연결
- Surface에 OpenGL이 렌더링 될 수 있도록 EGLS Display를 관리
- Activity의 라이프 사이클과 함께 OpenGL ES가 작동
- 프레임버퍼의 픽셀 포맷 선택이 용이
- 렌더링에 대한 별도의 스레드 생성
- OpenGL ES API 호출과 에러에 대한 검사를 위한 디버깅 도구 지원
또 하나의 중요한 부분은 Renderer이다. GLSurfaceView는 연결을 담당하고, 실제로 그리는 역할은 Renderer를 통해서 이루어진다. GLSurfaceView의 메서드를 호출하여 스레드를 중지 및 재개할 수 있으며, 다음 3개의 중요 메서드를 제공한다.
※ void onSurfaceCreated(Gl10 gl, EGLConfig config)
GLSurfaceView가 생성될 때나 EGL context가 소멸할 때 호출. 장비가 sleep 상태로 들어갈 때 자동으로 소멸되며 관련 리소스 역시 모두 소멸되기 때문에 이 메서드가 호출될 때마다 관련 리소스를 다시 준비해야한다.
※ void onSurfaceChanged(GL10 gl, int width, int height)
표면의 크기가 변경될 때 호출되며 생성 직후에도 호출된다.
※ void onDrawFrame(GL10 gl)
프레임을 그릴 때마다 호출된다. 3차원 장면을 그린다.
이 중요 메서드를 모두 구현해야 그려진다.
해당 Actitivy가 생성될 때 [그림8]의 과정과 같이 수행된다.
① Activity의 OnCreate 콜백 메소드 호출
② OnCreate 메소드는 GLSurfaceView와 Renderer 객체를 생성하고 GLSurfaceView 객체에 할당
③ GLSurfaceView는 GLThread를 생성하고 Renderer 객체를 할당
④ GLThread 시작
⑤ 생성된 GLSurfaceView를 Activity의 콘텐트 뷰로 설정
GLThread를 통해 주기적으로 Renderer에게 화면을 그리기를 요청한다.
① GLThread는 EGLHelper 생성
② EGLContext 생성을 위한 Configuration을 Renderer에 문의
③ 그에 대한 응답으로 EGLContext와 EGLDisplay 생성
2.2.1.4. Opengl ES와 OpenCV 연동
Activity가 생성이 되면, GLSurfaceView를 생성한 후 setContentView를 통해서 OpenGL ES를 위한 환경이 만들어진다. 이 파트에서는 카메라가 항상 동작하면서 그 위에 그림을 그려주는 방식이기 때문에 addContentView를 통해서 OpenCV를 추가로 설정해주면, [그림 10]에서 보이는 것처럼 두 파트의 연동 작업이 완료된다.
2.2.1.5. OpenGL ES를 이용한 Camera 영상에 화살표 출력 과정
연동작업이 끝나면, 본격적으로 화살표를 그리는 작업을 수행한다. 차선 인식을 통한 총 14개의 차선좌표정보를 가지는 배열을 이용한다.
우선 각 차선별로 각 6개씩의 총 12개의 x축 좌표를 받는다. y축 좌표는 사용자가 화면을 보는데 있어서 가시성을 고려해 y축 좌표는 고정 값을 사용하였다. 또한 실제 영상을 가리지 않기 위해 투명도 값을 이용하여 반투명의 화살표를 그리고, 화살표의 내부의 색은 위쪽 부분에서 아래쪽 부분으로 갈수록 점점 투명해지는 그라데이션 효과를 나타냈다.
그 다음 나머지 2개의 정보는 각 차선이 이어짐의 유무를 나타내는 정보 즉, 실선인지 아닌지를 나타낸다. 이 정보는 현재 사용자가 위치한 도로가 좌·우 끝 차선에 있는지 아닌지를 구분하는 기준으로 사용한다. 차선이 이어져 있다면 1을, 끊어져 있다면 0으로 기준을 정했으며, 이것을 이용하여 각 도로마다 텍스트를 출력하여 도로가 가리키는 목적지에 대한 정보를 사용자에게 알려준다.
출력된 텍스트의 내용은 통신 파트의 GPS의 자료를 통해 운전하는 목적지에 따라서 set함수를 이용하여 변경되도록 하고 차선변경 또한 고려했다. 예를 들어 사거리에서 우회전을 해야 한다고 가정해보자. 통신파트에서 주기적으로 도로의 정보를 주는데, 우회전을 하려면 가장 우측 차선으로 이동해야 하므로, 우측으로 차선 변경을 하라는 안내를 통해 우회전이 용이하게 운전자를 안내한다.
[그림 11]의 화면은 현재 주행 중인 차선 좌표를 검출하여 화살표 안내와, 양쪽차선이 점선임을 인식하고 그에 따라 차선이동이 가능한 구간이기 때문에 양쪽 차선에 대한 경로정보를 그려주고 있는 화면이다.
2.2.2. 주변 검색 기능
운전을 해본 사람이라면 누구나 편의점이나 주유소 등을 찾으려고 두리번거리며 운전해 본 경험이 있을 것이다. 자칫하면 부주의로 인한 사고로 이어질 수 있는 위험한 행동인데 이런 문제를 해결하고자 증강현실 기능을 추가하게 되었다. GPS 모듈을 통해 내 위치 정보를 받아오고 Wi-Fi/3G 모듈을 통해 웹 서버로부터 내 주변 기관들의 정보를 받아오면 카메라의 영상위에 편의점, 주유소 등 해당하는 마커가 보여 진다.
[그림 12]는 GPS를 통해 수신된 사용자 좌표를 기준으로 웹을 통해 얻은 각 건물 객체들의 좌표를 표현한 것으로 수직 좌표계로 표현이 가능하다. 오른쪽 상단의 부채꼴부터 반시계 방향으로 1~4사분면으로 나타낼 수 있고, 두 좌표를 이용하여 북쪽을 기준으로 한 새로운 좌표계를 생성할 수 있다.
이하 설명에서는 a를 두 객체의 경도 값 차이의 절대 값이라 하고, b를 두 객체의 위도 값 차이의 절대 값이라 하겠다. 또한 북쪽을 향한 좌표계를 개발자 정의 좌표계라 하겠다.
▶ 1 사분면: 1 사분면에 존재하는 객체는 직각 좌표계와 개발자 정의 좌표계 모두에서의 각도 값이 90도 이하의 값을 가지므로 90도에서 각도 계산식을 통해 구해진 값을 빼주면 변환 후의 각도 값과 같은 값이 구해지게 된다.
▶ 2 사분면: 2 사분면에 존재하는 객체는 직각 좌표계에서는 180도 이하의 값을 개발자 정의 좌표계에서는 360도 이하의 값을 가지므로 θ와 π의 차이에 270도를 더해주는 방식으로 좌표계 변환을 실행한다.
▶ 3 사분면: 3 사분면에 존재하는 객체의 직각 좌표계 값은 180도 이상 270도 이하의 값으로, 개발자 정의 좌표계에서의 값의 존재영역과 동일 하지만 직각 좌표계에서의 값이 증가할 경우 개발자 정의 좌표계에서의 값은 감소한다는 점에서 차이가 발생한다. 이는 계산 시 방향의 차이로 인해 생기는 오차 값으로 이런 경우 1 사분면에서의 값으로 구한다음 270에 빼주는 방식으로 좌표계 변환을 할 수 있다.
▶ 4 사분면: 4 사분면에 존재하는 객체는 직각 좌표계의 경우 270도 이상 360도 이하의 값을 지니고, 개발자 정의 좌표계의 경우 90이상 180도 이하의 값을 갖는다. 따라서 직각 좌표계에서의 시계 방향으로의 값(-)의 절대 값은 개발자 정의 좌표계에서 θ에 π/2를 빼준 값과 동일하며 이를 이용해 좌표계 변환을 실행시킬 수 있다
.
이렇게 모든 방향에 대해 변환된 좌표계의 값은 지자기 센서로부터 입력되는 사용자 방향과의 수학적 계산을 통해 화면상의 좌표를 구하는데 사용된다. AR 검색 모드에서의 나침반 기능 역시 각 객체의 각도 계산 값을 사용한다. 지자기 센서는 정북방향을 기준으로 하여 지구 자기장 방향과의 각도를 수치로 표현해 주는 센서로서 임베디드 보드가 가리키는 방향에 대한 수치데이터를 생성하여 제공해 준다.
카메라를 통해 사용자에게 보여지는 영역은 사용자가 바라보는 방향을 기준으로 양쪽 모두 36.5씩 총 73도다. 따라서 실제 건물객체가 카메라의 시야영역에 들어와 있는지를 확인 후 이미지를 출력 시키는 좌표 매핑 계산식이 필요하다. 사용자의 단말기는 왼쪽 상단을 화면상의 좌표의 원점(0, 0)으로 하고 있으며, 이는 좌표 매핑 계산식의 기준으로 작용한다.
[그림 14]는 사용자의 방향정보와 건물객체의 각도 데이터를 이용하여 화면에 이미지를 매핑시키는 과정을 보여준다. α는 객체 방향에 대한 기준 방향( 사용자 방향 - 36.5도)의 차이를 나타내는 값이고, β는 단말기를 수직으로 세웠을 때 지자기 센서의 X값(-90)을 기준으로 카메라의 시야각도의 절반가량(작은 흔들림에도 이미지가 화면상에서 사라지는 현상을 방지하기 위해 그 이상의 값을 더한다)을 더한 값으로 각 사이 각에 대한 데이터는 화면의 해상도 / 카메라 시야각도 수식을 통해 화면상의 좌표 값으로 변경된다.
2.2.3. 실시간 알림 기능
주행 중 사용자의 위치는 GPS를 통해 실시간으로 단말기에 수신된다. 현재 사용자의 위치정보를 서버와 통신하며 도로 상의 사고 등의 위험구역에 접근하게 되면 사용자에게 알림 메시지를 통해 위험상황에 대해 주의할 수 있도록 해준다.
도로상황에 대한 데이터들은 DB상태로 저장되어 있으며 손쉽게 등록 및 삭제할 수 있고, 사고 상황과 같은 긴급한 상황은 사용자가 직접 등록할 수 있게 함으로써 더욱 실시간화 될 수 있게 구현되었다. 또한 사용자에 따라 오히려 내비게이션 화면 내에 경고 알림창이 방해가 될 수도 있는 경우를 대비하여 입맛에 따라 설정화면에서 지정이 가능하여 필요한 위험 상황만을 안내 받을 수 있도록 하였다.
[그림 16]의 빨간점으로 표시된 부분이 사고구간이라 가정하면 서버에 좌표가 등록되고 빨간 원안에 운전자가 접근 시 [그림17]의 그림과 같이 사고구간이라는 알림메시지가 뜨게 되어 안전하게 통과 할 수 있다.
2.2.4. 친구위치 알림 기능
맵을 이용한 친구 위치 검색 기능은 검색하고자 하는 친구의 위치를 보다 정확하고 편하게 볼 수 있게 하기 위하여 구글맵을 이용하여 현재 나의 위치와 친구의 위치를 표시해주는 기능이다. [그림 18]은 현재 GPS를 통해 받고 있는 나의 GPS 좌표와 서버에서 받아 온 검색하고자 하는 친구의 GPS 좌표를 Google 맵을 통해 표시 해주는 과정을 나타낸 그림이다.
검색하는 친구가 없을 경우에는 나의 위치를 구글맵 중앙에 위치시켜 나의 위치를 맵으로도 확인 할 수 있다. 영상을 이용한 길 안내 뿐만 아니라 지도를 이용한 현재 나의 위치를 확인 할 수 있어 사용자에게 편의를 제공하도록 하였다.
검색하는 친구가 있을 경우에는 내 위치와 친구 위치의 중심점을 구글맵 중앙에 위치시켰고 두 좌표의 거리별 맵의 자동 확대/축소를 구현하여 한 화면 안에 내 위치와 친구 위치를 보여 지도록 하였다. 이를 통해 친구의 위치를 확인함으로써 나와의 거리, 또는 친구의 경로 등을 눈으로 확인할 수 있다.
또한 맵의 On/Off 기능을 이용하여 맵 사용을 원하지 않을 때는 화면에서 가림으로써 사용자의 편의를 고려하였다.
2.2.5. 데이터 통신부
본 시스템의 통신부는 [그림 19]와 같이 구현되어있으며, apache, MySQL, PHP를 이용한 웹서버와 안드로이드 기반의 httpClient를 이용한 클라이언트로 구성 되어 있다. 웹서버를 이용한 통신환경으로 Wi-Fi뿐만 아니라 3G를 이용한 단말기에서도 통신이 가능하도록 하였다. 또한 서버에 별도의 DB를 구축하여 보다 많은 양의 데이터를 저장할 뿐만 아니라 보다 신속하고 일관성 있게 데이터를 관리 할 수 있으며 이는 전체 프로그램 속도를 향상 시키는 효과가 있다.
서버와 클라이언트는 상황에 맞는 요청과 각 요청에 맞는 응답으로 이루어진다. 클라이언트는 httpClients를 이용하여 웹서버에게 필요한 정보나 수행을 요청한다. 각각의 요청은 몇 개의 파라미터를 전달하면서 원하는 정보나 수행을 서버에 요청한다. 서버는 클라이언트가 요청에 따라 PHP 코드에서 query문을 만들어 MySQL에게 query를 전달한다. MySQL은 query문에 따라 정보를 수정하거나 추출하여 결과를 반환한다. 정보는 PHP구문에 의해 XML 형식으로 클라이언트로 제공되며 클라이언트는 XML형식의 정보를 parsing 하여 필요에 맞게 사용하게 된다.
(2월호에서 계속)
[그림 및 표는 PDF버전을 참고할 것]
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음