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!