Compact Open Remote Nao

Transkrypt

1 Damian Kluba Katarzyna Lasak Amadeusz Starzykiewicz Techniki obiektowe i komponentowe Compact Open Remote Nao CORN Podsumowanie projektu

2 1. Powstałe komponenty 1.1. Video Component Elementy komponentu Główną częścią komponentu wideo jest interfejs komunikacyjny z robotem, który co 1/15 sekundy pobiera obraz i wyświetla go na dodanym elemencie do interfejsu graficznego użytkownika Wykorzystane rozwiązania Moduł korzysta z: transformacji obrazu dostępnych w platformie Windows Presentation Foundation NAOqi.NET do komunikacji z robotem Ograniczenia Komponent ze względu na swoją specyfikę jest mocno związany z możliwościami technicznymi robota. Bez problemu dałoby się go wykorzystać w nowszej wersji z lepszą kamerą, a także w wersjach ze słabszą kamerą. Niestety może to oznaczać, że robot nie wyśle wymaganych 15 klatek w ciągu sekundy w rozdzielczości VGA (640x480). Ponadto ze względu na ograniczenia w przepustowości łącza i opóźnienia tam powstające obraz może dotrzeć później lub zniekształcony Możliwości rozwoju Komponent w obecnej wersji jest bardzo prosty umożliwia pobieranie obrazu w prędkości 15 klatek na sekundę, w rozdzielczości VGA. Warto byłoby go rozbudować o interfejs ustawień, w których użytkownik może dostosować jakość obrazu w zależności od dostępnej przepustowości łącza. Również dobrym pomysłem na rozbudowę jest możliwość wyboru kamery, z której komponent korzysta (robot może posiadać ich więcej), a także możliwość obracania głową robota w celu przyjrzenia się otoczeniu Command Executor Elementy komponentu Komponent składa się z pięciu elementów: Bardzo prostego interfejsu użytkownika składającego się z jednego przycisku i etykiety informującej o tym, czy robot potrafi wykonać polecenie Modułu odpowiedzialnego za nagranie komendy i zapisanie jej w pliku Modułu rozpoznającego mowę Modułu tłumaczącego tekst w języku polskim na tekst w języku angielskim Modułu tłumaczącego tekst w języku angielskim na komendę zrozumiałą przez robota

3 Wykorzystane rozwiązania Wyżej wymienione moduły wykonując swoje zadania wykorzystują następujące rozwiązania: Google speech2text do rozpoznawania mowy Microsoft Translator do tłumaczenia tekstu w języku polskim na tekst w języku angielskim NAOqi.NET do komunikacji z robotem Sound exchange do nagrywania dźwięku i zapisu w odpowiednim formacie Ograniczenia Komponent jest uzależniony od wykorzystywanych technologii. Są one darmowe, ale z pewnymi ograniczeniami. Microsoft Translator jest darmowy przy tłumaczeniu do 2 mln znaków na miesiąc, powyżej tego progu tłumaczenie nie jest darmowe. Google speech2text natomiast ma darmowe API, ale dokumenacja nie jest dostępna za darmo. W związku z tym, mimo, że dostęp nie jest ogranicznony przez liczbę zapytań, mogą się pojawić problemy innego typu, np. przy zmianie API aplikacja może przestać działać. Taki problem powstał już przy tworzeniu komponentu i konieczne było dostosowanie się do nowego API (nie jest to więc tylko teoretyczny problem) Możliwości rozwoju Wydzielone moduły komponentu można rozwijać niezależnie. Elementem, który z pewnością można bardzo rozwinąć jest moduł komunikujący się z robotem. Posiada on słownik, który w tej wersji jest mocno ograniczony (zawiera tylko kilka funkcji, które może wykonać robot), natomiast można go dowolnie rozszerzać o nowe komendy czy zestawy komend. Drugim elementem, który warto rozwijać jest interfejs użytkownika, który w tej wersji jest minimalistyczny.

4 2. Możliwości rozwoju aplikacji Naturalną drogą rozwoju aplikacji wydaje się być dodawanie kolejnych komponentów oraz rozbudowanie API komponentów, np. poprzez dodanie globalnych ustawień. Można się zastanowić nad modułami np. nadzorującymi ruchy nao (sprawdzające stany jointów), rozpoznającymi i analizującymi kształty widziane przez kamerę albo moduły analizujące dźwięki. Dodatkowo można oczywiście rozbudować interfejs graficzny użytkownika, powielić kontenery, przeprojektować na zakładki i okna, dodać ustawienia użytkownika czy zamykanie komponentów. Miłym dodatkiem byłaby też możliwość tworzenia pre konfigurowanych profili z odpowiednimi komponentami (już skonfigurowanymi). Umożliwiłoby to szybkie wracanie do pracy po przerwie, a także możliwość wykorzystania aplikacji do dwóch różnych zastosowań, dla przykładu: wydawanie zdalne poleceń i obserwacja otoczenia lub przesyłanie poleceń tekstowo ze śledzeniem obiektów (np. przy pomocy kamery Kinect). 3. Napotkane problemy Na etapie wizji projektu staraliśmy się przewidzieć możliwe zagrożenia dla powstania aplikacji CORN. Analiza ta nie była zupełnie pozbawiona realności, ponieważ napotkaliśmy następujące problemy 1. Nieodpowiedni wybór technologii Pomimo początkowego zafascynowania platformą.net firmy Microsoft stwierdziliśmy, że nieznajomość języka w dużym stopniu wpłynęła na tempo realizacji projektu. Dodatkowym problemem było również nieznane środowisko Visual Studio. 2. Zmiana API wykorzystywanych usług Podczas prac nad komponentem przetwarzającym mowę w języku polskim na polecenia zdarzył się przypadek zmiany interfejsu programistycznego w usłudze Google speech2text. Z tego też względu komponenty nie są całkowicie odporne na zewnętrzne zmiany. 3. Niewykrycie błędów w aplikacji spowodowane ograniczonym dostępem do robota Ten problem spowodowany był dwoma poprzednimi przez opóźnienia w realizacji projektu mieliśmy mało możliwości sprawdzenia aplikacji z prawdziwym robotem Nao co spowodowało, że w komponentach wciąż mogą tkwić błędy i niedoróbki, których nie byliśmy w stanie wykryć.

5 4. Problemy ze środowiskiem testowym Ze względu na ograniczenia NAOqi oraz Choreographe jako środowiska testowego (bez rzeczywistego robota) niemożliwym było przetestowanie komponentu wideo związane jest to z brakiem symulacji kamery robota za pomocą kamery notebooka lub przygotowanego wcześniej filmiku testowego.