• 검색 결과가 없습니다.

R&D연구결과보고서

N/A
N/A
Protected

Academic year: 2021

Share "R&D연구결과보고서"

Copied!
78
0
0

로드 중.... (전체 텍스트 보기)

전체 글

(1)

글로벌전문기술개발사업

대용량 3차원 사물 인식 기능을 가진 개방형 융합 플랫폼 개발

Development of amalgamative open platform with the function of scalable 3D object recognition

201 5. 06. 10.

주관기관 : (주)맥스트

정보통신산업진흥센터

(2)

연차보고서

사업명 글로벌전문기술개발사업 과제번호 2014-050-005-024

과제명 (국문) 대용량 3차원 사물 인식 기능을 가진 개방형 융합 플랫폼 개발

(영문)

Development of amalgamative open platformwith the function of scalable 3D object recognition

주관기관 (주)맥스트 총괄책임자 박재완

참여기관 1

(책임자) 한국정보공학(주)/손태윤

참여기관 2

(책임자) (주)굿게이트/박영신

총수행기간 2014. 07. 01 ~ 2016. 06. 30 ( 24개월)

협약기간 2014. 07. 01 ~ 2015. 06. 30 ( 12개월) 해당년도

수행기간 2014. 07. 01 ~ 2015. 06. 30 ( 12개월) 협약기간

총사업비(천원)

정 부

출연금 830,000 민 간 부담금

현금 28,000

1,110,000 현물 252,000

해당연도 사업비(천원)

정 부

출연금 415,000 민 간 부담금

현금 14,000

555,000 현물 126,000

키워드 (6 ~ 10개)

3차원 사물 인식, 스마트 비전, 3차원 점군, 저전력 비콘, 비콘 기반 실내 측위

정보통신·방송연구개발 관리규정 제33조에 의거하여 연차보고서 15부를 제출합니다.

2015년 6 월 10 일

총괄책임자: 박재완 (인)

주관기관장: 박재완 (직인/인감)

정보통신기술진흥센터장 귀하

(3)

Ⅰ. 해당 연도 추진 현황

Ⅰ -1 기술개발 추진 일정 가 . ㈜맥스트

일련

번호 개발 내용 추진 일정(개월) 달성도

1 2 3 4 5 6 7 8 9 10 11 12 (%)

1

계획수립 및 자료조사

100%

2

환경 지도 생성 기술 카메라 추적 및 3D

개발

100%

3

디스크립트 생성 기술 개발

100%

4

라이브러리 개발 자세 추정

100%

5

데이터베이스 구조 학습정보

개발

100%

6

엔진 인터페이스 개발

100%

7

콘텐츠 생성 및 동적

로딩 기능 개발

100%

8

개발 모바일 앱 (안드로이드

기반 )

100%

9

설계 및 시범서비스 통합 인터페이스

개발

100%

(4)

나 . 한국정보공학㈜

일련

번호 개발 내용 추진 일정(개월) 달성도

1 2 3 4 5 6 7 8 9 10 11 12 (%) 1 계획수립 및

자료조사 100%

2 하드웨어 설계 100%

3 하드웨어 프로토타입

개발 100%

4 하드웨어 성능

테스트 100%

5 하드웨어 Firmware

개발 100%

6 실내측위 알고리즘

분석 및 설계 100%

7 실내측위 알고리즘

개발 100%

8 실내측위 DB 구축 100%

9 실내측위 DB 수집/생성/갱신

모듈 개발 100%

(5)

다 . ㈜굿게이트

일련

번호 개발 내용 추진 일정(개월) 달성도

1 2 3 4 5 6 7 8 9 10 11 12 (%)

1

계획수립 및 자료조사

100%

2

구축대상 목록작성

100%

3

UI, UX 디자인

100%

4

유물사진 촬영 및

유물설명 작성

100%

5

입체(3D) 콘텐츠

제작

100%

6

사용자 테스트

100%

7

피드백 및 보완

100%

(6)

Ⅰ -2 해당 연도 추진 실적

가 . 1차년도 개발 목표

구 분 내 용

1차년도 목표 대용량 3차원 사물 인식 플랫폼 핵심 기술 및 시범 콘텐츠 개발

세부 목표

l 사물 인식 및 추적 기술 개발과 모바일 앱 개발

l 비콘 디바이스 프로토타입 개발 및 실내 측위 알고리즘 개발 l 박물관 시범 서비스용 콘텐츠 개발

나 . 1차년도 개발 내용 종합

구 분 연구내용 실 적 달성도 %

주관기관 (맥스 트 ) : 사물 인식 및 추적

기술 개발과 모바일 앱

개발

PC기반 3차원 사물 인식 및 추적 기술 개발

알고리즘 비교분석 세미나, 알고리즘 설계서, 알고리즘 개발 결과물

100

엔진 인터페이스 개발 콘텐츠 생성 및 동적 로딩

기능 개발 통합 인터페이스 설계

인터페이스 설계 문서, Software Requirement

Specification

100

시범서비스용 모바일 앱 개발 모바일 애플리케이션 개발 100

참여기관 1(한국정보공

학 ) : 비콘 디바이스 프로토타입 개발 및 실내 측위 알고리즘

개발

저전략 비콘 디바이스 설계 및 프로토타입 개발

비콘 디바이스 H/W 설계, 비콘 프로토타입 개발, H/W 성능 테스트, H/W 펌웨어 개발

100

비콘 디바이스 기반 실내 측위 알고리즘 개발

실내 측위 알고리즘 설계, Fingerprint 알고리즘 개발, PDR 알고리즘 개발, Fingerprint 데이터 수집 알고리즘 개발, 실내 측위 DB 구축

100

참여기관 2(굿게이트) :

박물관 시범 서비스용 콘텐츠 개발

박물관 및 전시관 관련 시장 조사 및 자료 조사 박물관 및 전시관 서비스

시나리오

고궁 및 박물관 Point Of Interest (POI) 조사연구,

서비스 시나리오 설계

100

박물관 연구기술 시범 구축을 위한 DB 메타데이터 구조 정의

UI/UX 개발 박물관 시범서비스를 위한

콘텐츠 개발

모바일 서비스 기획서, 모바일 애플리케이션 GUI디자인, 콘텐츠

디자인

100

(7)

다 . 수행기관별 추진 실적

1. 주관기관 (맥스트) : 사물 인식 및 추적 기술 개발과 모바일 앱 개발

(1) PC기반 3차원 사물 인식 및 추적 기술 개발

증강현실 [체험] (그림 A)

step1. 사용자가 프로그램을 실행하여 시작한다

step2. 프로그램이 학습한 사물/공간 의 3D 지도와 분류기를 loading한다.

step3. 카메라로 전방의 view를 받아 들인다 .

step4. 사물/공간 인식을 시도한다.

step5. 인식에 성공했으면 추적을 시 도한다

step6. 인식에 실패했으면 step 3로 간 다 .

step7. 추적에 성공했으면 구해진 카 메라 자세로 그래픽 객체를 증강한다 .

step8. 추적에 실패했으면 step 4으로 간다 .

step9. 다음 카메라 이미지를 받아서 step 5로 간다.

사용자가 프로그램 시작

사물 /공간을 카메라로 비춤

추적중인가 ? 사물 /공간 인식

3D 그래픽 컨텐츠 증강 사물 /공간 추적 3D 지도와 분류기 load

yes

yes

no

no

no

사물 /공간 3D 지도 [학습] (그림 B)

step1. 사용자가 프로그램을 실행하여 시작한다

step2. 카메라로 원하는 사물/공간을 스캔하면서 view를 받아들인다.

step3. 특징점들을 추출하여 3D map 에 편입시킨다 .

step4. 3D map의 점들을 이미지 상에 서 추적하여 , 점들의 3D 좌표를 업데 이트 한다 .

step5. 사물/공간 스캔할 것이 남아 있으면 step 2로 간다.

step6. 3D 좌표들을 구분하는 분류기 를 만들고 저장한다 .

사용자가 프로그램 시작

특징점 추출

3D 지도 저장 특징점 추적 , 3D 좌표 추정 사물 /공간을 카메라로 비춤

더 스캔해야 하는가 ? yes

no

[시스템 Flow]

(8)

■ 기본적인 공통 알고리즘 개발

학습, 인식, 추적 등 시스템 전반에 필요한 기본적인 공통 알고리즘 개발

① 카메라 보정

1) 의미

<그림 1>에서와 같이, 3차원 물체의 좌표와 카메라 자세(위치와 방향)이 주어질 때, 그 물체가 카메라 이미지에 어디에 맺힐 것인가는 카메라의 내부인자에 의해 결정된다. 이 내부인자는 focal length, principal point, skewness, distortion factor 등을 말하며, 이 들로 이루어진 투영 함수(projection function)을 통해 3차원 좌표가 2차원 좌표로 변환된다 (<그림 2> 참고). 이러한 내부인자를 구하는 작업을 카메라 보정이라 한다.

그림 2 카메라 내부인자 (f_x, f_y, skew_c, c_x, c_y)와 자세 (r_11 ~ r_33, t_1 ~ t_3)가 주어졌을 때, 3차원 점 (X, Y,

Z)가 카메라의 어떤 위치(x, y)에 맺히는지의 projection function (matrix)

그림 1 핀홀카메라 모델

(9)

2) 용도

투영함수 및 그 역함수를 통해 [체험]step4, [체험]step5, [체험]step7, [학습]step4 등에 서 3D point의 투영 위치를 예측하거나, 이미지 특징점을 통과하는 3D ray를 계산할 수 있다.

3) 방법

사이즈가 알려진 물체(예, 체스보드)를 여러 view에서 찍은 이미지들을 입력으로 Camera Calibration Toolbox for Matlab1)을 사용하여 주어진 카메라를 보정.

실험에 사용한 Logitech C910에 대한 카메라 보정 결과 image size : 320, 240

focal length : 271.193, 272.413 principal point : 159.097, 122.250 skewness : 0.00000

distortion : -0.003760, -0.043900, 0.003030, -0.004980, 0.00000

② 이미지 perspective warping

1) 의미

<그림 3>에서와 같이 3차원 공간상의 평면을 카메라의 자세를 달리해서 찍은 두 장의 사진이 있을 때 두 평면 이미지 사이에는 perspective transform의 관계가 성립하고, 한 평면의 이미지에서 다른 평면의 이미지로 변환하는 것을 perspective warping이라고 한 다. 3D point의 경우 해당 point와 주변의 surface가 아주 작은 3D 평면을 이루고, 그 평 면이 camera 중심으로 부터의 ray에 수직을 이룬다고 가정하고, 카메라 자세를 달리하였 을 때 그 평면이 어떻게 보일 것인가를 계산한다.

2) 용도

3D point의 경우 해당 point와 주변의 surface가 아주 작은 3D 평면을 이루고, 그 평 면이 camera 중심으로 부터의 ray에 수직을 이룬다고 가정하여, 카메라 자세를 달리하였 을 때 그 평면이 어떻게 보일 것인가를 계산한다. [체험]step4에서 적용.

3) 방법

(1) <그림 4>에서와 같이 검출된 특징점을 중심으로 41 x 41 짜리 image patch를 저장 한다. (<그림 5> 41 x 41 이미지 확대)

(2) 임의의 프레임에서 해당 점의 주변의 13 x 13 짜리 patch 이미지의 warping 함수 를 구한다. (<그림 6>은 <그림 5>의 내부 13 x 13 이미지를 확대한 것이다.)

1) http://www.vision.caltech.edu/bouguetj/calib_doc

(10)

(3) patch내의 모든 점들에 대해 warping 함수를 적용해 interpolation한다. (<그림 7>과

<그림 8>은 각각 40번째와 80번째 프레임에서의 warping된 13 x 13 이미지 패치를 확대 한 것이다.)

그림 3 좌측과 우측의 이미지에서의 두 체스보드 이미지는, 하나의 카메 라를 서로 다른 자세를 취하여 동일한 체스보드를 찍은 영상이고 이 두 체스보드 이미지 사이에는 perspective transform의 관계가 있다.

그림 5 <그림 4>의 빨간 네모 41 by 41 image patch 확대. 빨간 네 모 : 13 x 13 image patch

그림 4 빨간 네모 : 검출된 특징점을 기준으로 취한

41 by 41 image patch

(11)

③ 특징점 추출

1) 의미

추적이나 검출이 용이할 만한 특징 있는 점들을 이미지에서 찾아내어 3D map의 구성 원으로의 candidate로 삼음.

2) 용도

학습 시에는 카메라로부터 새로운 이미지가 들어 올 때마다 즉 매 프레임마다 특징점 을 추출하며 ([학습]step3), 체험 시에는 추적하고 있는 점의 수가 너무 적을 때 특징점 추출을 하여 추적 대상의 수를 늘린다 ([체험]step4)

3) 방법

OpenCV2)에서는 FAST, ORB, Harris, BRISK, MSER, SURF, SIFT, GFTT, KAZE 등의 feature detector들을 제공하고 있으며, 상업적 사용에 제약이 없는 것들 중에서 실험 결 과, 속도 면에서 FAST를 선택해서 사용함. <그림 9>는 여러 이미지들에 대해 FAST corner detector를 적용한 예를 보여주고 있다.

2) G Bradski, “The opencv library”, Doctor Dobbs Journal 25 (11), 120-126 그림 7 40번째 프레임에

서의 warping된 13 x 13 image patch

점의 좌표 =

-0.37 0.13 1.04 카메라 회전 =

0.95 0.15 -0.25 -0.13 0.99 0.10

0.27 -0.07 0.96 카메라 위치 =

-0.36 0.07 0.04

그림 8 80번째 프레임에 서의 warping된 13 x 13 image patch

점의 좌표 = -0.36 0.13 1.00 카메라 회전 =

0.99 -0.12 -0.01 0.12 0.99 -0.01 0.01 0.01 0.99 카메라 위치 =

-0.09 -0.01 0.02 그림 6 초기 프레임에서

의 13 x 13 image patch (<그림 5>의 빨간 네모) 점의 좌표 =

-0.34 0.12 0.93 카메라 회전 =

1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0 카메라 위치 =

0 0 0

(12)

■ 학습 알고리즘 개발

추적한 3D point들로부터 3D map을 만들고 각 점들을 class로 하는 분류기를 학습하여 저장하는 작업 개발

① Descriptor 추출

1) 의미

각 3D point들의 주변 surface 이미지의 패턴을 기술함으로서 robust한 인식이 가능하 게 한다. 기술자(descriptor)는 <그림 10>과 같이 한 점에 대해 그 점을 중심으로 하는 sub-image를 설정하고 그로부터 의미 있는 수치들을 계산하여 vector형식으로 표현된다.

<그림 11>은 ferns3)를 이용한 기술자 생성의 예를 보여주고 있는데, 한 점과 그 sub-image 내에서 두 점을 선택해 그 밝기를 비교 (binary test) 함으로서 decision tree의 하나의 노드 역할을 하게 하고 있다. 그림에서 첫 번째 열은 노드 1개짜리 tree, 두 번 째 열은 노드 3개짜리 tree에 해당한다. 노드 한 개짜리 tree는 0과 1의 최대 두 가지의 기술자가 가능하고, 노드 3개짜리 tree는 000, 001, 010, 011, 100, 101, 110, 111의 최대 8 개, 즉 2^3 개까지의 기술자가 가능하다. 이러한 fern는 이러한 tree가 여러 개 있는 것 이므로 tree의 개수가 2개 라고 하면, 000000, 000001, 000010, ...., 111101, 111110, 111111의 2^(3 * 2)개의 기술자가 가능하며 ferns는 이러한 기술자 각각이 어떤 class에 속할 확률이 얼마인지를 계산하여, 가장 큰 확률을 갖는 class를 선정하게 된다.

3) M. Ozuysal, M. Calonder, V. Lepetit, P. Fua, "Fast Keypoint Recognition using Random Ferns" PAMI 2010.

그림 9 threshold 65일 때의 FAST corner detector의 검출 결과 예.

(13)

2) 용도

[체험]step4, [학습]step6

3) 방법

OpenCV에서는 BRIEF, BRISK, ORB, SURF, SIFT, FREAK, Ferns 등의 descriptor extractor들을 제공하며 이 중에서 상업적 사용에 제한이 없고 비교적 빠른 Ferns를 사용.

② 3D Map 생성

1) 의미

인식/추적의 대상이 되는 사물/공간을 대표하는 3D point들의 집합을 만듦. 대상의 표면 위에 있는 모든 점들로 dense map을 만들면 이상적으로 사물을 modelling 할 수 있 지만 증강현실이 가지고 있는 실시간 제약 조건 때문에 표면 위에서 특징적인 점들만 sampling해서 sparse map을 만드는 작업.

2) 용도

[체험]step2, [체험]step4, [학습]step6

그림 10 SIFT를 이용한 특징점 검출 및 기술자 생성의 예

그림 11 Ferns를 이용한 기술자 생성의 예

(14)

3) 방법

추적되는 점들은 초기에는 <그림 12>와 같이 inverse depth 표현법으로 3D 좌표를 나 타내고, 위치를 불확실성이 낮아지면 Cartesian 표현법으로 위치를 표현한다.

기본적으로, 사물/공간 표면상의 모든 점들 중에서, 특징점 추출을 통해 인식과 추적에 유리한 점들이 3차원 추적을 통해서 3D map의 후보가 된다. 하지만 인식 시 초기 포즈 추정할 때 좀 더 안정적인 결과를 얻기 위해 추적된 3D 점들 중에서도 위치의 불확실도 가 작은 점들만으로 3D map을 구성한다. 그러한 불확실도는 linearity index라는 수치를 통해 측정되며, inverse depth 표현법에 의한 linearity index, Lrho 는 다음과 같이 구해진 다.

위 식에서 1/ρ0 및 d0는 <그림 14>에서와 같이 제1 촬영 포인트에서 카메라로부터 3D 점 까지의 거리를 나타낸다. d1은 제2 촬영 포인트에서 카메라로부터 해당 점까지의 거리를

나타낸다. α는 두 카메라가 바라보는 방향 간의 각도를 나타낸다. 는 역 거리 의 가우시안 분포도를 나타낸다.

본 과제에서는 linearity index가 0.15이하인 3D 점들만 map의 구성원으로 참여하도록 하 였다.

그림 12 Cartesian 좌표계 (X, Y, Z)와 inverse depth

좌표계 (x, y, z, rho, theta, phi) 사이의 관계

(15)

③ 분류기 학습

1) 의미

사물/공간을 인식하기 위해 그 사물/공간의 표면상의 특징적인 3D point 각각을 인식 한다고 할 때, 그 것들을 하나의 class들로 보고 기술자들을 분류하는 분류기를 생성

2) 용도

[체험]step2, [체험]step4, [학습]step6

3) 방법

라. 1. 에서와 같이 본 과제에서는 Ferns4) 방식을 이용하여 이미지 상의 한 점이 3D map 상의 어떤 점인지를 분류하였다. Ferns는 기계학습 알고리즘 중에 Random forest라 는 분류기법을 이미지 인식에 적용한 방식이다. <그림 15>과 같이 random forest는 decision tree가 여러 개 모인 형태로서, 각 tree에서 내린 결정을 취합해서 최종 결정을 내리는 형태이다. 각 tree는 leaf node마다 각 class에 대한 근사화된 확률 분포를 가지 고 있으며, 학습시 label된 data들을 각 tree에 통과시킴으로서 각 leaf node마다 히스토 그램을 만든다. 테스트시 data를 각 tree에 통과시키고 도착한 leaf node에서 확률을 구 하고, 각 tree에서 나온 확률들과 곱해 준다. 여기서 가장 높게 나온 확률의 class가 해 당 data의 class로 지정된다. 이미지 인식의 경우 각 tree node에서의 binary test는 image patch 내에서의 두 점간의 대소 비교(<그림 11> 참조)이다. 즉 patch 중심으로부 터 정해진 offset의 두 점의 밝기 비교에서 첫 번째 점이 더 밝으면 왼쪽, 그렇지 않으면 오른쪽의 분기를 타게 된다. offset은 random하게 정하는 방식을 일반적으로 쓴다.

Ferns방식은 다른 분류기와 다르게 descriptor가 자체에 내장되었다고 볼 수 있다. 즉 binary test로부터 나오는 binary sequence가 descriptor vector 역할을 한다고 볼 수 있다.

본 과제에서는 OpenCV에서 제공하는 FernClassifier를 사용하였다.

4) M. Ozuysal, M. Calonder, V. Lepetit, P. Fua, "Fast Keypoint Recognition using Random Ferns" PAMI 2010.

그림 14 inverse depth 표현법

(16)

■ 인식 알고리즘 개발

학습한 사물/공간을 카메라로 다시 비췄을 때 인식하고 카메라 자세를 추정하는 알고리 즘 개발

① 3D map 인식

1) 의미

라. 3에서 학습한 분류기, 즉 ferns를 기반으로 현재 카메라 이미지에서의 특징점과 3D map의 구성 point들을 matching 시키는 것

2) 용도 [체험]step4

3) 방법

증강현실 체험시 다음과 같은 순서로 3D map point들의 인식이 이루어 진다.

(1) 학습한 분류기 정보(파라미터들)를 파일로부터 읽어 들인다.

(2) 카메라로부터 이미지를 읽어 들인다.

(3) 이미지로부터 특징점을 추출한다.

(4) 특징점을 중심으로 하는 image patch에서 기술자를 추출한다.

(5) 기술자를 학습한 ferns 분류기에 통과시켜, class label을 구한다.

(6) 구해진 class label에 해당하는 3D map point와 해당 특징점을 match 시킨다 (<그림.16> 참조)

그림 15 Random ferns 분류기 학습

(17)

② 초기자세 추정

1) 의미

이미지 특징점과 3D map의 구성 point들 간의 matching을 기반으로 현재 카메라의 자 세를 구하는 것. 3D map을 기준으로 봤을 때 상대적으로 카메라가 어디에 있는지 아는 것이 중요하며, 이러한 카메라의 초기자세를 알아야만 이후의 추적에서 쓰이는 Kalman filter5) 프레임에서 예측 단계를 수행할 수 있다. 참고로 사물/공간 3D 지도 학습에서는 카메라의 초기 자세를 위치는 원점 (0, 0, 0), 방향은 Indentity, 즉 카메라의 좌표계와 world 좌표계를 일치 시킨다.

2) 용도 [체험]step4

5) http://en.wikipedia.org/wiki/Kalman_filter

그림 16 3D map 인식의 시각화의 예. 가운데 이미지는 현재 카메라에 들어온 view. 녹색

점은 현재 카메라 이미지에서 검출된 특징점들 . 중심 이미지 주변의 8개의 이미지들은 3D

map의 각 점들이 학습시 최초로 검출 되었을 때의 이미지와 검출 위치(빨간점)를 보여 주

고 있다 .

(18)

3) 방법

3D 점들의 좌표와 그 점들의 2D 이미지 좌표들의 쌍들이 있을 때, 해당 카메라의 자 세를 구해 주는 방법을 PnP, 즉 perspective-n-point 알고리즘이라고 부른다. 자주 쓰는 알고리즘은 3쌍을 이용하는 P3P나 4쌍을 이용하는 P4P등이 있다. 또한 계산 방식에 따 라 EPnP, RPnP, UPnP 등의 변종이 있다. OpenCV에서는 solvePnPRansac() 함수가 이 역 할을 하는데, 테스트 결과 Levenberg-Marquardt 방식의 solvePnPRansac(ITERATIVE) 버전 이 가장 안정적인 결과를 보여 주어서 이를 사용했다.

③ 추적 초기화

1) 의미

구해진 카메라 자세와 이 때 사용된 3D map point들을 가지고 EKF(extened Kalman filter)를 초기화한다.

2) 용도

[체험]step5, [학습]step3

3) 방법

(1) PnP 알고리즘에서 카메라 자세와 함께, 자세 계산에 사용된 3D-2D 쌍들이 어떤 것들(low innovation inlier들)인지 밝혀진다

(2) 카메라 자세와 카메라 내부인자 등을 가지고, 3D map에서 low innovation inlier에 속하지 않은 점들의 카메라 이미지 투영 위치를 구한다.

(3) 각 투영점들에 perspective image warping(다. 2 참고)을 통해 현재 카메라 자세에 대한 13 x 13 짜리 예상 image patch를 생성한다.

(4) 각 투영점들의 이웃 영역에 대해 예상 patch와 template maching을 통해(OpenCV 의 matchTemplate() 함수 사용) 가장 이미지가 비슷한 지점을 찾는다.

(5) template matching 정도가 충분히 좋으면 해당 지점과 현재 3D point를 matching 시키고 high innovation inlier 그룹에 넣는다.

(6) 카메라 자세, low 와 hight innovation inlier들을 가지고 EKF의 상태 벡터와 공분산 행렬을 만들어 추적을 초기화 한다.

(19)

■ 추적 알고리즘 개발

3D map point의 현재 이미지에서의 위치를 추적함으로써 카메라 자세와 3D map point들 의 위치를 업데이트 작업 개발

① 3D point 추적

1) 의미

예상되는 카메라 자세와 3D 점의 위치로부터 현재 이미지 상의 대응점을 찾는다. 즉 Kalman filter의 상태 추정 메카니즘인 “예측 -> 관측 -> 수정”의 사이클에서 “관측”

에 해당하는 부분이 바로 3D 점이 실제로 현재 이미지에서 나타는 위치를 구하는 것이 다.

2) 용도

[체험]step5, [학습]step4.

3) 방법

이 전 프레임에서의 추적점의 주변 이미지와 비슷한 현재 프레임에서의 위치를 찾는 방식으로 2D 이미지 기반의 optical flow를 이용하였다. OpenCV에서는 여러 가지 방식 의 optical flow 함수를 제공하고 있는데, Lukas-Kanade 방식의 calcOpticalFlowPyrLK(), Farneback 알고리즘 방식의 calcOpticalFlowFarneback(), Horn-Schunck 방식의 calcOpticalFlowHS() 등이 있다. 본 과제에서는 <그림 17>과 같이 속도가 가장 빠른 편인 calcOpticalFlowPyrLK()을 사용하였다.

② 카메라 자세, 3D map 위치 추정

1) 의미

3D map point들의 현재 이미지 상의 대응점을 Kalman filter의 관측으로 보고 상태, 즉 카메라와 자세와 3D map point의 위치를 업데이트 한다. 바. 1에서도 언급했듯이 Kalman filter의 “예측 -> 관측 -> 수정”의 사이클에서 “수정”에 해당한다.

2) 용도

[체험]step5, [학습]step4.

3) 방법

일반적인 Kalman filter는 모든 관측데이터, 즉 바. 1에서 구한, 3D 점의 현재 이미지 에서의 관측점들을 모두 사용하여 현재 상태, 즉 카메라자세와 3D 점들의 위치를 업데이 트 한다 (<그림 19> 참조). 하지만 이 3D-2D 대응쌍 들 중에는 outlier 즉, 잘못된 추적

(20)

결과들이 섞여 있을 수 있으며 이러한 outlier는 상태추정에 커다란 오차를 야기한다. 이 러한 단점을 극복하고 빠른 상태 추정을 하기 위해 본 과제에서는 1-point RANSAC EK F6) 방식으로 Kalman filter를 업데이트 한다. <그림 18>는 line fitting에서의 1-point RANSAC EKF의 예를 보여주고 있다. line fitting의 경우 최소 2개의 점이 있어야 line의 파라미터 (기울기, y절편)을 구할 수 있다. 하지만 outlier들이 섞인 여러 점들을 다 이용 하여 최소자승법으로 line을 구하면 원하는 직선의 파라미터를 구할 수 없고, 이를 위해 RANSAC의 방법을 쓰지만 이는 여러번의 random sampling으로 인하여 시간이 오래걸리 는 단점이 있다. 마.2에서 언급한 바와 같이 카메라 자세 추정을 위해서는 최소 3점 이 상의 대응관계가 필요하며 이를 RANSAC을 통해 계산하려면 많은 시간을 필요로 한다.

본 과제에서 사용하는 Kalman filter가 최소 하나의 관측데이터 만으로도 업데이트가 될 수 있다는 점을 이용하여 1점의 대응관계로 Kalman filter를 업데이트하고 이러한 업데이 트가 다른 대응관계들에게도 얼마나 맞는지를 따지는 RANSAC 방식을 써서 빠른 시간에 적절한 inlier들을 찾고 이를 기반으로 EKF의 상태벡터와 공분산 행렬을 업데이트 할 수 있다.

6) Javier Civera, Oscar G. Grasa, Andrew J. Davison and J. M. M. Montiel “1-Point RANSAC for extended Kalman filtering: Application to real-time structure from motion and visual odometry”, Journal of Field Robotics, 2010.

그림 17 Optical flow를 사용한 카메라 시퀀스에서 연속된 두 이미지 사이에서의

2D image point matching의 예.

(21)

그림 18 line fitting을 위한 1-point RANSAC EKF 알고리즘의 예

그림 19 카메라 자세, 3D map point 위치의 3차원 시

각화의 예 . 삼각형의 카메라의 위치와 방향을 형상화

하고 있으며 , 녹색과 파란색 타원체은 각각 inverse

depth와 Cartesian 좌표계를 사용하는 3D point를 나타

내고 있다 . 타원체의 중심과 크기는 각각 위치의 불확

실성을 Gaussian으로 봤을 때의 mean과 covariance를

나타낸다 .

(22)

③ 재추적

1) 의미

갑작스런 카메라의 움직임 등 여러 요인으로 인해 3D map point들을 추적하는데 실패 할 경우, 다시 인식 단계로 돌아간다.

2) 용도 [체험]step8.

3) 방법

일단 재추적을 하라는 판단이 떨어지면, 다시 인식 모드로 전환하게 되므로 재인식이 라고 해도 무방하다. 따라서 재추적을 할 것인지 말 것인지, 즉 현재 추적 실패의 상황 인지 진단하는 것이 중요하다. 본 과제에서는 바.1의 점 추적 결과가 연속된 프레임들에 서 좋지 않을 때 추적에 실패 했다고 판단하고 있다. 현재 3개의 연속된 프레임에서 점 추적되는 수가 5이하 일 때 재추적 모드로 진입한다.

(23)

(2) 증강현실 엔진 인터페이스 및 콘텐츠 동적 로딩 기능 개발

1) Interface 구조

해당 프로젝트는 실제 환경을 하나의 장면(Scene)으로 구성해놓고, 해당 장면을 인식/추적하는 기술을 구현하여, 가상의 콘텐츠들을 증강시킴으로써, 사용자에게

추가적인 Interaction없이 보다 손쉽게 정보 전달할 수 있다. 2D 인식을 벗어난 실제 환경 인식은 이전보다 견고한 3D Map 환경으로 이루어져 있으며, 특별한 인식 대상이

필요하지 않는다는 장점이 있다. 또한 기존의 3D 콘텐츠들을 비롯하여 알파를 포함한 비디오 영상도 증강시킴으로써, 보다 다양한 방법으로 사용자에게 서비스를 제공한다.

디바이스 카메라를 이용하여 획득한 영상을 통해, Core Engine 에서는 영상을 분석, 학습해놓은 3D Map과 비교하여 인식, 동일한 Map의 영상이 획득되어진다면 추적 하는, 증강현실에 있어서 중추적인 역할을 하고 있다. 학습된 Map과 동일하다고 판단되어 지면, Map의 Root Position 을 중점으로 콘텐츠를 증강시킨다. 카메라 영상과 콘텐츠는, Unity3d 라는 강력한 게임엔진을 이용하여 렌더링한다. Unity3d는 3D 게임이나 실시간 애니메이션 같은 Interactive Contents를 제작하기 위한 통합 저작도구로, Multi Platform 과, mobile 환경에서도 PC 못지않은 렌더링 효과를 지원하는 게임 엔진이다. 이러한 Unity3d를 통해 증강된 콘텐츠의 애니메이션, 사운드, interaction 등을 구현하여 보다 사용자에게 현실에 있어서 자연스러운 증강 콘텐츠의 효과를 나타내었다.

2) Interface 기능

2.1. Hardware

해당 프로젝트는 Windows, Mac, Android, iPhone Platform 을 지원하며, Core Engine 에서 각 platform의 디바이스 카메라를 컨트롤 한다.

그림 20. Interface 구조

(24)

2.2. Core Engine

Hardware 로부터 전달받은 카메라 프레임 이미지를 갖고 Trackable(인식 할 대상)을 인식 / 추적한다.

2.3. Rendering by Unity3D

Unity3d 라는 렌더링 엔진을 이용함으로, 3D Contents 를 보다 손쉽게 기술할 수 있으며, 컨트롤이 용이하다. 또한 Windows, Mac, Android, iPhone, Web 등의

multi-platform 을 지원하며, 각 platform 의 native와 connection이 가능하다.

해당 프로젝트에서는 이러한 Unity3d를 통해 Core Engine 으로부터 전달받은 카메라 프레임을 텍스쳐로 렌더링해준다. 또한 인식 / 추적 결과로부터 증강시킬 콘텐츠들의 렌더링을 enable / disable 을 설정해주고, 추적의 결과로 콘텐츠의 위치, 회전, 스케일을 설정한다. 콘텐츠 타입이 비디오 일 경우에는 비디오 프레임마다 텍스쳐를 업로드 하여 화면에 렌더링해준다.

3) 주요 핵심 기술 상세

3.1. Camera Rendering

카메라 렌더링을 위해선 현재 SDK가 지원하는 Windows, Mac, Android, iPhone 플랫폼들 각각의 디바이스 카메라에 접근해야 한다. Mac 과 iPhone 은 OS에서 지원하는 AVFoundation.framework을 사용하여 디바이스에 접근, 32BGRA format의 카메라 프레임을 RGB 로 변환하여 Core data 와 Rendering data 로 사용한다. Android 역시 OS에서 지원하는 hardware camera 를 사용, Windows 는 오픈 라이브러리를 이용하여 카메라 디바이스에 접근한다. AutoFocus를 지원하는 디바이스인 경우, 해당 기능을 기본으로 설정한다. 현재는 각 카메라 프레임 사이즈를 640x480으로 고정된 값을 지원하고 있다.

- Mac, iPhone

카메라의 포지션에 따라 현재 사용하고 있는 카메라 디바이스를 프로그램 실행 중에 얻을 수 있다. AVCaptureDevice 의 Video Type array 에서 해당 포지션을 갖는 것이 현재 사용하는 디바이스 이며, 카메라 포지션이란 디바이스의 카메라 위치를 말한다.

iPhone인 경우 전면 카메라와 후면 카메라가 있다.

3.2. Jpeg Library

Core Engine 에서 trackable 을 인식/ 추적하기위해, DB에 포함된 JPEG 파일을 디코딩 한다. Windows, Android 는 기존의 jpeg library 인 libjpeg 를 사용하였다.

(25)

libjpeg은 Independent JPEG Group 에서 개발한 library로, JPEG 파일의 디코딩, 인코딩이 구현된, 전 세계적으로 널리 쓰이는 library다. libjpeg은 JPEG 과 다른 사진 파일

포맷간의 변환을 수행하기도 하며, JFIF 파일 안의 텍스트의 읽고 쓰기를 수행하기도 한다. 하지만 iOS 에서는 이 library를 사용할 수 없었다. 렌더링 엔진인 Unity3d 가 iOS 의 64bit를 지원하는 4.6 버전으로 업데이트 되면서 IL2Cpp 백엔드를 이용한 빌드방식을 지원하기 때문이다. IL2Cpp로 빌드방식이 바뀌면서 이전 버전과 달라진 점들을 꼽자면,

- 32bit, 64bit binary를 모두 포함하는 빌드가 생성되기 때문에 빌드 사이즈가 커진다.

- code stripping 이 항상 작동한다. Stripping level 를 비활성화해도 동작한다.

- native plugin 사용시, 64bit 지원되는 플러그인이 필요하다. 각 벤더들에게 64bit와 IL2Cpp 호환이 되는 플러그인을 제공받아야 한다.

등의 이슈가 있다. 이 중에 3번과 같은 이유로 인해 IOS 에서 기존의 libjpeg 를 사용할 수 없게 되었다. 해서, JPEG 픽셀 데이터 파일을 Quartz 이미지로 생성하여 JPEG 이미지 정보를 얻어내는 방식으로, 디코더의 기능을 iOS native 방식으로 구현하였다. Quartz는 CoreGraphics.framework 의 일부이며, iOS 및 OSX 의 그래픽 엔진을 다루는 API framework로, 상당히 괜찮은 성능과 품질로 그래픽 처리를 할 수 있는 그래픽 엔진이다.

Quartz는 비트맵 이미지 (CGImageRef)를 생성할 때 다음과 같은 정보를 사용한다.

- Quartz 데이터 제공자나 Quartz 이미지 소스가 될 수 있는 비트맵 이미지 소스

- 복원배열.

복원 배열은 이미지 흑백 변환이나 색상 전환과 같은 작업에 유용한 이미지 색상 값을 다른 색상 값으로 매핑하게 된다. 배열은 각 색상 컴포넌트에 대한 숫자 쌍을 포함한다.

Quartz 가 이미지를 렌더링 할 때, 원래의 컴포넌트 값을 목적지 색상 공간에 적절한 범위로 매핑하기 위해 선형 변환을 적용한다. 예를 들어, RGB 색상 공간의 이미지의 복원 배열은 빨강, 초록, 파랑 색상 컴포넌트에 대해 각 한 쌍씩, 총 6개의 값이 포함된다.

- 픽셀 포맷. 픽셀 포맷은 다음정보로 구성된다.

1) 픽셀에서 각 개별 색상 컴포넌트의 비트수를 나타내는 컴포넌트 당 비트 수(이미지 마스크에서 이 값은 소스 픽셀에서 중요한 마스킹 비트의 수를 나타낸다. 예를 들어, 소스 이미지가 8비트 마스크라면, 컴포넌트 당 8비트가 된다.)

2) 소스 픽셀에서 총 비트 수를 나타내는 픽셀 당 비트 수(이 값은 픽셀당 컴포넌트 수 * 컴포넌트 당 최소 비트수가 되어야 한다.)

(26)

3) 행 당 비트 수. (이미지에서 수평 행당 바이트의 수가 된다.)

- 색상 공간과 비트맵 레이아웃

Quartz가 픽셀 당 비트 수를 정확히 해석하는지 확인하려면 다음 사항을 명시해야 한다.

1) 비트맵이 알파 채널을 포함하는지 나타내야 한다. Quartz는 RGB, CMYK, GRAY 색상 공간을 제공한다. 알파 정보가 모든 비트맵 이미지 포맷에서 가능하지는 않지만, Quartz 는 알파나 투명도를 제공한다. 가능하면 알파 컴포넌트는 픽셀의 최상위 비트나 최하위 비트에 위치된다.

2) 알파 컴포넌트를 갖는 비트맵에 대해서, 색상 컴포넌트에 이미 알파 값이 곱해졌는지 나타내야 한다. 미리 곱해진 알파 값은 알파 값에 의해서 이미 곱해진 컴포넌트의 소스 색상을 나타내야 한다. 미리 곱하는 것은 색상 컴포넌트마다 곱셈 시간을 제거하는 것으로 이미지를 렌더링 하는 시간을 줄일 수 있다.

3) 정수나 실수 값인 샘플의 데이터 포맷

그림 21. iOS Framework

(27)

3.3. AssetBundle

유니티에서 asset이란 유니티 프로젝트에서 공용으로 사용하는 데이터를 의미한다.

3D 모델링, 이미지, 사운드, 텍스트 및 스크립트 파일등 모든 데이터가 asset이 될 수 있다. 더 쉽게 설명하면 프로젝트 뷰에 목록이 보이면 이 아이템들이 각각 asset이라고 해도 무방하다. asset은 파일 뿐만 아니라 메타 데이터라고 하는 엔진 내에서 데이터 활용을 위해 변환하는 정보도 같이 포함한다. 그리고 에디터는 각 asset에 고유한 GUID를 부여하고 관리한다.

AssetBundle이란 이러한 asset들을 묶어서 하나로 관리하는 파일을 의미한다. 다른 사용자에게 다량의 파일을 전송할 때 디렉토리 구조 및 파일들을 모아 하나의 zip파일에 압축하여 전송하듯이, 게임 제작에 사용하는 asset에 관련된 원본 데이터 및 관련 설정을 모두 포함하여 하나의 파일로 묶어 준다. 유니티에서 게임을 만들고 빌드하면

실행파일과 함께 이를 뒷받침하는 asset들이 제공된다. 이 asset들은 유니티만의 고유한 포맷으로 압축 및 보안이 적용된 형태로 저장되어 있어서, 빌드 후에는 이를 변경하는 것이 불가능하다. AssetBundle을 사용하게 되면, 게임에 사용되는 리소스들을 별도로 분리하여 나중에 스트리밍 방식으로 다운로드 받을 수 있도록 관리가 가능해진다.

AssetBundle을 통해 컨텐츠 패치를 수행할 수 있으며, 사이즈에 민감한 모바일의 경우, 초기 버젼은 사이즈를 작게 만들어서 배포하고 추가적으로 필요한 데이터들은 인터넷을 통해 점진적으로 받으면서 서비스 할 수 있다.

그림 22. Quartz에서 CMYK와 RGB 색상 공간의 16bit / 32bit

pixel format

(28)

AssetBundle은 유니티 에디터 라이브러리의 BuildPipeline 클래스를 통해 제작할 수 있다. 유니티 에디터에서 AssetBundle을 만드는 메뉴는 없으며, 에디터를 확장해서 직접 제작해야 한다. 일반적으로 에디터의 프로젝트 뷰에서 현재 선택된 파일 정보를

나타내는 Selection 클래스와 조합해서 사용한다. AssetBundle은 만드는 타입에 따라 크게 아래의 3 가지로 구분할 수 있다.

1) 일반 asset 번들 : 모든 타입의 asset을 묶어서 제작할 수 있다.

BuildPipeline.BuildAssetBundle 함수를 사용한다. 주 asset을 지정하는 첫 번째 인자에 특정 asset을 지정하면, AssetBundle.mainAsset 프로퍼티를 사용하여 바로 가져올 수 있다.

2) 스트리밍 씬 asset 번들 : 씬에 관련된 asset을 묶어서 저장하며, 이를 사용하면 새로운 씬을 스트리밍으로 로딩할 수 있다.

BuildPipeline.BuildStreamedSceneAssetBundle 함수를 사용한다.

3) 이름이 지정된 asset 번들 : 일반 AssetBundle과 동일하지만 각각 asset에 사용자가 지정한 이름을 지정할 수 있다.

BuildPipeline.BuildAssetBundleExplicitAssetNames 함수를 사용하며

BuildAssetBundle 함수와의 차이는 주 asset(Main Asset)을 지정하는 기능이 없으며, 대신 사용자가 지정한 이름의 배열을 지정할 수 있다

AssetBundle은 제작 옵션을 여러 가지로 설정할 수 있다.

1) CollectDependencies : 특정 asset에 연관된 다른 asset을 모두 포함시킨다.

2) CompleteAssets : asset이 속하는 게임 오브젝트와 관련된 모든 asset을 포함시킨다.

3) DisableWriteTypeTree : 유니티 버젼 정보가 달라도 asset의 정보를 올바르게 인식할 수 있는 타입트리(TypeTree) 정보를 제거하여 AssetBundle을 제작한다.

그림 23. 여러 Asset들을 AssetBundle를 이용하여 Server에 Upload

(29)

4) DeterministicAssetBundle : AssetBundle을 다시 빌드하더라도 처음 AssetBundle이 가지고 있던 GUID의 해시 값을 그대로 유지한다.

5) UncompressedAssetBundle : AssetBundle을 제작할 때 압축하지 않는다.

해당 옵션들은 모두 OR 연산에 의해서 복수개 지정이 가능하다. 마지막으로 플랫폼에 따라 AssetBundle간의 호환성이 다르기 때문에 반드시 빌드타겟을 명시해 주어야 한다.

AssetBundle은 Platform및 유니티 버젼에 따라 호환성 문제가 일어날 수 있다.

StandAlone Platform 및 Web Platform으로 제작된 AssetBundle들은 서로 호환되지만, iPhone 및 Android Platform AssetBundle은 다른 Platform의 AssetBundle과 서로 호환되지 않는다. 예를 들어 iPhone, Android에 모두 호환되는 서비스를 제작하기 위해서, 총 2가지 종류의 AssetBundle을 제작해야 한다.

그리고 유니티의 버전에 따라 AssetBundle의 호환성도 고려하여야 한다.

유니티에는 타입트리(Type Tree)라는 데이터가 있는데, 이 데이터가 AssetBundle에 포함되어 있으면 다른 버젼에서 만든 AssetBundle을 파악할 수가 있어서 AssetBundle을 재활용할 수 있게 된다. 하지만 모든 Platform AssetBundle에 타입트리 정보가 포함되는 것은 아니다. 모바일용 Assetbundle은 처리속도를 위해 타입 트리 정보가 포함되지 않게 설계되어 있어 유니티 버젼이 변경되는 경우 AssetBundle을 다시 빌드해야 한다.

StandAlone Platform은 빌드시 사용자 설정에 따라 타입 트리 정보의 포함 유무를 지정할 수 있으며, Web Platform은 언제나 타입 트리 정보를 포함한다. 이렇게 다운받은 AssetBundle 은 WWW클래스의 assetbundle 프로퍼티를 통해 AssetBundle 클래스를 사용하여 접근, 원하는 asset을 Runtime에서 로딩하는 것이 가능하다.

표 1. AssetBundle이 호환되는 Platform

(30)

3.4. 3D Animation Contents

정교한 증강을 위해선 실 물체 사이즈 비율을 고려하여 콘텐츠를 제작하여야 한다.

또한 현실과의 정합성을 높이기 위해선 물체의 디테일한 표현보다는 단순화된 콘텐츠가 현실과의 이질감이 덜하다. Occlusion 이 고려되지 않은 콘텐츠라면, 실제 눈에 보여지는 부분들만 렌더링 해주는 것도 하나의 방법이다. 모든 환경을 콘텐츠로 제작하지 않는한, 보이지 않는 영역까지 렌더링해주는 방법은 오히려 사용자에게 현실스럽지 못한 느낌을 줄 수 있다. 다채로운 색상보다는 한 두가지의 심플한 색상이 증강에 있어서 집중도를 높여주기도 한다.

또한, 정확한 위치에 증강하기 위해선 증강시킬 환경에 따라 콘텐츠의 루트를 수정하는 것을 권장한다. 예를들어 사용자가 증강시킬 물체의 top 부분을 바라본다고 하면, 콘텐츠의 top - center 에 루트를 설정하는 것이 위치시키기에 편리하다.

콘텐츠의 애니메이션과 사운드는 Tracking Success/Fail 에 의해 동작해야 한다.

각각의 컴포넌트들은 Runtime 시에 해당 콘텐츠를 찾아 Play / Pause / Stop 동작을 설정해줘야 한다. 이러한 런타임시의 컴포넌트 동작들은 Unity3d 의 Coroutine 을 이용하여 설정하는 것이 바람직하다.

3.5. Video / Alpha Video

비디오 증강을 하기 위해선 비디오 컨트롤러 역할을 하는 video player가 필요하다.

player의 비디오 텍스쳐를, Unity3d 에서 생성한 비디오 텍스쳐의 Id를 전달받아 해당 Id 의 텍스쳐에 binding 해야 한다. 이 때의 비디오 콘텐츠는 native 에서 전달받은 비디오 정보를 갖고 스케일을 설정한다. Windows, Android 는 로컬, 스트리밍 비디오 플레이가 가능하며, Mac, iOS 는 로컬 비디오 플레이만 가능하다.

- Alpha Video

Alpha Video 를 구현하기 위해선 비디오를 RGB 영역과 Alpha 영역을 추가하여 제작해야 한다.

그림 5. Runtime시, Server에서 AssetBundle을 Load하여 각각의 Asset 사용

(31)

[그림7]과 같이 왼쪽 영역엔 재생될 RGB영상, 오른쪽엔 Alpha값을 나타내는 영상을 제작 하여야 한다. 이때의 두 영상은 사이즈가 같아야 하며, 각 영상의 상하좌우에 여백이 없어야 한다. 오른쪽의 Alpha영상은 Alpha값이 적용되어 투명하게 보일 영역은 검은색, Alpha가 적용되지 않는 부분은 하얀색으로 제작하여야 한다. 현재 기술은 [그림7]과 같이 좌우로 영상을 제작할 수도 있지만, 상하의 영상을 제작, 증강도 가능하다. 왼쪽의 RGB영상과 오른쪽 Alpha영상을 합쳐주기 위해서, Unity3D의 Custom Shader를 제작하였다. 총 영상의1/2이 Alpha Video의 width이므로, 텍스쳐 좌표를 이용하여 왼쪽 영상의 RGB 값과 오른쪽 Alpha값을 렌더링하면 [그림8]과 같이 Alpha가 적용된 비디오가 렌더링된다. Alpha Video 증강은 로컬비디오만 지원하며, mp4 포맷을 지원한다.

3.6. Camera Interface

실시간 영상 처리를 하는 증강현실 기능에서 가장 중요한 입력 장치는 Web camera 나 Smart phone 의 카메라이다. 어플리케이션 개발 초기 단계에서는 PC 기반으로 개발을 하고 카메라를 제어 기능은 opencv를 사용해서 개발했다. 다음 단계로Android 버전으로 알고리즘 포팅을 하고 Smart phone의 카메라를 연동할 필요가 생겨 PC버전과 다른 인터페이스를 가진 구조로 개발을 하게 됐는데 구조다 다르다 보니 기능 변경이 생길 때 마다 PC 버전과 Android 버전을 각각 수정해야 하는 문제가 생겼다. 이를 위해 동일한 인터페이스 구조를 갖도록 해야 할 필요성이 생겼고 다음과 같은 연구/개발

그림 7. RGB영상(좌), Alpha 영상(우)

그림 8. Alpha Video 증강 화면

(32)

과정을 거쳤다.

- C/C++ -> Java 코드 호출

최초 고민은 Java -> C/C++ 코드 호출은 가능하지만 C/C++ -> Java 코드를 호출하는 방법을 찾는 것이었다. 해결책은 다음과 같다.

1) Java static 메소드를 통한 java 객체 얻어오기

생성된 java 객체는 native에서 직접 호출하는 방법은 없고 Java 코드에서 반드시 static 메소드를 구현해야지만 이것을 통해 native 쪽에서 생성된 java 객체를 얻을 수 있다.

2) 얻어온 Java 객체에서 Java 클래스 타입 유추

Java 객체를 얻었다면 GetObjectClass() 함수를 통해 java 의 클래스 타입을 구할 수 있다.

3) Java 클래스 타입에서 public 메소드 얻어오기

GetMethodID 함수를 통해 java 클래스의 메소드 id 를 구할 수 있다.

4) Native 코드에서 Java 코드 호출하기

생성된 Java 객체를 얻었고 메소드 id 도 구했기 때문에 CallVoidMethod 함수를 통해 Java 함수를 호출할 수 있다.

이렇게 C/C++ → Java 함수 호출하는 방법을 알았기 때문에 이제 PC, Android 가 동일한 구조를 가질 수 있는 기반을 갖게 됐다.

다음으로 연구하게 된 것은 os별 빌드를 통해 하나의 객체만 생성하는 방법이다.

이것이 필요한 이유는 Application 단에서는 제어하려는 카메라가 windows 용인지 Android용인지 판단할 필요 없이 추상 인터페이스만 통해서 해야 하기 때문이다. 해결 방법은 추상 클래스에서 getInstance() 라는 static virtual 함수를 두고 WindwosCamera와 AndroidCamera 가 각각 이것을 구현하는 것이었다. 위의 과정들을 통해 나온 구조는 아래 그림과 같다.

즉, Application 쪽에서는 Windows, Android 신경쓰지않고 CameraDevice라는 추상 클래스만으로 카메라 제어를 하고 출력을 받을 수 있는 구조가 가능하다.

그림 9. Camera Interface 구조

(33)

(3) 시범서비스용 모바일 애플리케이션 개발

1) 시스템 아키텍처

- 시스템 아키텍처는 Beacon을 스캔하는 Service와 앱 구동 및 AR 인식, 랜더링 등을 담 당하는 Activity 부문이 있다.

- Bluetooth Adapter를 통해(start LeScan method로 스캔시작) Beacon을 스캔하고, Beacon의 address, name, rssi 정보를 얻는다. rssi 값을 통해서 위치 및 유물을 파악한다.

- 앱의 UI 및 기능을 Activity에서 담당한다.

- Metaio SDK를 통해서 AR을 인식하고, 등록된 3D 컨텐츠나 영상을 제어한다. 카메라 정보를 얻어서 Unity에서 카메라화면을 그릴 수 있도록 한다.

- Unity classes를 통해서 Metaio SDK에 의한 결과화면을 랜더링한다(화면에 카메라화면, 3D 컨텐츠나 영상을 보여준다.

2) 시스템 인터페이스

(34)

- 3D 증강을 위해서 Metaio SDK를 사용한다.

- Metaio : 기기의 카메라를 통해서 물건을 인식하고, 인식 시 유니티를 제어해서 3D 컨 텐츠나 영상을 보여준다. Unity에서 Metaio SDK script로 기능을 제어한다.

Metaio SDK안의 Device Camera는 android에서 카메라 정보를 받아서 texture로 만들어서 카메라 화면을 보여준다. Metaio SDK안에 Metaio Tracker를 등록하고 그 안에 3d 컨텐츠 나 영상을 재생해줄 Video Plane을 넣으면, tracking될 때 보여진다.

- Unity : 인식 시 Open GL을 제어해서 3D 컨텐츠나 영상을 랜더링 한다.

안드로이드에서 Unity를 사용하기위해, Unity Player Activity를 상속받아 사용한 다.

Unity Player Activity -> Unity Player Native Activity -> Native Activity로 상속된다.

Native Activity는 NDK를 통해 실질적은 기능들을 제어하고, Unity Player Native Activity 는 UnityPlayer를 통해서 안드로이드의 surface 제어해서 최종 결과를 화면에 보여준다.

3) 기타 개발 기술

3.1. 무궁화 지도자수 게임 기술

(35)

- Image View를 통해서 Map 이미지를 나타낸다. Image View에 터치 이벤트를 등록하여, 터치 했을 때 좌표 정보를 받는다.

- Map image의 bitmap 정보를 얻는다. 터치 시, 터치 좌표로 bitmap에서 픽셀을 얻는다.

얻은 픽셀 값이 0이 아니면 Map 터치로 처리한다.(픽셀 값이 0이면 흰바탕을 터치했다고 볼 수 있다.)

- 안드로이드의 화면 좌표계에서는 좌상단이 기준점이 된다. 그래서 터치 시의 좌표를 그대로 적용하면, 꽃 이미지의 좌상단 점이 위치하게 된다.

이미지의 중심이 위치하도록 하기 위해서 이미지의 가로크기 반 만큼 왼쪽으로 (-imageWidth * 0.5) 세로크기 반 만큼 위쪽으로(-imageHeight * 0.5) 이동 시킨다.

- 이미 위치된 꽃 위에 터치 시 다시 꽃이 위치하는 것(메모리가 부족할 때 까지 무한정 꽃이 생긴다.) 을 방지하기 위해서 사각형 충돌 체크를 활용한다.

Map 이미지가 크지 않기 때문에, 꽃 이미지 크기 그대로 사각형 영역을 적용하면 매우 적은 수의 꽃만 위치되므로 가로의 0.3, 세로의 0.3 길이를 빼서 사각형 영역을 적용한다.

(36)

3.2. 블루투스 (비콘)

- Bluetooth Adapter.startLeScan (Le Scan Callback)으로 기념관에 설치된 비콘을 검색한 다.

- Le Scan Callback의 onLeScan (Bluetooth Device, rssi, scanRecord)를 통해서 비콘 정보 들이 전달된다. rssi 값의 크기를 비교해서 가까운 값의 비콘을 선택한다.

AR페이지가 아닐 경우, 이 비콘과 매칭되는 유물의 AR 페이지로 유도하는 팝업을 띄운 다. AR의 도움말 페이지일 경우 비콘에 따른 위치를 표시한다.

- LeScanCallback은 Android 4.3 버전(Jelly Bean)부터 사용이 가능하다.

(37)

4) 안드로이드 애플리케이션 개발

4.1 요구사항 분석

4.2 요구 사항 반영

ü 기존의 박물관 앱과 달리 유물 중심이 아닌 콘텐츠 중심으로 시나리오

ü 앱에 간략한 정보를 제공하여 최용신 기념관에 대해 더 많은 관람객이 찾을 수 있 도록 함

ü ‘최용신’이 누구인가에 대해 알려줄 수 있도록 인물 위주로 스토리를 구성 ü 텍스트로만 제공되던 기존의 전시관 스토리텔링을 음성으로 변환하여 텍스트와 음

성을 함께 제공

4.3 주요화면 개발

4.3.1. 최초 화면

(38)

- 최용신기념관 로고와 함께 첫 화면 부팅

- 비콘 신호를 받기 위해 블루투스가 켜져 있는지 체크하고, 꺼져있을 시 팝업을 띄 서 블루투스를 켜도록 유도한다.

4.3.2. 메인 메뉴

메인 메뉴는 크게 박물관 소개, 3D 증강현실, 전시스토리텔링 으로 구성된다.

- 박물관 소개, 3D 증강현실, 전시 스토리텔링 카테고리가 존재한다.

- 좌/우 버튼 터치 시 보여지는 카테고리가 변경된다.

(39)

- 박물관 소개 : 최용신 기념관에 관한 정보를 제공한다.

- 3D 증강현실 : 3D 증강을 할 수 있는 유물 정보를 제공한다.

- 전시 스토리텔링 : 전시실에 대한 영상 정보를 제공한다.

4.3.3 박물관 소개

- 기념관 개요 : 최용신 기념관의 개괄적인 소개를 볼 수 있다.

- 둘러보기 : 기념관이 어떤 구성을 이루고 있는지 한 눈에 볼 수 있다.

- 오시는 길 : 기념관의 위치를 알 수 있다.

- 관람안내 : 기념관을 이용할 수 있는 시간, 관람료에 대한 정보를 얻을 수 있다.

단체예약 신청 버튼 터치 시, 최용신 기념관 홈페이지의 예약 페이지로 링크 시킨다. 여기서 예약을 할 수 있다.

(40)

4.4.4 3D 증강현실

- 최용신 선생 흉상, 유언장, 샘골강습소 낙성식을 증강할 수 있고, 각 유물 정보를 제공한다.

- AR 버튼 터치 시, 카메라 화면으로 이동해서 유물을 증강할 수 있다. 증강했을 때

(41)

3D 모델이나 영상이 증강되는 유물에 나타난다.

- 유물 정보 버튼 터치 시, 유물에 대한 정보가 나오는 페이지로 이동된다.

- 무궁화 지도자수 게임의 게임시작 버튼을 터치하면 게임 페이지로 이동된다.

- 무궁화 지도자수처럼 무궁화로 지도를 꾸밀 수 있는 체험컨텐츠이다.

- 지도 위에 터치 하면, 그 위치에 무궁화가 나타난다. 무궁화는 백단심,자단심, 적단심, 청단심 순으로 나타난다.

- 도움말 버튼( i ) 터치 시, 도움말 페이지로 이동한다.

- 비콘 신호를 통해서 현재 어떤 전시실에 있는지 알 수 있다.

(42)

2. 참여기관1 (한국정보공학) : 비콘 디바이스 프로토타입 개발 및 실내 측위 알고리즘 개발

구 분 연구내용 실 적 달성도 %

비콘 디바이스 프로토타입 개발 및 실내

측위 알고리즘

개발

비콘 디바이스 프로토타입 개발 1. H/W 설계

2. H/W 프로토타입 개발

3. H/W 성능 테스트 4. H/W 펌웨어 개발

1. 비콘 디바이스 H/W 설계 - 비콘 H/W 설계 완료 - H/W 설계서 1건 2. 비콘 프로토타입 개발

- 비콘 프로토타입 개발 완료

3. H/W 성능 테스트 - 펌웨어 및 배터리 성능

테스트 완료 - 시험 성적서 1건 4. H/W 펌웨어 개발

- 비콘 H/W 펌웨어 개발 완료

100

실내 측위 알고리즘 1. 실내 측위 알고리즘 분석 및 설계

2. 실내 측위 알고리즘 개발

1. 실내 측위 알고리즘 설계 완료

- 실내 측위 알고리즘 설계서 1건

100

(43)

2. Fingerprint 알고리즘 개발 - 스마트 폰 기반 알고리즘

S/W 개발 완료

3. PDR 알고리즘 개발 - 스마트 폰 기반 PDR 알고리즘 S/W 개발 완료

4. Fingerprint 데이터 수집 알고리즘 개발

- 서버 기반 데이터 수집 알고리즘 S/W 개발 완료

실내 측위 DB 개발 1. 실내 측위 DB 구축 2. 실내 측위 DB 관리 모듈 개발

1. 실내 측위 DB 구축

- DB 설계 완료 : 설계서 1건 - 논리 데이터베이스 설계 완료

100

(44)

- DB 스키마 정의서 1건 - 리눅스 기반 MySql DB서버 구축 완료

2. 실내 측위 DB 관리 모듈 개발 - RESTful 방식의 서버

어플리케이션 개발 완료 - 비콘 rssi 수집용 안드로이드 앱 개발

- 비콘 rssi 수집 기능 개발 - 사용자 좌표 수집 기능 개발 - 서버/클라이언트 통신을 위한 API 연동 문서 1건

수치

그림  2 카메라 내부인자 (f_x, f_y, skew_c, c_x, c_y)와  자세 (r_11 ~ r_33, t_1 ~ t_3)가 주어졌을 때, 3차원 점 (X, Y,
그림  9 threshold 65일 때의 FAST corner detector의 검출 결과 예.
그림  10 SIFT를 이용한 특징점 검출 및 기술자 생성의 예
그림  12 Cartesian 좌표계 (X, Y, Z)와 inverse depth 좌표계  (x, y, z, rho, theta, phi) 사이의 관계
+7

참조

관련 문서

– 느리고 시간이 많이 드는 모든 작업을 메인 애플리케이션 쓰레드에서 자식 쓰레드 로 옮긴다. – Activity, Service, Broadcast Receiver 등을 포함한 모든

계획 목표는 국토 를 종합적으로 개발하여 증산과 수출을 최대한으로 지원하는 동시에, 국민복지생활 을 균등히 증진시키는 것이다... ③ 수리간척을

학생이 주인이 되는 미래형 학교를 만들겠습니다.. 학생 성장을

Nordstrom의 구조는 경영자들이 하위 계층의 종업원들에게 권한을 위양하고 그들을 지원하는 것이 중요하게 인식하는 조직문화를

업무 시스템의 이벤트 로그 데이터를 분석하여 실제 프로세스를 도출하고, 프로세스 개선을 지원하는 프로세스 마이닝 기반

Bluetooth 장치에 무선 연결하는 방법 페어링된 Android 스마트폰에 연결 Bluetooth 연결을 통해 장치에서 음악 듣기 헤드셋을

An Android program generally forms a Java program with APIs in Android platform. Using the APIs, one can build user interfaces to make a phone call, play a game, and so on. An

• 대체에너지개발, 에너지 효율화, 탄소저감기술의 개발, 탄소포집 및 저장, 탄소를 원재료로 이용하는 기술 개발 등에 지원하는