Молодцы! Рад, что в России осознали необходимость подобных соревнований и есть команды, способные решать такие задачи.
А то что с первого раза ничего не получилось это не беда. Сильную команду отрицательный опыт только подталкивает к поиску новых решений.
На данном этапе проекта в машину ставится ещё один Jetson TX2, который при помощи нашего драйвера подключается к Vector, который производит дешифровку данных автомобиля и отправку команд. TX2 получает команды на управление с центрального сервера и транслирует их автомобилю.
Я так понимаю, что сейчас поддерживается только ограниченный набор автомобилей?
Формат данных Вам производитель дал или из открытого доступа?
Скорее всего на таких скоростях для вас это некритично, но все же спрошу.
Упирались ли вы в производительность ROS? Например, то что сообщения не всегда гарантированно приходят или прыгает период между сообщениями.
Думали ли в сторону ROS 2.0 или какого-то другого фреймворка?
А как вы поступаете в случае если машина видна с нескольких камер?
Фьюзити как-то данные о ее положении или просто выбираете ту, с которой лучше видно?
Самой интересной работой в области предсказания 3D-положения объекта нам показалась вот эта, которая показывает довольно неплохие результаты на KITTI.
Мы тоже для своего автопилота в университете Иннополис делали сетку по похожему принципу :)
Интересно на сколько большой датасет вам понадобился, чтобы получить достаточно точные значения ориентации и размеров?
К слову сказать, мы использовали КИТТИ + свой датасет с ~3000 изображений и все равно точность детекции ориентации и размеров нас не всегда устраивает.
В конечном продукте каждая картинка сначала прогоняется через сеть для поиска объектов, затем все объекты отправляются в 3D-сеть для предсказания ориентации и размеров, после чего мы оцениваем центр проекции каждого и отправляем его и данные об ориентации и размере дальше.
Я правильно понимаю, что у Вас не отдельная 3D сеть, а просто дополнительные слои для регрессии размеров и ориентации?
Спасибо за интересную статью!
Вопрос не совсем по восстановлению разрешения, но все же близок к теме.
Есть интересная статья от Интел по восстановлению очень темных кадров. Интересно Ваше мнение на сколько это может быть работающая технология.
Полностью с Вами согласен. Если бы у нас в стране хотя бы сделали нормальные освещенные пешеходные переходы с островками безопасности и успокоением траффика, уже можно было бы снизить смертность не придумывая никаких супер систем.
Концепция центральной диспетчеризации, конечно, имеет свои преимущества. Но у меня есть большие сомнения в масштабируемости Вашей системы.
Во-первых, сможет ли Ваша система корректно распознавать и определять координаты всех автомобилей на шестиполосной дороге, да еще и при условии, что фуры могут загораживать часть автомобилей?
Во-вторых, сможет ли она корректно отслежвать автомобили на скорости, например, в 90 км/ч, учитывая задержки в камере, задержка на распознавание, задержки в передачи данных и т.д?
В третьих, сможет ли она корректно работать когда камер будет очень много? А если при этом часть камер перестала работать или видимость не позволяет распознать объекты?
В четвертых, что будет если на одном или нескольких автомобилей сломается система управления?
Отличная статья и проект! Скажите, а Вы не сравнивали по другим источникам скорость работы этой же сетки на GPU? В частности интересно, какую необходимо иметь графическую карту, чтобы добиться тех же 10.4 FPS?
С терминологией согласен. Все так! :)
В случае пакетной обработки лучше подойдет метод наименьших квадратов, который будет учитывать как неточности в данных IMU, так и неточности GPS и, конечно, саму модель движения.
Рекомендую книгу "Advanced Kalman Filtering, Least-Squares and Modeling: A Practical Handbook", теория там конечно сложновата, но на примерах становится более-менее понятно.
Когда bias является статическим параметром, то его, действительно, выгодней определить заранее путем калибровки. В случае же, если он меняется во времени, то его включают в состояние системы, хотя, конечно, по физическому смыслу он будет отличатся от других переменных состояния. Но это, как говорится, best practice. Например, в коде полетного контроллера PX4 примерно треть переменных состояния это bias.
Никакой backward функции для получения оптимального bias не нужно, т.к. сам по себе EKF относится к классу optimal estimator и соответственно на каждой итерации оцененное состояние является оптимальным по отношению к полученным измерения, шумам и модели.
Это не совсем перпендикулярная задача. По-сути EKF умеет корректировать рассчитанное состояние, когда приходят более точные данные. В частности, пока нет GPS фильтр рассчитывает позицию интегрирую ускорения, которые с ошибкой, но с поступление данных от GPS он скорректирует рассчитанную позициию и т.о. сбросит набежавшую ошибку интегрирования.
Если же мы хотим рассчитывать на лету постоянный сдвиг в данных датчика, то для этого нужно добавить дополнительное(ые) состояние(я) в фильтр, которое будет оценивать этот сдвиг (bias).
Наша команда была в шаге от того, чтобы выиграть весь сезон. Жаль, что чемпионат закрылся.
А то что с первого раза ничего не получилось это не беда. Сильную команду отрицательный опыт только подталкивает к поиску новых решений.
Я так понимаю, что сейчас поддерживается только ограниченный набор автомобилей?
Формат данных Вам производитель дал или из открытого доступа?
Упирались ли вы в производительность ROS? Например, то что сообщения не всегда гарантированно приходят или прыгает период между сообщениями.
Думали ли в сторону ROS 2.0 или какого-то другого фреймворка?
Фьюзити как-то данные о ее положении или просто выбираете ту, с которой лучше видно?
А какое преимущество это дает? Ведь в этом случае тело сети придется считать 2 раза.
Мы тоже для своего автопилота в университете Иннополис делали сетку по похожему принципу :)
Интересно на сколько большой датасет вам понадобился, чтобы получить достаточно точные значения ориентации и размеров?
К слову сказать, мы использовали КИТТИ + свой датасет с ~3000 изображений и все равно точность детекции ориентации и размеров нас не всегда устраивает.
Я правильно понимаю, что у Вас не отдельная 3D сеть, а просто дополнительные слои для регрессии размеров и ориентации?
Вопрос не совсем по восстановлению разрешения, но все же близок к теме.
Есть интересная статья от Интел по восстановлению очень темных кадров. Интересно Ваше мнение на сколько это может быть работающая технология.
Во-первых, сможет ли Ваша система корректно распознавать и определять координаты всех автомобилей на шестиполосной дороге, да еще и при условии, что фуры могут загораживать часть автомобилей?
Во-вторых, сможет ли она корректно отслежвать автомобили на скорости, например, в 90 км/ч, учитывая задержки в камере, задержка на распознавание, задержки в передачи данных и т.д?
В третьих, сможет ли она корректно работать когда камер будет очень много? А если при этом часть камер перестала работать или видимость не позволяет распознать объекты?
В четвертых, что будет если на одном или нескольких автомобилей сломается система управления?
В случае пакетной обработки лучше подойдет метод наименьших квадратов, который будет учитывать как неточности в данных IMU, так и неточности GPS и, конечно, саму модель движения.
Рекомендую книгу "Advanced Kalman Filtering, Least-Squares and Modeling: A Practical Handbook", теория там конечно сложновата, но на примерах становится более-менее понятно.
Никакой backward функции для получения оптимального bias не нужно, т.к. сам по себе EKF относится к классу optimal estimator и соответственно на каждой итерации оцененное состояние является оптимальным по отношению к полученным измерения, шумам и модели.
Если же мы хотим рассчитывать на лету постоянный сдвиг в данных датчика, то для этого нужно добавить дополнительное(ые) состояние(я) в фильтр, которое будет оценивать этот сдвиг (bias).