Successfully reported this slideshow.
Your SlideShare is downloading. ×

Presentation about AVLRescue - Android application for detecting avlanches (in Polish)

Presentation about AVLRescue - Android application for detecting avlanches (in Polish)

Download to read offline

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




Mobilny Alarm Lawinowy, czyli aplikacja której zadaniem będzie wykrycie momentu porwania turysty przez lawinę i wezwanie pomocy.

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




Mobilny Alarm Lawinowy, czyli aplikacja której zadaniem będzie wykrycie momentu porwania turysty przez lawinę i wezwanie pomocy.

Advertisement
Advertisement

More Related Content

Advertisement

Related Books

Free with a 30 day trial from Scribd

See all

Presentation about AVLRescue - Android application for detecting avlanches (in Polish)

  1. 1. Mobilny Alarm Lawinowy Marek Białowąs
  2. 2. Spis treści 1. Wstęp 2. Android 3. Algorytm 4. Wnioski 5. Demo 6. Pytania 7. Zdjęcia
  3. 3. #1 Wstęp czyli: o co dokładnie chodzi
  4. 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. 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. 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. 7. #2 Android czyli: z czym to się je
  8. 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. 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. 10. Activities Activities Views Views Intents Intents Services Services AndroidManifest.xml AndroidManifest.xml Notifications Notifications Komponenty Aplikacji ContentProviders ContentProviders
  11. 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. 12. Cykl życia aktywności Prostokąty, to funkcje które możemy nadpisać w naszej Antywności
  13. 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. 14. Views ● Android odpowiedzialny jest za: ‒ Wymierzenie ‒ Rozmieszczenie ‒ Rysowanie ● No i mamy dzięki temu spójne UI!
  15. 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. 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. 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. 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. 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. 20. #3 Cechy czyli: jak nadać znaczenie liczbom
  21. 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. 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. 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. 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. 25. #4 Wnioski czyli: czy to zadziała?
  26. 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. 27. Czy to działa?
  28. 28. #5 Demo czyli: chwalę się tym, co już mam i sprytnie przemilczam to, czego brakuje
  29. 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. 30. #6 Pytania których nie ma, więc przechodzimy do zdjęć z Indii!

×