Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 41
Очень впечатляет, продолжайте!
Подскажите, при использовании SLAM, если камера видит зеркало или телевизор у нее сильно «башня» съезжает? и вообще что происходит
Хороший вопрос… Если они не очень большую часть кадра занимают, то ничего особенного не должно произойти.
Прямо в деталях не разбирался, но НЯП этот SLAM выделяет в кадре ключевые точки, вероятностно их сопоставляет с точками предыдущего кадра и считает локальную жесткую трансформацию старых точек, которая минимизирует дистанцию (в среднем) до соответствующих новых. Если большинство ключевых точек — на неподвижных объектах, то всё в целом хорошо. На дороге постоянно часть точек цепляется за встречные и попутные авто, и SLAM нормально работает при этом. В упор к зеркалу подносить не пробовал.
Есть проблема когда, например, едешь в пробке вплотную за маршруткой, которая половину кадра занимает. Тогда большинство точек — на движущейся маршрутке, и тут уже у SLAM едет крыша и он думает, что стоим на месте, что относительно маршрутки впереди на самом деле так. Но тут уже чудес ожидать нет смысла. Есть план прикрутить фильтрацию движущихся объектов. Например на yolo определять машины и пешеходов, и рядом с ними ключевые точки для SLAM игнорировать, но руки пока не дошли.
Прямо в деталях не разбирался, но НЯП этот SLAM выделяет в кадре ключевые точки, вероятностно их сопоставляет с точками предыдущего кадра и считает локальную жесткую трансформацию старых точек, которая минимизирует дистанцию (в среднем) до соответствующих новых. Если большинство ключевых точек — на неподвижных объектах, то всё в целом хорошо. На дороге постоянно часть точек цепляется за встречные и попутные авто, и SLAM нормально работает при этом. В упор к зеркалу подносить не пробовал.
Есть проблема когда, например, едешь в пробке вплотную за маршруткой, которая половину кадра занимает. Тогда большинство точек — на движущейся маршрутке, и тут уже у SLAM едет крыша и он думает, что стоим на месте, что относительно маршрутки впереди на самом деле так. Но тут уже чудес ожидать нет смысла. Есть план прикрутить фильтрацию движущихся объектов. Например на yolo определять машины и пешеходов, и рядом с ними ключевые точки для SLAM игнорировать, но руки пока не дошли.
Вы как-нибудь проверяли, как соотносится угловая скорость или угол поворота полученные при помощи SLAM и реальные значения в тот же момент времени?
Пока что только на глаз — по крайней мере углы на траекториях очень похожи на то, что на местности, ну и руль на видосах крутится вроде разумно при объезде луж. Когда доковыряю запись акселерометра, можно будет оттуда еще попробовать независимый трек вытащить и сопоставить, но когда руки дойдут ещё не знаю.
А так есть стандартные датасеты и бенчмарки для видео SLAM систем:
http://www.cvlibs.net/datasets/kitti/eval_odometry.php — там гораздо более информативно. Но там камера другая была, а от камеры много зависит. Например видео SLAM любит широкоугольные объективы, а у смартфонов они более длиннофокусные обычно. Global shutter ещё желательно, что тоже далеко не везде есть.
А так есть стандартные датасеты и бенчмарки для видео SLAM систем:
http://www.cvlibs.net/datasets/kitti/eval_odometry.php — там гораздо более информативно. Но там камера другая была, а от камеры много зависит. Например видео SLAM любит широкоугольные объективы, а у смартфонов они более длиннофокусные обычно. Global shutter ещё желательно, что тоже далеко не везде есть.
А не проще дооборудовать руль и педали датчиками на базе какого-нибудь Ардуино, что-нибудь быстро монтируемое на базе оптопар + наклеек со штрихкодами или переменных резисторов? Качество данных ведь должно быть сильно выше, особенно памятуя про то, что измеренные по видео скорость/ускорение это некая свертка из управляющих воздействий на педали газа и тормоза, а нужны именно они.
Угловые энкодеры не так сложно приколхозить,
писать три угла на sd-карту, синхронизировать с видео примерно по времени + специальный звук.
писать три угла на sd-карту, синхронизировать с видео примерно по времени + специальный звук.
Тоже вполне рабочий вариант, многие так делают. Но (а) я лично совсем не умею в железо к сож., поэтому мне точно не проще, и (б) хочется в итоге получить решение для масштабного краудсорса данных, а там каждый чих по покупке и монтажу/наклейке/настройке будет отсекать потенциальных пользователей толпами. Пока что рабочая гипотеза — что сильно хуже такие данные не будут.
Управляющие воздействия хотя и придется делать индивидуальными для каждой модели авто, деваться некуда, но пока что мне кажется, что это будет несложно (поступательная скорость + угол поворота колес + колесная база + сход-развал какой-нибудь должны давать достаточно, чтобы угловую скорость ту же посчитать нормально, ну и обратно из угловой скорости в поворот колес).
Управляющие воздействия хотя и придется делать индивидуальными для каждой модели авто, деваться некуда, но пока что мне кажется, что это будет несложно (поступательная скорость + угол поворота колес + колесная база + сход-развал какой-нибудь должны давать достаточно, чтобы угловую скорость ту же посчитать нормально, ну и обратно из угловой скорости в поворот колес).
Положение педалей также можно фиксировать с помощью инфракрасного датчика приближения, например TCRT5000 (установив в основании педали некую мишень)
Ага, спасибо за инфо, посмотрю! С педалями на самом деле проще, если есть желание возиться с доп железом — bluetooth адаптер на OBD2 разъем, и считываем всё с блока управления напрямую. С рулём сложнее, НЯП если усилитель гидравлический, то информации об угле поворота в CAN просто нет, и остается либо из видео тащить, либо датчики угловой скорости добавлять, либо метку + отслеживание на само рулевое колесо.
На счет гидроусилителя не факт, у меня Е53, там гидроусилитель и датчик поворота руля есть, можно читать по OBD2 положения руля и педалей (по крайней мере педаль газа точно). Датчик положения руля, насколько я понимаю, необходим для системы стабилизации DSC. Так что в теории такой датчик должен присутствовать на множестве машин с такими системами стабилизации. Плюс в довесок, в такой старой машине есть CAN шина, но она только в моторной и коробочной проводке, но по идее к ней нет труда подключиться + сама приборка работает как «роутер» между шинами.
Интересно, спасибо за инфо!
Кстати во многих старых BMW такое есть на этой платформе (e38,e39,e53,e83,e46), в принципе если дойдете до железных тестов это хороший вариант, насколько знаю в России (если Вы из России) они не дорогие, ну а в Украине тесты можно и на нерастаможке делать)
а почему бы не расположить так камеру что бы в её поле зрения попадал руль? или хотя бы часть руля?
На руль можно нанести контрастные метки и по ним определять положение руля.
Отлично будет если в поле зрении будет панель приборов ( в частности спидометр и одометр ), тогда и траектории можно будет более точно определять.
На руль можно нанести контрастные метки и по ним определять положение руля.
Отлично будет если в поле зрении будет панель приборов ( в частности спидометр и одометр ), тогда и траектории можно будет более точно определять.
Не пробовал, но тоже вполне вариант, да. Там свой набор задач придется решить, навскидку: экспозиция, если делать всё одной камерой — элементы в салоне обычно гораздо темнее, чем за окном; фокусировка, чтобы и условные метки на руле и дорога были четко видны; разрешение видео если пытаться смотреть на спидометр и по нему скорость определять — там будет хорошо если по 50 пикселей в каждом направлении. Если брать отдельную камеру для руля и приборки, становится проще с оптикой, но надо возиться с синхронизацией.
В общем очевидно халявного решения не видно, везде свои плюсы и минусы, остается вкусовщина, кому какой тип задач интереснее.
В общем очевидно халявного решения не видно, везде свои плюсы и минусы, остается вкусовщина, кому какой тип задач интереснее.
Очень интересная статья! Спасибо!
Возможно тупой вопрос, но почему не взять видео с регистратора, например?
Просто у меня нет регистратора :)
Кроме шуток же, если нужен только угол поворота из видео, то хороший регистратор может быть даже лучше смартфона, т.к. в регистраторах обычно более широкоугольные объективы, а SLAM как раз любит широкое поле зрения. Но я хочу ещё и поступательную скорость получить, а с ней уже у SLAM сложности, поэтому нужно будет GPS и акселерометр подтягивать.
Есть конечно продвинутые регистраторы, где все эти датчики есть, но это уже далеко не каждый будет заморачиваться с покупкой, а телефон у всех и так есть.
Кроме шуток же, если нужен только угол поворота из видео, то хороший регистратор может быть даже лучше смартфона, т.к. в регистраторах обычно более широкоугольные объективы, а SLAM как раз любит широкое поле зрения. Но я хочу ещё и поступательную скорость получить, а с ней уже у SLAM сложности, поэтому нужно будет GPS и акселерометр подтягивать.
Есть конечно продвинутые регистраторы, где все эти датчики есть, но это уже далеко не каждый будет заморачиваться с покупкой, а телефон у всех и так есть.
У меня такой, вот и думаю, есть ли смысл ставить телефон или можно обойтись пережатым видео с регика.
Должно работать с пережатым (по разрешению) не хуже, чем с телефоном. Главное для калибровки видео записывать и пережимать с теми же настройками, ну и при пережатии битрейт не зажимать, чтобы артефактов кодека не добавлялось.
А, ещё если в регистраторе есть автофокусировка, то для калибровки её лучше выключить и поставить на бесконечность, т.к. в дороге предметы гораздо дальше от камеры, чем калибровочный лист в комнате, а мы хотим одинаковые настройки по возможности.
GPS вы тоже используете?
Тогда непонятно зачем использовать SLAM, я так понял она используется для построения трэка, хотя тот же трэк можно снять и с GPS. Или у SLAM точность выходит выше?
Еще навеяло мыслью про модуль optical_trajectories.
Может имеет смысл так же для оценки положения дороги брать данные с геокарт, ведь если есть gps то координаты мы тоже знаем и направление дороги можно предсказывать
Тогда непонятно зачем использовать SLAM, я так понял она используется для построения трэка, хотя тот же трэк можно снять и с GPS. Или у SLAM точность выходит выше?
Еще навеяло мыслью про модуль optical_trajectories.
что кроме горных дорог выделение главной плоскости будет плохо работать если машина всё время ехала по прямой
Может имеет смысл так же для оценки положения дороги брать данные с геокарт, ведь если есть gps то координаты мы тоже знаем и направление дороги можно предсказывать
GPS сейчас не используется, всё строится чисто из видео. У потребительских GPS приемников недостаточная точность и частота обновления (по кр. мере, насколько я видел что получается с телефона), для определения поворотов в нужном качестве. Особенно когда это не дорога за угол поворачивает и можно ещё что-то проинтерполировать, а машина колдобину размером в 50см объезжает. Для поворотов у SLAM точность явно выше.
С поступательной скоростью у этого SLAM есть проблемы. Если совсем на пальцах, после каждого серьезного поворота (в районе 90 градусов) набор ключевых точек быстро обновляется и происходит переоценка «характерной глубины кадра». И дальше пока мы едем по прямой «выжатая» SLAM скорость «привязана» к этой характерной глубине. Поэтому если глубину оценили неточно, что часто бывает, скорость будет отличаться от реальной на какой-то множитель, далекий от единицы. И после каждого поворота множитель меняется, т.е. его нельзя просто один раз откалибровать и забыть. Поэтому для поступательной скорости надо уже будет подключать GPS и акселерометр (это в процессе запиливания, пока выкладывать нечего).
К картам можно привязываться, Garmin кстати так делает для своих фитнес-трекеров. Правда не знаю, насколько картографическая подложка в наших краях качественная. Но как доп очистка данных после поднятия всего главного функционала вполне вариант.
С поступательной скоростью у этого SLAM есть проблемы. Если совсем на пальцах, после каждого серьезного поворота (в районе 90 градусов) набор ключевых точек быстро обновляется и происходит переоценка «характерной глубины кадра». И дальше пока мы едем по прямой «выжатая» SLAM скорость «привязана» к этой характерной глубине. Поэтому если глубину оценили неточно, что часто бывает, скорость будет отличаться от реальной на какой-то множитель, далекий от единицы. И после каждого поворота множитель меняется, т.е. его нельзя просто один раз откалибровать и забыть. Поэтому для поступательной скорости надо уже будет подключать GPS и акселерометр (это в процессе запиливания, пока выкладывать нечего).
К картам можно привязываться, Garmin кстати так делает для своих фитнес-трекеров. Правда не знаю, насколько картографическая подложка в наших краях качественная. Но как доп очистка данных после поднятия всего главного функционала вполне вариант.
Интересно. Тогда получается для большей точности SLAM имеет смысл постоянно ехать за каким-нибудь объектом(авто) что бы при повороте не уходил набор ключевых точек связанный с этим объектом?
Не очень понял причем тут Garmin с фитнес-трекером. Я имел ввиду что с помощью карт можно предсказывать в текущей ситуации направление дороги, там где с этим возникают трудности (горные дороги допустим )
Не очень понял причем тут Garmin с фитнес-трекером. Я имел ввиду что с помощью карт можно предсказывать в текущей ситуации направление дороги, там где с этим возникают трудности (горные дороги допустим )
Такой фокус к сож. не пройдет — ключевое предположение в SLAM — что окружающий мир статичен, и траектория вычисляется относительно этого статичного мира. Если ехать вплотную за другой машиной, траектория будет считаться относительно этой машины, получится что мы просто стоим на месте.
Garmin делает похожую концептуально вещь (пользуются картами для улучшения точности GPS данных), только не направление дороги предсказывают, а высоту над уровнем моря: тут вкратце можно посмотреть в секции «What are elevation corrections?». Но напрямую это конечно к нашей задаче не переносится, да.
Garmin делает похожую концептуально вещь (пользуются картами для улучшения точности GPS данных), только не направление дороги предсказывают, а высоту над уровнем моря: тут вкратце можно посмотреть в секции «What are elevation corrections?». Но напрямую это конечно к нашей задаче не переносится, да.
Это да, но чёрт как обычно в деталях. Во-первых помогают именно круги — этот SLAM очень круто замыкает циклы, а знание циклов в свою очередь позволяет исправить большую часть систематического дрифта, который в open loop мы не сможем заметить. К сож. в реальной жизни мало кому интересно ездить кругами, а краудсорса хочется. Во-вторых много зависит от камеры, завтра постараюсь ссылку нарыть, сейчас с утюга совсем не ищется. Но вкратце для оптимального результата надо широкоугольный объектив (что как правило не про смартфоны) и global shutter, что тоже НЯП не всегда есть. Без них деградация довольно резкая. В очереди висит эксперимент нацепить на объектив фишай клипсу за 300р и сравнить качество, убрать часть шумов оптикой было бы здорово.
Редкость, да. Варианты есть за не прямо космические деньги, но надо заморачиваться.
Так и не нашел ту ссылку с цифрами, зато копнул чуть глубже про разные сламы. В целом rolling shutter больше вредит тем, кто на более плотных фичах по кадру работает: lsd-slam, dso-slam. ORB_SLAM относительно более устойчив, хотя и не полностью. Тут есть интересная картинка тоже на Figure 20 про деградацию в зависимости от локальной дисторсии.
Тут автор для ORB_SLAM2 советует тоже ширик и глобальный затвор.
Тут автор для ORB_SLAM2 советует тоже ширик и глобальный затвор.
[потерто, промахнулся веткой]
Интересно, статьи точно есть. Comma похоже что-то тоже уже умеет. В принципе если сегментировать дорожное полотно deconvnet-ом каким-нибудь, найти там разметку и предположить, что дорога плоская, а разметка прямая, то для вычисления дисторсии должно хватить инфы, но повозиться придется серьезно.
Было бы круто конечно сделать самокалибровку и уменьшить барьер гемора для краудсорса. Насчет вытаскивания данных из прямо левых видео с регистраторов я не так оптимистичен. Пока есть ощущение, что без GPS и акселерометра нужной точности по скорости не будет всё равно. Ну и вопрос, что именно в итоге хотим получить. С одной камерой, какой бы там ни был ширик, про самостоятельные перестроения можно сразу забыть, т.к. слепые зоны огромные. Значит надо целиться в относительно простой ADAS, выдерживающий полосу и оттормаживающийся перед препятствиями, а там надеюсь требования к разнообразию данных полегче будет и примеров типа «подрезали — притормозил» можно будет набрать относительно легко.
Было бы круто конечно сделать самокалибровку и уменьшить барьер гемора для краудсорса. Насчет вытаскивания данных из прямо левых видео с регистраторов я не так оптимистичен. Пока есть ощущение, что без GPS и акселерометра нужной точности по скорости не будет всё равно. Ну и вопрос, что именно в итоге хотим получить. С одной камерой, какой бы там ни был ширик, про самостоятельные перестроения можно сразу забыть, т.к. слепые зоны огромные. Значит надо целиться в относительно простой ADAS, выдерживающий полосу и оттормаживающийся перед препятствиями, а там надеюсь требования к разнообразию данных полегче будет и примеров типа «подрезали — притормозил» можно будет набрать относительно легко.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автопилот своими силами. Часть 1 — набираем обучающие данные