Jak mogę kontrolować szybki (200 Hz) system czasu rzeczywistego za pomocą wolnego (30 Hz) systemu?

Obecnie projektujemy robota mobilnego + ramię montowane z wieloma kontrolowanymi stopniami swobody i czujnikami.

Rozważam architekturę w dwóch częściach:

1. Zestaw kontrolerów czasu rzeczywistego (Raspeberry Pis z systemem RTOS, takich jak Xenomai lub mikrokontrolery z czystego metalu) do sterowania silnikami ramion i enkoderami. Nazwijmy te maszyny RTx, gdzie x = 1,2,3… w zależności od liczby mikrokontrolerów. Ta pętla sterująca będzie działać przy 200 Hz.

2. Potężna waniliowa maszyna linux z systemem ROS do obliczania SLAM, mocap i wykonywania logiki wysokiego poziomu (decyduj o zadaniu robota i oblicz żądaną pozycję i prędkość silników). Ta pętla sterująca będzie działać przy 30 Hz.

Wiem, że mój framework musi być skalowalny, aby uwzględnić więcej silników, więcej czujników, więcej komputerów (np. Dla zewnętrznego mocapa).

Moim głównym problemem jest wybór sposobu komunikacji różnych RTx z PC1. Przyjrzałem się artykułom związanym z architekturą robotów (np. HRP2 ), najczęściej opisują one architekturę sterowania na wysokim poziomie, ale muszę jeszcze znaleźć informacje na temat tego, jak komunikować się z poziomem wysokim w sposób skalowalny. Przegapiłem coś?

Aby podłączyć szybkie maszyny RT zapewniające sterowanie silnikiem za pomocą PC1, rozważałem TCP / IP, CAN i UART:

• TCP / IP: nie deterministyczny, ale łatwy do wprowadzenia. Czy brak determinizmu jest prawdziwym problemem (ponieważ i tak będzie stosowany przy niskiej prędkości 30 Hz)?
• CAN: powolny, bardzo niezawodny, ukierunkowany na samochody (widziałem kilka przykładów użycia CAN z robotami, ale wyglądało to egzotycznie)
• UART: gdybym miał tylko jedną maszynę RT do sterowania silnikiem, rozważyłbym UART, ale sądzę, że ten port nie skaluje się dobrze z wieloma RTx. Czy TCP / IP naprawdę nie wchodzi w grę z powodu jego niedeterministycznych właściwości? Jest tak łatwy w użyciu…

W tej chwili żadne rozwiązanie nie wydaje mi się oczywiste. A ponieważ nie mogę znaleźć żadnego poważnego przykładu robota używającego konkretnego niezawodnego i skalowalnego rozwiązania, nie czuję się pewny, aby dokonać wyboru.

Czy ktoś ma jasne zdanie na temat tego punktu lub literatury, na które należy wskazać? Czy w robotach stosowane są typowe lub powszechne rozwiązania komunikacyjne?

Myślę, że zrobiłeś dobry pierwszy krok; podzieliłeś problem na platformę mobilną (która ma niepewność pozycji i musi nawigować) i ramię (które ma dość pewną pozycję w czasie rzeczywistym, za pomocą koderów).

Przeglądałem artykuły związane z architekturą robotów [...], ale jeszcze nie znalazłem informacji na temat tego, w jaki sposób komunikować niski poziom z wysokim poziomem w skalowalny sposób. Przegapiłem coś?

Z twojego opisu wygląda na to, że próbujesz powiązać każdy kontroler RTx bezpośrednio z PC1, na którym działa ROS. To, czego przegapiłeś, to to, że ROS został zaprojektowany do obsługi grupy aplikacji, które mogą wytwarzać i konsumować dane z różnymi prędkościami.

Twoja aplikacja potrzebuje mostka komunikacyjnego - pojedynczego interfejsu między pętlą 200 Hz a środowiskiem ROS. Innymi słowy, zamiast związania każdego kontrolera RTx do PC1, związać wszystkie kontrolery RTX razem i podłączyć to do PC1.

Na przykład użyj magistrali I2C, aby połączyć ze sobą systemy RTx i dodaj kolejny kontroler RTx, aby był „Arm Master” (AM). Zadaniem AM byłoby przyjmowanie poleceń przychodzących w formacie i protokole przyjaznym dla PC1 oraz konwertowanie tych poleceń na komunikaty I2C. Następnie napiszesz aplikację ROS, aby wysyłać polecenia do AM.

Innym sposobem na zrobienie tego z I2C byłoby umieszczenie kontrolera I2C bezpośrednio na PC1 i zapisanie całej logiki sterowania ramieniem w aplikacji ROS. Może to wydawać się bardziej uproszczonym sposobem na osiągnięcie celu, ale może utrudnić debugowanie, ponieważ usuwasz modułowość systemu - będziesz musiał rozwiązać go jako jeden duży złożony system zamiast dwóch łatwo testowalnych komponentów.

Powiedziałbym, że każda aplikacja, w której wymagana jest duża liczba węzłów komunikacyjnych (czujniki lub urządzenia wykonawcze), mogłaby skorzystać na implementacji jako magistrala systemowa (w przeciwieństwie do połączeń punkt-punkt, takich jak UART lub Ethernet), ze względu na złożoność okablowania, determinizm i modułowość.

Każdy system sterowania wymaga wysokiego stopnia determinizmu, w którym kanały o dużej przepustowości (takie jak Ethernet) są zwykle słabe (szczególnie gdy są używane z systemem operacyjnym ogólnego przeznaczenia, który wprowadza duże ilości fluktuacji planowania, patrz poniższy link do dyskusji na temat determinizmu planowania) ). Procesory aplikacyjne (takie jak ARM11 z Raspberry Pi) również prawdopodobnie źle pasują do systemów czasu rzeczywistego (z powodu takich efektów, jak opóźnienie przerwania i wykładanie instrukcji). Zobacz poniższą digikey dyskusję porównującą zachowanie rdzenia aplikacji ARM w czasie rzeczywistym z mikrokontrolerem .

Szkoda, że ​​dostępność zintegrowanego CAN nie jest tak powszechna jak UART (RS-485) lub I2C (jeszcze), ponieważ myślę, że to naprawdę upraszcza problem rozproszonego wykrywania i aktywacji. I chociaż zwykły 1 Mb / s może wydawać się wolny, zwykle jest więcej niż wystarczający po obliczeniu częstotliwości odświeżania wszystkich elementów magistrali (a szybkość transmisji można zawsze zwiększyć, w zależności od długości magistrali, impedancji i tego, czy twój nadajnik-odbiornik na to pozwoli). Dostępne jest także genialne oprogramowanie do symulacji, które zasadniczo gwarantuje najgorsze czasy reakcji w przypadku najgorszych przypadków (na przykład RealTime-at-work ma bezpłatny analizator magistrali CAN o nazwie RTaW-Sim). I wreszcie wydaje się, że dostępność czujników MEMS ze zintegrowanym CAN jest raczej niska.

Innym przykładem, w którym siłowniki są skonfigurowane jako magistrala (lub pierścień), są Dynamixels serii AX i MX, w których każdy silnik jest połączony szeregowo z drugim za pomocą łącza UART. To znacznie upraszcza projektowanie systemu, jeśli masz dużą liczbę siłowników.

Ale wracając do rzeczywistego pytania, myślę, że jeśli opisujesz swój system jako punkty nastawy w czasie rzeczywistym, zamiast poleceń (np. Raczej stale nadaj kąt silnika niż instruując polecenie, takie jak kąt goto), upraszcza to sprzężenie między pętla 200 Hz i 30 Hz.

Wygląda na to, że masz 2 oddzielne (ale powiązane) problemy, które próbujesz rozwiązać na raz. Podzielmy twoją zagadkę na mniejsze części:

1. Jak przekazywać polecenia z wolnego systemu (30 Hz) do szybkiego kontrolera (200 Hz) i jak komunikować dane odbierane przy 200 Hz z powrotem do mojego cienkiego zbiornika 30 Hz?
2. Jak kontrolować to, co dzieje się przy 200 Hz, kiedy mogę tylko powiedzieć robotowi, co ma robić przy 30 Hz?

Pozycja 1 może być rozwiązana sprzętowo, jak wydaje się wskazywać twoje pierwotne pytanie - możesz ustawić w kolejce dane przy 200 Hz i wysłać pakiet przy 30 Hz do systemu wyższego poziomu. Możesz to zrobić za pomocą TCP / IP lub ewentualnie CAN w zależności od ilości danych, które chcesz wysłać. Inny sprzęt ma różne maksymalne szybkości przesyłania danych. Dodanie poziomu architektury, takiego jak ROS, aby działał jako most komunikacyjny / arbiter, jak sugerowano w innych postach, może również pomóc.

Punkt 2 to problem teorii sterowania , którego nie można rozwiązać za pomocą samego sprzętu. SLAM, określanie pozycji i prędkości oraz określanie zadań, które chcesz, będą musiały być mądrzejsze, ponieważ rzadziej wysyłają i odbierają informacje. Prawdopodobnie będziesz potrzebować 2 pętli sterowania : 1 przy 200 Hz i 1 przy 30 Hz.

Jest wiele innych pytań, które żywią do przodu okładka, zwrotnych i pętle regulacji PID, ale specjalnie poprosił o scaleability- drodze skala najbardziej gigantyczne systemów jest przez warstwy pętle sterowania i logiki, tak aby minimalna niezbędna informacja idzie w poprzek jakiegoś sprzętu skończysz z. Na przykład kontroler najwyższego poziomu może jedynie podawać punkty pozycji celu i średnią prędkość bramki do poziomu niższego, a nie zmieniać prędkości 30 razy na sekundę.