Wróciłem do komputera!
Jak powiedziałem w tym komentarzu , ROS zasadniczo nie jest obowiązkowy. ROS jest jedną z wielu platform, słynną głównie z tego, że Willow Garage rozdaje darmowe roboty każdemu, kto napisał najwięcej modułów ROS. To powiedziawszy, nie jest to najlepsza możliwa platforma, a na pewno nie jest niczym nadzwyczajnym. W szczególności wspomniany konkurs zaowocował wieloma modułami niskiej jakości, aby zwiększyć liczbę.
Z biegiem czasu jakość modułów ROS poprawiła się i jest ich również wiele. Korzystając z ROS, możesz ponownie wykorzystać wiele z tego, co już zrobiono. Możesz przeczytać tutaj kilka powodów, dla których możesz chcieć używać ROS.
Mając to na uwadze, należy również zwrócić uwagę na skutki uboczne.
Kontrola rozproszona
Dzięki ROS masz wiele węzłów, które rozmawiają ze sobą przez sieć. Czasami jest to dobre i łatwe, ale ogólnie powoduje bardzo różne opóźnienie w odbiorze wiadomości. W rezultacie musiałbyś mieć duże opóźnienie kontroli, aby upewnić się, że wszystkie wiadomości dotarły, co oznacza, że nie możesz szybko reagować na zdarzenia, co z kolei oznacza, że musisz poruszać robotem z mniejszą prędkością, aby nie przegapić tych zdarzeń.
Wierzcie lub nie, ludzie faktycznie kontrolują robota za pomocą ROS ( MoveIt! To nazwa odpowiedniego zestawu komponentów). Powolny. Niebezpieczny. Ale łatwo!
Nie w czasie rzeczywistym
Nawet jeśli nie jest dystrybuowany, ROS nie jest platformą czasu rzeczywistego. Oznacza to, że jądro Linuksa ma całkowitą swobodę planowania harmonogramu zadań w dowolnym momencie, kiedy uzna to za stosowne. Jest to odpowiednie dla niektórych aplikacji, ale dla innych nie. Musisz więc spojrzeć na własne wymagania. Czy potrzebujesz gwarancji, że Twoje zadanie zakończy się w znanym terminie? Jeśli tak, potrzebujesz systemu czasu rzeczywistego.
Hostowane środowisko wykonawcze
Inną kwestią do rozważenia jest to, że chociaż ROS jest ogólnym protokołem komunikacji, jest zasadniczo obsługiwany tylko w środowiskach hostowanych. Hostowany oznacza, że kod działa na jądrze, w przeciwieństwie do wolnostojącego, co oznacza, że kod bezpośrednio kontroluje sprzęt (np. Na mikrokontrolerze).
Jeśli twoja aplikacja robotyki działa blisko sprzętu, a zatem potrzebujesz programu działającego na mikrokontrolerze, ROS nie jest dla ciebie pomocny.
Blokada platformy
Wreszcie, opracowanie oprogramowania ROS powoduje zablokowanie platformy. Oznacza to, że jeśli w przyszłości, z tego czy innego powodu, zdecydujesz się oprzeć swoją pracę na innej platformie robotycznej, takiej jak OROCOS, YARP itp., Byłoby to dręczące.
Byłbyś także trochę zablokowany na Linuksie. Linux jest najlepszy, bez wątpienia, ale pewnego dnia może się okazać, że będziesz musiał obsługiwać inny system, taki jak QNX, VxWorks itp., I będziesz miał również problemy.
Jeśli piszesz dla mikrokontrolerów, zapomnij o ROS. Jeśli piszesz moduły wysokiego poziomu, zdecydowanie zalecam pisanie przenośnego kodu. Załóżmy na przykład, że opracowałeś nowy czujnik i chcesz napisać moduł, który pobiera dane z tego czujnika, który jest podłączony do komputera za pośrednictwem magistrali CAN.
W tej sytuacji możesz napisać niezależną bibliotekę z funkcjami, które będą w stanie współpracować z czujnikiem i zbierać dane. Można nawet pomyśleć o odrodzeniu wątku w bibliotece, który okresowo zbiera i kolejkuje dane.
Gdy masz już tę bibliotekę pomocniczą, możesz napisać CLI, GUI, moduł ROS, moduł OROCOS, moduł YARP, połączyć się z Matlabem lub cokolwiek innego, czego chcesz użyć do interakcji z czujnikiem.
Ostatnia uwaga: to, co tu powiedziałem, ogólnie dotyczy wszystkich platform robotyki, a nie tylko ROS.