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

20

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 1 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?

1 lub podobnie Xenomai

Shahbaz
źródło
1
Myślę, że to świetne pytanie. Rozważ podzielenie go na dwie części i wyjaśnienie głównego pytania. „Czy można używać ROS w czasie rzeczywistym?” lub „Czy ROS jest używany w czasie rzeczywistym?” (2 różne pytania) są oddzielone od głównego pytania.
hauptmech
@hauptmech, cóż, ROS z pewnością nie może być używany w czasie rzeczywistym, ponieważ tak nie jest!
Shahbaz
Zgadzam się z @hauptmech. Pytania są mylące. Na górze pytasz, ile osób / jak często używane są systemy czasu rzeczywistego, a później pytasz, kiedy / w którym przypadku . Oba pytania są dobre, więc podziel je na dwa lub zmniejsz do jednego. Dzięki!
bit-pirate
@ bit-pirate, nie rozumiem, dlaczego mówisz, że zapytałem, kiedy / w którym przypadku . Nigdy nie pytałem o coś takiego. Tak jak powiedziałem . Pytanie brzmi, jak bardzo programiści są skłonni pisać aplikacje w czasie rzeczywistym, gdy zachowanie w czasie rzeczywistym jest rzeczywiście potrzebne? Innymi słowy, jaki procent aplikacji uwagi wymagają zachowania w czasie rzeczywistym, są faktycznie realizowane w czasie rzeczywistym? Wiem osobiście, kiedy iw jakim przypadku potrzebne jest zachowanie w czasie rzeczywistym, i nie mam absolutnie żadnych pytań w tej sprawie. W rzeczywistości jestem zaskoczony, widząc odpowiedzi, które to wyjaśniają .
Shahbaz
Dziękuję za wyjaśnienie! Dla mnie tytuł był mylący. Programowanie w czasie rzeczywistym + implementacja IMO jest dojrzała w robotyce, ale wymaga więcej wysiłku (czasu, pieniędzy, umiejętności itp.), Więc większość ludzi tego unika, gdy nie jest to naprawdę konieczne.
bit-pirate

Odpowiedzi:

10

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ć!

Mark Booth
źródło
Rozróżnienie tutaj jest dość istotne ... nawet w systemach niskopoziomowych w „prawdziwym świecie”, bit czasu rzeczywistego jest dość mały (na podstawie przerwania taktu timera), podczas gdy większość systemu jest nominalnie w czasie rzeczywistym (ale + / - kilka nano sekund tutaj i tam jest do przyjęcia). Uśmiecham się, gdy widzę ludzi mówiących o aplikacjach czasu rzeczywistego zbudowanych na WindowsCE lub Linux ...
Andrew
1
Jak mówię @Andrew z odpowiednim oprogramowaniem, nawet Windows 7 może być utrudniony w czasie rzeczywistym z RTX . Nie jestem pewien, dlaczego nie uważasz Windows CE za działający w czasie rzeczywistym, ponieważ miał on deterministyczne planowanie zadań w czasie rzeczywistym, ponieważ wersja 2 i Linux mogą być wykonywane w czasie rzeczywistym za pomocą jądra takiego jak RTLinux .
Mark Booth
Witaj ponownie Mark (nie jestem pewien, kto prześladuje, kto tutaj ...) - Zgadzam się, że możesz to zrobić, ale trudne doświadczenie pokazało, że w wielu (? Większości?) Przypadkach użytkownicy (menedżerowie) ignorują wymagane dodatki i zakładają zrobi to system waniliowy.
Andrew
@Andrew - Moje doświadczenia z RTX polegały na tym , że to po prostu działało . W Pentium 4 dni trzeba było uważać, aby nie używać zintegrowanej grafiki lub dźwięku, które nasycały magistralę PCI, ale nie powinno to stanowić problemu w dzisiejszych czasach.
Mark Booth
Minęło dużo czasu, ale czytając tę ​​stronę, szczególnie w odniesieniu do okien, chciałbym tylko powiedzieć, że wspominasz tylko część tego, jak system jest tworzony w czasie rzeczywistym. Planowanie w czasie rzeczywistym jest oczywiście ważne, ale istnieją różnego rodzaju rzeczy, które mogą generować skoki, które również muszą być obsługiwane, aby system działał w czasie rzeczywistym. Przerwy są częstym przykładem, SMI, pamięci podręczne i przepustowość pamięci są innymi przykładami. Tylko dlatego, że istnieje harmonogram w czasie rzeczywistym, nie tworzy systemu w czasie rzeczywistym.
Shahbaz
8

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:

PR2

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.

Rocketmagnet
źródło
Krótko mówiąc, mówisz, że często nie używa się czasu rzeczywistego, ponieważ oprogramowanie działające w czasie rzeczywistym działa „wystarczająco dobrze”?
Shahbaz
@Shahbaz - Nie mogę wypowiedzieć się na temat tego, jak często jest faktycznie używany, ale mogę powiedzieć, że jeśli jest używany, to może być niepotrzebny. Kiedyś używaliśmy RTAI, a następnie porzuciliśmy go, ponieważ w rzeczywistości przeszkadzał on bardziej niż pomagał.
Rocketmagnet
1
Chciałbym podkreślić jeden punkt: masz tyle mocy obliczeniowej na PR2, że możesz uzyskać coś „wystarczająco dobrego”. Pracowałem nad robotem z „tylko” Core2 Duo. To nie jest opcja: pełny stos zajmuje każdy rdzeń w 100% przez większość czasu. Tutaj Rock (Orocos) i RT-Linux były niezbędne do utrzymania pętli sterowania 1kHz razem.
sylvain.joyeux
@ sylvain.joyeux - Zgadzam się. ROS radzi sobie dość słabo pod względem kontroli, gdy masz tylko 2 rdzenie.
Rocketmagnet
@Rocketmagnet Przykro mi, że muszę głosować za tym, ale część PR2 jest nieprawidłowa. Na PR2 jest pojedyncza pętla czasu rzeczywistego działająca z częstotliwością 1000 Hz równolegle do ROS (w Linux + RT PREEMPT), która komunikuje się za pośrednictwem Ethercat z płytami kontrolera silnika, wykonując rzeczywiste sterowanie silnikiem dla każdej DOF. Należy zachować ostrożność podczas programowania kontrolerów (np. Wspólnego kontrolera trajektorii), aby nie złamać się w czasie rzeczywistym, a także mają specjalne narzędzia do zarządzania nimi (np. Ładowanie / rozładowywanie). Zajrzyj tutaj, aby uzyskać więcej informacji.
bit-pirate
4

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ć.

ronalchn
źródło
Dziękuję za odpowiedź. Być może moje pytanie wymaga lepszego sformułowania, ale nie chciałem pytać „kiedy używać w czasie rzeczywistym”, ale „jak często ludzie faktycznie używają w czasie rzeczywistym, gdy potrzebny jest czas rzeczywisty”. Niemniej jednak twoje zachowanie w czasie rzeczywistym na mikrokontrolerach bez potrzeby posiadania platformy czasu rzeczywistego było dobrym punktem, którego nie wziąłem pod uwagę.
Shahbaz
Na marginesie, w czasie rzeczywistym i szybkie są dwie ortogonalne koncepcje. Jeśli planista ścieżki musi podjąć decyzję ściśle w ciągu jednej minuty, jest to aplikacja działająca w czasie rzeczywistym. Chociaż rozumiem, dlaczego wspominałeś o szybkim robocie.
Shahbaz
2

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.

Crake
źródło
2

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.

hauptmech
źródło
2

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.

Joe
źródło
2

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.

Jay Beavers
źródło
0

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. :-)

bit-pirat
źródło
0

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.

hauptmech
źródło
0

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

użytkownik3150208
źródło