Допустим, вы решили заняться беспилотными технологиями в стартапе или RnD подразделении при университете. У вас за плечами мобильный робот на условном Arduino. И вот появился заказчик, который хочет автоматизировать свои процессы и даже готов за это заплатить. Вам нужно взять некую технику, обвешать датчиками и приводами, добавить вычислитель и научить автономно двигаться, попутно решая проблему заказчика. У вас всё серьёзно: у проекта есть руководитель, электроникой занимаются электронщики, механикой - конструктора, есть специализация у программистов (системы восприятия, навигации, планирования и т.п.). Казалось бы, что может пойти не так?

Ниже я хотел бы описать ряд проблем, с которыми столкнулся (как программист) при работе над проектами по созданию беспилотных технологий. Врядли я кого-то удивлю, наверняка это всё “детские болезни”, которые решаются правильным планированием и в зрелых компаниях не встречаются. Но на начальном этапе о них полезно помнить.

Фокус на движении, а не решении задачи бизнеса

Если бы нужно было выбрать одну главную проблему, я бы оставил эту. Безусловно, если техника не сможет правильно ездить / плавать / летать, то и задачу решить не сможет. И для этого нужно учесть много факторов: навигация по спутникам или видеоизображению, выбор алгоритма планирования и управления, взаимодействие с препятствиями и другой техникой, требуемые электрические и механические доработки системы и пр. И вам кажется, что решение этих проблем это 90% решения общей задачи. Иногда так и есть. Но чаще в голове заказчика всё уже давно ездит и плавает, а основная работа в этой точке только начинается. В лучшем случае это чревато разочарованием, когда вам говорят, что “непонятно, чем вы вообще занимались”, в худшем - необходимостью в авральном режиме реализовывать то, что казалось очевидным и второстепенным, а на практике оказалось весьма нетривиальным.

Пренебрежение интерфейсом

По сути, это следствие предыдущей проблемы. Интерфейс пользователя видится чем-то второстепенным, мы ведь можем всё запустить из терминала, а если работаем в ROS (Robot Operating System), то использовать инструменты экосистемы типа Rviz и Rqt. Однако, по моим наблюдениям, заказчик считает основной программой именно то, что запущено на планшете или ноутбуке, а не в вычислителе беспилотной техники, даже если это всего лишь тонкий клиент. И именно по его удобству и функциональности оценивается работа всего комплекса.

Пренебрежение “второстепенными” специалистами

Аналитик. Команде нужен человек, который смог бы изучить техпроцессы и потребности бизнеса, и донёс их до разработчиков вместе с используемой заказчиком терминологией. Неприятно, когда не можешь понять, что тебе говорят, ещё неприятнее, когда незадолго до завершения проекта наконец узнаешь, какие режимы работы требуются и как они связаны друг с другом.

Архитектор ПО. Когда команда использует ROS, кажется, что об архитектуре можно не думать, просто пиши отдельные программные модули (ноды), которые будут обмениваться сообщениями, и всё само заработает. Однако, чем больше выделяется подсистем и чем больше программистов над ними заняты, тем меньше каждый из них понимает, как работает система в целом. Это путь в “чёрный ящик”.

Тестировщик. Когда наконец появляется прототип, в симуляторе или “в железе”, имеет смысл подключать тестировщика. Проверка работы физического объекта в реальном времени это обычно длительный процесс, особенно если необходимо выехать в какую-то удаленную локацию. Использование разработчика для этого часто неоправданно. К тому же, мы имеем привычку выполнять для тестирования одни и те же действия, а заказчик, почему-то, склонен выполнять другие, что на демонстрации приводит к “неожиданному” поведению.

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

Размытое техническое задание

Возможно, причина проблемы в том, что беспилотные системы - технология относительно молодая. В результате, либо заказчик не до конца понимает, что он хочет, либо исполнитель - что он может. Если у вас нет за плечами пары-тройки аналогичных проектов, шансы столкнуться с подобным очень велики, а интерпретация заказчиком пунктов ТЗ может вас весьма удивить.

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

Специфические проблемы

Можно перечислить много технических проблем, связанных с разработкой беспилотников. Вот те, что особенно запомнились.

• Перенос из симулятора на железо занимает больше времени, чем планируется. Причины могут быть самые разные: инерционность и/или нелинейность моторов, отличие поведения реальный приборов от использованных в симуляции программных заглушек, настройки сетей, прав доступа и пр.

• Система планирования считает, что распознавание никогда не ошибается.

• Предполагается, что одометрия всегда актуальна и согласована с данными сенсоров.

• Не учтены задержки при передаче сообщений (в системе типа ROS).

• Много кода на Python. При переносе системы на бортовой вычислитель может оказаться, что модули, которые нормально работали по-отдельности, начинают конкурировать за ресурсы.

Последний пункт связан с такой особенностью робототехники как наукоемкость. Поэтому код часто пишут люди с хорошими знаниями в математике и физике, но не в технологии программирования. И если они добавляют unit-тесты, это уже огромный плюс для проекта.

Итого

В процессе разработки беспилотных систем важно помнить, что успех проекта зависит не только от технической реализации движения, но и от комплексного подхода к решению бизнес-задач. А грамотное распределение ролей в команде, чёткое техническое задание и внимание к интерфейсной части являются такими же важными факторами, как и следование траектории или обход препятствий.