Wizualizacja przejazdu labiryntu przez robota mobilnego typu Micromouse

Transkrypt

1 Wizualizacja danych sensorycznych prowadzący: dr inż. Bogdan Kreczmer Wizualizacja przejazdu labiryntu przez robota mobilnego typu Micromouse Raport z projektu Jędrzej Boczar 20 czerwca 2017

2

3 SPIS TREŚCI SPIS TREŚCI Spis treści 1 Wstęp 3 2 Założenia projektowe 3 3 Harmonogram projektu Kamienie milowe Diagram Gantta Opis aplikacji Graficzny interfejs użytkownika Komunikacja bezprzewodowa Opis protokołu Wykresy danych sensorycznych Wykres napięcia zasilania Wykres odczytów z czujników odległości Dane tekstowe o parametrach ruchu Reprezentacja graficzna labiryntu Budowa aplikacji Struktura okna głównego Reprezentacja graficzna labiryntu Testy aplikacji 12 7 Podsumowanie Wnioski

4 3 HARMONOGRAM PROJEKTU 1 Wstęp Niniejszy raport jest sprawozdaniem końcowym z projektu realizowanego w ramach przedmiotu Wizualizacja danych sensorycznych, polegającego na opracowaniu aplikacji do wizualizacji przejazdu robota typu Micromouse. 2 Założenia projektowe Micromouse to konkurencja, w której roboty rywalizują ze sobą próbując w jak najkrótszym czasie pokonać labirynt poprzez dotarcie z jego rogu do środka i z powrotem. Kształt labiryntu nie jest wcześniej znany, a więc robot musi podczas przejazdu samemu stworzyć sobie jego mapę oraz odszukać najlepszą ścieżkę. Od początku znana jest jednak jego wielkość: liczba komórek (16x16) oraz wymiary pojedynczej komórki. Tematem projektu jest stworzenie, z pomocą bibliotek Qt, aplikacji pozwalającej na wizualizację przejazdu tego typu robota na ekranie komputera. Wykorzystany robot jest tworzony niezależnie, jednakże aplikacja poprzez ustalenie stosownego API pozwoli na wykorzystanie przez inne tego typu konstrukcje. Aktualne dane odczytywane będą z portu szeregowego na komputerze, a przesyłane z wykorzystaniem modułu bluetooth znajdującego się na pokładzie robota. W założeniach wizualizacja ma przedstawiać: schemat labiryntu z zaznaczonymi jak dotąd odkrytymi ściankami, aktualnym położeniem robota (obecna komórka oraz orientacja robota) i planowaną ścieżką chwilowe parametry ruchu (prędkość, przyspieszenie) bieżące odczyty z czujników odległości (w formie wykresu słupkowego) stan napięcia zasilania w czasie (w formie wykresu) 3 Harmonogram projektu W tym rozdziale przedstawiony został harmonogram przebiegu projektu. 3.1 Kamienie milowe Odbiór danych z portu szeregowego Wyświetlanie tekstowych danych o parametrach robota Dane w formie wykresów Graficzna reprezentacja labiryntu Gotowa aplikacja zrealizowane 3

5 3.2 Diagram Gantta 4 OPIS APLIKACJI Zadanie Kompilacja, okno aplikacji 2 Plan rozkładu elementów 3 Odbiór danych przesyłanych z robota 4 Wygodny interfejs połączenia 5 Wyświetlanie tesktowe danych 6 Wykresy danych 7 Graficzna reprezentacja labiryntu 8 Dopracowanie wizualizacji przejazdu 9 Poprawa wygody interfejsu Rysunek 1: Diagram Gantta: tygodnie rozpoczynając od dnia 27. marca. Kolor zielony - zadania zrealizowane. Kolor czerwony - zadania zaległe. Kolor niebieski - zadania do zrealizowana w przyszłości. 3.2 Diagram Gantta Terminy: Wstępne rezultaty koniec tygodnia 4. Rezultaty prawie końcowe koniec tygodnia 7. Rezultaty końcowe koniec tygodnia 11. Planowany rozkład pracy przedstawiony został w formie diagramu Gantta na rys Opis aplikacji Aplikacja podzielona jest na cztery główne części: część odpowiedzialną za komunikację bezprzewodową wykresy odczytów z czujników i napięcia zasilania wyświetlanie danych tekstowych o parametrach ruchu wizualizację przejazdu po labiryncie 4.1 Graficzny interfejs użytkownika Pierwotny szkic interfejsu graficznego przedstawiony został na rysunku 2, zaś na rysunku 3 widać obecny wygląd okna aplikacji. Okno aplikacji podzielone zostało na 5 głównych części. Są to: 4

6 4.2 Komunikacja bezprzewodowa 4 OPIS APLIKACJI Rysunek 2: Pierwotny projekt ułożenia elementów interfejsu użytkownika Maze wyświetlanie labiryntu i położenia robota MovementData wyświetlanie tekstowych danych o parametrach ruchu SensorsPlot wykres słupkowy odczytów z czujników odległości PowerPlot wykres liniowy monitorowanego napięcia zasilania Bluetooth interfejs połączenia bezprzewodowego bluetooth 4.2 Komunikacja bezprzewodowa Komunikacja z robotem przebiega z wykorzystaniem technologii bluetooth. Aplikacja pozwala na wyszukanie urządzeń znajdujących się w pobliżu, a po wybraniu modułu znajdującego się na robocie, łączy się z nim w trybie portu szeregowego w standardzie RFCOMM. Nawiązanie połączenia polega na wybraniu przycisku Scan, co wywołuje okno dialogowe (patrz rysunek 4), w którym użytkownik może wybrać odpowiednie urządzenie zatwierdzając przyciskiem Connect. Po nawiązaniu połączenia lewym dolnym rogu głównego okna programu zostanie wyświetlona informacja o nawiązanym połączeniu (rys. 3). Przycisk Clear pozwala na wyczyszczenie okna z informacjami. W przypadku problemów z połączeniem, można zrestartować bluetooth za pomocą przycisku Restart bluetooth. Dodatkowo aplikacja pozwala wysyłać polecenia do robota (pole tekstowe z zachętą Send message). Na rysunku 5 przedstawiony został diagram przepływu sterowania w programie podczas nawiązywania komunikacji z robotem poprzez bluetooth. 5

7 4.2 Komunikacja bezprzewodowa 4 OPIS APLIKACJI Rysunek 3: Ostateczny interfejs graficzny Rysunek 4: Okno skanera urządzeń bluetooth. 6

8 4.2 Komunikacja bezprzewodowa 4 OPIS APLIKACJI Rysunek 5: Diagram przepływu. 7

9 4.3 Wykresy danych sensorycznych 4 OPIS APLIKACJI Tabela 1: Typy danych przesyłanych z robota (także te obecnie niewykorzystywane). Kod Typ danych Liczba bajtów Znaczenie bajtów Wykorzysywane D Czujniki odległości 12 6 x uint16 t Tak P Zasilanie 4 2 x uint16 t Tak L Czujniki linii 16 8 x uint16 t Nie E Enkodery 4 2 x uint16 t Nie I Czujniki inercyjne 12 6 x int16 t Nie W Wykryte ściany 1 1 x uint8 t Tak M Ruch po labiryncie 1 1 x uint8 t Tak V Obecna prędkość 4 1 x float Tak A Obecne przyspieszenie 4 1 x float Tak Opis protokołu Aby umożliwić właściwą komunikację z robotem opracowany został odpowiedni protokół przesyłu danych. Pozwala on odbiór zarówno danych o aktualnym stanie robota i odczytach z czujników, jak i wiadomości tekstowych. W protokole jednostką przesyłu danych jest bajt. Zakłada się wstępnie, że wszystkie odbierane dane są wiadomością tekstową, aż do napotkania bajtu o wartości 0xFF - oznacza on początek nadawania paczki danych (bajt START). Jest to znak spoza kodu ASCII, więc nie występuje w wiadomościach tekstowych. Wartość następującego po nim bajtu to liczba bajtów pozostałej części paczki danych (inaczej mówiąc: jest to długość całej paczki, pomniejszona o 2). Reszta wiadomości składa się z par kod-dane. Kod jest to litera ASCII oznaczająca typ danych. Każdy typ ma z góry przyporządkowaną długość i format danych. Typy danych zdefiniowane są w tabeli 1. Wykorzystany format protokołu pozwala jednak na łatwe rozszerzanie funkcjonalności. Większość typów danych odczytywana jest poprzez konwersję surowych bajtów do odpowiednich typów zmiennych języka C++. Jedynie informacje o wykrytych ścianach oraz o kierunku ruchu robota po labiryncie interpretowane są na poziomie pojedynczych bitów, przy czym bitom [0, 1, 2, 3] odpowiadają kierunki [północ, wschód, południe, zachód] (patrz sekcja 5.2). Na rysunku 6 przedstawiona została przykładowa ramka danych. 4.3 Wykresy danych sensorycznych W aplikacji, do wizualizacji danych sensorycznych, zastosowano dwa wykresy działające w czasie rzeczywistym. Pomiędzy wykresami znajduje się element pozwalający na zmianę 8

10 4.4 Dane tekstowe o parametrach ruchu 4 OPIS APLIKACJI START 4 bajty 12 bajtów 4 bajty 0xff 23 P... D... E... Rysunek 6: Przykładowa ramka danych. wielkości wykresów lub też na całkowite ukrycie jednego z nich Wykres napięcia zasilania Napięcie zasilania charakteryzuje się niską zmiennością, dlatego interesującą dla użytkownika informacją jest nie jego wartość chwilowa, lecz zmiany na dłuższej przestrzeni czasu. Aby zrealizować jego wyświetlanie w odpowiedni sposób wykorzystany został wykres liniowy. Oczekiwane wartości napięcia powinny znajdować się w zakresie między 6V a 9V, jednakże lokalnie jego zmiany są względnie małe. Z tego powodu umożliwiono użytkownikowi dynamiczną modyfikację zakresu osi rzędnych. Możliwe jest to na dwa sposoby: skalowanie - przybliżanie/oddalanie za pomocą kółka myszy translacja - przesuwanie trzymając przycisk myszy Wykres odczytów z czujników odległości Robot posiada sześć czujników odległości wykorzystywanych do wykrywania ścian w labiryncie oraz określania dystansu między robotem a ścianą. Dane te charakteryzują się dużą rozpiętością zasięgu wartości jakie mogą przyjmować. Dodatkowo różne czujniki mogą przyjmować jednorazowo skrajne wartości. Do reprezentacji tego typu danych wykorzystano wykres słupkowy, dzięki czemu można przejrzyście reprezentować na raz wszystkie wartości. Zakres osi ustawiony jest na stałe na całą rozpiętość zakresu pomiarowego, ponieważ dokładna wartość pomiaru nie jest dla użytkownika tak ważna, jak stosunek tej wartości do pozostałych. Zakres pomiarów został znormalizowany do wartości w przedziale [0, 1]. 4.4 Dane tekstowe o parametrach ruchu W prawym górnym rogu głównego okna aplikacji (rys. 3) wyświetlane są na bieżąco informacje o prędkości i przyspieszeniu robota. Wartości te pochodzą wprost od robota, a więc obrazują jego bieżący stan wewnętrzny (nie są liczone na podstawie przebytej drogi). 4.5 Reprezentacja graficzna labiryntu Labirynt znajduje się w lewej górnej części okna aplikacji (rys. 3). Przedstawiony został on schematycznie za pomocą siatki szarych linii dzielących go na komórki oraz czarnych linii oznaczających ściany. Robota symbolizuje obrazek myszy, która przesuwa się z komórki do komórki na podstawie danych wysyłanych poprzez bluetooth, zachowując przy tym odpowiednią orientację. Labirynt jest aktualizowany w miarę otrzymywania informacji o nowo wykrytych ścianach. 9

11 5 BUDOWA APLIKACJI 5 Budowa aplikacji W tym rozdziale przedstawione zostały wybrane aspekty budowy wewnętrznej programu. Dokładne opisy poszczególnych struktur umieszczone zostały w dokumentacji wygenerowanej za pomocą programu Doxygen. 5.1 Struktura okna głównego Całość aplikacji zbudowana jest jako centralne pole pojemnika MainWindow będącego rozszerzeniem QMainWindow. Każdej z opisanych w sekcji 4.1 części aplikacji odpowiada klasa dziedzicząca po klasie QWidget. Wszystkie z nich znajdują się wewnątrz pojemnika Viewer, który służy również do kontroli przesyłania danych pomiędzy pozostałymi składowymi aplikacji. W nim to łączone są sloty i sygnały odpowiedzialne za przesyłanie danych otrzymanych poprzez bluetooth. Poza tym każda część aplikacji jest w pełni autonomiczna. Pomiędzy SensorsPlot, a PowerPlot znajduje się element typu QSplitter, który pozwala na przeciąganie granicy pomiędzy wykresami lub też na całkowite schowanie jednego z nich. Ponad wykresami umieszczony został Widget MovementData wyświetlający w postaci tekstowej informacje o prędkości ruchu robota i jego przyspieszeniu. Jest to najprostsza część aplikacji. Do formatowania napisów wykorzystany został tak zwany Rich Text, pozwalający między innymi na zapis znaków w indeksie górnym. Diagram UML z atrybutami i metodami klas dotychczas zaimplementowanych przedstawiono na rysunku Reprezentacja graficzna labiryntu Do wizualizacji labiryntu wykorzystano udostępniany przez Qt mechanizm Graphics View Framework. Klasa Maze dziedziczy po klasie QGraphicsView służącej do wyświetlania scen (QGraphicsScene). Całość obrazu na scenie reprezentowana jest jako zbiór elementów typu QGraphicsItem. Elementami są zarówno komórki labiryntu (klasa Cell), jak i reprezentacja robota. Labirynt posiada (ustalane na etapie kompilacji) rozmiary wyznaczające ilość komórek przypadających na bok kwadratu (np. rozmiar 8 oznacza labirynt o wymiarach 8 x 8). Ruch robota możliwy jest jedynie o pełne komórki w czterech kierunkach (oznaczanych kierunkami geograficznymi, przy czym północ znajduje się na górze okna aplikacji) i ograniczony do przestrzeni labiryntu. W każdej pozycji możliwe jest dodanie nowo wykrytych ścian wokół obecnej komórki. Ruch wykonany przez istniejącą ścianę powoduje wypisanie komunikatu ostrzeżenia, jednakże sam ruch zostaje wykonany. Dzięki temu możliwe jest zauważenie, że robot wysyła sprzeczne dane i podjęcie odpowiednich kroków w celu naprawienia algorytmu. Cała wizualizacja labiryntu wykonywana jest na podstawie tylko dwóch typów danych, mogących przybyć w dowolnym czasie (i zawierających jedynie informację o kierunku): wykrycie położenia ściany w danym kierunku (w obecnej komórce) wykonanie ruchu w danym kierunku Dzięki takiemu podejściu minimalizowana jest ilość komunikacji z robotem, co upraszcza dostosowanie robota do pracy z aplikacją. 10

12 5.2 Reprezentacja graficzna labiryntu 5 BUDOWA APLIKACJI «QWidget» BluetoothInterface + RobotDataInterpreter *datainterpreter - QLineEdit *sendingbox - QPlainTextEdit *conversationbox - QPushButton *scanbutton, *disconnetbutton, *resetbutton, *clearbutton - BluetoothScanner *scanner - QBluetoothSocket *rfcommsocket - QBluetoothLocalDevice *localdevice - QByteArray databuffer «QMainWindow» MainWindow - Viewer *viewer «QWidget» Viewer «QWidget» MovementData - static const QString vlabel - static const QString acclabel - QLabel *velocity, *acceleration + explicit MovementData(QWidget *parent = 0) +$ void setvelocity(qreal v) +$ void setacceleration(qreal a) > void robotdataready(const QByteArray data) -$ void scancompleted(int result) -$ void sendmessage() -$ void receivedmessage() -$ void connectsocket() -$ void disconnectsocket() -$ void resetbluetooth() -$ void socketconnected() - void printmessage(const QByteArray msg) «QObject» RobotDataInterpreter enum DataType: char const char DATA_START, DATA_STOP - QHash<char, int> datalengths - QByteArray databuffer bool isdatatypebyte(char byte) bool isdatastartbyte(char byte) bool isdatastopbyte(char byte) void receivedata(const QByteArray data) > void readypowerdata(int voltage) - void interpretdatabatch(char type, const QByteArray data) «QDialog» BluetoothScanner - QPushButton *cancelbutton, *connectbutton - QBluetoothDeviceDiscoveryAgent *discoveryagent - QListWidget *discovereddevices - QBluetoothDeviceInfo *chosendevice + QBluetoothDeviceInfo *getchosendevice() +$ virtual int exec() +$ void devicediscovered(const QBluetoothDeviceInfo &device) +$ void scanfinished() +$ void scanerror() +$ void devicechosen(qlistwidgetitem *current) +$ void close() - BluetoothInterface *bluetooth - Maze *maze - MovementData *movementdata - PowerPlot *powerplot - SensorsPlot *sensorsplot «QGraphicsView» Maze - static qreal MAZE_SIZE - static int MAZE_DIM - QGraphicsScene *scene - QGraphicsPixmapItem *mouse - QPoint currentpos - Cell *cells[maze_dim][maze_dim] + explicit Maze(QWidget *parent = 0) +$ void newwall(direction dir) +$ void movemouse(direction dir) - qreal celllength() const - void setmousedirection(direction dir) - void setmouseposition(int x, int y) - QPoint positionaftermove(direction dir) - bool ispositioninmaze(qpoint pos) - qreal size - QBitArray walls 1 1..n «QWidget» SensorsPlot - const int FPS - QCustomPlot *plot - QCPBars *sensorbars + explicit SensorsPlot(QWidget *parent = 0) +$ void addnewdata(const QVector<int> data) +$ void refresh() +$ void simulate() «QGraphicsItem» Cell «QWidget» PowerPlot - const int FPS - const float PLOT_TIME_RANGE - const float VOLTAGE_MULTIPLY_FACTOR - const float ADC_REF_VOLTAGE - const int ADC_RESOLUTION - QCustomPlot *plot - QTime time + explicit PowerPlot(QWidget *parent = 0) +$ void addnewdata(int value) +$ void refresh() +$ void simulate() - float countvoltage(int adcreading) + explicit Cell(qreal size, QGraphicsItem *parent = 0) + QRectF boundingrect() const + void paint(qpainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget) + void addwall(direction dir) + bool haswall(direction dir) Rysunek 7: Diagram klas w wariacji języka UML (> - sygnały, $ - sloty) 11

13 7 PODSUMOWANIE 6 Testy aplikacji Aplikacja została przetestowana na własnym robocie Micromouse wyposażonym w moduł bluetooth XM-15B o standardzie Bluetooth EDR. Komunikacja przebiegała bez zauważalnych problemów. Jako że robot nie był w tym czasie zdolny do przejechania samodzielnie labiryntu, informacje o labiryncie zostały zasymulowane wewnątrz programu. Zrobiono to jednak w taki sposób, że działanie aplikacji było praktycznie identyczne z planowanym w rzeczywistym przypadku (aplikacja dostawała paczkę danych zgodną z protokołem opisanym w sekcji 4.2.1). Na rysunku 8 widać działanie aplikacji w praktyce. 7 Podsumowanie Przedstawiona aplikacja została skończona zgodnie z założeniami projektu. W trakcie trwania projektu wprowadzonych zostało kilka zmian, głównie dotyczących interfejsu graficznego, jednakże kluczowe założenia są zgodne z początkową specyfikacją. Ostateczna aplikacja pozwala na połączenie się z robotem poprzez interfejs bluetooth oraz wyświetlanie w czasie rzeczywistym danych o stanie czujników oraz położeniu w labiryncie. 7.1 Wnioski Na podstawie wykonanych prac oraz przebiegu projektu sformułowano następujące spostrzeżenia: Aplikację udało się skończyć w ustalonym terminie, pomimo nieznacznych opóźnień z powodu nieprzewidzianych wcześniej problemów. Było to możliwe, ponieważ harmonogram uwzględniał czas na dodatkowe poprawki i sytuacje wyjątkowe. Połączenie poprzez interfejs bluetooth często przysparza problemów. Biblioteka QtBluetooth okazuje się w tym przypadku bardzo dobrym rozwiązaniem i minimalizuje ilość błędów połączenia. Mimo to wciąż mogą zdarzać się problemy związane z wykorzystywanym sprzętem, dlatego też warto dać aplikacji możliwość zresetowania bluetooth, jeżeli problemu nie da się rozwiązać w inny sposób. Pośród dostępnych w Qt bibliotek do tworzenia wykresów niewiele pozwala na rysowanie ruchomej osi czasu. W razie potrzeby wykonywania wykresów liniowych w czasie rzeczywistym, godną polecenia jest biblioteka QCustomPlot, w której możliwe jest to w bardzo prosty i intuicyjny sposób. Dodatkowo jest to jedna z najszybszych bibliotek do tworzenia wykresów dedykowanych do wykorzystania w Qt i pozwala na łatwą integrację z resztą aplikacji. 12

14 7.1 Wnioski 7 PODSUMOWANIE Rysunek 8: Testy aplikacji z wykorzystaniem rzeczywistego robota. 13