Wykorzystanie czujników głębi w robotyce społecznej

Transkrypt

1 Wykorzystanie czujników głębi w robotyce społecznej Michał Dziergwa 1, Paweł Kaczmarek 1, Jan Kędzierski 1 Streszczenie W referacie przedstawiono przebieg i wyniki testów czujnika Kinect for Windows, wraz z dedykowanym oprogramowaniem, pod kątem zastosowania w robotyce społecznej. Rozważono dwa pakiety oprogramowania - Microsoft Kinect SDK i OpenNI z biblioteką NiTE. Szczególny nacisk położono na parametry mające wpływ na działanie kompetencji robota społecznego, takie jak szybkość wykrycia użytkownika, dokładność określenia jego położenia i orientacji czy też stabilność śledzenia poszczególnych użytkowników. Wskazano kluczowe cechy i różnice między przetestowanymi pakietami w kontekście algorytmów zorientowanych na percepcję człowieka. 1. Wstęp Do niedawna percepcja robotów społecznych opierała się głównie na kamerach RGB. Możliwe do wyekstrahowania z obrazu dane, ważne w kontekście robotyki społecznej, to m.in. położenie i parametry twarzy użytkownika, kolor jego ubioru czy też wykonywane przez niego gesty. Działanie kamer RGB jest jednak ograniczone, ze względu na bardzo dużą wrażliwość na warunki oświetlenia. Ponadto, do pracy z obrazami o wysokich rozdzielczościach wymagana jest duża moc obliczeniowa. Równie istotną dla robota społecznego grupą czujników są różnego rodzaju czujniki odległości (dalmierze optyczne, macierze sonarów ultradźwiękowych, skanery laserowe, etc.). Czujniki te wykorzystywane są nie tylko podczas klasycznej nawigacji, ale pozwalają także na zachowanie dystansu proksemicznego w trakcie interakcji z człowiekiem. Wprawdzie na rynku od lat były dostępne kosztowne sensory 3D (głównie kamery stereo), to jednak prawdziwa rewolucja w ich stosowaniu nastąpiła w listopadzie 2010 roku, kiedy to firma Microsoft wprowadziła na rynek czujnik Kinect. Urządzenie to oprócz obrazu RGB dostarcza również obraz głębi (tzw. chmura punktów). Kinect został docelowo stworzony jako kontroler dla konsoli Xbox 360. Z czasem zaczął być wykorzystywany do celów badawczych, głównie na potrzeby analizowania postury człowieka i mechanizmów zachowywania równowagi [1], trójwymiarowego mapowania wnętrz [3], detekcji i rozpoznawania gestów [7] czy też analizowania modelu 3D twarzy [4]. Przykłady aplikacji czujnika w robotach społecznych i usługowych można znaleźć w pracach [9, 11]. Olbrzymie zapotrzebowanie na tani czujnik głębi Praca została wykonana w ramach grantu nr 2012/05/N/ST7/01098 finansowanego z Narodowego Centrum Nauki. 1 Instytut Informatyki, Automatyki i Robotyki, Politechnika Wrocławska, Wybrzeże Wyspiańskiego 27, Wrocław, {michal.dziergwa, pawel.m.kaczmarek, jan.kedzierski}@pwr.wroc.pl

2 M. Dziergwa, P. Kaczmarek, J. Kędzierski Rys. 1: Kinect for Windows, ASUS Xtion Pro, PrimeSense sensor OEM spowodowało, że w lutym 2012 roku Microsoft wprowadził na rynek zmodyfikowaną, deweloperską wersję o nazwie Kinect for Windows. Ostatecznie Kinect trafił do Księgi Rekordów Guinessa jako najszybciej sprzedające się urządzenie elektroniczne przeznaczone dla konsumentów indywidualnych. W ramach niniejszego referatu przeprowadzono weryfikację zastosowania czujnika Kinect w kontekście realizacji kompetencji społecznych robota FLASH [2]. Badaniom poddano dwa narzędzia do tworzenia aplikacji zorientowanych na interakcję z człowiekiem - Kinect SDK [6] oraz bibliotekę OpenNI [8] wraz z oprogramowaniem NiTE. 2. Kinect Opisane poniżej testy przeprowadzono z wykorzystaniem czujnika w wersji Kinect for Windows (K4W). Zasięg sensora wynosi cm. Jego działanie wykorzystuje światło strukturalne na podstawie którego urządzenie uzyskuje obraz głębi o rozdzielczości 300x200. Obraz ten jest programowo interpolowany do rozdzielczości 640x480 przy częstotliwości odświeżania na poziomie 30 fps. Rozdzielczość kamery RGB wynosi 640x480 przy 30 fps na sekundę. Możliwe jest również uzyskanie obrazu o wyższej rozdzielczości 1280x960 przy spadku częstotliwości odświeżania do 12 fps. Kinect posiada macierz 4 mikrofonów pozwalającą wykrywać kierunek dźwięku, silnik służący do pochylania czujnika oraz 3-osiowy akcelerometr. Jest już dostępna nowa generacja czujnika Kinect 2.0. Obecnie został on udostępniony jedynie deweloperom. Główne zmiany to zwiększenie rozdzielczości obrazu RGB i głębi. Pozwoli to na wykrycie nie tylko kończyn, ale i palców. Zwiększono także pole widzenia układu optycznego. Na rynku dostępne są również alternatywne produkty takie jak, sensor Asus Xtion i Asus Xition Pro. Do niedawna można było zakupić wersję OEM, której producentem był twórca technologi firma PrimeSense (Rys. 1). Obecnie firma ta została kupiona przez koncern Apple Microsoft Kinect SDK Microsoft Kinect SDK to zestaw sterowników, bibliotek oraz przykładowych programów, rozwijanych przez producenta czujnika. Umożliwiają one tworzenie własnych aplikacji w językach C++, C# i Visual Basic. Oprogramowanie to pozwala na detek-

3 Wykorzystanie czujników głębi w robotyce społecznej cję sześciu użytkowników oraz śledzenie sylwetki dwóch z nich. Każda ze śledzonych sylwetek reprezentowana jest za pomocą szkieletu o 20 przegubach. Biblioteka umożliwia przełączenie czujnika w tryb Near mode, w którym strefa martwa zostaje zmniejszona do 40 cm. Dzieje się to kosztem zmniejszenia zasięgu czujnika do 3m. Opcja ta jest dostępna jedynie dla czujnika w wersji K4W. SDK umożliwia także śledzenie sylwetki osoby siedzącej, jest to tzw. Seated mode. Na rysunku 2 zaprezentowano efekt wykrycia sylwetki. Microsoft SDK zapewnia pełny dostęp do ustawień kamery, takich jak: balans bieli, wzmocnienie, czas naświetlania, itp. Oprócz algorytmów śledzenia sylwetki, biblioteki zawierają implementację algorytmów wykrywania prostych gestów oraz detekcji twarzy w 3D. Możliwy jest także dostęp do silnika sterującego pochyleniem czujnika i pomiarów z akcelerometru. Warto także wspomnieć, że SDK dostarcza gotową implementację algorytmów detekcji kierunku dźwięku oraz posiada zintegrowane oprogramowanie Microsoft Speech Platform do rozpoznawania mowy. Działanie Microsoft Kinect SDK ograniczone jest do systemu Windows OpenNI/NiTE OpenNI to otwarte oprogramowanie rozwijane przez organizację non-profit zrzeszającą m.in. firmy ASUS (producent konkurencyjnego czujnika Xtion PRO) i Primesense (producenta technologii pomiaru głębi stosowanej w czujnikach Kinect). Biblioteka OpenNI jest jedynie platformą odpowiedzialną za akwizycję danych z czujników RGB-D i przedstawienie ich w zunifikowany sposób. Do obróbki danych, można posłużyć się szerokim zestawem bibliotek współpracujących z platformą OpenNI. Na szczególną uwagę zasługuje projekt NiTE, który dostarcza funkcji wykrywania i śledzenia nieograniczonej ilości osób. Użytkownik reprezentowany jest za pomocą szkieletu składającego się z 15 przegubów. Możliwe jest również wykrywanie podstawowych gestów, śledzenie dłoni użytkownika oraz detekcja póz ciała. Dostęp do ustawień kamery jest bardzo ograniczony w porównaniu do Microsoft Kinect SDK. OpenNI jest oprogramowaniem przenośnym i korzysta z zewnętrznych sterowników czujnika Kinect (sterownik dostarczany przez Microsoft Kinect SDK dla systemu Windows i Freenect driver dla systemów Linux). Na rysunku 2 zaprezentowano efekt działania wykrywania szkieletu. 3. Badania W celu przeprowadzenia badań, do istniejącego systemu sterowania robota społecznego [5], dodano nowe moduły, których implementacja opierała się na wspomnianych powyżej projektach (Microsoft SDK, OpenNI/NiTE). Zgodnie z ideą tworzenia modułów do systemu, który bazuje na oprogramowaniu URBI [10], przygotowano dwie biblioteki typu UObject (UKinect oraz UKinectOpenNI2). Opisane w niniejszym rozdziale badania zostały zrealizowane w postaci skryptów w języku urbiscript, który dostarcza URBI. Dokumentacja systemu znajduje się na stronie [2]. Punktem odniesienia dla przedstawionych poniżej wyników były pomiary przeprowadzone za pomocą taśmy mierniczej. Ich dokładność jest całkowicie wystarczająca z punktu wi-

4 M. Dziergwa, P. Kaczmarek, J. Kędzierski Rys. 2: Porównanie rozpoznanych szkieletów użytkownika (od lewej, Kinect SDK, Kinect SDK - Seated mode, OpenNI/NiTE) dzenia algorytmów percepcji zorientowanych na człowieka stosowanych w robotyce społecznej Przejście po prostokacie Pierwszym przeprowadzonym badaniem, było przejście po zadanej ścieżce. Jej kształt stanowił prostokąt o wymiarach 1,29 2,58m, usytuowany w odległości 1,27m od czujnika Kinect. Dłuższy bok prostokąta był równoległy do osi Z czujnika, zaś krótszy do osi X. Zdjęcie pomieszczenia testowego wraz z naniesioną ścieżką przedstawia rysunek 3a, zaś oczekiwany wynik pomiaru przedstawiono na rysunku 3b - czerwonymi punktami oznaczono miejsca stawiania kolejnych kroków. Podczas testów, 4 osoby o różnej posturze ciała i wzroście pokonywały, obrócone przodem do kierunku ruchu, pięć okrążeń z prędkością 80 lub 120 kroków na minutę. Rysunki 4a oraz 4b przedstawiają rzuty na płaszczyznę XZ ścieżki środka ciężkości wykrytej postaci, dla każdej z 4 badanych osób podczas pojedynczego okrążenia. Analiza rysunków sugeruje, że dokładność określenia pozycji przy użyciu biblioteki Kinect SDK jest większa niż w przypadku OpenNI, mniejszy jest także rozrzut uzyskanych wyników. Dla obydwu bibliotek, nie zaobserwowano znaczących różnic w zależności od badanej osoby, co pokazuje że przeprowadzone testy są dostatecznie powtarzalne i miarodajne. Istotnym celem niniejszego testu było wskazanie przegubów (dla obu bibliotek), które pozwolą najdokładniej określić położenie człowieka, a także zbadanie jak na dokładność określenia pozycji wpłynie tempo w jakim badany się porusza. Rysunki 5a i 5b przedstawiają ścieżkę głowy, torsu, lewego oraz prawego ramienia dla obu modułów. Istotną obserwacją jest nieciągła ścieżka położenia głowy na rysunku 5a. Podczas całego badania w 330 z 1472 pomiarów dla tempa wolnego oraz w 44 z 1019 pomiarów dla tempa szybkiego, określenie pozycji przez bibliotekę OpenNI nie było możliwe. Problem pomiaru pozycji nie występował dla innych przegubów. W przypadku użycia biblioteki Windows SDK nie zaobserwowano tego

5 Wykorzystanie czujników gł ebi w robotyce społecznej (a) Miejsce badan z naniesiona s ciez ka (b) Oczekiwany pomiar Rys. 3: S ciez ka testowa (a) Biblioteka OpenNI, widok 2D (b) Kinect SDK, widok 2D Rys. 4: S ciez ka s rodka ci ez kos ci podczas pojedynczego przejs cia, tempo wolne (co dziesiaty pomiar) zjawiska. Pozycje przegubów, które zdaniem autorów, moga najdokładniej okres lac połoz enie człowieka zostały zebrane w tabeli 1. Prezentuje ona s rednia odległos c od s ciez ki wzorcowej oraz zmierzona wysokos c dla wybranych przegubów. Były nimi szyja i tors (w przypadku uz ycia OpenNI) lub s rodek ramion i grzbiet (w przypadku uz ycia Windows SDK) oraz głowa. W tabeli znajduja si e takz e pomiary dla s rodka ci ez kos ci wykrytej postaci oraz punktu znajdujacego si e w połowie odcinka łacz acego prawe i lewe ramie. Na podstawie tych danych wskazano przeguby, dla których uzyskano najlepsza dokładnos c zmierzonej pozycji na płaszczyz nie XZ oraz najmniejszy rozrzut wyników w osi Y. W przypadku biblioteki OpenNI najlepsza dokładnos c po-

6 M. Dziergwa, P. Kaczmarek, J. Kędzierski (a) Biblioteka OpenNI, tempo wolne (b) Kinect SDK, tempo wolne (c) Biblioteka OpenNI2, tempo szybkie (d) Kinect SDK, tempo szybkie Rys. 5: Trajektoria przegubów podczas pierwszego z pięciu okrążeń (co piąty pomiar) miaru na płaszczyźnie XZ uzyskano dla środka ciężkości wykrytej postaci oraz pozycji torsu. Dokładność określenia położenia w osi Y jest dla wszystkich przegubów porównywalna, wyjątek stanowi środek ciężkości wykrytej postaci, który charakteryzuje się nieco większym rozrzutem pomiarów. W przypadku Kinect SDK najlepszą dokładność pomiaru na płaszczyźnie XZ gwarantuje środek ciężkości wykrytej postaci. Najmniejsze odchylenie standardowe pomiarów w osi Y zaobserwowano dla grzbietu oraz środka odcinka łączącego prawe i lewe ramię. Wnioskując na podstawie tabeli 1, tempo chodu ma znikomy wpływ na pomiary Orientacja Poprawne określenie orientacji sylwetki jest kluczowe z punktu widzenia interakcji człowieka z robotem. Pozwala ono stwierdzić kiedy człowiek jest zwrócony w kierunku robota. Znajomość orientacji jest również konieczna do prawidłowego określenia stron użytkownika, co może mieć istotne znaczenie dla przebiegu interakcji. Do celów porównawczych przygotowano test polegający na wykonaniu 30 obrotów w czasie poruszania się po dwóch ścieżkach przedstawionych na rysunku 6.

7 Wykorzystanie czujników głębi w robotyce społecznej Tab. 1: Dokładność wyznaczenia pozycji przegubów wybranej osoby w zależności od tempa chodu. Wyniki podano w metrach Od. st. - odchylenie standardowe, W. mi. - wartość międzyszczytowa Próba Odległość (w rzucie na XZ) Wysokość (wartość Y) Średnia Od. st. W. mi. Średnia Od. st. W. mi. Biblioteka OpenNI Środek ciężkości, tempo wolne 0,0118 0,0529 0,3250-0,0549 0,0671 0,3126 Głowa, tempo wolne -0,0110 0,0959 0,5342 0,4271 0,0424 0,3369 Szyja, tempo wolne -0,0044 0,0728 0,3944 0,1671 0,0548 0,3325 Tors, tempo wolne 0,0052 0,0608 0,3872-0,0044 0,0566 0,3496 Średnia ramion, tempo wolne -0,0044 0,0728 0,3944 0,1671 0,0548 0,3325 Środek ciężkości, tempo szybkie 0,0083 0,0608 0,3570-0,0568 0,0794 0,3926 Głowa, tempo szybkie -0,0287 0,1131 0,5689 0,4179 0,0490 0,4892 Szyja, tempo szybkie -0,0182 0,0877 0,4613 0,1702 0,0557 0,4521 Tors, tempo szybkie -0,0120 0,0755 0,4005 0,0073 0,0557 0,4287 Średnia ramion, tempo szybkie -0,0182 0,0877 0,4613 0,1702 0,0557 0,4521 Kinect SDK Środek ciężkości, tempo wolne -0,0095 0,0990 0,2800-0,0633 0,0566 0,6814 Głowa, tempo wolne -0,0514 0,0775 0,4629 0,5397 0,0592 0,3868 Środek ramion, tempo wolne -0,0519 0,0755 0,3788 0,3894 0,0510 0,3904 Grzbiet, tempo wolne -0,0540 0,0707 0,3801 0,0615 0,0510 0,2841 Średnia ramion, tempo wolne -0,0340 0,0600 0,4064 0,2865 0,0548 0,4238 Środek ciężkości, tempo szybkie -0,0087 0,1082 0,6446-0,0580 0,0480 0,6032 Głowa, tempo szybkie -0,0598 0,0911 0,5679 0,5383 0,0447 0,4105 Środek ramion, tempo szybkie -0,0602 0,0877 0,5133 0,3885 0,0447 0,4020 Grzbiet, tempo szybkie -0,0626 0,0877 0,5188 0,0621 0,0374 0,2548 Średnia ramion, tempo szybkie -0,0402 0,0883 0,5210 0,2835 0,0316 0,3661 Rys. 6: Trajektoria testowa - punkty oznaczają miejsca stawiania kolejnych kroków, strzałki orientację ciała Wyniki testów z wykorzystaniem biblioteki OpenNI przedstawiono na rysunkach 7a i 7c, z wykorzystaniem Kinect SDK na rysunkach 7b i 7d. Nie trudno zauważyć, że biblioteka OpenNI poprawnie określa orientację ciała, zaś Kinect SDK zawsze

8 M. Dziergwa, P. Kaczmarek, J. Kędzierski (a) Biblioteka OpenNI, 1. trajektoria (b) Kinect SDK, 1. trajektoria (c) Biblioteka OpenNI, 2. trajektoria (d) Kinect SDK, 2. trajektoria Rys. 7: Orientacja ciała podczas realizacji eksperymentu (wyświetlono co trzeci pomiar) przyjmuje, że człowiek jest zwrócony w stronę urządzenia. Dokładna analiza orientacji w otoczeniu punktów, w których powinna ona wynosić π 2 lub π 2 (lewy i prawy wierzchołek trójkąta z rysunku 6) wykazała, że biblioteka OpenNI zawsze określała ją prawidło, a średni błąd wynosił jedynie 0,0215π radianów dla pierwszej ścieżki i 0,0297π radianów dla drugiej ścieżki. Biblioteka Kinect SDK nigdy nie wykrywała poprawnie orientacji ciała skierowanego tyłem do urządzenia. Najwyraźniej przyjęto założenie, że człowiek jest zawsze zwrócony w stronę czujnika Czas wykrycia Kolejnym etapem badań było porównanie czasów w jakich obydwie biblioteki wykrywają osobę (nazywanych dalej czasami wykrycia) oraz rozpoczynają śledzenie jej szkieletu (nazywanych dalej czasami śledzenia). Dla każdego wariantu badania wykonano po 30 pomiarów dla obu bibliotek. Pomiar rozpoczynał się od uruchomienia nowej instancji aplikacji, tak aby historia poprzednich wykryć nie miała wpływu na

9 Wykorzystanie czujników głębi w robotyce społecznej Tab. 2: Wyniki pomiarów czasu wykrycia osoby oraz rozpoczęcia śledzenia jej szkieletu. Myślnik oznacza brak wykrycia postaci lub rozpoczęcia śledzenia przez bibliotekę. Czas podano w sekundach Od. st. - odchylenie standardowe Wariant Klatka wykrycia Czas wykrycia Klatka początku Czas początku śledzenia śledzenia Średnia Od. st. Średnia Od. st. Średnia Od. st. Średnia Od. st. OpenNI ,33 2,42 0,73 0,46 26,63 2,52 1,30 0, ,33 2,31 0,60 0, ,07 2,37 0,63 0,47 556,63 24,00 24,12 19, Kinect SDK 1 20,97 1,35 1,03 0,55 22,97 1,35 1,11 0, ,93 0,92 0,92 0,20 21,93 0,92 0,99 0, ,40 1,21 0,99 0,51 22,40 1,21 1,06 0, ,80 2,49 1,13 0,62 26,80 2,49 1,22 0,62 uzyskane rezultaty. Wyniki badań przedstawiono w tabeli 2. Przeprowadzono następujące warianty badań: 1. Postać stojąca w odległości 2,4m od Kinecta, całość postaci w polu widzenia. 2. Postać wykonująca pojedyncze kroki lewo-prawo o długości 43 cm, w tempie 100 kroków na minutę, całość postaci w polu widzenia. 3. Postać wykonująca pojedyncze kroki lewo-prawo o długości 43 cm, w tempie 100 kroków na minutę, postać widziana od szyi w dół. 4. Postać wykonująca pojedyncze kroki lewo-prawo o długości 43 cm, w tempie 100 kroków na minutę, postać widziana od kolan w górę. 5. Postać wykonująca pojedyncze kroki lewo-prawo o długości 43 cm, w tempie 100 kroków na minutę, postać widziana od pasa w górę. Analiza wyników przedstawionych w tabeli 2 pozwala zauważyć kilka kluczowych różnic między biblioteką OpenNI, a Kinect SDK. Biblioteka OpenNI nie potrafi wykryć zarówno obecności osoby jak i jej szkieletu kiedy ta stoi w bezruchu. Wskazać można dwa potencjalne powody tego zjawiska - po pierwsze, OpenNI nie wykorzystuje wstępnej informacji o wykrytych postaciach udostępnianej przez czujnik Kinect na ostatnich 3 bitach obrazu głębi. Po drugie, wykrywając szkielet postaci, OpenNI wykorzystuje sekwencję klatek, nie bazuje zaś na statycznym obrazie jak to ma miejsce w przypadku Kinect SDK. Oprócz zaobserwowanego braku możliwości wykrycia nieruchomej osoby, hipotezę tę potwierdzają obserwacje uzyskane podczas użytkowania oprogramowania. Wraz ze spadkiem liczby przetwarzanych klatek na sekundę, np. ze względu na obciążenie komputera lub rzadsze wywoływanie funkcji pobierającej nową klatkę, skuteczność biblioteki drastycznie spada. Kolejną istotną różnicą jest wpływ ograniczenia pola widzenia na możliwość wykrycia postaci i śledzenia jej szkieletu. Biblioteka OpenNI lepiej radzi sobie z osobami widzianymi od szyi w dół - potrafi wykryć ich obecność, podczas gdy w Kinect

10 M. Dziergwa, P. Kaczmarek, J. Kędzierski Tab. 3: Wyniki pomiarów czasu wykrycia osoby oraz rozpoczęcia śledzenia jej szkieletu dla dwóch osób Od. st. - odchylenie standardowe Biblioteka Klatka wykrycia Klatka wykrycia Klatka początku Klatka początku - 1. osoba - 2. osoba śledzenia - 1. osoba śledzenia - 2. osoba Średnia Od. st. Średnia Od. st. Średnia Od. st. Średnia Od. st. OpenNI 16,10 2,72 20,83 2,85 27,87 2,82 34,73 3,68 Kinect SDK 23,27 2,80 29,93 3,89 25,27 2,80 31,93 3,89 SDK, próba wykrycia kończy się niepowodzeniem. Skuteczność Kinect SDK jest za to zdecydowanie wyższa w sytuacjach gdy widziana jest jedynie górna część sylwetki. Jest to sytuacja zdecydowanie częstsza, a informacje o górnych częściach ciała są znacznie istotniejsze w kontekście interakcji robota z człowiekiem. Biblioteka potrafiła szybko wykryć (po przetworzeniu średnio 20, 4 24, 8 klatek) zarówno osoby widziane od kolan jak i od pasa w górę. Wynik ten uzyskano bez włączania trybu Seated mode. Wyniki biblioteki OpenNI były w tym przypadku zdecydowanie gorsze - dla sylwetki widzianej od kolan wzwyż, czas wykrycia postaci był wprawdzie porównywalny z czasem wykrycia przy pełnej widoczności, jednak średni czas rozpoczęcia śledzenia wyniósł aż 24,12s i miał bardzo duże odchylenie standardowe. W przypadku widoczności od pasa w górę, biblioteka OpenNI nie wykrywała sylwetki. Dla człowieka będącego w ruchu, czas wykrycia postaci i rozpoczęcia jej śledzenia, dla obydwu bibliotek jest niewielki. Badania pokazały, że biblioteka OpenNI nieznacznie szybciej, bo już średnio w 15. klatce, wykrywała obecność człowieka, a średnio w 27. wykrywała sylwetkę. Dla Kinect SDK wykrycie następowało średnio w 20., a śledzenie rozpoczynało się średnio w 22. klatce. Zauważyć należy również, że czasy wykrycia i śledzenia w bibliotece OpenNI mają dużo wyższe odchylenie standardowe niż w przypadku Kinect SDK. W przypadku oprogramowania firmy Microsoft wykrycie szkieletu następuje zawsze dokładnie dwie klatki po wykryciu osoby - w bibliotece OpenNI nie zaobserwowano żadnych prawidłowości. Ostatnim eksperymentem dotyczącym czasu wykrycia i rozpoczęcia śledzenia osoby było zbadanie wpływu większej liczby osób znajdujących się w polu widzenia czujnika. Jako, że Kinect SDK ma możliwość śledzenia jedynie dwóch szkieletów, test ograniczono do dwóch osób. Wyniki pomiarów zebrano w tabeli 3. Szybsze wykrycie osób uzyskano dla biblioteki OpenNI, zaś szybsze rozpoczęcie śledzenia dla Kinect SDK Minimalna odległość od ściany Podczas licznych badań HRI zaobserwowano negatywny wpływ bliskości ściany (lub innej płaskiej powierzchni) za plecami wykrywanej osoby na możliwość poprawnego zlokalizowania i śledzenia jej szkieletu. Ze względu na przyjęta metodologię eksperymentu (użytkownik się poruszał), test ten przeprowadzono jedynie dla biblioteki Kinect SDK. Wyznaczona odległość dla której wykryto sylwetkę człowieka to 0, 28m od ściany do jej środka ciężkości.

11 Wykorzystanie czujników gł ebi w robotyce społecznej Rys. 8: Wykrywanie w trakcie mijania (u góry: OpenNI, u dołu: Kinect SDK) 3.5. Mijanie si e postaci W celu podtrzymywania kontaktu wzrokowego lub nawiazywania konwersacji z uz ytkownikiem, robot społeczny musi wybierac rozmówc e spos ród kilku osób. Niezwykle waz ne jest, aby po nawiazaniu kontaktu robot był w stanie poprawnie s ledzic konkretnego uz ytkownika. Bez tej umiej etnos ci poprawna interakcja robota moz e zachodzic jedynie z jednym uz ytkownikiem. Zaproponowano test, w którym sprawdzono, czy obie biblioteki poprawnie nadaja uz ytkownikom numery identyfikacyjne, kiedy ci wzajemnie si e przysłaniaja. Przeprowadzono dwa warianty eksperymentu: dwie osoby chodzace w tempie 80 kroków na minut e po odcinkach równoległych do osi X czujnika, oddalone od niego o 1, 71m i 2, 35m i mijajace si e w połowie drogi, trzy osoby, w tym dwie chodzace w tempie 80 kroków na minut e po kwadracie o boku 1, 29m, dla którego os Z czujnika stanowi os symetrii, bliz szy bok oddalony o 1, 71m, mijajace si e w połowie drogi, trzecia osoba stojaca na osi Z czujnika w odległos ci 2, 35m od Kinecta. Wyniki badania pokazuja istotna przewag e biblioteki OpenNI nad Kinect SDK. Typowy przypadek detekcji uz ytkownika dla obu pakietów przedstawiony został na rysunku 8. W kaz dym przypadku przysłoni eta osoba nie była s ledzona. Jednak w przypadku uz ycia OpenNI po jej odsłoni eciu nast epowało wznowienie s ledzenia, nawet jes li ta znajdowała si e w pozycji bocznej. Co wi ecej, zgubionej postaci nadawany był ten sam numer identyfikacyjny, który otrzymała przed przesłoni eciem. Biblioteka Kinect SDK nadawała zawsze nowy numer identyfikacyjny i detekcja nast epowała dopiero wtedy, kiedy postac stawała frontem do czujnika.

12 M. Dziergwa, P. Kaczmarek, J. Kędzierski Tab. 4: Wyniki pomiarów dokładności określenia pozycji dłoni. Wyniki podano w metrach Od. st. - odchylenie standardowe Brak ruchu Ruch Filtr Blisko Daleko Blisko Daleko Błąd Od. st. Błąd Od. st Błąd Od. st Błąd Od. st Open NI Filtr = 0,0 0,0210 0,0426 0,2718 0,1224 0,0304 0,0558 0,0750 0,0191 Filtr = 0,15 0,0305 0,0777 0,0420 0,0103 0,0299 0,0371 0,0649 0,0194 Filtr = 0,3 0,0232 0,0410 0,0434 0,0105 0,0180 0,0329 0,0768 0,0222 Filtr = 0,45 0,0220 0,0163 0,0369 0,0093 0,0391 0,0680 0,0879 0,0249 Filtr = 0,6 0,0175 0,0269 0,0403 0,0073 0,0230 0,0391 0,0701 0,0232 Kinect SDK Filtr = 0 0,0638 0,0171 0,1253 0,0106 0,0799 0,0223 0,1065 0,0292 Filtr = 1 0,0606 0,0039 0,1183 0,0107 0,0822 0,0291 0,1096 0,0273 Filtr = 2 0,0787 0,0159 0,1278 0,0096 0,0879 0,0265 0,1099 0,0260 Filtr = 3 0,0880 0,0044 0,1293 0,0082 0,0664 0,0246 0,1024 0, Dokładność określenia pozycji dłoni Podczas eksperymentów HRI często występuje potrzeba dokładnego określenia położenia wybranej części ciała (najczęściej dłoni lub głowy), np. podczas rozpoznawania koloru trzymanego przedmiotu, określenia kierunku wskazywanego przez człowieka lub innego statycznego gestu. Chcąc sprawdzić dokładność określenia pozycji przeprowadzono eksperyment, w którym mierzono położenie prawej dłoni. Podczas eksperymentu czujnik Kinect (środek układu optycznego czujnika) znajdował się na wysokości 0, 81m od podłogi. Prawa ręka podczas pomiaru znajdowała się w bezruchu, oparta na stojaku, na wysokości 1,35m i w odległości w osi X równej 0,86m. Eksperyment wykonano w następujących wariantach: różna odległość od sensora (w osi Z): blisko - 1,71m, daleko - 2,57m, stanie w bezruchu oraz ruch lewo-prawo (przy unieruchomionej dłoni) o długości kroku 0,43m wykonywany w tempie 100 kroków na minutę. Podczas eksperymentu przebadano również wpływ filtrów wygładzających zmianę położenia przegubów w czasie. Dla modułu biblioteki OpenNI rodzaj filtru określa się jako liczbę z zakresu 0 do 1, gdzie 0 to brak filtracji, a 1 to całkowity brak ruchu przegubów (wartość domyślna to 0, 3), zaś dla biblioteki Kinect SDK poprzez wybranie jednej z 4 predefiniowanych konfiguracji filtru (gdzie 0 - brak filtracji, 4 - najsilniejsze wygładzanie). Wyniki eksperymentu przedstawia tabela 4. Na ich podstawie, zaobserwowano, że ustawienia filtrów nie miały większego wpływu na uzyskane pomiary. Dalsza analiza wyników pozwala zauważyć, że w większości przypadków biblioteka Open- NI zapewnia większą dokładność określenia pozycji (2-3 krotnie) w porównaniu do Kinect SDK. Odchylenie standardowe pomiarów jest w przypadku bliskiej odległości niższe dla Kinect SDK (około 2 razy), zaś w wariancie eksperymentu z czujnikiem Kinect w odległości 2, 57m wyniki są porównywalne. Dla biblioteki OpenNI wpływ ruchu osoby na błąd określenia pozycji jest znaczący jedynie przy większej odległo-

13 Wykorzystanie czujników głębi w robotyce społecznej ści, dla bliższej jest znikomy. W przypadku Kinect SDK, niezależnie od odległości, ruch nie wpływa na dokładność pomiarów. 4. Wnioski Opisane w niniejszym artykule badania miały na celu zweryfikowanie możliwości zastosowania czujnika Kinect w robotyce społecznej. Szczególne znaczenie miało zdefiniowanie kluczowych cech i różnic między bibliotekami Microsoft SDK, a Open- NI/NiTE, które wykorzystywane są do tworzenia aplikacji i algorytmów zorientowanych na percepcję człowieka. Obie biblioteki dostarczają, istotnych z punktu widzenia interakcji robota z człowiekiem, algorytmów wykrywania sylwetki użytkownika i śledzenia położenia jego poszczególnych przegubów. Na korzyść Kinect SDK przemawia możliwość śledzenia większej liczby przegubów (20 przy 15 przegubach dostępnych w OpenNI), zaś zaletą OpenNI jest śledzenie dowolnie dużej liczby użytków (w Kinect SDK jest ona ograniczona do dwóch). Kluczową zaletą oprogramowania dostarczonego przez Microsoft jest bardzo duża liczba dodatkowych funkcji - obsługa trybów Near mode i Seated mode, wykrywanie twarzy w przestrzeni 3D oraz obsługa wbudowanej macierzy mikrofonów. OpenNI jest otwartą platformą integrującą i może zostać rozbudowane przez liczne biblioteki (obecnie na stronie OpenNI jest ich 50). Dostarczają one wielu funkcji, m. in. od precyzyjnego śledzenia dłoni i twarzy, rozpoznawania gestów, także skanowanie i rekonstrukcję modeli 3D. Pod względem analizy obrazu RGB-D obie biblioteki mają porównywalne możliwości. Zgodnie z wiedzą autorów nie istnieją biblioteki współpracujące z OpenNI, umożliwiające dostęp do wbudowanej macierzy mikrofonów. Podsumowując przeprowadzone porównanie bibliotek i eksperymentalną weryfikację ich parametrów, można stwierdzić, że obydwa środowiska zapewniają skuteczną percepcję otoczenia zorientowaną na użytkownika. Wybór biblioteki do zastosowania z czujnikiem Kinect nie jest jednoznaczny i zależny od indywidualnych potrzeb. OpenNI/NiTE zapewnia śledzenie nieograniczonej liczby osób, poprawne określenie orientacji człowieka w przestrzeni, czy precyzyjne zmierzenie położenia wybranego przegubu. Kinect SDK dostarcza znacznie więcej funkcji, zapewnia szybkie wykrywanie i śledzenie nawet w sytuacji ograniczonej widoczności, a przede wszystkim potrafi wykryć użytkownika nawet jeśli on się nie porusza. LITERATURA [1] R. A. Clark, et al. Validity of the Microsoft Kinect for assessment of postural control. Gait and Posture, 2012, Vol. 36, No. 3, s [2] FLASH. Homepage [3] P. Henry, et al. RGB-D mapping: Using Kinect-style depth cameras for dense 3D modeling of indoor environments. International Journal of Robotics Research, 2012, Vol. 31, No. 5, s

14 M. Dziergwa, P. Kaczmarek, J. Kędzierski [4] T. Huynh, R. Min, J. Dugelay. An Efficient LBP-Based Descriptor for Facial Depth Images Applied to Gender Recognition Using RGB-D Face Data. Lecture Notes in Computer Science, 2013, Vol. 7728, s [5] J. Kędzierski. System sterowania robota społecznego. Praca doktorska, Politechnika Wrocławska, Wrocław, [6] Microsoft. Kinect SDK documentation [7] I. Oikonomidis, N. Kyriazis, A. Argyros. Efficient model-based 3D tracking of hand articulations using Kinect. In: Proceedings of the British Machine Vision Conference. Proceedings. BMVA Press, 2011, s [8] OpenNI. Project website [9] A. Ramey, V. Gonzalez-Pacheco, M. A. Salichs. Integration of a low-cost RGB- D sensor in a social robot for gesture recognition. In: th ACM/IEEE International Conference on Human-Robot Interaction. Proceedings, 2011, s [10] Urbi. Project website [11] D. Vasquez, et al. Human Aware Navigation for Assistive Robotics. Experimental Robotics, 2013, Vol. 88, s RGB-D sensors in social robotics This paper describes experiments carried out using a Kinect for Windows sensor and dedicated software with emphasis on use in social robotics. Two software packages are considered - Microsoft Kinect SDK and OpenNI with NiTE library. Particular emphasis is placed upon the parameters affecting the competencies of a social robot, such as detection time, accuracy of joint position and orientation detection or stability of tracking of individual users. Key characteristics of the tested packages are identified and the integration with exisiting social robot control system is described.