- PVSM.RU - https://www.pvsm.ru -
Привет! Я работаю в небольшом стартапе в Берлине, занимающимся разработкой автопилотов для автомобилей. Мы заканчиваем проект для сервисных станций одного крупного немецкого автопроизводителя и я бы хотел рассказать о нём: как мы его делали, с какими трудностями столкнулись и что нового открыли для себя. В этой части я расскажу про perception модуль и немного про архитектуру решения в целом. Про остальные модули, возможно, расскажем в следующих частях. Буду очень рад обратной связи и взгляду со стороны на наш подход.
Пресс-релиз проекта со стороны заказчика можно найти тут [1].
Для начала скажу, зачем автопроизводитель обратился к нам, а не сделал проект своими силами. Крупным немецким концернам сложно менять процессы, а формат разработки автомобилей редко подходит для программного обеспечения — итерации долгие и требуют хорошего планирования. Мне кажется, немецкие автопроизводители это понимают, и поэтому можно встретить стартапы, которые основаны ими, но работают как независимая фирма (например, AID от Audi и Zenuity от Volvo). Другие автопроизводители организуют мероприятия вроде Startup Autobahn, где они ищут возможных подрядчиков для задач и новые идеи. Они могут заказать продукт или прототип и через короткий промежуток времени получить готовый результат. Это может оказаться быстрее, чем пробовать делать то же самое самим, и по затратам выходит не дороже собственной разработки. Сложность изменения процессов хорошо демонстрирует количество разрешений, необходимое для того, чтобы начать тестирование машины с автопилотом у заказчиков: согласие на видеосъемку людей (даже если мы не сохраняем данные, а потоковое видео используем только в анонимном виде без идентификации конкретных людей), согласие на видеосъемку территории, согласие профсоюза и рабочего консула на тестирование данных технологий, согласие службы безопасности, согласие службы IT — это ещё не весь список.
В текущем проекте заказчик хочет понять, возможно ли управлять автомобилями в сервисных центрах при помощи “AI”. Пользовательский сценарий при этом такой:
Особенности: не на всех машинах есть камеры. На тех машинах, на которых они есть, мы не имеем к ним доступа. Единственные данные на машине, к которым у нас есть доступ — сонары и одометрия
Таким образом, управление автомобилем должно происходить по внешним сенсорам, установленным в сервисной зоне.
Архитектура конечного продукта выглядит следующим образом:
Для уровня инфраструктуры используется ROS [2].
Вот что происходит после того, как техник выбрал машину и нажал “заехать”:
Выезд наружу происходит так же, как и заезд.
Одним из основных и, по моему мнению, самым интересным модулем является perception. Этот модуль описывает данные с сенсоров в таком виде, чтобы можно было точно принять решение о движении. В нашем проекте он выдает координаты, ориентацию и размеры всех объектов, попадающих на камеры. При проектировании этого модуля мы решили начать с алгоритмов, которые позволили бы производить анализ изображения за один проход. Мы попробовали:
Одна из итераций Conditional GAN для одной камеры, слева направо: входное изображение, предсказание сети, ожидаемый результат
Фактически идея этих подходов сводится к тому, чтобы конечная сеть могла понимать расположение и ориентацию всех автомобилей и других подвижных объектов, попавших на камеру, посмотрев на входную фотографию один раз. Данные об объектах в таком случае будут хранится в латентных векторах. Тренировка сети происходила на данных из симулятора, который является точной копией точки, где будет проходить демонстрация. И у нас получилось добиться определенных результатов, но мы решили не использовать данные методы по нескольким причинам:
Тем не менее, нам интересно было понять возможности данных подходов, и мы будем иметь их в виду для будущих задач.
После этого мы подошли к задаче с другой стороны, через обычный поиск объектов + сеть для определения пространственного положения найденных объектов (например такая [5] или такая [6]). Этот вариант нам показался наиболее точным. Единственный минус — он медленнее предложенных до этого подходов, но укладывается в наши возможные рамки задержки, так как скорость движения автомобиля по сервисной зоне не более 5 км/час. Самой интересной работой в области предсказания 3D-положения объекта нам показалась вот эта [7], которая показывает довольно неплохие результаты на KITTI [8]. Мы построили аналогичную сеть с некоторыми изменениями и написали наш собственный алгоритм определения surrounding box, а если быть более точным, алгоритм оценки координат центра проекции объекта на землю — для принятия решений о направлении движения нам не нужны данные о высоте объектов. На вход сети подается изображение объекта и его тип (машина, пешеход,..), на выходе — его размеры и ориентация в пространстве. Далее модуль оценивает центр проекции и отдает данные по всем объектам: координаты центра, ориентацию и размеры (ширину и длину).
В конечном продукте каждая картинка сначала прогоняется через сеть для поиска объектов, затем все объекты отправляются в 3D-сеть для предсказания ориентации и размеров, после чего мы оцениваем центр проекции каждого и отправляем его и данные об ориентации и размере дальше. Особенностью данного метода является то, что он очень сильно завязан на точность границы boundary box из сети поиска объектов. По этой причине сети типа YOLO нам не подошли. Оптимальный баланс производительности и точности boundary box нам показался на сети RetinaNet.
Стоит заметить одну вещь, с которой нам повезло на данном проекте: земля плоская. Ну, то есть, не такая плоская, как у известного сообщества, но на нашей территории изгибов не наблюдается. Это позволяет использовать зафиксированные монокулярные камеры для проекции объектов в координаты плоскости земли без информации о расстоянии до объекта. В дальнейших планах стоит внедрение monocular depth prediction. Работ на эту тему много, вот [9], например, одна из последних и очень интересных, которую мы сейчас пробуем для будущих проектов. Depth prediction позволит работать не только на плоской земле, он потенциально должен увеличить точность определения препятствий, упростить процесс конфигурации новых камер и позволит отказаться от необходимости лейблировать каждый объект — нам не важно что именно это за объект, если это какое-то препятствие.
На этом всё, спасибо, что прочитали, и с удовольствием отвечу на вопросы. В качестве бонуса хочу рассказать про неожиданный негативный эффект: автопилот не заботится об ориентации автомобиля, для него не важно как ехать — передом или задом. Главное — ехать оптимально и ни в кого не врезаться. Поэтому есть большая вероятность, что автомобиль часть пути будет проезжать задним ходом, особенно на небольших площадках, где требуется высокая маневренность. Однако люди привыкли, что автомобиль в основном двигается передом, и часто ожидают такого же поведения от автопилота. Если человек бизнеса видит машину, которая вместо того, чтобы ехать передом, едет задом, то он может посчитать, что продукт не готов и содержит ошибки.
P.S. Прошу прощения, что нет изображений и видео с реальным тестированием, но я не могу их публиковать по юридическим причинам.
Автор: Александр Гечис
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/robototehnika/321935
Ссылки в тексте:
[1] тут: https://newsroom.porsche.com/ru/2019/company/ru-porsche-autonomous-driving-workshop-cooperation-kopernikus-automotive-startup-autobahn-17017.html
[2] ROS: https://ru.wikipedia.org/wiki/ROS_(%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0)
[3] Disentangled VAE: https://openreview.net/forum?id=Sy2fzU9gl
[4] pix2pix: https://affinelayer.com/pixsrv/
[5] такая: https://arxiv.org/abs/1712.03904
[6] такая: https://arxiv.org/abs/1803.11493
[7] вот эта: https://arxiv.org/abs/1612.00496
[8] KITTI: http://www.cvlibs.net/datasets/kitti/eval_object.php?obj_benchmark=3d
[9] вот: https://arxiv.org/abs/1906.05717
[10] Источник: https://habr.com/ru/post/457500/?utm_source=habrahabr&utm_medium=rss&utm_campaign=457500
Нажмите здесь для печати.