Pull to refresh

Comments 31

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

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

Если человек бизнеса видит машину, которая вместо того, чтобы ехать передом, едет задом, то он может посчитать, что продукт не готов и содержит ошибки.
О да, у сложных задач — половина усилий тратится на решение задачи, а потом еще половина — на объяснение закачику, что это и есть самое оптимальное решение.
Аварийка на продакшн использовании обязательна — не все люди, находящие в сервисной зоне, внимательно читают знаки и могут не ожидать появления автопилота.
К чему такие сложности с распознаванием положения? Почему бы не сделать как на круглых вертикальных парковках? Как вариант: машина паркуется на подвижной платформе, которая потом по направляющим перемещается в сервисную зону. Даже распознавать номер на машиноместе не придется, если при регистрации на ремонт сразу указывать водителю номер парковочного места куда ему следует поставить машину или наоборот он сам сообщает номер места куда поставил машину.
Мотивация в выборе подхода — не нужно перестраивать существующие сервисные станции, возможность использовать в гибридном режиме (часть автопилот, часть вручную), стоимость установки решения на новые точки значительно ниже, чем установка подвижных платформ.
а не смотрели в сторону устройств а-ля «радиометка с сигнализацией» (например)?
Чтобы находить и уточнять положение машины по нему (+ чтобы оно напоминало о себе при попытке уноса за территорию).
Нет, не смотрели. Заказчику интересно именно решение с machine learning
так ведь не для замещения ML, а для помощи.

PS: В том числе — помощи людям (если он на магните на крыше или хотя бы на дворниках прикреплен, и издает звуки\мигает при движении красным\синим — он даже более заметен ИМХО чем аварийка)
Спасибо за интересный материал!
Самой интересной работой в области предсказания 3D-положения объекта нам показалась вот эта, которая показывает довольно неплохие результаты на KITTI.

Мы тоже для своего автопилота в университете Иннополис делали сетку по похожему принципу :)
Интересно на сколько большой датасет вам понадобился, чтобы получить достаточно точные значения ориентации и размеров?
К слову сказать, мы использовали КИТТИ + свой датасет с ~3000 изображений и все равно точность детекции ориентации и размеров нас не всегда устраивает.

В конечном продукте каждая картинка сначала прогоняется через сеть для поиска объектов, затем все объекты отправляются в 3D-сеть для предсказания ориентации и размеров, после чего мы оцениваем центр проекции каждого и отправляем его и данные об ориентации и размере дальше.

Я правильно понимаю, что у Вас не отдельная 3D сеть, а просто дополнительные слои для регрессии размеров и ориентации?

К сожалению, KITTI запрещает коммерческое использование. У нас в датасете около 10тыс аннотированных изображений, половина из них из симулятора. Увеличение размера датасета с определенного момента практически не влияет на улучшение работы сети, наибольший эффект оказывает работа c самой сетью: loss function и тп. Кстати, если тренировать сеть только на данных из симулятора, то результат тоже получается неплохой.
Я правильно понимаю, что у Вас не отдельная 3D сеть, а просто дополнительные слои для регрессии размеров и ориентации?

У нас две сети: одна для 2D, вторая для 3D, в которой регрессия размеров и ориентации — отдельные слои.
Спасибо!

У нас две сети: одна для 2D, вторая для 3D, в которой регрессия размеров и ориентации — отдельные слои.

А какое преимущество это дает? Ведь в этом случае тело сети придется считать 2 раза.
Их архитектура в корне разная, плюс результаты работы 2D используются в 3D: сначала мы определяем границы объектов и их тип в 2D сети, потом каждый объект отправляем в 3D, которая уже определяет ориентацию и размеры объекта.
А как вы поступаете в случае если машина видна с нескольких камер?
Фьюзити как-то данные о ее положении или просто выбираете ту, с которой лучше видно?
Берем изображение со всех камер, на которых она видна и мы можем гарантировать хорошее качество (не сильно далеко от камеры), далее data fusion в модуле трекинга.
Скорее всего на таких скоростях для вас это некритично, но все же спрошу.
Упирались ли вы в производительность ROS? Например, то что сообщения не всегда гарантированно приходят или прыгает период между сообщениями.
Думали ли в сторону ROS 2.0 или какого-то другого фреймворка?
Да, ROS2 в pipeline. Сейчас начали тестировать Crystal Clemmys (для другого проекта). С нашей нагрузкой ROS1 более менее справляется, надо учесть, что это ранний прототип и без real-time требований. Но в общем тяжелые данные (картинки с камер, occupancy grids и тд) даже для прототипа лучше передавать в обход ROS топиков (например, gstreamer или nodelets). Также мы используем свой проприетарный bus для общения с актуаторами и сенсорами машины, что дает возможность вывести safety модули в более легкое, высокопроизводительное окружение. С другой стороны нельзя недооценивать возможность очень быстрого прототипирования и огромный выбор модулей для ROS1.
Спасибо за развернутый ответ!
На данном этапе проекта в машину ставится ещё один Jetson TX2, который при помощи нашего драйвера подключается к Vector, который производит дешифровку данных автомобиля и отправку команд. TX2 получает команды на управление с центрального сервера и транслирует их автомобилю.

Я так понимаю, что сейчас поддерживается только ограниченный набор автомобилей?
Формат данных Вам производитель дал или из открытого доступа?
данные вопросы я не могу комментировать, на предыдущий вопрос про ROS уточняю у коллег и скоро напишу.
Кстати, а как вы отличаете каким автомобилем вы управляете когда в кадре 2 и более машин одинаковых моделей и цветов?

А также в случае, когда клиент просто решит помигать аварийкой, а ваша система начнет искать (совсем другую) машину?

Машина идентифицируется один раз и дальше трекается системой. Нам совершенно не важно какой формы и цвета машины вокруг: мы уже определили нашу. В случае если потеряется — остановим, найдем заново.
Если в момент поиска автомобиля мы детектим более одного автомобиля, мигающего огнями, то лейбл ego-car не присваевается ни одному из них. Если с этим возникнут сложности, то у нас есть план как исправить это в будущем при помощи детекта определенной последовательности вкл-выкл огней, но на данном этапе проекта это не требуется
Решение получается не масштабируемым: для всех последующих установок и для случаев, когда нужно изменить направление некоторых камер, требуется переконфигурация симулятора и повторная полная тренировка.

Тем не менее, нам интересно было понять возможности данных подходов, и мы будем иметь их в виду для будущих задач.

Просто 5.
Вопрос с заказчиком разве не обсуждался?

Я думаю, если бы заказчик знал ответы на такие детали, то ему бы не понадобилось обращаться во внешнюю фирму за разработкой
Масштабируемость и переиспользование — это не деталь, а высокоуровневое требование, которое заказчику вполне по зубам.
Данные ограничения методов были не понятны до начала работы с ними: теоретически можно так построить процесс тренировки, что сеть можно будет использовать на любых территориях, если на вход подавать данные о положении камер, но за отведенное время мы не смогли сделать масштабируемое решение ни с VAE, ни с GAN, поэтому переключились на третий метод
Я правильно понимаю, что если на парковке 100 машин, то вам нужно иметь 100 Jetson? Дороговато выходит.
Немного больше: ещё по одному на три камеры. На данном этапе прототипа это так, но в будущем возможен другой формат.
автопилот не заботится об ориентации автомобиля, для него не важно как ехать — передом или задом. Главное — ехать оптимально и ни в кого не врезаться.

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

Как обойти проблему — понятно и не сложно, меня удивил сам факт наличия проблемы в глазах посторонних людей.

А что Вы ожидали публикуя статью? Одни только восторженные возгласы? )))
Может быть это и не проблема, поэтому я и интересуюсь. Вы ведь так и не ответили на мой вопрос по поводу критериев оптимальности.

Интересно а до какой максимальной скорости работает это управление по внешним датчикам?

Понятно что в сервисном центре небольшая скорость по факту, но возможно такое управление задействовать например по датчикам других машин?(т.е. несколько беспилотных автомобилей вокруг машины могут превратить в беспилотник один, или два обычных автомобиля в процессе движения?).
Sign up to leave a comment.

Articles