Jak dojrzałe jest programowanie w czasie rzeczywistym w robotyce? [Zamknięte]

Edycja: Nie wiem dlaczego, ale to pytanie wydaje się wprowadzać w błąd wielu ludzi. Wiem, kiedy / gdzie / dlaczego / jak korzystać w czasie rzeczywistym. Interesuje mnie to, czy ludzie, którzy wykonują zadanie w czasie rzeczywistym, naprawdę dbają o to, aby wdrożyć je w czasie rzeczywistym, czy nie.

Nie trzeba wspominać, dlaczego operacje w czasie rzeczywistym są ważne dla robota. Moje pytanie brzmi jednak, ile faktycznie jest wykorzystywane w robotyce?

Weźmy na przykład to pytanie . Tylko jedna odpowiedź wspomina o dowolnej platformie z możliwościami w czasie rzeczywistym, i to również daleko od szczytu. Najwyraźniej ROS jest bardzo popularną platformą, która nie działa w czasie rzeczywistym.

Jednak w świecie czasu rzeczywistego RTAI ¹ wydaje się być jedyną wykonalną darmową platformą użytkowania w czasie rzeczywistym. Jest jednak ograniczony do Linuksa (bez problemu), źle udokumentowany i powoli rozwijany.

Jak bardzo poszukiwane są zachowania w czasie rzeczywistym wśród twórców robotyki?Pytanie brzmi: na ile programiści są skłonni pisać aplikacje w czasie rzeczywistym, gdy zachowanie w czasie rzeczywistym jest rzeczywiście potrzebne? Jeśli nie wiele, dlaczego?

Na przykład zachowanie zwrotne oparte na danych dotykowych nie może przejść przez ROS, ponieważ utraci swoją właściwość w czasie rzeczywistym. Ale czy ludzie naprawdę wymyślają rozwiązanie w czasie rzeczywistym, czy mimo to używają ROS, ignorując właściwość w czasie rzeczywistym?

¹ lub podobnie Xenomai

Pamiętaj, że jest czas rzeczywisty i czas rzeczywisty .

Trudny czas rzeczywisty jest trudny do osiągnięcia bez wsparcia sprzętowego lub oprogramowania na niskim poziomie, ale często nie potrzebujesz wszystkiego, aby być zdolnym do obsługi czasu rzeczywistego . Miękkie i twarde reakcje w czasie rzeczywistym są znacznie łatwiejsze do osiągnięcia i często są więcej niż wystarczające dla wielu aplikacji.

Ponadto różne części systemu mogą mieć bardzo różne wymagania w czasie rzeczywistym . Jeśli korzystasz z programowych pętli PID, naprawdę powinny one mieć trudną reakcję w czasie rzeczywistym (naprawdę nie chcesz wybierać między miękkim dostrajaniem swoich PID lub ich dostrajaniem a czasami powodowaniem niestabilności). System wizyjny może mieć rygorystyczne wymagania dotyczące reakcji w czasie rzeczywistym , wydajność obniży się, jeśli nie będzie można przetworzyć obrazu na czas do podjęcia kolejnej decyzji, ale nie musi on uniemożliwiać działania systemu, w tym przypadku, jeśli nie można go przetworzyć na czas lepiej wyrzucić częściowe wyniki i nie tracić czasu na rozpoczęcie analizy na następnej klatce. Wreszcie ogólne planowanie i koordynacja (prawdopodobnie najbardziej złożonaczęść twojego systemu robotycznego) często może pozostać mocno w dziedzinie miękkiego czasu rzeczywistego .

Nawet w dziedzinie komputerów z systemem Windows możesz uzyskać wysoką wydajność w czasie rzeczywistym , potrzebujesz tylko odpowiedniego oprogramowania z odpowiednimi zaczepami do jądra. Miękki sterownik PLC TwinCat firmy Beckhoff całkiem szczęśliwie przeprowadził sterownik PLC o wysokiej szybkości skanowania, dzieląc połowę cykli maszyny Pentium, przekazując drugą połowę Windows NT, a było to ponad dekadę temu. Nawet nowoczesne systemy sterowania, takie jak niektóre opcje z zakresu A3200 firmy Aerotech, wykonują gruntowne prace na komputerze hosta, przy czym jądro niskiego poziomu zajmuje tyle czasu procesora, ile potrzebuje na twarde wymagania w czasie rzeczywistym i pozostawia resztę cykli procesora w systemie Windows 7 używać!

System czasu rzeczywistego nie jest tak naprawdę wymagany w przypadku wielu (większości?) Robotycznych systemów sterowania. Tak długo, jak masz pętlę sterowania, która działa wystarczająco szybko, z wystarczająco niskim jitterem i nie przepuszcza zbyt wielu cykli, jest to dość odpowiednie do sterowania robotami i serwosterowania.

Jako dowód tego pozwólcie, że przedstawię PR2 i Rękę Robota Cienia:

Ten robot ma około 20 stopni swobody, z których wszystkie są obsługiwane przez główną pętlę ROS. A co powiesz na Shadow Robot Hand, który ma również 20 DOF, plus szereg czujników dotykowych i innych, a także jest serwowany przez główną pętlę ROS.

Pętla główna ROS cierpi z powodu niewielkiego jittera, czasem nawet 100us, a czasem nawet całkowicie traci cykle. Ale nie ma znaczenia, czy 99,9% cykli wykonano pomyślnie.

Zastosowanie wielu rdzeni w komputerach-hostach oznacza, że ​​jeden cały rdzeń jest przeznaczony do działania w głównej pętli, więc bardzo rzadko jest opóźniany przez inne zadania.

Głównym powodem korzystania z systemu operacyjnego robotów w czasie rzeczywistym jest bezpieczeństwo. Jeśli robot pracuje w sytuacji krytycznej z punktu widzenia bezpieczeństwa, Twoim obowiązkiem jest zagwarantowanie 100% czasu sprawności sterowania, a część tego gwarantuje jego charakter w czasie rzeczywistym.

Niezależnie od tego, czy korzystasz z systemu operacyjnego w czasie rzeczywistym, czy nie, twoje serwomechanizmy powinny zrobić coś bezpiecznego na wypadek, gdyby pętla sterowania całkowicie zginęła. Ten system bezpieczeństwa byłby również pomocny w rzadkich przypadkach, gdy system operacyjny działający w czasie rzeczywistym przeskakuje więcej niż cykl. Na przykład w Ręce Cienia silniki są zatrzymywane, jeśli pętla sterowania nie wykona więcej niż 20 cykli (20 ms). Jednak nigdy tego nie widziałem.

Dodany

Innym sposobem na zastanowienie się nad tym jest: Jakiej aktualizacji potrzebuje Twój system serwo? Jeśli jest to duże ramię i nie wymaga super wysokiej wydajności, szybkiego pozycjonowania, wtedy 500Hz może być wystarczające. Do prowadzenia pojazdu prawdopodobnie wystarcza 200 Hz. W obu przypadkach, jeśli twoja pętla faktycznie pracuje z częstotliwością 1000 Hz, to spóźniony lub brakujący cykl naprawdę nie stanowi żadnego problemu, o ile twój algorytm kontrolny bierze pod uwagę faktyczny upływ czasu między pętlami.

Cel oprogramowania określa, czy musi on być ściśle w czasie rzeczywistym.

Gdy celem jest planowanie trasy lub lokalizacja, często wystarczająca jest niska częstotliwość, na przykład 10 Hz. W takich przypadkach konfiguracja odtwarzacza / sceny działająca w systemie Linux jest w porządku. Widzimy, że problemów jest niewiele, jeśli jeden krok jest nieco dłuższy lub krótszy.

Zachowanie ściśle w czasie rzeczywistym jest wymagane, jeśli dynamika robota jest szybka. Na przykład poruszanie ramieniem robota w celu śledzenia pozycji lub manipulowania / chwytania obiektów i przenoszenia ich. W przypadku pominięcia kroku czasowego pozycja może być nadmiernie przekroczona i możemy chcieć bardziej przewidywalnego zachowania. W takim przypadku możemy mieć częstotliwość do 1 kHz lub więcej. Jeśli używany jest system operacyjny, chcemy systemu operacyjnego w czasie rzeczywistym.

Zachowanie w czasie rzeczywistym można osiągnąć we wbudowanych aplikacjach, używając timerów i przerwań (skompilowany kod C na mikrokontrolerze). W takim przypadku musimy upewnić się, że obciążenie przetwarzania nie jest zbyt duże, aby można było utrzymać regularną częstotliwość próbkowania.

Roboty korzystające z komputerów / mikroprocesorów (ponieważ wymagana jest większa moc obliczeniowa) będą musiały korzystać z systemu operacyjnego w czasie rzeczywistym, aby zagwarantować wysoką częstotliwość próbkowania.

Dlatego to, czy wymagane jest zachowanie w czasie rzeczywistym, zależy od tego, do czego programista zamierza go użyć.

Nasza firma buduje roboty wykorzystujące FreeRTOS działające na mikrokontrolerach PIC. Dla nas głównym powodem korzystania z FreeRTOS jest łatwość zmiany priorytetów w zadaniach, obsługa wielu linii komunikacyjnych jednocześnie oraz łatwa komunikacja między modułami obsługi przerwań i głównymi zadaniami. Mikrokontrolery są znacznie tańsze niż instalowanie pełnej maszyny linuxowej w każdym produkowanym przez nas robocie.

Jeśli faktycznie potrzebujesz czasu rzeczywistego, korzystaj z systemu operacyjnego czasu rzeczywistego. Monitorowanie bezpieczeństwa, akwizycja danych i stałe pętle kontroli częstotliwości próbkowania są powszechnymi podsystemami, które używają planowania w czasie rzeczywistym.

Część programowania w czasie rzeczywistym jest zwykle tak mała, jak to możliwe, ponieważ trudniej jest ją debugować, a mniej kodu łatwiej sprawdzić pod kątem poprawności. Dokumentacja systemu operacyjnego w czasie rzeczywistym jest zwykle całkiem dobra (w tym RTAI / Xenomai).

Używałem QNX i RTAI-> Xenomai w różnych prawdziwych projektach robotyki. Wolałem QNX, ale Xenomai był równie skuteczny.

Orocos to dojrzałe środowisko oprogramowania do sterowania robotami w czasie rzeczywistym. Widziałem, jak to było używane do skutecznego sterowania szybkimi manipulatorami robotami o wysokich wymaganiach w czasie rzeczywistym. Zawiera wiele takich samych komponentów na poziomie frameworku jak ROS, komunikacja, konfiguracja, serializacja i pakowanie oparte na komponentach.

Zacznij myśleć o swoim robocie w kategoriach wielu procesorów i przesuwania pytań w czasie rzeczywistym. Jeśli masz algorytm, który wymaga niezawodnego sprzężenia zwrotnego z dużą prędkością, takiego jak wyważarka dwukołowa lub stabilizator quad-copter lub impuls serwa, czas rzeczywisty jest niezwykle ważny, ale zadanie jest również bardzo ograniczone.

Taką pętlę kontrolną można odciążyć do dedykowanego procesora w czasie rzeczywistym, takiego jak tani 8-bitowy AVR lub 32-bitowy ARM klasy niskiej klasy, znaleziony w klasie urządzeń Arduino. Nic nie stoi na przeszkodzie, aby dodać wiele tuzinów tych małych MCU z dedykowanymi pętlami sterowania, a wyliczenie urządzeń USB nawet to ułatwia.

Teraz, gdy masz pętle sterowania wrażliwe na czas obsługiwane przez dedykowany procesor, możesz rozluźnić potrzeby „mózgu” robota w czasie rzeczywistym, który może obsługiwać wyższą logikę przy użyciu takich komponentów, jak ROS w systemie Linux lub Kinect dla systemu Windows.

W odpowiedzi na „kiedy / w którym przypadku” stosowane są systemy czasu rzeczywistego:

Z mojego doświadczenia wynika, że ​​kontrola ruchu jest główną aplikacją do systemów czasu rzeczywistego. Do sterowania silnikami ważna jest wysoka częstotliwość (100 Hz, 1000 Hz i więcej) oraz niski jitter (zmiany czasu). Bezpieczeństwo jest tutaj bardzo ważne. Rozważmy robota wśród ludzi: na przykład chcesz / musisz upewnić się, że robot (ramię) zatrzymuje się w określonym przedziale czasowym / odległości.

W przypadku innych zadań, takich jak planowanie ścieżki, przetwarzanie obrazu i wnioskowanie, system czasu rzeczywistego nie jest tak ważny i często unika się go z powodu nadmiernego czasu projektowania i kosztów sprzętu.

Obecnie duże roboty, takie jak PR2, łączą oba światy. W kontekście czasu rzeczywistego systemu operacyjnego z obsługą RT (np. Linux + Xenomai) zachodzi kontrola ruchu, aw części nierealnej (ziemia użytkownika) przetwarzanie i planowanie wizji są osadzone w systemach takich jak ROS. Oba mogą działać na tym samym komputerze.

Z przyjemnością edytuję tę odpowiedź, gdy pytanie zostanie wyjaśnione. :-)

Tak, zakładając, że zasoby sprzętowe mogą spełniać wymagania czasowe (wystarczająca moc obliczeniowa, wystarczająco małe opóźnienie), gdy program planujący nie może odpowiednio sekwencjonować procesów i wątków, wówczas używa się harmonogramu w czasie rzeczywistym, zwykle podłączonego do jądra specjalnie zoptymalizowanego dla wyzwania tego. Sterowniki sprzętowe można również optymalizować pod kątem warunków w czasie rzeczywistym.

Tak, jeśli nie można zagwarantować, że oprogramowanie wykona swoje zadanie w wymaganych ograniczeniach czasowych, wówczas stosuje się podejście w czasie rzeczywistym.

Jednym dobrym rozwiązaniem jest ZARÓWNO. Projekt, którego używam, umieszcza „twarde” funkcje w czasie rzeczywistym na małym mikrokontrolerze, ciasne pętle sterowania serwo i tym podobne. Potem jest inny, większy procesor, działający pod Linuksem i ROS. Pozwalam ROS obsługiwać zadania wyższego poziomu, a uP takie rzeczy, jak sterowanie silnikiem krokowym lub uruchamianie pętli PID.

Jak powiedziano powyżej przez innych, MOŻESZ zezwolić, aby system operacyjny działający w czasie rzeczywistym działał w pętlach kontrolnych 1 KHz, ale aby to zadziałało, potrzebujesz komputera o nadmiernym zabójstwie, który spędza większość czasu w bezczynnej pętli. Jeśli używasz komputera z systemem Linux / ROS przy prawie 100% wykorzystaniu procesora, wydajność w czasie rzeczywistym jest niska. Korzystanie z dwupoziomowej konstrukcji pozwala zawsze uzyskać bardzo dobrą wydajność RT, a także używać mniejszego, mniej wymagającego energii komputera (być może zadania wyższego poziomu w Pi2). Mój uP obecnie nie działa na żadnym systemie operacyjnym, ale przechodzę do FreeRTOS