RobREx - Autonomia dla robotów ratowniczo-eksploracyjnych


Celem projektu jest wytworzenie zestawu technologii oraz odpowiedniej architektury niezbędnych do produkcji autonomicznych robotów usługowych i terenowych, a w szczególności robotów ratowniczo-eksploracyjnych, w Przemysłowym Instytucie Automatyki i Pomiarów (PIAP) w Warszawie. PIAP jest uznanym w świecie producentem robotów interwencyjnych i antyterrorystycznych (INSPECTOR, EXPERT, SCOUT, IBIS, GRYF).

Obecne konstrukcje są zdalnie sterowane przez operatora, co istotnie ogranicza ich zasięg operacyjny i wymaga ciągłego zaangażowania człowieka w działania robota. Dla zapewnienia kontynuacji trendu rozwojowego wytyczonego przez PIAP, modernizacji konstrukcji robotów zgodnie z osiągnięciami współczesnej robotyki i jednocześnie stworzenia podstaw do wykorzystania potencjału nowo powstającego rynku robotów usługowych i terenowych, projekt będzie nakierowany na robota służącego do wspomagania akcji ratowniczych i eksploracyjnych (Robot Ratowniczo-Eksploracyjny, w skrócie RobREx). Technologie wytworzone w ramach proponowanego projektu zostaną zweryfikowane na robotach zdolnych do autonomicznej realizacji zadań zleconych przez operatora, takich jak dotarcie do i inspekcja wyznaczonych obszarów, dostarczenie danych operatorowi i wykonanie działań manipulacyjnych, lokomocyjnych i percepcyjnych. Docelowym zadaniem proponowanego robota będzie wspomaganie ludzi w akcjach ratowniczych i eksploracyjnych prowadzonych w pomieszczeniach domowych, biurowych, budynkach użyteczności publicznej lub w ich bezpośrednim otoczeniu. Przykładem wykorzystania takiego robota są akcje poszukiwawcze.

Zakładamy, że demonstratory technologii opracowanych w projekcie będą testowane na następującym scenariuszu. Środowisko działania robota zostało częściowo zniszczone, a w związku z tym posiadana przez niego mapa nie jest w pełni aktualna i tylko w części (nie wiadomo jakiej) dobrze opisuje środowisko.

Scenariusze testowe


Scenariusze zostały wykonane na 3 komputerach. Menedżer Zadań był uruchomiony na pierwszym komputerze. Na drugim część Menedżerów Usług, a pozostałe komponenty (Repozytorium, Rejestr Usług, symulacja i Menedżery Usług) na trzecim. Poza symulacją, komponenty systemu nie wymagają dużej mocy obliczeniowej, więc umieszczenie tylu komponentów na jednym komputerze nie stanowiło problemu.

Scenariusz 1a

Pierwszy scenariusz testowy będzie polegał na przewiezieniu przedmiotu z otwartej szafki na platformę. Transportowanym przedmiotem jest w tym przypadku słoik z zawartością (granulkami). Zadanie jest realizowane przez jedną usługę typu TransferObject reprezentującej jednego robota wyposażonego w chwytak. Zadanie jest zdefiniowane następująco:
  • warunki początkowe: Jar002 IsIn Cabinet001
  • warunki końcowe: Jar002 IsOn Platform001



Scenariusz 1b

W czasie wykonywania zadania transportu może dojść do wielu niepowodzeń. Jednym z nich jest częściowe uszkodzenie robota, w tym przypadku będzie to uszkodzenie napędu. W takiej sytuacji robot posiada działającą jednostkę sterującą i może komunikować się z resztą systemu. Posiada także działający nadal chwytak. Odkłada więc transportowany przedmiot na ziemię i wysyła do Menedżera Zadań informację o jego położeniu (warunki końcowe: Jar002.PositionX=12.5 AND Jar002.PositionY=1.3 AND Jar002.PositionZ=7). Dzięki temu Menedżer Zadań może podjąć akcje pozwalające na dokończenie zadania. W analizowanym scenariuszu znajduje inną usługę tego samego typu (TransferObject - transport przedmiotu) i zleca jej wykonanie, wskazując jako sytuację wejściową otrzymaną od robota pozycję słoika. Realizacja drugiej usługi polega na podjechaniu do miejsca uszkodzenia robota, podniesieniu słoika z ziemi, przetransportowaniu do pozycji docelowej i odłożeniu słoika na platformę.




Scenariusz 2a

Scenariusz 2 jest po części rozwinięciem scenariusza 1. Zamiast słoika transportowany jest niebezpieczny ładunek wybuchowy (bomba). Docelowym miejscem jest platforma urządzenia do unieszkodliwienia ładunku. W tym przypadku zadanie realizowane jest za pomocą dwóch usług. Pierwsza jest usługą transportującą ładunek, natomiast druga unieszkodliwia ładunek, który został wcześniej umieszczony na odpowiedniej platformie. Zadanie jest zdefiniowane następująco:
  • warunki początkowe: Bomb001 IsIn Cabinet001
  • warunki końcowe: Bomb001 IsIn Platform001



Scenariusz 3a

Zadanie w scenariuszu 3 polega na przetransportowaniu zawartości słoika znajdującego się w szafce do miski znajdującej się na stole. Zawartością słoika jest granulat, którego transfer będzie polegał na operacji przesypania. Zadanie jest zdefiniowane następująco:
  • warunki początkowe: ?Granules002 IsIn Jar001
  • warunki końcowe: ?Granules002 IsIn Bowl001



Scenariusz 3b

W trakcie realizacji analizowanego w scenariuszu 3 zadania może dojść do niepowodzenia polegającego na wydostaniu się transferowanej substancji poza pojemnik docelowy. W takim przypadku zostanie uruchomiona procedura obsługi niepowodzenia (zdefiniowana wcześniej w planie), zawierającą usługę (CleanArea) sprzątającą substancję (granulki), która znalazła się na podłodze. Po sprzątaniu granulki są transferowane do wskazanego miejsca. Może to być miska, do której miały trafić pierwotnie. W takim przypadku, po zakończeniu procedury obsługi niepowodzenia, zadanie kończy się sukcesem (wszystkie granulki znajdują się w obiekcie docelowym). Jeżeli zadanie wymaga przetransferowania wszystkich granulek, a robot sprzątający nie zdołał ich znaleźć lub nie mogą być one umieszczone w pojemniku docelowym, to zadanie kończy się niepowodzeniem. W opisywanym scenariuszu została wybrana pierwsza opcja, dlatego warunki końcowe dla usługi sprzątania to „?Granules002 isIn Bowl001”. Warunki początkowe są przekazywane z usługi zakończonej niepowodzeniem, która wysłała opis sytuacji wskazującej, że granulki znajdują się na podłodze (?Granules002 isOn Floor001).




Scenariusz - niepowodzenie