На выставке Robotics-Expo, состоявшейся в ноябре 2014 года в Москве, внимание нашей редакции привлек стенд проекта Robot Control Technologies, Метаязык для роботов. Этот проект был создан в прошлом году и развивается в рамках деятельности компании «Телеком Актив», г.Пермь. Руководитель проекта — Михаил Тюлькин, кандидат технических наук. Узнать подробности об этой разработке на выставке нам не удалось, поэтому мы решили пообщаться с Михаилом в более спокойной обстановке.
Robogeek.ru: Михаил, здравствуйте! Ваш проект метаязыка вырос из идеи создания робота, который может собрать себя сам. Как возникла эта идея, для чего?
Михаил Тюлькин: Добрый день. Эта идея возникла из размышлений о практических задачах, которые должны решаться в условиях агрессивной для человека среды, например, в Арктике или в Антарктике, или в космосе. Соответственно, такие задачи трудно и очень дорого решаемы, поскольку требуется обеспечение условий для человека. Однако если человеку в решении таких задач задействовать роботов, то это бы существенно удешевило их решение.
Но если роботы должны работать над нетривиальными задачами без человека, то такие роботы должны быть довольно-таки самостоятельными и интеллектуальными. При этом, независимо от решаемой задачи, первая универсальная подзадача, которая встанет перед роботами - это собственная модернизация, починка и сервисное обслуживание, поэтому мы, так или иначе, переходим к задаче автоматизированной сборки. Робот должен уметь собрать себя или собрать своего «собрата».
Если думать о решении этой задачи, например, в Антарктике, то сначала большой теплоход или самолёт забрасывает туда роботов-сборщиков с необходимым запасом деталей, и уже там они собирают каких-то роботов под необходимую деятельность, и эти собранные роботы идут работать. Предположим, задача решается: рабочие роботы выкопали яму, теперь надо туда, допустим, закладывать трубу - роботы сборщики «пересобирают» роботов-рабочих в других роботов, имеющих иной функционал. Далее, если доводить эту задачу до более абстрактного уровня, у нас должен получиться робот, который может сам собирать конструкции, в идеале - сколь угодно сложные.
Если фантазировать на тему будущего, то в последующем эти роботы были бы очень интересны при освоении и исследовании космоса. Предположим, робот высадился на астероиде, переработал там все полезные ископаемые и построил ещё одного такого же робота, как он сам. Часть полезных ископаемых отправлена на Землю, часть полезных ископаемых переработана в нового робота, который полетел к следующему астероиду – чтобы таким образом они в автоматическом режиме исследовали космос, и армия исследователей постоянно пополнялась, причем на передовой границе исследования, а не на Земле. Не надо строить спутник, которому предстоит лететь от Земли до далёкого астероида, лучше действовать пошагово: от очередного исследованного астероида к следующему летит спутник, который строится прямо там, на астероиде, потом следующий спутник к другому астероиду, там строит новый спутник, который полетит к третьему астероиду, и так далее, чтобы освоить Вселенную дальше. (Прим.: Разработкой идеи самовоспроизводящегося автомата ещё в тридцатые годы прошлого века занимались американские математики Джон фон Нейман и Станислав Улам).
Robogeek.ru: Почему в итоге все переросло в проект по созданию языка для программирования роботов?
М.Т.: Когда мы начали размышлять о проекте робота, который собирает сам себя, мы обнаружили, что необходимо решить как минимум две задачи. Первая задача — это непосредственно сборка, когда робот берёт деталь, он знает, что это за деталь, где она должна быть, и крепит эту деталь в нужное место. Вторая задача - это распознавание, когда робот должен взять деталь из кучи и понять, что это за деталь, нужна она ему или нет, участвует она в сборке или не участвует.
Но какой бы ни был робот, для решения задачи сборки нужно понять: как объяснить роботу, что и в какой последовательности собирать? То есть, однозначно, нужно какое-то средство коммуникации между роботом и человеком - язык. Вначале мы думали, что это может быть не язык, а какой-то конфигурационный файл, в декларативном стиле описывающий, как крепить детали. Потом выяснили, что должна быть и какая-то реакция робота на ошибки при сборке и проверка качества сборки, то есть команды, действия и условия их выполнения, а, значит, это должен быть полноценный язык, причем язык программирования, потому что задать возможность управления в декларативном стиле затруднительно.
В процессе создания языка возникло разделение на язык управления (Robot Control Meta Language) и язык сборки (Robot Build Language): все управляющие конструкции вошли в язык управления, имеющий императивный стиль, который оформляется в виде приказов, а язык сборки всё-таки остался декларативным, больше похожим не на язык, а на некоторое описание требуемой конструкции. Между этими языками есть взаимосвязь: описание собираемой конструкции транслируется в набор команд, которые необходимо выполнить роботу, чтобы в итоге собрать требуемую конструкцию.
Создание двух языков помогло нам упростить деятельность в дальнейшем. Потому что когда мы описываем конструкцию, нам не нужно знать, какой робот её собирает, нам не нужно знать, как его программировать (это, например, полезно для проектировщиков — им не надо вникать в детали роботов, которые будут собирать конструкцию по их проекту). А в языке управления уже прописываются реакции на различные типы исключительных ситуаций, ошибок.
Например, у нас есть роботы какой-то одной модели, и конструкция космического корабля. Они собирают корабль по такому-то набору команд за такое-то время. Потом вышли роботы новой модели, более быстрые, собирающие корабль за меньшее время, набор команд, понятных роботам, тоже поменялся вместе с ними, а конструкция-то, которую надо собрать, осталась та же самая. Поэтому мы конструкцию описываем на одном языке (Robot Build Language), и это описание не меняется во времени, а инструкции по сборке на другом языке. То есть, "железяки" меняются, "железяки" улучшаются, получают новые команды и возможности, а конструкция остаётся такой же. Или наоборот - конструкция меняется и улучшается, но благодаря языку управления (Robot Control Meta Language) это не приводит к тому, что приходится править код, относящийся к роботам.
Robogeek.ru:В чем суть Вашей разработки, говоря простым языком?
М.Т.:Начнём издалека. Можно сказать, что сейчас тенденция такова, что алгоритмическая и программная часть робототехники отделяется от аппаратной составляющей робота. Это вполне логично. Некоторые алгоритмы, например, поиск пути или анализ роботом окружающего пространства, будут общими для всех роботов или, по крайней мере, для широкого класса роботов. То есть, они универсальны и не должны зависеть от аппаратной реализации робота. Это исключает дублирование работы, связанной с реализацией одного и того же алгоритма для разных роботов.
Что касается нас, то в нашей разработке мы преследуем две цели. Первая - это независимость результата от исполняющего механизма. Вторая - снижение барьера между программистом, который разрабатывает алгоритмы и программы, и робототехником, который занимается «железной», аппаратной частью, чтобы любой программист, зная одно лишь средство программирования, мог без проблем программировать действия любого робота, поддерживающего это средство программирования. И чтобы программисту не приходилось изучать все нюансы каждого робота в отдельности. Это повышает эффективность труда программиста, снижает его нагрузку и снижает, в том числе, порог входа программистов в такую сферу деятельности как программирование робототехники.
Robogeek.ru:Где ваш язык может быть востребован?
М.Т.: Если говорить об общих задачах, то есть мнение, что в секторе крупного бизнеса и промышленности рынок робототехники имеет четко определенные зоны и малые темпы роста, а в секторах же малого и среднего бизнеса есть новые направления роста для роботизации. Однако, у среднего и малого бизнеса немного иной характер задач, это задачи, которые довольно быстро и часто меняются. Поскольку у среднего и малого бизнеса малые партии, то такой бизнес должен более быстро реагировать на изменения, и нужно какое-то универсальное средство, чтобы быстро перепрограммировать имеющихся у небольшого предприятия роботов под изменяющиеся задачи. Либо средство, которое бы позволяло быстро заменять роботов на более эффективных, но при этом бы не приходилось править программу, описывающую технологический процесс. То есть программа от старого робота применялась бы и к новому роботу.
И ещё - из диалогов с робототехниками и представителями промышленных производителей роботов на выставке мы поняли, что сейчас задачи по робототехнике смещаются в интеллектуальную сферу: уже научились делать точные манипуляторы, двигатели с микронной точностью, то есть аппаратные вопросы решены, исчерпаны, однако, есть громадный пласт интеллектуальных задач, которые надо решать. Это задачи положения и передвижения в пространстве, задачи сборки, задачи распознавания. Получается, что сейчас идёт сдвиг в роботехнической сфере от задач аппаратных в задачи, которые от «железок» не зависят, в такие задачи, которые должны быть применимы ко всем «железкам». И в таком ракурсе наш язык выглядит как универсальный «клей» между роботами и решениями интеллектуальных, дорогих и сложных задач. Сейчас рынок и соответственно деньги смещаются в интеллектуальную сферу, и необходимо какое-то средство связи интеллектуальной сферы и аппаратной.
Если говорить именно про нашу разработку, а не в целом про идею унификации и универсализации алгоритмов, потому что эта же идея прослеживается, например, у таких разработок как ROS или URBI. Так вот, если говорить конкретно о нашем языке, он применим и востребован в тех задачах, где нужна кооперация роботов, потому что на нём можно описывать, как один робот должен реагировать на действия другого робота, причем даже в том случае, если роботы на аппаратном уровне не предусматривают связи друг с другом. Второй класс задач - это универсальность выбора робота для решения очередной задачи. Можно сделать так, чтобы роботы разных моделей, но похожие по функционалу, одинаково решали одну и ту же задачу.
Раз наш язык не зависит от робота, он может быть ещё востребован различными научными организациями, инжиниринговыми компаниями, которые разрабатывают именно прикладные программы для роботов, то есть описывают, как робот должен реализовывать тот или иной технологический процесс. Описывая это на одном языке, они автоматом распространяют свою программу на целый ряд роботов.
Robogeek.ru: Есть ли уже какие-то примеры использования Вашей разработки — на производствах, в организациях, занимающихся робототехникой, в других компаниях?
М.Т.: Разработка находится на лабораторном уровне, но наш контакт с промышленностью уже произошёл. С компанией KUKA (немецкая компания, крупнейший в Европе производитель промышленных роботов), которая решила нас поддержать, дала обратную связь нашей разработке, оценку, мы сделали совместный стенд на выставке Robotics Expo в Москве в ноябре прошлого года. Это первая компания, чьи промышленные роботы работали под управлением наших систем.Если говорить более узко, на лабораторном уровне, где наш язык уже апробирован, то наши лабораторные манипуляторы и прочие лабораторные роботы имеют самую разную управляющую электронику от любительской до профессиональной.
Robogeek.ru: Есть ли подобные разработки в России и в мире?
М.Т.:Дело в том, что наш язык может быть по отношению к роботу на двух уровнях - как управляющий конкретным роботом, так и управляющий группой роботов. Если мы говорим об уровне робота то тут, естественно, самым крупным аналогом, преследующим ту же идею: универсальность и независимость алгоритмической программы от аппаратной составляющей - является операционная система ROS, которую я уже упомянул. Тут же рядом находится так же выше упомянутая система URBI, она тоже позиционируется как средство по управлению роботом.
Далее, если говорить про подобные разработки на другом уровне - взаимодействия группы роботов, то в данном случае конкурентов назвать очень трудно, можно только назвать общие направления или поля деятельности, которые могут конкурировать с нами. Это промышленное производство роботов, производство роботов полного цикла, как таковое. То есть, у каждого производителя роботов, так или иначе, есть какое-то своё решение по координации своих роботов, которых он производит, но не решение по интеграции между собой роботов разных производителей.
Другой конкурент именно в отношении языка управления роботами - это Институт технологий в Цюрихе, они занимаются задачами, близкими к сборке конструкций, но только в области архитектуры и промышленного дизайна зданий. Они не позиционируют себя как управляющая система для группы роботов. С другой стороны, они близки к нам, поскольку тоже разрабатывают язык, описывающий собираемую конструкцию, только в сфере архитектуры. Есть ещё ряд локальных разработок, но по ним почти нет информации.
Наше преимущество в том, что, поскольку наша система управления располагается «снаружи», а не внутри роботов, то она может заставить взаимодействовать даже тех роботов, которые не способны вообще совместно что-то делать на аппаратном уровне, разумеется, с учётом некоторых их конструкторских ограничений. Например, если двигатели у какой-то радиоуправляемой тележки не имеют высокой точности, то заставить её двигаться по одинаковой траектории с высокоточным промышленным роботом сложно, но подать команду на начало их одновременного движения с помощью программного обеспечения, написанного на нашем языке, возможно.
Robogeek.ru: Почему Вы делаете язык бесплатным — ведь это огромная работа?
М.Т.: Во-первых, с идеей координации роботов, возможно, мы даже немного опережаем время, поскольку есть сообщества для создания общих алгоритмов для робота, но для групп роботов пока нет. Мы хотим создать новую сферу деятельности. Мы выпускаем не отдельный продукт, а создаём платформу для ведения бизнеса, создаём целое направление в бизнесе, это более масштабно, чем выпуск отдельного продукта. В любом случае, наше конкурентное преимущество в том, что мы придумали разработку и у нас больше наработок в этой сфере. Мы делаем открытым язык, а в последующем и, возможно, код его компилятора, но, по крайней мере на первое время, управление разработкой оставляем за собой, чтобы иметь возможность влияния на формирование нового поля деятельности в робототехнике.
Во-вторых, наличие бесплатного и открытого инструмента создает предпосылки для роста рынка в этой сфере и снижает порог входа сюда. Увеличение объемов и разнообразия рынка приведет к увеличению денежных масс в данной сфере, в которой мы надеемся быть наиболее компетентны.
В-третьих, сам язык запатентовать нельзя, мы не можем наложить авторские ограничения на набор символов, обозначающий ту или иную команду. Мы можем только обозначить авторство. Синтаксические правила должны быть доступными, чтобы их можно было использовать и писать на них программы, поэтому язык бесплатный и открытый. С другой стороны, если мы будем делать язык закрытым и ограничивать вход в эту область, то для её роста нам потребуется привлекать намного больше сил и ресурсов. Закрытая разработка более рискованна, может быть, даже близка к провалу, а открытые системы лучше выживают, поскольку могут развиваться совместными усилиями.
Robogeek.ru: Михаил, я благодарю Вас за очень интересные, развернутые ответы. И от лица всей редакции желаю успеха и дальнейшего развития Вашей разработке.
Комментарии
(0) Добавить комментарий