Mobilny Alarm Lawinowy

Marek Białowąs

Spis treści

1. Wstęp2. Android3. Algorytm4. Wnioski5. Demo6. Pytania7. Zdjęcia

#1Wstępczyli: o co dokładnie chodzi

Pomysł

● Co chcemy?‒ Aplikację na tel. komórkowy‒ Wykrycie „porwania przez lawinę“ w górach‒ Odpowiednia reakcja – np. wysłanie SMS z

prośbą o pomoc (i współrzędnymi), sygnały dźwiękowe pomocne przy szukaniu poszkodowanego

● Jak?‒ System operacyjny – Android‒ Sensory: akcelerometry (przyspieszenie -+3g w

3 osiach), magnetometry (możliwość obliczenia obrotu telefonu)

Motywacja

Podstawową motywacją do realizacji tego projektu

jest możliwość zwiększenia zimowego bezpieczeństwa w górach przy minimalnym koszcie.

Grupą docelową aplikacji są turyści, którzy okazyjnie poruszają się zimą po górach (pieszo, na rakietach, czy jeżdżąc pozatrasowo na nartach/snowboardzie). Robią oni raczej wycieczki jednoniowe i pozostają w zasięgu telefonii komórkowej (oraz pomocy z zewnątrz).

Definicja problemu● Problem wykrywania aktywności wykonywanej

przez użytkownika● Musimy robić to:

‒ Na bieżąco (strumień ciągle napływających danych)‒ Na telefonie (algorytm nie może być ciężki)‒ Szybko (opóźnienie pomiędzy akcją a jej wykryciem

nie może być zbyt długie)● Schemat rozwiązania:

‒ Wyciągamy z danych pewne cechy, za pomocą których najłatwiej odróżnić poszczególne aktywności

‒ Trenujemy klasyfikator, który będzie je odróżniał● Tylko...

‒ Jakie aktywności? Skąd dane?‒ Jakie cechy? Jaki algorytm klasyfikujący?

#2Android

czyli: z czym to się je

Dlaczego Android?● Popularny

‒ W USA najpopularniejszy (Google - 31.2%; RIM - 30.4%, Apple – 24.7%) - średnia z ostatnich 3mies.

‒ Coraz więcej telefonów (i tabletów) na tej platformie● Każdy może pisać aplikacje, jakie tylko chce

‒ Nie tylko Android Market (vs. App Store)‒ Możliwe aplikacje OSS (no license, no review)

● Fajnie się na niego pisze ;)‒ Java (vs. Objective C), a nawet C/C++‒ Eclipse, a nawet tylko ant (vs Apple Xcode)‒ Narzędzia wspomagające tworzenie aplikacji

Informacje ogólne● Android to nie GNU/Linux

‒ Android oparty jest na jądrze Linuxa (modyfikacje: Alarm, Binder, Power Management, LMK, ...)

‒ Nie ma glibc (Bionic libc)● Biblioteki systemowe (C/C++)

‒ WebKit – do wyświetlania‒ SQLite – data storage (lekka, transakcyjna BD)‒ Media Framework, Flingers‒ HAL – pisanie sterowników w C/C++ w userspace

● Dalvik Virtual Machine‒ To nie jest JVM (własny byte-code - .dex)‒ przenośność aplikacji‒ Bezpieczeństwo (sandboxing)

Komponenty Aplikacji

AndroidManifest.xmlAndroidManifest.xml

Act

ivitie

sAct

ivitie

s

Vie

ws

Vie

ws

Inte

nts

Inte

nts

Ser

v ice

sSer

v ice

s

Notif ica

t ions

Notif ica

t ions

Cont e

ntP

rov i

der

sCont e

ntP

rov i

der

s

Activities● Aktywności działają jak

stos kart● Tylko jedna jest na

wierzchu● Tylko jedna jest

aktywna● Każda nowa Aktywność

ląduje na górze stosu

Cykl życia aktywności

Prostokąty, to funkcje które możemy nadpisać w naszej Antywności

Views● View to podstawowy klocek do budowy UI● Wie jak siebie narysować● Odpowiada na zdarzenia● Łącznie zorganizowane jako drzewo (do budowy

GUI)● Opisany przez XML w resource'ach

Views● Android odpowiedzialny

jest za:‒ Wymierzenie‒ Rozmieszczenie‒ Rysowanie

● No i mamy dzięki temu spójne UI!

Intents● Intent używany jest do poruszania się między

aktywnościami● Opisuje, co aplikacja chce zrobić● Łączenie Intentu z konkretną Aktywnością w czasie

działania

● Każda aplikacja może określić, że potrafi odebrać dany Intent

● Przykład: odtwarzacz wideo (gdziekolwiek użytkownik będzie chciał odtworzyć wideo, może zdecydować którą aplikację chce użyć)

atrybut opis

action Akcja, którą chcemy wykonać, np. EDIT, VIEW, MAIN, itp.

data Dane, na których chcemy operować, np. Wpis osoby z książki tel., jako URI

atrybut opis

action Akcja, którą chcemy wykonać, np. EDIT, VIEW, MAIN, itp.

data Dane, na których chcemy operować, np. Wpis osoby z książki tel., jako URI

Services● Chodzą w tle● Brak interakcji z użytkownikiem● Chodzą w głównym wątku (UI)

aplikacji (!!!)● Działa dopóki:

‒ Przetwarza komendę‒ Jest związany z Aktywnością

Notifications● Do informowania

użytkownika o zdarzeniach

● Wysyłane przez NotificationManager

● Widoczne w górnym pasku telefonu

● Można ustawiać:‒ Typ: jednorazowe/ciągłe‒ Ustawianie LEDów‒ Dźwięk/wibracja‒ Intent na kliknięcie

Content Providers● ContentProvider to obiekt, który potrafi:

‒ Pobierać dane‒ Trzymać dane

● Dane są dostępne dla każdej aplikacji● Jedyny sposób na współdzielenie danych między

aplikacjami● Dane udostępniane są jako unikalny URI

AndroidManifest.xml● Plik który opisuje jak traktować aplikację● Spis wszystkich Activities i Intentów, które one

odbierają● Spis wszystkich Services● Spis używanych Permissions

#3Cechy

czyli: jak nadać znaczenie liczbom

Problemy● Przyspieszenie ziemskie

(nie znamy kierunku)● Swobodny spadek

(wartości: 0)● Ruch jednostajny (nie

znamy prędkości pocz.)● Przyspieszenie kątowe● Dane we „współrzędnych

telefonu“ (obrót urządzenia)

Time series embedding #1● Intuicja:

‒ Korzystając z kilku ostatnich pomiarów chcemy odtowrzyć trajektorię ruchu

● Trochę matematyki:‒ Założenia:

● Obserwujemy deterministyczny układ dynamiczny (czyli: istnieje zasada, za pomocą której znając obecny stan, możemy przewidywać przyszłe stany)

● Dla ułatwienia zapisu – dyskretny (prawda: pomiary z pewną częstotliwością)

● Zakładamy, że proces jest stacjonarny (dokładnie - później)

Time series embedding #2

zn∈M⊆ℝk

Niech:

będzie k-wymiarowym wektorem stanu, M – atraktorem, do którego ewoluuje układ dynamiczny, oraz funkcja ewolucji:

:M×ℤM taka, że: zn , t =zntWówczas, układ dynamiczny jest deterministyczny, jeśli jest deterministyczna, tzn. jesteśmy w stanie napisać matematyczną regułę przejścia ze stanu do Ponadto:

M ,

zn znt

xn=xm⇒xn , .=xm , .nawet jeśli n≠m(stacjonarność)To nie takie straszne, bo k (ilość wymiarów systemu nie jest ograniczona). Najczęściej dobieramy takie k, by była stacjonarna.

Time series embedding #3Mamy deterministyczny, stacjonarny układ dynamiczny.Teraz, funkcja obserwacji:

g :M ℝ

która daje nam opis aktualnego stanu w postaci skalarnej.Pojedyncza wartość g(.) nie opisuje nam całego układu, ale obserwując przez pewien ciągły czas – tak.xn=g zn

Zgodnie z twierdzieniem Takensa o embeddingu: dla odpowiednio dużego , ewolucja będzie taka sama jak .

de xn , xn−1 , xn−2 ,, xn−d e

zn

Dowód tego twierdzenia jest topologiczny, ale można wytłumaczyć to intuicyjnie: powiedzmy, że możemy policzyć wielokrotne pochodne g(.) do pewnego skończonego poziomu d. Jeśli d >wymiar układu, możemy go w pełni opisać (mamy d równań). Ale, dla odpowiednio dużej częstotliwości, mierzenie d pochodnych jest równe d następującym po sobie pomiarom układu.

#4Wnioski

czyli: czy to zadziała?

Co z tego wynika?● Funkcja obserwacji – wartość wektora przyspieszenia:

Czyli: pozbywamy się problemów z obrotem urządzenia.● Musimy (eksperymentalnie) dobrać wymiar i opóźnienie● Wynik wykorzystujemy jako dane dla klasyfikatora● Do przemyślenia

‒ Co z szumem? (filtowanie niskoprzepustowe, PCA?)‒ Może jeszcze jakieś inne cechy? (np. „obrotowość“?)‒ Jaki klasyfikator? (sieci neuronowe?)

x2 y2z2−g

Czy to działa?

#5Demo

czyli: chwalę się tym, co już mami sprytnie przemilczam to, czego brakuje

Co jest zrobione● Aplikacja do zbierania i

wysyłania danych – SensorLog

● Strona z informacjami● Strona do zbierania

danych● Dane z lawin

Pobierz aplikację:

http://avl.wm.lapy.pl/

#6Pytania

których nie ma, więc przechodzimydo zdjęć z Indii!