Udostępnij za pośrednictwem

  • Artykuł

     

Platforma Windows Azure - interPeter

Udostępnij na: Facebook

Autor: Grzegorz Glonek

Opublikowano: 2011-07-11

Pobierz i uruchom

Wprowadzenie

W poprzedniej części został opisany przykładowy projekt oparty na chmurze Windows Azure o nazwie Bid Now. Drugim przykładem aplikacji wykorzystującej chmurę jest projekt interPeter (rys. 1), stworzony w ramach konkursu Imagine Cup 2010 przez zespół fteams w składzie Magdalena Jonczyk, Tomasz Ciejka, Grzegorz Glonek, Daniel Moliński oraz Jacek Pintera. Opiekunem drużyny był dr inż. Jarosław Koszuk.

Rysunek1. Ekran powitalny aplikacji klienckiej interPeter.

Założenia projektu

InterPeter to projekt będący tłumaczem dwukierunkowym gestów Systemu Językowo-Migowego[1] (SJM) na tekst (a w przypadku translacji na język angielski również na mowę). Przy tworzeniu tego projektu zależało nam na osiągnięciu dwóch celów – umożliwić pracę aplikacji na sprzęcie o stosunkowo niewielkiej wydajności oraz wyeliminować konieczność używania jakichkolwiek znaczników w celu detekcji osoby migającej. Udało nam się osiągnąć oba te cele, a dodatkowo przeniesienie części obliczeń w chmurę pozwoliło na stworzenie aplikacji klienckiej, która, wykorzystując fragment możliwości silnika, pracuje na telefonie komórkowym i może tłumaczyć wiadomości SMS na język migowy.

Pomysłem, na którym oparliśmy się tworząc system, była rozprawa doktorska Pana dra inż. Tomasza Kapuścińskiego stworzona w 2006 roku.

Technologie

InterPeter został w pełni oparty na platformie .Net 4.0, z wykorzystaniem zewnętrznych modułów napisanych jako aplikacje oraz biblioteki statyczne w języku C wchodzące w skład biblioteki HTK. Program dla systemu Windows przeznaczony dla użytkownika końcowego został napisany w technologii WPF, co pozwoliło w łatwy sposób wykonać ergonomiczny interfejs[2].

Budowa i działanie

System jest przykładem projektu opartego na modelu S+S. Logika odpowiedzialna za interpretację gestów została stworzona jako usługa WCF uruchamiana na instancji Worker Role. W tym przypadku było to rozwiązanie wystarczające, ponieważ interpretacja danych następowała w bardzo krótkim czasie, więc nie było potrzeby rozbijania implementacji pomiędzy instancjami Web i Worker Role. Ogólny schemat budowy systemu przedstawia rysunek 2.

Rysunek2Ogólny schemat budowy systemu InterPeter.

Scenariusz działania rozpoznawania można podzielić na dwa etapy – rozpoznawanie z gestów na tekst oraz w odwrotnym kierunku, tj. z tekstu na gesty. W pierwszym przypadku cały proces rozpoznawania rozpoczyna się od detekcji głowy oraz dłoni na obrazie z kamerki internetowej przez aplikację kliencką uruchomioną na komputerze użytkownika. Aplikacja kliencka oprócz detekcji części ciała dokonuje także ich opisu w przestrzeni. Wśród miar zastosowanych w wektorze opisującym znajdują się m.in. położenie rąk względem głowy, kąt, pod jakim są nachylone oraz powierzchnia dłoni. Tak przygotowany wektor przesyłany jest do serwera i tam analizowany przez silnik wykorzystujący ukryte modele Markova. Usługę uruchomioną na platformie Azure możemy podzielić na dwie części. Pierwszą z nich jest aplikacja stworzona w języku C#, która odpowiedzialna jest za komunikację z użytkownikiem (dalej nazywana interfejsem), oraz program napisany w języku C dokonujący rozpoznania dostarczonych danych jako gesty (dalej nazywany silnikiem). W tym miejscu warto zaznaczyć, że silnik jest samodzielną aplikacją działającą w osobnym procesie względem interfejsu. Po zakończeniu rozpoznawania przez silnik zwraca do interfejsu gotowe zdanie w języku polskim. W tym momencie, na podstawie otrzymanych od użytkownika parametrów, następuje decyzja, czy należy dokonać translacji zdania pomiędzy językami narodowymi. Jeśli istnieje taka potrzeba, interfejs komunikuje się z zewnętrzną usługą tłumaczącą. W trakcie tworzenia projektu testowane były dwie takie usługi – Google Translate oraz Bing Translator. Ostatecznie zdecydowaliśmy się użyć usługę Bing ze względu na wygodę korzystania z przygotowanego API dla platformy .Net. Następnie gotowe zdanie zostaje przesłane w odpowiedzi do klienta. Jeśli rozpoznane zdanie jest w języku polskim, tekst zostaje wyświetlony na ekranie w formie czatu, natomiast jeśli jest to zdanie angielskie, istnieje możliwość, aby zostało ono "wypowiedziane" za pomocą wykorzystanego syntezatora mowy zawartego w Microsoft Speech API. Cały proces został przedstawiony na rysunku 3.

Rysunek3. Proces tłumaczenia języka migowego na pismo lub mowę.

W przypadku tłumaczenia tekstu na język migowy, aplikacja kliencka przesyła do serwera zdanie wpisane przez użytkownika (jeśli językiem źródłowym jest język angielski, wykorzystane jest także rozpoznawanie mowy oparte na MS Speech API). Następnie zdanie to, jeśli jest taka potrzeba, tłumaczone jest na inny język narodowy w oparciu o tę samą usługę, która wykorzystana jest w poprzednim scenariuszu działania. Kolejnym krokiem jest analiza zdania oparta na korpusie językowym. Z uwagi na dostępność darmowych korpusów, analiza zdania przebiega tylko dla zdań w języku polskim. Jako interfejs do korpusu wykorzystano darmowy program Poliqarp, będący, podobnie jak silnik w poprzednim scenariuszu, aplikacją napisaną w C uruchamianą jako osobny proces. Dzięki korpusowi analizowane zdanie zostaje uproszczone tak, aby każde użyte w nim słowo występowało w podstawowej formie gramatycznej. Uproszczenie zdania do postaci zbudowanej z podstawowych form gramatycznych poszczególnych słów nie zmienia sensu zdania przy jego tłumaczeniu na język migowy. Język migowy nie posiada bowiem odmiany gramatycznej słów, a ich forma i sens zależy jedynie od interpretacji osób rozmawiających w ten sposób i od ogólnego kontekstu rozmowy. Przykładowo zdanie ,,bardzo boli mnie głowa'' w SJM ma formę ,,bardzo boleć ja głowa''. Problemem, który jednak może pojawić się w innych wariantach języka, to różnica w szyku zdania pomiędzy językiem mówionym a językiem gestów –różnice te jednak są na tyle mało istotne, że nie zaburzają przekazu[3]. Następnie do tak przygotowanego zdania dopasowywane są sekwencje filmowe gestów na podstawie prostego słownika. W odpowiedzi klient nie dostaje jednak zbioru kilku plików filmowych, ale jedynie nazwy plików i kolejność, w jakiej powinien je wyświetlić. Dzięki temu zminimalizowana została ilość danych przesyłanych pomiędzy klientem a chmurą Azure.

Następną rzeczą, jaką musi wykonać klient, to wyświetlenie filmów. Aplikacja kliencka posiada lokalnie pewną bazę plików filmowych prezentujących najpopularniejsze gesty, a także te pliki, które zostały wykorzystane wcześniej, a wykraczają poza te najpopularniejsze. Jeśli aplikacja nie posiada jednak potrzebnego pliku, może go pobrać z dowolnego lustrzanego serwera ftp (aplikacja posiada listę adresów IP takich serwerów). Takie podejście pozwala na zbudowanie większej bazy serwerów zawierających pliki filmowe potrzebne do działania aplikacji, niż oparcie się na mechanizmie CDN wykorzystywanym w Azure. Dodatkowo można tak zaimplementować aplikację kliencką, aby jej lokalnie zgromadzone zasoby także były udostępniane innym użytkownikom. Po pobraniu wszystkich niezbędnych plików, sekwencja filmów zostaje odtworzona na ekranie. Proces tłumaczenia tekstu lub mowy na gesty języka migowego przedstawia rysunek 4. Jako inny przykład aplikacji klienckiej została przygotowana także wersja instalowana na telefonie komórkowym z systemem Windows Mobile, która tłumaczy wiadomości SMS na język migowy. Cały proces odbywa się analogicznie do tego opisanego powyżej.

Rysunek 4. Proces tłumaczenia pisma lub mowy na gesty języka migowego.

Dlaczego Windows Azure

W tym przypadku wybór platformy Windows Azure związany był ściśle z wykorzystywaną technologią. Ta platforma jako jedyna spośród chmur zbudowanych w modelu PaaS daje możliwość pracy z platformą .Net i równoczesne działanie aplikacji w kodzie natywnym. Decyzja o wykorzystaniu chmury w miejsce tradycyjnego serwera obliczeniowego była podyktowana niemożnością przewidzenia obciążenia, jakie mogłoby być generowane pomiędzy klientami a usługą. Specyfika konkursu Imagine Cup, na który ten system został przygotowany, wymaga rozważenia aspektów biznesowych działania proponowanych rozwiązań. Sytuacja, gdy nie ma możliwości przewidzenia, jaka będzie ilość potencjalnych użytkowników korzystających z usługi, jest jednym z typowych scenariuszy do zastosowania chmury. Usługa taka, aby optymalnie wykorzystać zalety platformy cloudcomputingowej, powinna zawierać moduł monitorujący obciążenie maszyny, na której jest uruchomiona, i w razie potrzeby zwiększyć ilość dostępnych instancji lub wykorzystanie istniejących narzędzi firm trzecich.

[1] W Polsce istnieje kilka wariantów języka używanego przez osoby głuchonieme. W trakcie prac zdecydowaliśmy się rozpoznawać SJM ze względu na to, że jeden z członków drużyny znał już wcześniej ten system. Sam silnik, po odpowiednim procesie nauki, byłby jednak w stanie rozpoznawać także gesty w innych wariantach języka.

[2] Projekt interfejsu został nagrodzony wyróżnieniem przyznawanym przez Instytut Wzornictwa Przemysłowego w Warszawie dla Magdaleny Jonczyk.

[3] Aby zobaczyć przykład zdań pisanych przez osoby głuche, warto zobaczyć rozmowy prowadzone na forum http://forum.alldeaf.pl (przykładowa rozmowa: http://forum.alldeaf.pl/topics438/2792.htm post 4 jest pisany przez osobę niesłyszącą).

 

     

Grzegorz Glonek (MCP, MCTS)

Absolwent Wydziału Fizyki Technicznej, Informatyki i Matematyki Stosowanej Politechniki Łódzkiej. Uczestnik konkursu ImagineCup. Wraz z drużyną fteams zdobył w 2009 roku drugie miejsce na finałach światowych tego konkursu w kategorii Software Design : InteroperabilityAward oraz pierwsze miejsce w finałach krajowych kategorii Software Design w 2010 roku. Obecnie zatrudniony w polskim oddziale firmy Microsoft na stanowisku Software Development Engineer in Test.