Napisałbym odpowiedź, ale piszę na telefonie. Zasadniczo ROS nie jest obowiązkowy. Moim osobistym zdaniem, w zależności od ROS jest nawet źle. Niezależnie od tego, jaki masz komponent, stwórz z niego bibliotekę przenośną, a następnie napisz moduł ROS, używając go. Gdy ROS umiera lub zmieniają się Twoje wymagania, z pewnością docenisz to.
Shahbaz
Odpowiedzi:
18
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.
Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
Mark Booth
2
„ROS” jest terminem względnym, APM uruchamia pełny niestandardowy kod specjalnie zaprojektowany do sterowania kwadrokopterem, w którym niestandardowy ROS może być pożądany, aby uniknąć awarii, z drugiej strony Navio + działa na jądrze Linux i uruchamia kod inny niż autopilot, i wciąż udaje się uniknąć awarii. Większość ROS-ów to tak naprawdę zestaw funkcji na istniejącym systemie operacyjnym, a nie pisanie systemu operacyjnego od podstaw. Jak wszystko, to zależy.
Mówi o RobotOperatingSystem, a nie RealtimeOperatingSystem ...
FooTheBar,
2
Oświadczenie: Ta odpowiedź jest w jakiś sposób reakcją na post Shahbaza, więc ma nastawienie pro-ROS.
Nie sądzę, że ROS jest obowiązkowy, ale jest to świetny punkt wyjścia i warto poświęcić czas na inwestowanie. Zaczęło się w Willow Garage, ale ta firma zniknęła, a ROS wciąż żyje, jest używany i rozwijany. Większość ROS jest w pełni open source, a także użyteczne komercyjnie, więc nie ma mowy, aby ROS zniknął, jeśli firma nie jest już nim zainteresowana. Jakość kodu oczywiście różni się między modułami podstawowymi a implementacjami najnowocześniejszych algorytmów, które doktorant opublikował w swoim artykule.
ROS nabiera coraz większej prędkości w środowisku przemysłowym (byłbym zaskoczony, jeśli na całym świecie jest znaczna część startupów robotyki, które nie używają ROS). Niektóre algorytmy będą dalej utrzymywane i rozwijane przez konsorcjum ros-industrial, a jeśli przyjrzysz się członkom, to dobrze, że ROS stanie się standardem w branży:
Rozproszony sposób korzystania z ROS bardzo pomaga w tworzeniu i utrzymywaniu nowych pakietów, szczególnie w zespołach. Definicje komunikatów i akcji bardzo pomagają w definiowaniu interfejsów, dzięki czemu można szybko wymieniać sprzęt i algorytmy. Pomaga także w integracji nowych członków zespołu, ponieważ nowy węzeł spowoduje zniszczenie innych węzłów, jeśli ulegnie awarii (o ile nie zje całej pamięci RAM ..), więc raczej bezpiecznie jest zintegrować częściowo działające węzły z działającym systemem jako ich efekt jest ograniczony. Komunikacja wykorzystuje protokół TCP, który jest niezawodny i szybki (na lokalnej maszynie), dzięki czemu przekazywanie wiadomości jest bardzo szybkie (możliwe jest kilkaset Hz dla pętli sterowania).
Nie w czasie rzeczywistym
ROS nie jest obecnie dostępny w czasie rzeczywistym, ponieważ ogromna większość algorytmów nie potrzebuje czasu rzeczywistego. W większości przypadków wykrywanie lub planowanie nie ma ograniczeń w czasie rzeczywistym (ile osób buduje samobieżne samochody dużych prędkości?). Wystarczy, że ostatnia pętla sterowania działa w czasie rzeczywistym, co w wielu przypadkach można wykonać bezpośrednio na silniku (do którego pozycja końcowa jest wysyłana np. Przez CAN). Czas rzeczywisty jest jednak jednym z głównych celów ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ), więc nawet jeśli będziesz tego potrzebować w przyszłości dla całego systemu, ROS Cię objął .
Jeśli naprawdę chcesz uruchomić rzeczy osadzone, istnieje oczywiście połączenie z arduino, dzięki czemu możesz pisać wiadomości ROS bezpośrednio na arduino, które następnie są wysyłane przez połączenie szeregowe.
Uruchamianie ROS w systemie Windows jest obecnie dość uciążliwe, ale ponieważ Windows zbliża się do Linuksa (nawet zaczyna mieć coś w stylu bash), to tylko kwestia czasu, aż będzie to możliwe. (Ale kto w ogóle chce uruchomić robota z oknami?)
Interfejsy sprzętowe i algorytmy:
Myślę, że to naprawdę mocna strona ROS. Wiele dostępnych w handlu robotów ma już interfejs ROS lub ktoś zainwestował już trochę czasu w implementację interfejsu. Większość komercyjnych broni może być użytych w MoveIt tak wiele pracy, aby aplikacja mogła działać z określonym ramieniem, może być ponownie wykorzystana z innym sprzętem.
Społeczność:
Kolejna mocna strona ROS. Nowe algorytmy bardzo szybko uzyskują interfejs ROS, a wiele osób miało takie same problemy jak Ty, więc znajdziesz kogoś, kto Ci pomoże.
Ostatnią rzeczą, którą chciałbym zobaczyć, jest spojrzenie wstecz za 20 lat, kiedy wszystko jest zbudowane wokół ROS i zdać sobie sprawę, że, potrzebujemy robotów do pracy z prędkością porównywalną do ludzi, ale nie możemy, bo 20 lat temu myśleliśmy ilu ludzi i tak buduje samobieżne samochody dużych prędkości ?
Shahbaz,
2
Myślę, że muszę poprzeć @Shahbaz w tej sprawie. Nie chodzi o to, że ROS nie ma swojego miejsca, ale o to, że nie powinieneś używać ROS zamiast dobrych praktyk kodowania. Tworzony protokół ROS powinien pochodzić z biblioteki interfejsów, a nie na odwrót.
Odpowiedzi:
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.
źródło
„ROS” jest terminem względnym, APM uruchamia pełny niestandardowy kod specjalnie zaprojektowany do sterowania kwadrokopterem, w którym niestandardowy ROS może być pożądany, aby uniknąć awarii, z drugiej strony Navio + działa na jądrze Linux i uruchamia kod inny niż autopilot, i wciąż udaje się uniknąć awarii. Większość ROS-ów to tak naprawdę zestaw funkcji na istniejącym systemie operacyjnym, a nie pisanie systemu operacyjnego od podstaw. Jak wszystko, to zależy.
źródło
Oświadczenie: Ta odpowiedź jest w jakiś sposób reakcją na post Shahbaza, więc ma nastawienie pro-ROS.
Nie sądzę, że ROS jest obowiązkowy, ale jest to świetny punkt wyjścia i warto poświęcić czas na inwestowanie. Zaczęło się w Willow Garage, ale ta firma zniknęła, a ROS wciąż żyje, jest używany i rozwijany. Większość ROS jest w pełni open source, a także użyteczne komercyjnie, więc nie ma mowy, aby ROS zniknął, jeśli firma nie jest już nim zainteresowana. Jakość kodu oczywiście różni się między modułami podstawowymi a implementacjami najnowocześniejszych algorytmów, które doktorant opublikował w swoim artykule.
ROS nabiera coraz większej prędkości w środowisku przemysłowym (byłbym zaskoczony, jeśli na całym świecie jest znaczna część startupów robotyki, które nie używają ROS). Niektóre algorytmy będą dalej utrzymywane i rozwijane przez konsorcjum ros-industrial, a jeśli przyjrzysz się członkom, to dobrze, że ROS stanie się standardem w branży:
http://rosindustrial.org/ric/current-members/
Rozproszony sposób korzystania z ROS bardzo pomaga w tworzeniu i utrzymywaniu nowych pakietów, szczególnie w zespołach. Definicje komunikatów i akcji bardzo pomagają w definiowaniu interfejsów, dzięki czemu można szybko wymieniać sprzęt i algorytmy. Pomaga także w integracji nowych członków zespołu, ponieważ nowy węzeł spowoduje zniszczenie innych węzłów, jeśli ulegnie awarii (o ile nie zje całej pamięci RAM ..), więc raczej bezpiecznie jest zintegrować częściowo działające węzły z działającym systemem jako ich efekt jest ograniczony. Komunikacja wykorzystuje protokół TCP, który jest niezawodny i szybki (na lokalnej maszynie), dzięki czemu przekazywanie wiadomości jest bardzo szybkie (możliwe jest kilkaset Hz dla pętli sterowania).
Nie w czasie rzeczywistym
ROS nie jest obecnie dostępny w czasie rzeczywistym, ponieważ ogromna większość algorytmów nie potrzebuje czasu rzeczywistego. W większości przypadków wykrywanie lub planowanie nie ma ograniczeń w czasie rzeczywistym (ile osób buduje samobieżne samochody dużych prędkości?). Wystarczy, że ostatnia pętla sterowania działa w czasie rzeczywistym, co w wielu przypadkach można wykonać bezpośrednio na silniku (do którego pozycja końcowa jest wysyłana np. Przez CAN). Czas rzeczywisty jest jednak jednym z głównych celów ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ), więc nawet jeśli będziesz tego potrzebować w przyszłości dla całego systemu, ROS Cię objął .
Jeśli naprawdę chcesz uruchomić rzeczy osadzone, istnieje oczywiście połączenie z arduino, dzięki czemu możesz pisać wiadomości ROS bezpośrednio na arduino, które następnie są wysyłane przez połączenie szeregowe.
Uruchamianie ROS w systemie Windows jest obecnie dość uciążliwe, ale ponieważ Windows zbliża się do Linuksa (nawet zaczyna mieć coś w stylu bash), to tylko kwestia czasu, aż będzie to możliwe. (Ale kto w ogóle chce uruchomić robota z oknami?)
Interfejsy sprzętowe i algorytmy:
Myślę, że to naprawdę mocna strona ROS. Wiele dostępnych w handlu robotów ma już interfejs ROS lub ktoś zainwestował już trochę czasu w implementację interfejsu. Większość komercyjnych broni może być użytych w MoveIt tak wiele pracy, aby aplikacja mogła działać z określonym ramieniem, może być ponownie wykorzystana z innym sprzętem.
Społeczność:
Kolejna mocna strona ROS. Nowe algorytmy bardzo szybko uzyskują interfejs ROS, a wiele osób miało takie same problemy jak Ty, więc znajdziesz kogoś, kto Ci pomoże.
http://download.ros.org/downloads/metrics/metrics-report-2016-07.pdf
źródło