1. Mobilny Alarm Lawinowy
Marek Białowąs

2. Spis treści
1. Wstęp
2. Android
3. Algorytm
4. Wnioski
5. Demo
6. Pytania
7. Zdjęcia

3. #1
Wstęp
czyli: o co dokładnie chodzi

4. 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)

5. 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).

6. 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?

7. #2
Android
czyli: z czym to się je

8. 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

9. 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)

10. Activities
Activities
Views
Views
Intents
Intents
Services
Services
AndroidManifest.xml
AndroidManifest.xml
Notifications
Notifications
Komponenty Aplikacji
ContentProviders
ContentProviders

11. 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

12. Cykl życia aktywności
Prostokąty, to funkcje które możemy
nadpisać w naszej Antywności

13. 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

14. Views
●
Android odpowiedzialny
jest za:
‒
Wymierzenie
‒
Rozmieszczenie
‒
Rysowanie
●
No i mamy dzięki temu
spójne UI!

15. 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
atrybut
atrybut opis
opis
action
action Akcja, którą chcemy wykonać, np. EDIT, VIEW, MAIN, itp.
Akcja, którą chcemy wykonać, np. EDIT, VIEW, MAIN, itp.
data
data Dane, na których chcemy operować, np. Wpis osoby zz
Dane, na których chcemy operować, np. Wpis osoby
książki tel., jako URI
książki tel., jako URI
●
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ć)

16. 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ą

17. 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

18. 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

19. 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

20. #3
Cechy
czyli: jak nadać znaczenie liczbom

21. 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)

22. 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)

23. Time series embedding #2
Niech:
k
z n ∈M ⊆ℝ
będzie k-wymiarowym wektorem stanu,
M – atraktorem, do którego ewoluuje układ dynamiczny,
oraz funkcja ewolucji:
 : M ×ℤ M taka, że: z n ,t =z nt
Wówczas, układ dynamicznyM , jest deterministyczny,
jeśli  jest deterministyczna, tzn. jesteśmy w stanie
napisać matematyczną regułę przejścia ze stanu z n do z nt
Ponadto:
x n=x m ⇒  x n , .= x m , .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.

24. Time series embedding #3
Mamy 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 x n =g z n  przez pewien ciągły czas – tak.
Zgodnie z twierdzieniem Takensa o embeddingu: dla
odpowiednio dużego d e , ewolucja  x n , x n−1 , x n−2 ,, x n−d e 
będzie taka sama jak z n .
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.

25. #4
Wnioski
czyli: czy to zadziała?

26. Co z tego wynika?
●
Funkcja obserwacji – wartość wektora przyspieszenia:
 x  y z −g
2 2 2
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?)

27. Czy to działa?

28. #5
Demo
czyli: chwalę się tym, co już mam
i sprytnie przemilczam to, czego brakuje

29. Co jest zrobione
●
Aplikacja do zbierania i
Pobierz aplikację:
wysyłania danych –
SensorLog
●
Strona z informacjami
●
Strona do zbierania
danych
●
Dane z lawin
http://avl.wm.lapy.pl/

30. #6
Pytania
których nie ma, więc przechodzimy
do zdjęć z Indii!