Comments 20
И третье, пожалуй, основное ограничение ROS1 — данная система не является real-time системой. Это в первую очередь проявляется в том, что скорость работы в сети различна, в зависимости от того, используется ли Ethernet или WI-FI.
А вот тут поподробнее пожалуйста, причем тут Ethernet или WI-FI? Вы таки хотите сказать что по uart данные не теряются? Абсолютно неочевидно, что всякий Ethernet быстрее всякого WI-FI.
А если все узлы на одной машине то ROS1 сразу становиться real-time ?
Что в свою очередь, приводит к задержкам в получении данных и их потере.
Каким образом? Там UDP что ли использован для передачи?
А TCP/IP в приципе не может быть real-time by design.
И какой real-time имеется ввиду ?
Real-time, который здесь упомянут лишь отчасти касается возможностей Wi-Fi, Ethernet.
Своими корнями он уходит в концепцию создания «реальной» real-time системы — ссылка.
Работа по ее созданию еще не завершена до конца, о чем в том числе говорят регулярные встречи Группы разработчиков по этому вопросу — здесь.
Первая ссылка (https://design.ros2.org/articles/realtime_background.html) которую вы дали это просто одно из определений системы реального времени (далеко не самое правильно кстати), и рекомендации по написанию программ в user-space, это к ROS отношение не имеет. ROS не являеться ОС — это фактически просто набор программ.
Вторая ссылка — извините не увидел ничего существенного.
Вторая ссылка — это «митинг» очередной встречи Группы, говорящий о том, что работа в данном направлении еще ведется.
Real-time это прежде всего ОС. Еще раз официальная цитата:
Support for real-time
ROS 1 does not support writing real-time code but relies on external frameworks like Orocos. In ROS 2 it will be possible to write real-time nodes when using a proper RTOS and with carefully written user code.
в данном направлении еще ведется
В каком "данном" — они собираються писать свою операционную систему ?
И заметьте я обошел вниманием фразы про "отчасти касается возможностей Wi-Fi, Ethernet". Потому что первый мой вопрос будет, "А что именно вы понимаете под этими терминами ?"
Под возможностями Wi-Fi, Ethernet понимается:
«Quality of Service: The overall performance of a network. Includes factors such as bandwith, throughput, availability, jitter, latency, and error rates.»
И нет. Я вообще то пошел вам навстречу — вы могли сказать "корова не моя" — ну ок.
В каком месте про ROS 1/2 поднимается вопрос в одном контексте real-time и Wifi, Ethernet?
Вас не смущает то что это физический уровень транспорта, а ROS как бы надстройка и использует возможности ОС ?
Сударь, мне очень понравились ваши статьи ваши статьи про ROS тележку и я очень благодарен за ваш вклад, но эта статья выглядить как marketing bullshit.
Откуда вы вообще взяли эту картинку?
Разбираем по полкам (http://design.ros2.org/articles/changes.html):
C++ standard
The core of ROS 1 is targeting C++03 and doesn’t make use of C++11 features in its API. ROS 2 uses C++11 extensively and uses some parts from C++14. In the future ROS 2 might start using C++17 as long as it is supported on all major platforms.
Официальная цитата. Ключевое major platforms — ну и собственно что? Свой узел я могу написать на любом стандарте, который позволяет мне компилятор — сейчас gcc 10.0, если что вышел, рабочий 9.4. Опять же компилятор вместе с ROS не ходит.
Support for real-time
ROS 1 does not support writing real-time code but relies on external frameworks like Orocos. In ROS 2 it will be possible to write real-time nodes when using a proper RTOS and with carefully written user code.
Сам по себе ROS никакой "real-time" дать не может, слова Windows 10!!! и real-time по крайней мере вызывают недоумение. Ключевые слова "proper RTOS" и "carefully written user code". Даже Linux является реалтайм системой со знаменитыми патчами (которые уже вроде полностью в ядре) только сферическим в вакууме, не говорю, что это вообще не возможно, но кланяюсь людям, которые действительно его сделали для целевых задач real-time.
Python packages
In ROS 1 a package with Python code can only use a small subset of the features available in setup.py files since the setup.py file is being processed by custom logic from within CMake. In ROS 2 a Python package can use anything in setup.py files, e.g. entry points since they are being invoked with python3 setup.py install.
Здесь пояснять не надо.
— реализуется уровень ROS архитектуры для работы с «железом» напрямую
Этот момент даже комментировать не хочется. Прерывания тоже в user-space будете обрабатывать?
В отличие от ROS1, cтек которого написан на C++, а клиентские библиотеки на C++ и Python, в ROS-2 используется язык C.
Это как понять? С++ больше не используется? Т. е. всю ос переписали на голых сях?
Но это все придирки. Меня больше беспокоит, что бравурность и пафос зашкаливают. Технические тексты так не пишут. А вот маркетинговый булшит — только так.
Это как понять? С++ больше не используется? Т. е. всю ос переписали на голых сях?
Нет, конечно. Слово «также» выпало. *Дополнено.
В чем бравурность и пафос вы заметили?
Статья же не про фундаментальное сравнение двух фреймворков, а позволяющая сделать следующий шаг вперед. Поэтому и инсталляция приведена, а не математические выкладки.
Или вы предлагается оставить ROS на том и так недосягаемом уровне, на котором она находится? ) Я пытаюсь снизить порог входа.
систему ROS2, подходящую для более «рукастых» разработчиков
Поподоробнее хотелось бы. Чем ROS2 лучше для «рукастых»? Я вижу только эволюцию проекта.
Про REAL-TIME соглашусь, всё таки real-time ОС это отдельное явления. А здесь я вижу framework. Как я понимаю, они хотят спортироваться на real-time ОС вроде vxWorks, qnx? Интересно стало, на свежую голову пожалуй перечитаю.
ROS2 vs ROS1.Установка ROS2 на Ubuntu 18.04