Informatyka II stopień: Studio projektowe 1 (2016)

Uwaga: strona zawiera informacje dla studentów II stopnia Informatyki.

Nie jest jeszcze gotowa

Terminy spotkań: poniedziałek 15.30 C2 403

Projekty są wykonywane w grupach. Zaleca się, aby były to grupy o liczebności wskazanej przy tematach projektów. Grupa powinna wybrać temat projektu z listy i zarezerwować za pomocą formularza rejestracji. Tematy projektów muszą być unikalne. Jeżeli na liście pojawią się dwie rezerwacje tego samego projektu – późniejszy wpis zostanie usunięty.

Grupa, która wybrała projekt ma zaproponować i ustalić:

• podział na zadania
• plan realizacji (termin i osoba)
• kamienie milowe (prezentacja wyników danego etapu)
• więcej o harmonogramie...

Dla poszczególnych projektów/grup zostaną założone repozytoria git. Mają się tam znaleźć:

• Harmonogram
• Raport z realizacji (uaktualniany nie rzadziej niż co 2 tygodnie)
• Kod źródłowy

Tematy projektów odzwierciedlają aktualnie prowadzone lub planowane prace badawcze. Podana liczba osób jest orientacyjna.

Grupa 2-3 os. Kontynuacja

Repozytorium przechowuje zasoby (np. klipy wideo, ramki wideo, wydzielone obiekty) oraz implementuje kontenery typu sekwencja oraz zbiór (bag). Dodatkowo, implementuje także nazwane relacje binarne pozwalające na ustalenie powiązań. Dla każdego z elementów można zdefiniować metadane w postaci par klucz-wartość. Należy przewidzieć hierarchiczne klucze (np.. w stylu rejestrów windows), które w interfejsie mogą być np. odwzorowane na XML. Zastosowanie: wsparcie dla systemu analizy wideo.

Co może być umieszczone?

• Dane opisujące ustawienia kamery
• Obrazy tła z anotacjami czasowym
• Przetworzone ramki obrazu
• Zdefiniowane stałe obiekty sceny (typy + informacja geometryczna)
• Wydzielone segmenty obrazu (ramki, elipsy, wieloboki lub bitmapy)
• Wydzielone obiekty (ramki, elipsy, wieloboki lub bitmapy), typy obiektów
• Relacje pomiędzy obiektami (wraz z cechami)
• Wektory cech przypisanych obiektom i relacjom (pary klucz-wartość)
• Obiekty mogą być wykryte (zidentyfikowane) ale mogą to być również manualne anotacje
• Dodatkowo - powiązania między klipami, np. ta sama scena obserwowana z różnych kamer

Przykłady zbiorów podlegających obróbce:

• http://homepages.inf.ed.ac.uk/rbf/CAVIARDATA1/,
• http://www.cvg.rdg.ac.uk/PETS2007/data.html, itp.

Do zrealizowania:

• serwer (BD + usługi sieciowe)
• opracowanie przypadków użycia
• implementacja przykładowych klientów
• fasady dla serwera implementujące wybrane specyficzne interfejsy

W projekcie można wykorzystać fragmenty implementacji serwera z poprzedniego cyklu.

Grupa 2 os.

Kluczowym zadaniem jest opracowanie i implementacja algorytmu, który generuje graf opisujący układ pomieszczeń na podstawie planów zapisanych jako bitmapy. Węzły to pomieszczenia, okna, drzwi, krawędzie to połączenia. Zarówno węzłom, jak i krawędziom mogą być przypisane atrybuty, np. rozmiar pomieszczenia, kształty geometryczne.

• Wejściem jest bitmapa zawierająca plan, np. mieszkania, galerii handlowej. Przykład wyrazistego planu

Przykładowy algorytm:

• Na plan nakładana jest siatka komórek
• Następuje scalanie komórek sklasyfikowanych jako “wnętrze” w węzły grafu
• Wykrycie komórek składających się na takie obiekty jak przejścia (drzwi) oraz okna
• Zbudowanie grafu

Funkcje systemu:

• Upload bitmapy lub PDF
• Możliwość zaznaczenia interesującego regionu podlegającego analizie (wielobok)
• Możliwość wprowadzenia manualnych anotacji dla komórek lub regionów na testowym obrazie (jednym z grupy). Celem jest nauczenie, jak wygląda ściana, tekst, drzwi
• Budowa grafu i zapis w BD (wraz referencyjną bitmapą)
• Możliwość przeglądania i wizualizacji (np. w przeglądarce)
• Możliwość naniesienia poprawek manualnych w przypadku błędnego rozpoznania
• Eksport grafów w formacie XML

Grupa 2 os. Kontynuacja

Celem projektu jest budowa systemu symulującego inteligentny obszarowe sterowanie oświetleniem dróg.

Rozważamy sieć drogową podmiejską. Przy drogach rozmieszczone są lampy diodowe, dla których można sterować natężeniem światła. Przy lampach zainstalowane są czujniki ruchu pozwalające wykryć pojazd i oszacować jego prędkość.

• Kiedy droga jest pusta, lampy świecą światłem małej mocy.
• Kiedy wykrywany jest pojazd, lampy mają przed nim rozjaśnić się z wyprzedzeniem uzależnionym od prędkości, pola widzenia, itp.
• Należy również rozważyć ruch ciągły na wybranych drogach (utrzymywane stałe natężenie)

System składa się ze sterowników (agentów) działających równolegle i zarządzających kilkunastoma lampami i czujnikami na pewnym obszarze. Agenci przekazują sobie informację o nadjeżdżającym pojeździe tak, aby “przekazać” sobie pojazd.

• Import mapy z OSM
• Manualne naniesienie lamp i zaznaczenie obszarów
• Symulacja ruchu pojazdów (różne natężenia) wraz z wizualizacją
• Implementacja pojedynczego sterownika
• Integracja kilku(nastu) sterowników wraz z wymianą komunikatów (definicja protokołu)
• Wizualizacja zmian natężenia światła podczas ruchu pojazdów
• Automatyczne rozmieszczenie lamp (w zadanym obszarze)
• Automatyczna budowa grafu połączeń
• Testy działania i dobór parametrów

Grupa 2-3 os.

Ideą sieci XQPN jest wykorzystanie języka funkcyjnego XQuery do przetwarzania rozproszonych dokumentów XML. Umieszczone są one w miejscach sieci. Tranzycje przesyłają dane pomiędzy miejscami. W ich definicji stosowane są wyrażenia zapisane w języku Xquery.

Projekt obejmuje dwa moduły:

• Silnik wykonania sieci XQPN (z użyciem Saxon HE: http://www.saxonica.com/welcome/welcome.xml)
• Edytor sieci Petriego XQPN najchętniej na platformie Eclipse/EMF wraz z możliwością wizualizacji wykonania

Platforma Java.

Informacje o sieciach:

• Szwed, P.: XQPN – colored Petri nets for processing XML data with XQuery language Electrical Review Stowarzyszenie Elektryków Polskich ; ISSN 0033-2097. — 2010 R. 86 nr 9 s. 221–225 PDF

• Szwed, P., Wadowski, D., Paździora, K.: A framework for testing Web services based on XQPN Petri nets In IFIP 2009: Software Engineering Techniques in Progress : the 4th IFIP TC2 Central and East European Conference on Software Engineering Techniques, CEE-SET 2009 : Kraków, Poland, October 12–14, 2009 / eds. Zbigniew Huzar, Jerzy Nawrocki, Marcin Szpyrka. — Kraków : AGH University of Science and Technology Press, 2009. — ISBN 978-83-7464-259-0. — 53–66. PDF Presentation: PPT

Grupa 2 os.

Celem projektu jest przede wszystkim zaproponowanie, opracowanie i porównanie kilku wersji algorytmów.

• Obiekt jest scharakteryzowany przez pewien abstrakcyjny wektor cech (np. kolor, powtarzający się wzorzec ruchu)
• Źródłem danych o położeniu obiektów mogą być czujniki różnego typu (mapa WiFi, kamery).
• Obiekt może nie być jednoznacznie identyfikowany (w przypadku kamer)
• Mają zostać zastosowane symulowane dane o obiektach i ich położeniu. Należy zaimplementować definiowanie scenariusza ruchu i opcjonalnie zmian cech w interfejsie graficznym
• Podczas eksperymentów na ruch ma zostać nałożony szum (możliwa zmiana odczytanej lokalizacji oraz niepewność co do ustalenia ID)
• Konieczność fuzji danych (np. z kilku kamer obserwujących równocześnie tę samą scenę)

System powinien zapewniać:

• Funkcje definiowania sceny (plan pomieszczeń)
• Definiowania scenariuszy ruchu
• Wizualizację przebiegu śledzenia

Platforma: Java+Swing

Grupa 2 os.

Motywacje: w rozwijanym systemie zbierane są parametry ruchu dla wybranych dużych skrzyżowań (np.: skrzyżowanie Czarnowiejska/Aleje). Ich źródłem są kamery wideo. Na podstawie interpretacji danych z kamer określane są takie parametry, jak prędkość ruchu, czas wykonania manewru na skrzyżowaniu lub długość kolejki pojazdów. Pokrycie pomiarami w docelowym systemie można szacować na 1% odcinków dróg. Równocześnie, system powinien dostarczać przybliżone informacje o parametrach ruchu dla dróg nieobjętych monitorowaniem.

Mapy kognitywne: http://home.agh.edu.pl/~pszwed/en/lib/exe/fetch.php?media=papers:fcm-ocena-jednostek-slides.pdf

Projekt obejmuje następujące etapy: *Modelowanie zależności pomiędzy ruchem z wykorzystaniem map kognitywnych dla wybranego skrzyżowania *Opracowanie algorytmu uczenia map kognitywnych dla sztucznych przebiegów czasowych (ogólnie jest to algorytm optymalizacji – do dyskusji czy dyskretnej czy ciągłej) *Automatyczne wygenerowanie mapy kognitywnej dla wybranego obszaru mapy połączeń drogowych *Zebranie danych symulacyjnych *Testy algorytmu

Źródło mapy: Open Street Map (OSM)

Projekt ma wykorzystywać pakiet SUMO będący zaawansowanym narzędziem symulacji ruchu drogowego.

Możliwe wykorzystanie wyników pracy magisterskiej (w tym zbieranie danych z SUMO)

Grupa 2 os. Repozytorium (o charakterze hurtowni danych, czyli danych nie usuwamy) przechowuje informacje o sekwencjach zdarzeń oraz pozwala na wykonanie zapytań, których wynikiem są sekwencje.

• Projekt i implementacja repozytorium.
• Zasilanie: pliki tekstowe w formacie XES http://www.xes-standard.org/
• Model zapytań:
  • Restrykcja (ograniczenie zdarzeń w sekwencji do elementów spełniających określone warunki)
  • Selekcja ciągów zawierających zdarzenia o wybranych atrybutach
  • Selekcja ciągów zdarzeń spełniających warunki temporalne – formuły opisujące następstwo zdarzeń i inne operatory w stylu http://en.wikipedia.org/wiki/Linear_temporal_logic. Jest to kluczowy element projektu.
  • Join: utworzenie ciągu zdarzeń na podstawie dwóch (kilku) ciągów spełniających określone warunki

Platforma, narzędzia, sposób interakcji – do ustalenia

Grupa 2-3 os.

Dynamicznie zmieniające się informacje taktyczne reprezentowane są w postaci grafu z atrybutami: Wierzchołki:

• jednostki biorące udział w akcji (agenci)
• punkty terenu, bezpieczne miejsca, schronienia, miejsca zbiórki dla ewakuacji
• obszary objęte zagrożeniem
• jednostki wroga
• cywile lub ich grupy

Krawędzie (relacje):

• kontakt wzrokowy,
• bliskość, dostępność
• łącza komunikacyjne
• przepustowość

Graf sytuacyjny

• Utrzymywany i uaktualniany na szczeblu taktycznego systemu dowodzenia
• Prognozowanie w warunkach niepewności lub utraty łączności
• Agenci utrzymują częściowe grafy sytuacyjne (podgrafy). Ze względu na ograniczenia pasma następuje transmisja danych różnicowych.

Jest to projekt w pewnym sensie bliski programowaniu gier. Oczekiwana jest symulacja ruchu, np. na heksagonalnej siatce, wraz z możliwością wizualizacji stanu grafu (punkt widzenia agenta).

Kontynuacja zrealizowanego w zeszłym roku projektu, w którym:

• zrealizowany został serwer SOAP na platformie Android - z użyciem biblioteki natywnej gSOAP
• zrealizowany został serwer udostępniający informacje o aktywnych serwerach mobilnych oraz ich usługach

Grupa 2 os.

Ideą jest, aby zestaw usług oferowanych przez mobilny serwer zależał od kontekstu, w którym się znajduje. Czyli zachodzi odwzorowanie [Kontekst] → [Zbiór usług]

Przykładowe składniki kontekstu:

• zasilanie sieciowe/bateryjne/poziom baterii
• WiFI / GPRS
• pora dnia
• oświetlenie
• lokalizacja GPS, np. bliskość punktu POI określonego typu
• zmienne ustawienia wprowadzone przez użytkownika

Należy opracować i zaimplementować sensowne przypadki użycia.

Grupa 2 os.

Celem dalszych prac jest rozszerzenie platformy o możliwość wykonania algorytmu typu Pregel http://kowshik.github.io/JPregel/pregel_paper.pdf

Wyobraźmy sobie, że urządzenia mobilne implementują usługi wykonania na węzłach wybranych algorytmów (niekoniecznie wszystkie):

• Random walk
• MDP policy
• Page Rank

Zadaniem serwera jest przydział zadań do wykonania (fragmentów grafów) oraz orkiestracja przebiegu algorytmu.

Celem projektu jest implementacja wybranych populacyjnych algorytmów optymalizacyjnych, np.:

• PSO (Particle Swarm Optimization)
• ACO (Ant Colony Optimization)
• BA (Bees Algorithm)
• inne?

Cechą charakterystyczną ma być implementacja na platformie obliczeń równoległych OpenCL (można także użyć biblioteki aparapi w języku Java ). Biblioteka i driver OpenCL są dostępne dla kart graficznych AMD, znacznej części kart NVIDIA, Procesorów wielordzeniowych Intela oraz Intel HD graphics. Podczas obliczeń równoległych można przetwarzać duże populacje, rzędu 10000 osobników.

lista algorytmów i problemów

Grupa 1-2 os.

Implementacja algorytmów dla zagadnień ciągłych ze zbiorów http://www.sfu.ca/~ssurjano/optimization.htmlhttp://www.robertmarks.org/Classes/ENGR5358/Papers/functions.pdf.

Grupa 1-2 os. Zbiory: http://www.iwr.uni-heidelberg.de/groups/comopt/software/TSPLIB95/ http://people.brunel.ac.uk/~mastjjb/jeb/info.html http://anjos.mgi.polymtl.ca/qaplib/inst.html

Grupa 2 os.

Celem tematu jest zbudowanie systemu symulującego zachowanie odbiorców energii elektrycznej korzystających z takich urządzeń, jak lodówka żelazko, klimatyzacja, zmywarka, pralka, podgrzewacz przepływowy, oświetlenie…

Projekt obejmuje:

• definicję modelu konsumpcji energii przez urządzenia (np.: włączony telewizor ma stałe zużycie energii, natomiast żelazko okresowe)
• definicję odbiorcy (gospodarstwa domowego, dodanie mieszkańców)
• definicję modelu zachowania konsumenta (czasy aktywności, użycie urządzeń)
• pogodę
• taryfy (konsument może podejmować decyzję o użyciu urządzenia w okresie optymalnej taryfy)

Funkcjonalność systemu ma umożliwić konfigurację tych danych

Dane otrzymane w wyniku symulacji (zagregowane, a także indywidualne zużycie poszczególnych urządzeń) mają trafić do specjalnie w tym celu zaprojektowanej bazy danych. System powinien także wizualizować zebrane dane.

Symulator powinien wykorzystać środowisko agentowe JADE http://jade.tilab.com/ lub Akka http://akka.io/ (ale raczej język Java :) )

2 osoby

Współczesne ogólnodostępne mapy, np. Open Street Map (OSM) zawierają takie informacje, jak:

• kształty dróg
• budynki
• POI (points of interest): kościoły, szkoły, sklepy, boiska, restauracje, itp..
• dane demograficzne

Celem projektu jest implementacja i testy oprogramowania/algorytmu, który będzie rekomendował ograniczenia ruchu (zwłaszcza ograniczenia prędkości) dla wybranych dróg mapy… Powinien wykorzystać takie informacje, jak:

• oszacowanie wielkości ruchu (także pieszego)
• gęstości zaludnienia - liczba małych uliczek, budynków, itp..
• oszacowanie “krętości drogi”
• bliskość specyficznych POI

Jako system rekomendacji należy użyć reguł rozmytych:

• http://pl.wikipedia.org/wiki/Logika_rozmyta
• http://riad.usk.pk.edu.pl/~bmrozek/dydaktyka/LabFL2_ModelMamdani.pdf

Etapy:

• import danych mapy i analiza
• modelowanie i propozycja zbioru reguł: IF punkt blisko szkoły THEN ogranicz prędkośc
• implementacja (lub użycie) systemu wnioskowania oraz testy
• manualne wprowadzenie ograniczeń (lub wykorzystanie tych w OSM) i dobór parametrów funkcji przynależności
• wyświetlanie wyników http://openlayers.org/

2 osoby Celem projektu jest implementacja aplikacji pozwalającej na zebranie danych zwracanych przez wybrane czujniki: akcelerometr, żyroskop, kompas, odbiornik GPS…

Do ustalenia:

• rozpoznawanie (klasyfikacja) aktywności użytkownika, np.: na podstawie ciągów odczytu akcelerometru
• rozpoznawanie kierunku ruchu (kompas)

2 osoby

Celem projektu jest implementacja aplikacji webowej umożliwiającej zarejestrowanym użytkownikom (np. uczestnikom dużego projektu) wprowadzanie opisów struktur danych. Ogólnie, poziom złoóznoscipowinien być bliski RDF Schema oraz ewentualnie diagramów ilustrujących zależności.

Główne funkcje:

• Definiowanie klas (i atrybutów) wraz z opisami.
• Definiowanie relacji
• Refaktoring: takie operacje, jak zmiana nazwy, usunięcie części atrybutów, podział klasy.
• Śledzenie historii zmian
• Import/eksport RDFS oraz innych formatów (np. związanych z MOF)
• Wizualizacje modelu (Graphviz)
• Generowanie raportów i podsumowań

http://home.agh.edu.pl/~pszwed/wiki/doku.php?id=tematy_prac_inzynierskich

Najchętniej przez dotychczasowych wykonawców.

1-2 osoby Na podstawie Autentykacja użytkownika na podstawie charakterystyk czasowych uderzeń w klawisze. Rozszerzenie i zmiana platformy. Implementacja gotowej do użycia biblioteki, przeprowadzenie testów, implementacja przykładowej apliakcji.

1-2 osoby Do rozważenia:

• rekomendacja, a nie wyłącznie klasyfikacja
• hierarchizacja danych
• zmiana języka na polski i użycie pakietu Morfologik do wyodrębnienia stemów
• opcjonalnie polskiego WordNetu

1-2 osoby

• Bardziej zaawansowane sterowanie pojazdami
• Opracowanie bardziej realistycznego modelu protokołu
• Opracowanie kryteriów oceny jakości
• Zebranie danych
• Testy dla różnych parametrów i wariacji protokołu
• Optymalizacja

1 osoba

W pracy z 2013 roku zaimplementowana została wtyczka do Archi (język ArchiMate) umożliwiająca obliczenie kilku wybranych metryk.

Celem jest:

• uaktualnienie do nowej wersji Archi
• implementacja większej liczby metryk
• generacja atrakcyjnego wizualnie raportu
• agregacja oceny (wpływ metryk na atrybuty jakości systemu)

Uwaga Przed zarejestrowaniem tematu sprawdź, czy nie jest zajęty. Dany temat może zostać wybrany tylko przez jedną grupę.

Zarejestruj temat

Lista zarezerwowanych tematów

Funkcja do rejestracji jest niestety bardzo prymitywna, za co z góry przepraszam. Działanie jej polega na dopisywaniu kolejnych wierszy do pliku tekstowego. Nanosząc ręcznie poprawki najłatwiej jest mi usuwać całe wiersze.

• Jeśli 1-2 osobowa grupa chce dodać kolejną osobę - proszę zarejestrować jeszcze raz wpisując wszystkich członków grupy. Wcześniejszy wpis zostanie usunięty
• Jeżeli grupa chce zmienić temat - proszę zarejestrować jeszcze raz grupę i nowy temat.