Wirtualna proteza dłoni - raport końcowy. Wizualizacja danych

Wirtualna proteza dłoni - raport końcowy.
Wizualizacja danych sensorycznych, ARES00101,
semestr letni 2009/2010.
Michał Wcisło
11 czerwca 2010
1
Spis treści
1 Wprowadzenie
3
2 Wykorzystane narzędzia
3
3 Struktura przegubowa
4
4 Implementacja programowa
4.1 Struktura klasowa . . . . . . . . . . . . .
4.2 Klasy ruchu . . . . . . . . . . . . . . . . .
4.3 System komend . . . . . . . . . . . . . . .
4.4 Aktualnie zaimplementowane mechanizmy
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
7
5 Uwagi do projektu
7
6 Podsumowanie
8
2
1
Wprowadzenie
Celem projektu było stworzenie wirtualnego modelu protezy dłoni, który mógłby posłużyć do wizualizacji pracy sterownika zbierającego dane z czujników
umieszczonych na ciele człowieka i podejmującego decyzje o ruchach chwytnomanipulacyjnych. Powstały model byłby bardzo wygodnym narzędziem do testowania sterowników, a także elementów sensorycznych wykorzystanych do budowy robotów biomedycznych będących protezami dłoni.
2
Wykorzystane narzędzia
Do stworzenia animacji zostały wykorzystane programy Blender [3] oraz Ogre3D
[2]. Elementy składowe wirtualnej dłoni w formie siatek obiektów zostały zbudowane w programie Blender. Aplikacja ta pozwala na edycją punktu ciężkości
obiektów, co umożliwia kontrolowanie obrotów tworzonych elementów. Środowisko omawianego narzędzia wyposażone jest w szereg eksporterów umożliwiających konwersje do innych formatów, między innymi obiektów siatek Ogre3D
(.mesh). Wtyczką odpowiedzialną za eksport danych jest OGREMeshesExporter.
Skonsolidowany model protezy został umieszczony w środowisku silnika graficznego Ogre3D rysunek 1. Scena została zbudowana jako rozszerzenie przykładów zamieszczonych w kursie na portalu pl.wikibooks.org [1]. Ogre3D pozwala
na hierarchiczne budowanie sceny, co wraz z możliwością wykorzystania parametryzacji RPY (Roll-Pitch-Yaw) pozwoliło na stworzenie obiektu o charakterze
manipulatora.
Rysunek 1: Model wirtualnej protezy umieszczony na scenie w środowisku
Ogre3D
Oba narzędzia są bardzo popularne i cieszą się dużym wsparciem ze strony społeczności grafiki 3D. Łatwy dostęp do informacji, kursów i ewentualnych
rozwiązań problemów były powodem wyboru tych aplikacji. Co więcej, oba narzędzia są darmowe (Blender - licencja GNU GPL, Ogre3D - licencja MIT) ale
z powodzeniem dorównują aplikacjom komercyjnym i często wykorzystywane są
przez profesjonalistów.
3
Kod programu powstawał w zintegrowanym środowisku programistycznym
Code::Blocks. Zostało ono wybrane z uwagi na duże możliwości i stosunkową
łatwość integracji z silnikiem Ogre3D. Bardzo wartościowy przewodnik po integracji obu narzędzi można znaleźć na witrynie Wydziału Matematyki i Informatyki Uniwersytetu Mikołaja Kopernika w Toruniu1 , autorką tego tekstu jest
Patrycja Suchomska. W rozwiązywaniu problemów przy instalacji niezwykle pomocne okazało się oficjalne forum silnika Ogre2 , na którym można także szukać
informacji o interakcji środowiska silnika graficznego z Blenderem.
3
Struktura przegubowa
Graficzna reprezentacja struktury przegubowej została zaprezentowana na rysunku 2. Model jest pewnym uproszczeniem rzeczywistych możliwości dłoni,
gdyż nie uwzględnia ruchów palców w płaszczyźnie dłoni. Jest to spowodowane
trudnością implementacji związaną z problemem kolizji palców. Należy także
wspomnieć o sztywności części dłoniowej ręki, która w rzeczywistości podlega wygięciom. Początkowo końcowe dwa przeguby każdego z palców zostały
sprzężone, co miało uprościć model, ostatecznie zrezygnowano z tego pomysłu z
uwagi na łatwość modelowania wszystkich ruchów. W wirtualnym modelu protezy występują pewne przekłamania z uwagi na fakt, że część ruchów ręki jest
wspomagana lub w całości wykonywana przez mięśnie dłoni, które z założenia mają zostać zastąpione protezą. Dotyczy to głównie kciuka, którego jedynie
ruchy odwodzące są realizowane przez mięśnie przedramienia. Brak implementacji tych ruchów byłby dużym uszczerbkiem na funkcjonalności całej protezy,
dlatego zostały one uwzględnione. W modelu dodano dwa przeguby q0 i q7.
Pierwszy z nich umożliwił obracanie całego modelu. Drugi został dodany w celu
zwiększenia realizmu animacji.
4
Implementacja programowa
4.1
Struktura klasowa
Diagram klas został zamieszczony na rysunku 3. Scena budowana jest przy pomocy standardowych funkcji createCamera(), createViewports() i createScene().
Główna część aplikacji została umieszczona w klasie MenadzerRuchu. Funkcja
frameStarted odpowiedzialna jest za animację i odbiera rozkazy zmiany położenia przegubów. Ruchy wykonywane są ze stałą, globalnie ustaloną prędkością
na zasadzie osiągania kolejnych konfiguracji przegubów. W celu zamodelowania
ruchów protezy powstały klasy Obrot,RuchZlozony i KlasaRuchu. Klasy te nie
są bezpośrednio spokrewnione, ale łączą je silne zależności. Obrot reprezentuje
ruch pojedynczego przegubu, RuchZlozony jest grupą obiektów Obrot, natomiast KlasaRuchu jest grupą obiektów RuchZlozony. Taka budowa struktury
1 www-users.mat.umk.pl/
papi/tut.pdf
2 http://www.ogre3d.org/forums/
4
Rysunek 2: Struktura manipulatora odpowiadającego stworzonemu modelowi
protezy (z zakresem wybranych przegubów)
klasowej pozwala wykonywać skomplikowane ruchy wielu przegubów, a także
pozwala modelować ruchy złożone z kilku kolejnych sekwencji.
4.2
Klasy ruchu
Zapis ruchów przechowywany jest w plikach tekstowych zawierających listę nastaw przegubów w kolejnych sekwencjach ruchu. Nazwy plików zawierających
klasy ruchu mają postać ’klasax.txt’, gdzie x jest numerem klasy. Nastawy podawane są w stopniach, w celu zachowania konwencji struktury komend, omawianej w dalszej części dokumentu, zakres kątów został znormalizowany, tak
by najmniejsza wartość kąta była reprezentowana przez 0. Pozwoliło to na zawarcie zakresów w przedziale 0-255. Przyjęcie takiej konwencji umożliwia łatwe
programowanie nowych ruchów, a także pozwala w intuicyjny sposób tworzyć
proste sekwencje jak i bardziej złożone ruchy. Ruchem pomiędzy wyznaczonymi sekwencjami zajmuje się obiekt klasy MenadzerRuchu ograniczając wkład
użytkownika do podania jedynie oczekiwanych nastaw protezy.
Pierwsze 30 klas ruchów zostało zarezerwowanych dla pojedynczych przegubów. Ponieważ na tym etapie wirtualna proteza posiada 20 przegubów pozostałe
10 pozostawiono w celu umożliwienia rozbudowy aplikacji. Klasa zerowa wykorzystywana jest do definicji stanu początkowego dla wszystkich ruchów i może
być swobodnie modyfikowana na ogólnych zasadach.
5
Rysunek 3: Diagram klas modelujący strukturę aplikacji
4.3
System komend
Ponieważ z założenia proteza ma być sterowana z zewnątrz konieczne było stworzenie systemu komend pozwalającego na zadawanie położeń spoza aplikacji.
Ustalono system komend opierający się o dwie liczby jedno-bajtowe bez znaku.
Schemat blokowy struktury docelowej aplikacji przedstawiono na rysunku 4.
Do komunikacji użyto potoków FIFO pozwalających na wymianę danych pomiędzy procesami wizualizacji protezy a modułem zapewniającym komunikację
z mikrokontrolerem (przy wywołaniu należy użyć opcji -i potok wejściowy -o potok wyjściowy). Aplikacja może działać w trybie pojedynczego potoku wejściowego, pozwalając na testowanie aplikacji i stworzonych klas ruchu(opcja -i potok
wejściowy). Przepływ danych jest jednostronny, zgodny ze wskazaniami na schemacie. Zakres pierwszego bajtu komendy został podzielony w celu zapewnienia
komunikacji pomiędzy elementami docelowej struktury, tak że poprzez maskowanie początkowych 3 bitów pierwszego bajtu komendy poszczególne elementy
mogą sprawdzać czy dana komenda jest do nich skierowana. Stąd pierwszy bajt
komendy traktowany jest jako adres. Element wizualizacji posiada zakres 0-159,
przy czym liczby 0-127 są zarezerwowane na klasy przegubów, a więc konkretne ruchy, a pozostałe kombinacje pozwalają na przekazywanie danych konfiguracyjnych. Podobnie przestrzeń adresowa 160-191 została przyporządkowana
warstwie komunikacji po stronie komputera, 192-223 warstwie komunikacji po
stronie mikrokontrolera i 224-255 sterownikowi protezy. Ten bardzo prymitywny
protokół komunikacji pozwala na przekazywanie danych pomiędzy elementami
struktury umożliwiając jednocześnie wykonywanie 98 klas ruchów użytkownika
i 30 ruchów pojedynczymi przegubami.
Zaimplementowana przestrzeń dla danych konfiguracyjnych może zostać wy-
6
Rysunek 4: Schemat blokowy przedstawiający docelową strukturę aplikacji
korzystana do lepszej symulacji protezy, poprzez np. przekazywaniu danych o
stanie protezy, czy ustawieniach transmisji. Dla celów testowych stworzono proste programy po stronie komputera i mikrokontrolera w celu zasymulowania
docelowej struktury. Komunikacja realizowana jest z wykorzystaniem standardu USB. Przykład wymiany danych konfiguracyjnych został zaimplementowany
jako prosty test łączności. Aplikacja protezy rozsyła komendy na pierwszy adres
z zakresu poszczególnych elementów w drugim bajcie przekazując własny adres
(128). Poszczególne elementy struktury przestawiają bajty komendy i ponownie
ją wysyłają, co prowadzi do przesłania danych do aplikacji wirtualnej protezy,
która sprawdza czy wszystkie elementy są osiągalne.
W celu umożliwienia zadawania pozycji protezy z terminala, został stworzony prosty program zapisujący dwubajtowe dane w formie ’x x’ (gdzie x∈[0,255])
do potoku (Zapis.c). Jego wywołanie z opcją ’-o potok wyjściowy’ tworzy potok
FIFO i przesyła do niego wprowadzone dane. Następnie należy wywołać aplikację protezy z tą samą nazwą potoku w parametrze ’-i’, co pozwoli na zadawanie
położeń z programu ’Zapis’.
4.4
Aktualnie zaimplementowane mechanizmy
Aby uniknąć nieporozumień lub niepożądanego działania aplikacji należy przedstawić zaimplementowane na tym etapie mechanizmy i komendy. Przy uruchomieniu potokowania wejściowego i wyjściowego automatycznie przeprowadzany
jest omawiany wcześniej test osiągalności, jeżeli wszystkie elementy nie odpowiedzą test będzie ponawiany i nie będzie możliwości przesyłania komend do
momentu otrzymania komend zwrotnych.
Jeśli chodzi o zaimplementowane komendy, pierwszy bajt równy 0 pozwala na
uśpienie aplikacji na podaną w drugim bajcie liczbę sekund. Natomiast komenda
o adresie 129 pozwala na zmianę szybkości protezy na wartość podaną w drugim
bajcie. Wartość początkowa prędkości jest równa 20.
5
Uwagi do projektu
Stworzona wizualizacja protezy dłoni działa poprawnie, ale istnieje grupa obszarów aplikacji, które można ulepszyć. Przede wszystkim w celu uzyskania peł7
nej funkcjonalności wizualizacji protezy dłoni warto byłoby dodać do głównej
aplikacji elementy interfejsu graficznego użytkownika pozwalającego na symulacje pewnych scenariuszy lub sytuacji w celu dogłębnego testowania sterownika. Stworzony interfejs mógłby także posłużyć do zbierania danych z sensorów
(EMG,MMG) na zasadzie powtarzania ruchów wirtualnej protezy i kojarzenia
ich z konkretnymi sekwencjami, co pozwoliłoby na wydajne tworzenie bazy ruchów koniecznej do implementacji sterownika protezy.
Kolejnym elementem pozwalającym na rozwój projektu jest implementacja
ruchów palców w płaszczyźnie prostopadłej do obecnego obszaru roboczego. Z
uwagi na problem kolizji palców na tym etapie został on pominięty. Do zapewnienia całkowitego realizmu protezy konieczne jest także zapewnienie dynamiki
ruchów, w obecnej wersji aplikacji ruchy wykonywane są ze stałą globalnie ustaloną prędkością.
6
Podsumowanie
Sprawozdanie to miało na celu przedstawienie wyników prac nad projektem wirtualnej protezy dłoni. Stworzenie tej aplikacji pozwoliło na prześledzenie kompletnej ścieżki tworzenia aplikacji graficznej w przestrzeni 3D od etapu modelowania poszczególnych elementów, poprzez umieszczanie ich na scenie, animowanie i wreszcie wdrażanie zaplanowanej funkcjonalności. Aplikacja posiada pewne
obszary wymagające udoskonaleń, co pozwala na dalszy rozwój projektu.
Literatura
[1] ... http://pl.wikibooks.org/wiki/OGRE. pl.wikibooks.org, 2010.
[2] Gregory Junker. Pro Ogre3D Programming. Apress, 2006.
[3] Jarosław Kolmaga Kamil Kuklo. Blender. Kompedium. Helion, 2007.
8