Wizja projektu

Damian Kluba Katarzyna Lasak Amadeusz Starzykiewicz Techniki obiektowe i komponentowe
Compact Open Remote Nao CORN Wizja projektu
1. Cel projektu
Celem projektu jest stworzenie aplikacji desktopowej do obsługi robota Nao. 2. Opis produktu
Zadaniem aplikacji będzie dostarczenie użytkownikowi możliwości oglądania na ekranie tego, co widzi robot przez swoją kamerkę, jak również wydawania mu komend zdalnie, siedząc przy komputerze, dodatkowo w języku polskim. Aplikacja będzie napisana w modelu komponentowym, co pozwoli na proste dokładanie kolejnych funkcjonalności. 3. Analiza wymagań
Podstawowe wymagania funkcjonalne: ● System umożliwia podgląd obrazu z kamerki robota na ekranie komputera ● System umożliwia zdalne sterowanie robotem za pomocą instrukcji głosowych w języku polskim Podstawowe wymagania niefukcjonalne: ● Interfejs użytkownika jest przejrzysty i wygodny w użytkowaniu 4. Założenia i ograniczenia
Do działania aplikacji konieczny będzie dostęp do internetu. Część wykorzystywanych technologii nie jest darmowa dla dużej ilości przetwarzanych danych, więc w przyszłości może okazać się konieczne wykupienie licencji (na podstawowe potrzeby licencja darmowa jest wystarczająca). Program wykorzystuje zewnętrzny program Sox (w wersji 14.4.0!) 5. Podział na komponenty / Podział zadań / Opis kompetencji
Części realizowane przez poszczególnych członków zespołu: ● Interfejs użytkownika, integracja komponentów ­ Damian Kluba ● Komponent odpowiedzialny za przetwarzanie poleceń głosowych w języku polskim na komendy zrozumiałe przez robota. Komponent ten będzie składał się z trzech mniejszych komponentów ­ jeden będzie zamieniał polecenie głosowe na tekst, drugi będzie tłumaczył tekst na język angielski, trzeci ­ zamieniał tekst na polecenie dla robota ­ Katarzyna Lasak ● Komponent umożliwiający śledzenie obrazu z kamery robota ­ Amadeusz Starzykiewicz 6. Technologie wykorzystane do rozwiązania problemu
●
●
●
●
.Net, Google speech2text, Microsoft Translator, NAOqi.NET. 7. Pokrewne rozwiązania
Podobnym, aczkolwiek zdecydowanie bardziej złożonym rozwiązaniem jest Choregraphe. 8. Analiza ryzyka
Powodzenie projektu jest ściśle związane z wykorzystywanymi przez nas technologiami. Jest ich kilka, są różnorodne, większość z nich jest bardzo złożona, więc istnieje ryzyko, że wybierzemy technologię, która nie będzie zgodna z naszymi potrzebami lub nie poznamy jej wystarczająco dobrze. Ponadto, problemem jest ograniczony dostęp do robota, co może znacznie utrudnić proces testowania. W rezultacie produkt może zawierać błędy, które nie zostaną wykryte. Dodatkowym zagrożeniem jest niewystarczające poznanie środowiska (bibliotek) do oprogramowania robota. Niestety, aby otrzymać biblioteki potrzebne jest konto developerskie na stronie firmy wytwarzającej NAO lub płyta dołączona do robota. Zagrożenie Prawd. Skutki Przeciwdziałanie Nieodpowiedni wybór wykorzystywanych technologii średnie 5 Niewykrycie błędów w średnie 7 aplikacji spowodowane ograniczonym dostępem do robota Dogłębne zapoznanie z dostępnymi technologiami przed dokonaniem wyboru jednej z nich i implementacją Próby symulowania środowiska robota, niezależne testowanie komponentów niezwiązanych bezpośrednio z komunikacją z robotem Niewystarczające poznanie duże środowiska NAO. 8 9. Realizacja projektu - kamienie milowe
●
●
6.05.2014 ­ Stworzenie wizji projektu, wybór wykorzystanych technologii 19.05.2014 ­ Poznanie wybranych technologii, stworzenie szkieletów komponentów ● 2.06.2014 ­ Stworzenie gotowych komponentów ● 16.06.2014 ­ Integracja komponentów, stworzenie dokumentacji produktu 10. Dokumentacja
W ramach dokumentacji projektu powstaną: ● Wizja projektu ● Krótka dokumentacja użykownika 11. Bibliografia
●
●
https://community.aldebaran­robotics.com/ http://totologic.blogspot.com/2013/09/nao­new­c­library­with­event.html