Комментарии 13
Нужно, чтобы робототехника приходила на выручку медицине. К примеру, до сих пор биопсия миокарда проводится с помощью биоптома человеческой рукой. И точность под вопросом, отсюда осложнения. А с другой стороны мне непонятно, как у робота можно гарантировать точность? Как в алгоритм заложить толщину вены, изгибы и т.д.? Хотелось бы подробностей разработки ПО, например, для роботов медицинского назначения.
Отвечает Виталий:
Вы очень верно указали на «больное место» не только медицины, но и робототехники в целом — контактные операции требуют высокоточной обратной связи. Тем более когда речь идет о неполноприводных системах, аналогичных системе рука-катетер, которые пытаются провести контактную операцию на достаточно резко и часто сокращающейся мышце.
Давайте попробуем понять, что нам обеспечит успех в проведении (я верно согласовал термин? — Виталий) биопсии. Да ровно то же, что и у человека!
При такой требуемой точности _относительного_ позиционирования, воздействия в определенном интервале силы и направления нажатия, важно все — и «измерительные приборы» (человеческие глаза и осязание), и «управляющий алгоритм», который следит за измерением и подстраивается под перемену внешних условий (попал-не попал, проколол вену или не дожал).
То есть для успешного построения робота с таким «умением», по сути, нужно пытаться интегрировать измерительные приборы и ставить много экспериментов, а в основе успеха должна быть достаточно глубоко продуманная модель системы. И «математика» должна учитывать отклонения параметров системы от «идеальных» (или допустимых) в реальном времени.
(Не будучи ученым, надеюсь, изложил, не очень греша против истины.)
Вы очень верно указали на «больное место» не только медицины, но и робототехники в целом — контактные операции требуют высокоточной обратной связи. Тем более когда речь идет о неполноприводных системах, аналогичных системе рука-катетер, которые пытаются провести контактную операцию на достаточно резко и часто сокращающейся мышце.
Давайте попробуем понять, что нам обеспечит успех в проведении (я верно согласовал термин? — Виталий) биопсии. Да ровно то же, что и у человека!
При такой требуемой точности _относительного_ позиционирования, воздействия в определенном интервале силы и направления нажатия, важно все — и «измерительные приборы» (человеческие глаза и осязание), и «управляющий алгоритм», который следит за измерением и подстраивается под перемену внешних условий (попал-не попал, проколол вену или не дожал).
То есть для успешного построения робота с таким «умением», по сути, нужно пытаться интегрировать измерительные приборы и ставить много экспериментов, а в основе успеха должна быть достаточно глубоко продуманная модель системы. И «математика» должна учитывать отклонения параметров системы от «идеальных» (или допустимых) в реальном времени.
(Не будучи ученым, надеюсь, изложил, не очень греша против истины.)
Очень хотелось бы послушать/ почитать про то, как выстраивать коммерческую часть в случае, когда имеем дело с коллаборацией, ведь есть какие-то доли участия, как продвигаться, как продавать и делить заработанное? Коллаборация, она не только в железе+софте, она есть и в чистом софтвере. И был опыт, что два софтверщика просто не поделили доход и управление. Классный проект с машинным обучением слился.
А могли бы Вы уточнить, что в данном контексте означает «слиться»? Вопросы корпоративного управления у нас на ISDEF, конечно, обсуждаются. В целом, разделение дохода и полномочий/обязанностей нужно излагать на бумаге до старта бизнеса.
На рынке интеграторском (именно так себя видит большинство компаний-разработчиков и поставщиков кастомизированных решений под конкретные задачи) принято работать в консорциумах просто потому, что задач — море, и в одиночку их «не съесть» даже гигантам (у тех не хватает ноу-хау и умения «вкурить» конкретную задачу), а «малышам» не хватает денег на собственные лаборатории и/или закупку дорогого оборудования для воспроизведения в эксперименте своих предсказаний, как должны работать их алгоритмы. Хотя большинство предсказаний оборачиваются совсем новыми выводами о свойствах реальных систем :)
На рынке интеграторском (именно так себя видит большинство компаний-разработчиков и поставщиков кастомизированных решений под конкретные задачи) принято работать в консорциумах просто потому, что задач — море, и в одиночку их «не съесть» даже гигантам (у тех не хватает ноу-хау и умения «вкурить» конкретную задачу), а «малышам» не хватает денег на собственные лаборатории и/или закупку дорогого оборудования для воспроизведения в эксперименте своих предсказаний, как должны работать их алгоритмы. Хотя большинство предсказаний оборачиваются совсем новыми выводами о свойствах реальных систем :)
Спасибо за ответ! Слиться в моей истории — развалить совместный проект. Сейчас обе компании в стагнации: одна никак не может выйти на рынок с КИС, другая ушла в очередной этап доработки продукта и вообще не монетизирует его, живет за счет второго «дела». А дружили бы они, сейчас бы появился новый уровень лидогенерации с сайтов)
Вообще, мне кажется, при коллаборации риск растет — когда замешаны несколько компаний, нужно договариваться. А то будут лебедь, рак и щука… и особенно важно понимать, чего стоит и как происходит выход из коллаборации. Как оно вообще будет, если одного из участников совместного проекта перекупят или увлекут на более выгодное сотрудничество?
Вообще, мне кажется, при коллаборации риск растет — когда замешаны несколько компаний, нужно договариваться. А то будут лебедь, рак и щука… и особенно важно понимать, чего стоит и как происходит выход из коллаборации. Как оно вообще будет, если одного из участников совместного проекта перекупят или увлекут на более выгодное сотрудничество?
Кстати, в голову пришло, что Google и Boston Dynamics, несмотря на общих акционеров (Alphabet), исповедуют разные подходы к робототехнике. То самое «машинное обучение» побеждает в мире изображений, где «нет места» для других сенсоров, в отличие от медицины и промышленности.
Google — за Q-learning (в частности, машинного обучения на базе распознавания изображений с огромной базой картинок) — ОЧЕНЬ грубо говоря, показывая роботу картинки и командуя «делай, как на картинке» — и рассчитывает, что за счет записи многих координат робот, например, пойдет или сможет, к примеру, схватить что-то упругое. Но сможет ли при таком подходе робот от Google схватить кусочек тающего льда? Мы не знаем. Нам показывают только плод «глубокого» машинного обучения.
В то же время Boston Dynamics делает все в эксперименте, как «правильные» робототехники, основываясь на решении модельных задач в условиях реального мира с задачами интеграции многих сенсоров и постоянного совершенствования механизмов управления по обратной связи…
В этом отношении мои убеждения и симпатии — скорее на стороне «более физичных» BD, благо основатели Robotikum выпустили аспиранта, занимавшегося в том числе и BigDog.
Google — за Q-learning (в частности, машинного обучения на базе распознавания изображений с огромной базой картинок) — ОЧЕНЬ грубо говоря, показывая роботу картинки и командуя «делай, как на картинке» — и рассчитывает, что за счет записи многих координат робот, например, пойдет или сможет, к примеру, схватить что-то упругое. Но сможет ли при таком подходе робот от Google схватить кусочек тающего льда? Мы не знаем. Нам показывают только плод «глубокого» машинного обучения.
В то же время Boston Dynamics делает все в эксперименте, как «правильные» робототехники, основываясь на решении модельных задач в условиях реального мира с задачами интеграции многих сенсоров и постоянного совершенствования механизмов управления по обратной связи…
В этом отношении мои убеждения и симпатии — скорее на стороне «более физичных» BD, благо основатели Robotikum выпустили аспиранта, занимавшегося в том числе и BigDog.
В статье, да и комментариях несколько раз встречаются слова «моделирование», «физические системы», «обратная связь», «модель», «алгоритмы». Все это в принципе относится к созданию систем управления реального времени. Робототехника — это частный вариант применения таких систем. В принципе подход к созданию системы автоматической посадки первой ступени Falcon 9 и какого нибудь квадрокоптера одинаков.
Проблема в том, что недостаточно быть хорошим ай-тишником, чтобы решать задачи по созданию софта для таких систем. Для этого нужно хорошо знать теорию управления, автоматы, быть хорошим математиком… Эта проблема создает первый порог вхождения в этот бизнес — наличие специалистов такого профиля. Их реально мало, за ними гоняются компании.
Второй порог заключается в средствах разработки. Средства моделирования и автоматической генерации кода, да еще и для ПЛИС, стоят дорого, но позволяют добиться работающего в железе алгоритма за гораздо меньшее время, чем при классическом способе разработки. В этом случае выигрывают большие компании, у которых есть деньги на покупку данного ПО и как ни странно, мелкие восточно-европейские и китайские компании, которые просто пользуются пиратскими версиями.
Проблема в том, что недостаточно быть хорошим ай-тишником, чтобы решать задачи по созданию софта для таких систем. Для этого нужно хорошо знать теорию управления, автоматы, быть хорошим математиком… Эта проблема создает первый порог вхождения в этот бизнес — наличие специалистов такого профиля. Их реально мало, за ними гоняются компании.
Второй порог заключается в средствах разработки. Средства моделирования и автоматической генерации кода, да еще и для ПЛИС, стоят дорого, но позволяют добиться работающего в железе алгоритма за гораздо меньшее время, чем при классическом способе разработки. В этом случае выигрывают большие компании, у которых есть деньги на покупку данного ПО и как ни странно, мелкие восточно-европейские и китайские компании, которые просто пользуются пиратскими версиями.
Вы все очень верно описали. Специалистов в теории управления, а равно и в прикладной механике, не становится экспоненциально больше (а потребность растет примерно так). Да и математики сейчас склонны основывать свои компании… Наш случай :) Правда, мы еще и строим экосистему специалистов в теории управления — ведь недостаточно иметь работающий алгоритм, нужно «засеять» его приложениями как минимум исследовательскую сферу, поставив ей ряд амбициозных задач, чтобы рост был и количественный (в числе готовых специалистов-исследователей), и качественный (в их желании развиваться).
Наличие костяка ученых, совершающих трансфер технологии в реальные задачи, в микровендорах ПО — это тренд робототехнического бизнеса, мы на крупнейшей мировой выставке по промышленной автоматизации и мехатронике www.automatica-munich.com встретили таких микровендоров не меньше 7-8 (в основном, Германия, Канада, Голландия).
Ядро тех, кто в научных целях разработал собственные алгоритмы автоматического управления (движением — по обратной связи, как наш) и/или нашел их приложения в реальном мире, в бизнесе позволяет привлекать уже инженеров разных профилей, дообучать их работе на компонентах реальных промышленных роботов. Если погуглите Robotikum, мы делаем примерно это: и дообучаем продвинутых робототехников через поставку образовательного «железа» уровня hi-end с готовым курсом, и разрабатываем конечные продукты — робототехнические ячейки для решения задач промышленников.
У больших компаний, как я все же подчеркну еще раз, есть потолок роста применений собственных разработок без подключения новых игроков. Я не зря написал, что разработчикам на стороне клиента (промышленным предприятиям) приходится «вскрывать мозги» серийных роботов-манипуляторов, получив прямой доступ к API/SDK или даже source code от производителя (greyhat хакерство тоже не исключено, есть примеры). Таких примеров знаю уже 10-ки. На российских выставках в этом по секрету признаются заводские робототехники («да, вскрыли сами»). На международных — на совместных стендах производители «железа» и motion planning software показывают итог «белой» интеграции.
Наличие костяка ученых, совершающих трансфер технологии в реальные задачи, в микровендорах ПО — это тренд робототехнического бизнеса, мы на крупнейшей мировой выставке по промышленной автоматизации и мехатронике www.automatica-munich.com встретили таких микровендоров не меньше 7-8 (в основном, Германия, Канада, Голландия).
Ядро тех, кто в научных целях разработал собственные алгоритмы автоматического управления (движением — по обратной связи, как наш) и/или нашел их приложения в реальном мире, в бизнесе позволяет привлекать уже инженеров разных профилей, дообучать их работе на компонентах реальных промышленных роботов. Если погуглите Robotikum, мы делаем примерно это: и дообучаем продвинутых робототехников через поставку образовательного «железа» уровня hi-end с готовым курсом, и разрабатываем конечные продукты — робототехнические ячейки для решения задач промышленников.
У больших компаний, как я все же подчеркну еще раз, есть потолок роста применений собственных разработок без подключения новых игроков. Я не зря написал, что разработчикам на стороне клиента (промышленным предприятиям) приходится «вскрывать мозги» серийных роботов-манипуляторов, получив прямой доступ к API/SDK или даже source code от производителя (greyhat хакерство тоже не исключено, есть примеры). Таких примеров знаю уже 10-ки. На российских выставках в этом по секрету признаются заводские робототехники («да, вскрыли сами»). На международных — на совместных стендах производители «железа» и motion planning software показывают итог «белой» интеграции.
Это конечно интересно, но в чем смысл «вскрывать мозги», если для создания сколько-нибудь продвинутого алгоритма управления в первую очередь нужна модель физической системы, которой нужно управлять? На основе этой модели и создается нужный контроллер управления роботом. С ней же он и отлаживается и настраивается. Далее из контроллера генерируется код, который и загружается в робота и который вы вскрыли.
Но прикол в том, что модель физической системы вы таким образом не получите — она осталась на фирме. А без нее модифицировать полученный управляющий код или сделать на его основе новый можно только путем слепого тыканья. Хорошо еще, если полученный контроллерный код имеет читаемую структуру, из которой понятно, как он работает, но обфускация в этом сегменте сейчас тоже шагает семимильными шагами.
С промышленными роботами, разработанными по классической схеме это еще может и пройдет, но с современными на основе моделей — нет
Но прикол в том, что модель физической системы вы таким образом не получите — она осталась на фирме. А без нее модифицировать полученный управляющий код или сделать на его основе новый можно только путем слепого тыканья. Хорошо еще, если полученный контроллерный код имеет читаемую структуру, из которой понятно, как он работает, но обфускация в этом сегменте сейчас тоже шагает семимильными шагами.
С промышленными роботами, разработанными по классической схеме это еще может и пройдет, но с современными на основе моделей — нет
Если могу еще чем-то поделиться, пишите! И встретимся на www.gotech.vc — там ISDEF дает доклады на «гостевой» часовой секции.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Виталий Янко (ISDEF): Поздно ли соваться на рынок разработки софта для робототехники?