Open-source в робототехнике: ROS как способ быстрее собирать прототипы
Как открытый стек снижает стоимость эксперимента и сокращает путь от идеи до работающего пилота.
Когда разговор заходит о роботизации на производстве или в логистике, обычно следует один из двух сценариев. Первый - берётся интегратор, покупается закрытая платформа, и через год компания обнаруживает, что любое изменение стоит как небольшой проект. Второй - задача откладывается до лучших времён, потому что "это слишком дорого и непонятно".
Между этими двумя вариантами есть третий, который в последние несколько лет становится всё более практичным. Его основа - открытый стек, и в частности Robot Operating System, то есть ROS.
Я не буду убеждать, что open-source - это идеология. Здесь я говорю о нём как об инструменте снижения стоимости первого эксперимента. Бизнес-обоснование роботизации - и почему правильный расчёт выходит за рамки сокращения ФОТ к предсказуемости потока - определяет, что именно нужно проверить в открытом стеке.
Что такое ROS и почему он появился
ROS - это не операционная система в привычном смысле. Это набор библиотек и инструментов, который задаёт общий язык для компонентов робота: датчики, актуаторы, алгоритмы навигации, камеры, манипуляторы. Изначально он возник в академической среде - в Стэнфорде и Willow Garage - как ответ на один конкретный вопрос: почему каждая исследовательская группа пишет одни и те же базовые вещи с нуля?
Принцип прост. Вместо монолита - граф узлов, которые общаются через стандартизированные сообщения. Это позволяет заменять один компонент, не трогая остальные. Алгоритм навигации можно поменять, не переписывая драйвер камеры.
К 2012 году вокруг ROS сложилось достаточно зрелое сообщество, пакетный репозиторий с сотнями готовых компонентов и практика использования на реальном оборудовании - не только в лабораториях.
Почему это важно для компании, которая думает о пилоте
Самый дорогой момент в любом роботизированном проекте - не серийное внедрение, а первый прототип. Именно на нём проверяется, работает ли идея вообще. Именно здесь чаще всего теряются деньги.
Открытый стек меняет экономику этого этапа по нескольким причинам.
Во-первых, готовые компоненты. Алгоритмы локализации и картографирования, драйверы для популярных лидаров и камер, стеки управления манипуляторами - всё это уже написано и используется другими командами. Можно не платить за разработку того, что существует.
Во-вторых, независимость от вендора на этапе эксперимента. Когда прототип собирается на открытом стеке, решение о выборе "железа" можно откладывать дольше. Это важно: часто именно ранняя фиксация на вендоре закрывает дешёвые альтернативы.
В-третьих, нанимаемость. Специалисты, которые умеют работать с ROS, есть на рынке. Это не экзотика.
Где граница применимости
Open-source в робототехнике - это не ответ на любой вопрос. Есть задачи, где он уместен, и есть задачи, где он создаёт больше проблем, чем решает.
Он хорошо работает там, где:
- нужно быстро проверить гипотезу или собрать демонстрационный стенд;
- команда имеет инженерный ресурс, чтобы поддерживать и развивать стек;
- требования к сертификации и надёжности не критичны на данном этапе.
Он плохо работает там, где:
- нет инженеров, готовых работать с открытым кодом;
- требования к промышленной надёжности и поддержке 24/7 возникают сразу;
- компания хочет купить решение и не хотеть думать о нём.
Переход от прототипа к серийному внедрению почти всегда требует другого разговора - о поддержке, о сертификации, о SLA. Но это разговор уже после того, как идея подтверждена.
Как думать о пилоте с открытым стеком
Прежде чем браться за прототип, я обычно задаю несколько вопросов:
- Что именно мы проверяем этим пилотом - техническую выполнимость или бизнес-ценность?
- Есть ли у нас инженер с опытом работы с ROS или мы рассчитываем на внешнего подрядчика?
- Какое "железо" уже есть или планируется - и насколько оно совместимо с открытым стеком?
- Каков реальный бюджет на эксперимент, и что будет считаться успехом?
- Если пилот успешен - кто будет владельцем системы дальше?
Эти вопросы не про технологию. Они про то, готова ли организация к типу работы, который предполагает открытый стек. Если ответ "не очень" - лучше это знать до, а не после того как потрачены деньги и время.