Salem Robotics: софт превращает обычных роботов в инспекторов для опасных производств

> Мы используем ИИ там, где полезны семантическое понимание и гибкость, например, для интерпретации менее структурированной информации или понимания того, что в незнакомой сцене относится к процедуре. Как только система знает, какое физическое взаимодействие ей нужно выполнить, мы предпочитаем явную геометрию, планирование, оптимизацию и управление, где это возможно...

> Несколько сантиметров ошибки могут не иметь большого значения при движении по коридору, но это важно, если датчик должен оставаться перпендикулярным изогнутой поверхности.

Это отличный конкретный пример того, где творческий подход (читай: случайность) ИИ упирается в стену. Видите ли вы, что это изменится со временем по мере улучшения моделей, или вы ожидаете, что критически важные для безопасности / узкоспециализированные задачи всегда будут требовать более явного набора инструкций?

Всего наилучшего! Очень четкая постановка и определенно востребованная услуга. Помню, в 2011 году недалеко от Фукусимы после проблем с ядерными реакторами. Компания здесь столкнулась с очень сложными задачами инспекции, в том числе среди обломков. Были роботы, способные справиться с некоторыми проблемами, но не в Японии, и в любом случае им нужно было действовать быстро, поэтому отправили людей. По-видимому, это было достаточно безопасно, но способные роботы были бы гораздо безопаснее.

Технический вопрос: чтобы точно сканировать поверхность, я бы предпочел разместить переключатели на конечном эффекторе рядом с датчиком, чтобы рука позиционировалась примерно над сканируемой поверхностью, нажимала до срабатывания переключателей и сканировала, удерживая их включенными. Простое тактильное ощущение, в основном. Вся традиционная робототехника, которая плавно следует по многим плоским и изогнутым поверхностям. Я вовсе не против ИИ здесь; похоже, вся ветка — это конструктивный подход, сочетающий лучшие инструменты для конкретных целей. Нежизнеспособен ли ваш подход в ваших сценариях?

Мысли по вашим заключительным вопросам:

> где должна находиться граница абстракции в робототехнике. Что должно исходить от производителя робота, что относится к прикладному уровню, а что неизбежно останется специфичным для объекта?

Мне очень нравится, когда есть "двойной SDK": низкоуровневый для управления приводами и датчиками по отдельности (двигатель 2 ноги 4) и высокоуровневый с предопределенными сценариями (движение вперед, независимо от того, является ли бот двуногим, квадрокоптером или слизнем). Эти два типа API часто облегчают работу в приложениях...

Поздравляю с запуском. Я работаю в робототехнической отрасли уже десять лет и видел, что эта граница проходит в самых разных местах. Не уверен, что есть однозначный ответ.

Самореклама: я основатель Clipper, реестра контейнеров, который обеспечивает в 10 раз более быстрые загрузки и в 7 раз более быструю сборку по сравнению с DockerHub, ориентированного на робототехнику. Мне надоело, что развертывание робототехники занимает весь день, и я исправил это сам. Если вам это интересно или вы просто хотите поговорить о деле, давайте пообщаемся.

Поздравляю с запуском. "Успешное выполнение траектории не означает, что проверка прошла успешно" — отличная формулировка, замыкание цикла на самом измерении — это сложная часть.