Spis treści Wstęp 2 Opis robota mobilnego 3



Pobieranie 148.32 Kb.
Strona1/2
Data28.04.2016
Rozmiar148.32 Kb.
  1   2


Spis treści


1. Wstęp 2

2. Opis robota mobilnego 3

2.1. Ogólna charakterystyka 3

2.2. Koncepcja sterowania 4

2.3. Język robota 6



2.3.1. Instrukcje warstwy niższej 6

2.3.2. Instrukcje warstwy wyższej sterujące ruchem robota 12

2.3.3. Instrukcje procesu określania pozycji 31

Podsumowanie 34




1.Wstęp


W dzisiejszych czasach jesteśmy wszyscy świadkami dążenia ludzkości do automatyzowania procesów produkcyjnych. Duża część produktów sprzedawanych na świecie nie jest bezpośrednim wytworem rąk ludzkich. Są one wytwarzane przez różnego rodzaju maszyny takie jak obrabiarki numeryczne oraz różnego rodzaju roboty. Część z nich wykonuje prace, które są szkodliwe dla ludzi, część takie których ludzie nie są w stanie wykonać.

Odrębną klasą robotów są roboty mobilne, mogą być one wykorzystywane do celów transportowych, bądź jeżeli robot jest specjalnie skonstruowany to może służyć np.: jako urządzenie sprzątające podłogi pomieszczeń, bądź jako kelner w barze szybkiej obsługi. Należy powiedzieć, że wielu ludzi upatruje tutaj zagrożenia dla rynku pracy.

Zaprezentowano tutaj problemy i ich rozwiązania, które powstały podczas pisania programu sterującego robotem mobilnym. Zamieszczono tutaj także informacje niezbędne do przeniesienia czytelnika w świat komend sterujących robotem i jego systemu operacyjnego.

Pracę rozpoczęto w miejscu, w którym jedynymi elementami dostępnymi były gotowy robot mobilny wraz z instrukcją, oraz komputer klasy IBM-PC. W tym momencie należało sprecyzować co będzie ostatecznym efektem pracy. Zdecydowano się na napisanie programu sterującego robotem w taki sposób, by znacznie uprościć jego kontrolę. Żądane cechy programu to:




  • umożliwienie ręcznego sterowania robotem, za pomocą prostych rozkazów;

  • umożliwienie układania sekwencji ruchów robota;

  • odczytywanie sonarów i prezentacja graficzna danych z nich uzyskanych;

  • zabezpieczenie robota przed możliwością zderzenia się z przeszkodą (podczas realizacji programu);

  • możliwość zapisywania uzyskanych pomiarów w postaci plików do późniejszego wykorzystania;

  • możliwość zapisywania do pliku ułożonych sekwencji ruchów robota.

Praca ta została ułożona w taki sposób, aby zapoznać czytelnika z budową robota (rozdział 2.1.), zestawem komend sterujących jego ruchem (rozdział 2.3.) oraz jego systemem sonarów (rozdział 2.4.). Dodatkowo została opisana specyfika systemu Albatros i wynikająca z tej specyfiki koncepcja sterowania robotem (rozdział 2.2.). Potem opisana jest specyfika tworzenia programów pod Windows (rozdział 3.1.). Wewnętrzna struktura napisanego programu, sposób jego podziału na moduły (rozdział 3.3.1.) oraz opis działania wszystkich funkcji programu (rozdziały 3.3.1., 3.3.2., 3.3.3., 3.3.4., 3.3.5, 3.3.6.). Następnie umieszczony jest opis użytkowania gotowego programu (rozdział 3.4.), przedstawione są ważniejsze okienka dialogowe, ich właściwości i sposoby wykorzystania. W przed ostatniej części zawarto przykładowe efekty pracy programu (rozdział 3.5.). W ostatniej zaś części umieszczone jest podsumowanie całości pracy (rozdział 4.).



2.Opis robota mobilnego

2.1.Ogólna charakterystyka


Robot jest urządzeniem, które jest produkowane przez francuską firmę
ROBOSOFT SA specjalizującą się w konstrukcjach robotów mobilnych. W związku z tym należy zaznaczyć, że robot jest konstrukcją zamkniętą, a niektóre opcje rozszerzeń jego możliwości są dostępne jedynie poprzez zakup dodatkowych pakietów oprogramowania, bądź też w postaci urządzeń elektronicznych.

System sterujący robota jest wykonany w oparciu o procesor Motorola 68020 pracujący z zegarem 16 MHz. Został wyposażony w 4 szesnastobitowe liczniki współdziałające z optycznymi enkoderami służącymi do kontroli pozycji. Ponadto system robota jest wyposażony w 4 dwunastobitowe przetworniki AC oraz po 8 wejść i wyjść cyfrowych. Robot został dodatkowo doposażony w system sonarów zbudowany w oparciu o procesor Motorola 68000 i wyposażony w 8 sonarów. Należy wspomnieć, że ilość sonarów może zostać zmieniona. Integralnym elementem elektronicznej części robota jest jego system operacyjny. Przez producenta nazwany został on ALBATROS i występuje tutaj w wersji 6.0. System ten, jak zapewnia producent, został stworzony specjalnie do zastosowań w urządzeniach kontrolujących wiele osi. Ponadto jest to system modularny, zapewniający łatwość rozbudowy, tak by można było dołączać obsługę nowych elementów systemu, przykładowo ramienia o sześciu stopniach swobody. Należy jednak zaznaczyć, że taka możliwość w aktualnej sytuacji jest nieosiągalna, ponieważ aby dołączać dodatkowe polecenia systemu operacyjnego robota, należy posiadać odpowiednie oprogramowanie, które można zakupić w firmie ROBOSOFT SA.

Komunikacja z systemem operacyjnym robota odbywa się za pomocą interfejsu RS232. Komendy wysyłane do robota są w formie tekstowej i w takiej samej formie są odbieranie odpowiedzi. Przypomina to mniej więcej „rozmowę” z systemem operacyjnym MS-DOS tyle, że poprzez terminal.


Rys. 1. Wygląd zewnętrzny robota.

2.2.Koncepcja sterowania


Jak zaznaczono w poprzednim rozdziale, robot jest wyposażony w system operacyjny ALBATROS. System ten jest jądrem wiążącym wszystkie elementy systemu sterowania robota, to tu jest dokonywana interpretacja wszelkich komend dostarczonych do robota i to stąd wysyłane są polecenia do urządzeń składających się na jego całość.

Na każdy system operacyjny, z punktu widzenia użytkownika, składają się komendy, to ich bogactwo i elastyczność decyduje o jego przydatności do danego zastosowania. ALBATROS został napisany specjalnie do współpracy z urządzeniami wyposażonymi w wiele osi ruchu. Jego komendy są więc przystosowane do współpracy z robotem, dodatkowo należy podkreślić, że jest to system wielozadaniowy. Można powiedzieć, że decyzja firmy ROBOSOFT SA dotycząca umieszczenia tego systemu jako jądra systemu sterowania robota była dobra.

Z punktu widzenia osoby piszącej program sterujący, najbardziej interesująca jest ta część systemu operacyjnego, która współpracuje z użytkownikiem. W tym systemie odbywa się to za pomocą komend tekstowych przesyłanych przez łącze RS232. Sama transmisja odbywa się następująco: użytkownik przesyła do robota daną komendę systemu operacyjnego, system ją interpretuje, podejmuje odpowiednie działania i jeśli przez autora systemu została przewidziana odpowiedź to ją odsyła. Odpowiedzią, w wypadku gdy jest ona zwracana, może być tekst określający rodzaj błędu lub też dane żądane przez użytkownika, np. wynik działania procesu odometrii. Ostatnim krokiem pojedynczej wymiany danych, jest przesłanie przez system operacyjny do użytkownika tekstu zachęty.

Analizując zestaw komend robota określono najczęstsze zachowania się systemu i na tej podstawie wyciągnięto następujące wnioski:




  • System na właściwie sformułowane komendy, wysłane we właściwym czasie, nie odpowiada inaczej niż znakiem zachęty.

  • Na komendy źle sformułowane, bądź z jakichś innych powodów niemożliwe do zrealizowania, system wysyła tekst precyzujący typ błędu.

  • Nie jest wysyłana do użytkownika informacja zwrotna o stanie wykonywania danej komendy. Poprawna komenda zostaje przyjęta, potwierdzane jest to znakiem zachęty, ale jej realizacja odbywa się w tle, a system jest przygotowany na przyjęcie kolejnego zlecenia. Przykładem tu mogą być komendy dotyczące wykonywania przez robota ruchu.

Wielozadaniowość systemu robota jest narzędziem pozwalającym na wydanie polecenia ruchu i w czasie jego wykonywania odczytywanie pomiarów z sonarów lub też danych o pozycji robota z procesu odometrii. Wielozadaniowość ma też wadę: każdy proces uruchomiony w systemie robota powinien mieć dostęp do interfejsu, powoduje to, że po wydaniu polecenia i ewentualnej odpowiedzi, powinien on natychmiast zwolnić ten zasób systemu. Prostymi słowy nie dowiemy się czy ruch robota się skończył, jeśli o to nie zapytamy.

Te cechy systemu zaważyły na metodzie budowy i przesyłania do robota układanych przez użytkownika zestawów sekwencji ruchów. Przyjęto zasadę, że dane przygotowywane do przesłania do robota są w postaci gotowych instrukcji systemu ALBATROS lub prostych pseudo poleceń. Pociąga to za sobą brak możliwości modyfikacji trajektorii ruchu robota podczas realizacji programu. Jedynym dostępnym, w aktualnej wersji programu, pseudo poleceniem, jest żądanie wykonania ruchu po klotoidzie (kontrolowanej). Innymi słowy oznacza to, że została udostępniona możliwość umieszczania w programie polecenia wyliczającego parametry klotoidy i na ich podstawie wykonującego odpowiedni zestaw ruchów.

Sama koncepcja wykonywania przez robota gotowych sekwencji ruchów jest następująca. Tworzymy za pomocą narzędzi zawartych w programie plik tekstowy, w którym w każdej linijce jest umieszczona komenda służąca do umieszczenia jednego ruchu w kolejce ruchów do wykonania. Długość kolejki w robocie wynosi dziesięć (patrz komenda MOTV AD, rozdział 2.3.2.2). Ilość linii skryptu jest z punktu widzenia użytkownika nielimitowana, w rzeczywistości narzędzia programu służące do tworzenia skryptów ograniczają ich długość do trzydziestu dwóch tysięcy siedemset sześćdziesięciu siedmiu linii. Ograniczenie to nie dotyczy procedur wysyłających skrypt do robota.

Tak przygotowany zestaw danych wejściowych program przesyła się do robota. Dokonuje tego funkcja UruchomSkrypt(). Szczegółowy opis jej działania znajduje się w rozdziale 3.3.6., tutaj zaś tylko przybliżono jej koncepcję. Podczas uruchamiania tej funkcji program przekazuje do niej informację o pliku zawierającym dane do przesłania do robota, oraz flagę określającą sposób zachowania procedury wysyłającej. Flaga ta może przybierać dwa stany, jeden określa czy komendy mają być przesyłane do robota, drugi czy należy zatrzymać awaryjnie ruch robota. Samo przesłanie realizowane jest następująco: procedura uruchamia proces MOTV systemu robota, następnie odczytuje linię tekstu skryptu i przesyła ją do robota, odczytuje odpowiedź, potem uruchamia funkcję odczytującą dane z sonarów. Pamiętamy, że te dwie funkcje w środowisku ALBATROS mogą wykonywać się równolegle. W kolejnym kroku funkcja analizuje odpowiedź przesłaną podczas wysyłania ruchu, jeżeli proces ten przebiegł bezbłędnie, to etap przesłania i pomiaru sonarami wykonywany jest ponownie z kolejną linią skryptu. Jeśli robot zgłosił błąd, związany z przepełnieniem kolejki ruchów oczekujących na wykonanie, to następuje próba ponownego przesłania polecenia do robota, która trwa tak długo, aż się powiedzie. Cały ten cykl trwa aż do wyczerpania poleceń zawartych w skrypcie, lub do momentu, gdy opisywana powyżej flaga sterująca zmieni stan na zatrzymujący robota. W pierwszym wypadku wykonywane jest, po zakończeniu ruchu przez robota, wyłączenie procesu MOTV. W drugim przypadku, następuje przesłanie do robota komendy MOTV KI. Powoduje ona zatrzymanie robota, po czym następuje wyłączenie procesu MOTV.

Flaga swój stan może zmienić w dwu przypadkach:




  1. Po dokonaniu pomiarów sonarami, odległość od jednego z nich jest mniejsza niż zadana przez użytkownika.

  2. Użytkownik, żąda zatrzymania realizacji skryptu (przycisk dostępny w okienku Uruchamianie skryptów).

Należy tutaj powiedzieć, że wybrany sposób nie jest jedynym. Można sterować przepływem informacji pomiędzy robotem, a programem nie interpretując komunikatów błędów, a żądając przesłania statusów. Sposób ten jednak wymaga przesyłania dodatkowych komend w kanale łączności pomiędzy robotem, a komputerem. Możliwe jest także zaprojektowanie takiego algorytmu sterującego, aby na bieżąco układał trajektorię robota. Program wtedy musiał by się składać z dodatkowych pseudo poleceń nie interpretowalnych bezpośrednio przez system ALBATROS. Mogły by się wtedy pojawić polecenia wykonywania ruchu robota w zadanej odległości od przeszkody, wykorzystywały by one dane z sonarów i po ich interpretacji generowały by zestaw elementarnych ruchów robota.



  1   2


©absta.pl 2016
wyślij wiadomość

    Strona główna