Zamierzam zbudować mały system robota i wygląda na to, że ROS stanowi niezłą platformę do sterowania i programowania systemu.

Zastanawiam się jednak, jaka jest najlepsza praktyka zarządzania komponentami mojego robota.

• Czy sensowne jest umieszczenie wszystkich czujników w jednym węźle?

• Czy powinienem umieszczać czujniki tego samego typu w jednym węźle, czy lepiej jest mieć jeden węzeł dla jednego czujnika?

• Czy dobrą praktyką jest posiadanie jakiegoś węzła obsługi, który pobiera dane z czujników i steruje odpowiednimi siłownikami, czy też węzły siłowników i węzły czujników powinny się komunikować bezpośrednio?

1. Zabezpieczone węzły czujników i węzły siłowników z obsługą

2. Węzły pojedynczego czujnika i siłownika z modułem obsługi

3. Bezpośrednia komunikacja

Wydaje mi się, że najlepiej jest mieć jakiś moduł obsługi, który obsługuje komunikację między czujnikami i siłownikami i ma jeden węzeł dla każdego elementu robota (jak na rysunku 2), ponieważ system jest w ten sposób luźno sprzężony i można łatwo rozszerzyć, ale chcę wiedzieć, jaka jest twoja opinia.

Bardzo krótka odpowiedź: 2

Czujniki

Jeśli chodzi o to, czy odczytujesz z czujników w jednym węźle czy osobno, powinieneś zadać sobie następujące pytanie:

Czy czujniki są bez znaczenia bez drugiego?

To pytanie dotyczy tego, czy czujniki są ściśle połączone, czy nie. Załóżmy na przykład, że masz czujnik wrażliwy na temperaturę (i musisz to skompensować). Czujnik temperatury dodaje się przede wszystkim w celu ustalenia wartości drugiego czujnika. W tym scenariuszu sensowne jest odczytywanie obu wartości jednocześnie, ponieważ są one ściśle powiązane. W rzeczywistości bez odczytów z czujnika temperatury odczyty z oryginalnego czujnika są bezużyteczne.

Z drugiej strony, jeśli czujniki są indywidualnie użyteczne, z całą pewnością trzymaj je w osobnych węzłach. Ma to wiele zalet:

• Węzły można uruchamiać na osobnych procesorach
• Węzły mogą być ponownie wykorzystane w przyszłych robotach
• Awaria komunikacji z jednym węzłem nie powoduje awarii całego systemu
• Ponowne uruchomienie akwizycji z uszkodzonej płyty czujników można wykonać oddzielnie od pozostałych

W rzeczywistości, jeśli potrzebujesz którejkolwiek z powyższych korzyści, musisz iść z osobnymi węzłami, nawet jeśli czujniki są ściśle połączone, ale zwykle tak się nie dzieje.

Siłowniki

To jest analogiczne.

Czy siłowniki są bez znaczenia bez drugiego?

Na przykład, jeśli projektujesz nadgarstek ze zautomatyzowanymi ścięgnami, w przypadku których dla każdego ścięgna (z dowolnego powodu) dwa silniki są odpowiedzialne za jednoczesną pracę w celu przesunięcia stawu w jednym lub drugim kierunku, wówczas ich obsługa w tym samym węźle znacznie więcej sens niż oddzielny.

Z drugiej strony, gdy siłowniki są niezależne (częsty przypadek), sensowne jest posiadanie jednego węzła dla każdego siłownika. W takim przypadku każdy może zostać umieszczony w innym węźle. Oprócz tych samych zalet, co w przypadku czujników, istnieje ta dodatkowa korzyść:

• Jeśli siłowniki są zablokowane (z jakiegokolwiek powodu), pozostałe siłowniki nadal działają. Jeśli istnieją zbędne stopnie swobody, mogą nawet całkowicie to zrekompensować.

Ma to jedną implikację. Jeśli potrzebujesz siłowników do harmonijnej pracy, umieść je w tym samym węźle. Nie dzieje się tak tylko z powodu awarii komunikacji, ale dlatego, że różne węzły oznaczają różne opóźnienia; w systemie rozproszonym każdy węzeł znajduje się w innej części sieci, stąd różnica w opóźnieniach, w systemie scentralizowanym różne opóźnienia występują przy dużych obciążeniach procesora ze względu na szczęście każdego procesu w planowaniu.

Czy powinien istnieć moduł obsługi?

Mimo że odpowiedź brzmi „to zależy”, istnieje wspólne podejście z wieloma zaletami. Zmieńmy nazwę i nazwijmy ją „kontrolerem”. Podejście brzmi „tak, powinien istnieć kontroler”.

Zalety posiadania kontrolera to (wśród wielu):

• Przetwarzanie oddzielone od produkcji: każdy węzeł odpowiada za jedną rzecz, co oznacza:
  • Prostota: co oznacza
    • Łatwiejszy rozwój
    • Łatwiejsze debugowanie
    • Mniej błędów
    • Mniejsza szansa na porażkę
  • Wielokrotnego użytku: ponieważ ten sam kontroler może być używany z różnymi węzłami czujników, jeśli mają one tę samą funkcjonalność (tj. Formaty komunikatów i usług).
• Wykonanie na osobnym sprzęcie: każdy węzeł można przenieść w sieci. Na przykład węzły czujnika i urządzenia wykonawczego można przenieść do dedykowanego mikrokontrolera ( na przykład Arduino (nie tego polecam)) i kontrolera na komputerze.
• Unikaj skrajnej brzydoty: jeśli czujniki chcą bezpośrednio wpływać na siłowniki, wynik jest po prostu bałaganem. Zakładając brak kontrolera, spójrzmy na każdy przypadek:
  • Jeden węzeł czujnika: zasadniczo oznacza to, że węzeł czujnika i sterownik są umieszczone w tym samym węźle. Nieźle, ale bardzo niepotrzebnie.
  • Wiele węzłów czujnikowych: to jest bałagan. Oznacza to, że sterownik jest rozdzielony między węzły czujników. Dlatego wszystkie węzły czujników muszą ze sobą rozmawiać, aby wiedzieć, jak kontrolować powiązane z nimi siłowniki. Wyobraź sobie niepowodzenie w komunikacji lub różnego rodzaju opóźnienia, a zobaczysz, jak trudne to staje się. Biorąc pod uwagę, że jest to całkowicie niepotrzebne, nie ma powodu, aby to robić!

To powiedziawszy, są też wady. Posiadanie większej liczby węzłów (dowolnych węzłów, nie tylko kontrolera) oznacza:

• Więcej marnotrawstwa komunikacji: dane muszą się przemieszczać w standardowych formatach (tak serializowane i bez szeregów) przez pamięć sieciową lub współdzieloną, rdzeń ROS musi na nie patrzeć i decydować, komu je dostarczyć itp. Krótko mówiąc, niektóre zasoby systemowe są marnowane w komunikacji. Gdyby wszystkie węzły były w jednym, koszt ten mógłby wynosić zero.
• Większa szansa na awarię: jeśli z jakiegokolwiek powodu łącze sieciowe ulegnie awarii lub węzeł umrze, oznacza to awarię systemu. Jeśli nie jesteś na to przygotowany, może to zniszczyć cały system. Teraz ogólnie rzecz biorąc dobrze jest stracić część systemu, ale nie całość ( płynna degradacja ), ale istnieją również aplikacje, w których należy tego unikać w jak największym stopniu. Przerwanie komunikacji i umieszczenie całego kodu w jednym węźle faktycznie pomaga w stabilności systemu. Wadą jest oczywiście to, że system albo działa dobrze, albo nagle całkowicie umiera.
• Chaotyczne czasy: każdy węzeł działa samodzielnie. Czas potrzebny na dotarcie wiadomości do innych jest niedeterministyczny i zmienia się w zależności od cyklu. Chyba że twoje węzły znaczą czasowo każdą wiadomość (na marginesie: musisz mieć zsynchronizowane zegary w dobrym stopniu, czego ROS nie robi) i chyba że każdy węzeł odbiorczy może wziąć pod uwagę opóźnienie i odpowiednio kontrolować (co jest bardzo trudnym zadaniem samodzielnie), a zatem posiadanie wielu węzłów oznacza dużą niepewność co do wieku danych. Jest to właściwie jeden z powodów (spośród wielu), że większość robotów porusza się tak wolno; ich pętla kontrolna musi być wystarczająco wolna, aby mieć pewność, że wszystkie dane odpowiadają bieżącemu okresowi. Im większe opóźnienia, tym wolniejsza pętla sterowania.

We wszystkich powyższych wadach rozwiązaniem jest zmniejszenie liczby węzłów, najlepiej do pojedynczego węzła. Chwileczkę, to już nie używa ROS! Dokładnie.

Podsumowując:

• Użyj ROS dla systemów nie działających w czasie rzeczywistym, w których opóźnienia mogą sporadycznie wzrosnąć. W takim przypadku możesz mieć dowolną liczbę węzłów ROS. W rzeczywistości bardzo dobrą praktyką jest, aby każdy węzeł ROS wykonywał jedną i tylko jedną rzecz. W ten sposób stają się bardzo proste i nadają się do wielokrotnego użytku.
• Z drugiej strony, w przypadku systemów czasu rzeczywistego, zdecydowanie należy unikać ROS. Do tego istnieją orocos i technologie, takie jak EtherCAT, a częściej rozwiązania ad-hoc.

Na koniec, w praktyce ROS ma się dobrze. Nie wspaniale, ale dobrze. Bardzo często system nie jest krytyczny, a prawdopodobieństwo awarii jest tak małe, że od czasu do czasu ponowne uruchomienie nie jest wielkim problemem. To jest algorytm strusia !