Этот пример показывает ускорение FPGA обнаружения маркировки маршрута.
Обнаружение маршрута является критическим этапом обработки в Усовершенствованных ведущих системах помощи (ADAS). Автоматически обнаружение контуров маршрута от видеопотока в вычислительном отношении сложно, и поэтому аппаратные акселераторы, такие как FPGAs и графические процессоры часто требуются, чтобы достигать оперативной производительности.
В этой модели в качестве примера основанный на FPGA кандидат маршрута генератор является вместе с основанным на программном обеспечении полиномом подходящим механизмом, чтобы определить контуры маршрута.
Систему LaneDetectionHDL.slx показывают ниже. Подсистема HDLLaneDetector представляет аппаратно ускоренную часть проекта, в то время как подсистема SWLaneFitandOverlay представляет основанный на программном обеспечении полином подходящий механизм. До блока Frame to Pixels вход RGB преобразован в цветовое пространство интенсивности.
Детектор Маршрута HDL представляет аппаратно ускоренную часть проекта. Эта подсистема получает поток входного пикселя от обращенного к передней стороне источника камеры, преобразовывает представление, чтобы получить вид с высоты птичьего полета, определяет местоположение кандидатов маркировки маршрута от преобразованного представления и затем буферизует их в вектор, чтобы отправить стороне программного обеспечения для аппроксимирования кривыми и наложения.
Блок Birds-Eye View преобразовывает обращенное к передней стороне поле зрения камеры к перспективе птичьего глаза. Работа с изображениями в этом представлении упрощает требования к обработке нисходящих алгоритмов обнаружения маршрута. Обращенное к передней стороне представление страдает от перспективного искажения, заставляя маршруты сходиться на пределе. Первая стадия системы исправляет перспективное искажение путем преобразования к виду с высоты птичьего полета
Обратное Перспективное Отображение дано следующим выражением:
Матрица homography, h, выведена от четырех внутренних параметров физической настройки камеры, а именно, фокусное расстояние, подача, высота и принципиальная точка (из модели камеры с точечной диафрагмой). Отошлите к Системе Компьютерного зрения документацию Toolbox™ для получения дальнейшей информации.
Прямая оценка источника (обращенного к передней стороне) месту назначения (птичий глаз), сопоставляющий в режиме реального времени на оборудовании FPGA/ASIC, сложна. Требование для деления наряду с потенциалом для непоследовательного доступа к памяти от кадрового буфера означает, что вычислительные требования этой части проекта являются существенными. Поэтому вместо того, чтобы непосредственно оценить вычисление IPM в режиме реального времени, оффлайновый анализ входа, чтобы вывести отображение выполнялся и использовался, чтобы предварительно вычислить схему отображения. Это возможно, когда матрица homography фиксируется после калибровки/установки фабрики камеры, из-за положения камеры, высоты и зафиксированной подачи.
В этом конкретном примере выходное изображение птичьего глаза является кадром [700x640] размерности, тогда как обращенное к передней стороне входное изображение имеет [480x640] размерности. Нет достаточного очищения, доступного в порядке вывести полный кадр птичьего глаза, прежде чем следующий обращенный к передней стороне вход камеры будет передан потоком в. Внутренне, блок Вида с высоты птичьего полета поэтому запрется, когда он начнет обрабатывать новый входной кадр и не примет новые данные о кадре, пока он не закончил выводить текущий кадр птичьего глаза.
Проективное преобразование в натуральную величину от входа, чтобы вывести привело бы к [900x640] выходное изображение. Это требует, чтобы полное [480x640] входное изображение хранилось в памяти, в то время как местоположение исходного пикселя вычисляется с помощью исходного местоположения и матрицы homography. Идеально память на чипе должна использоваться с этой целью, удаляя требование для кадрового буфера вне кристалла. Анализ отображения входной строки, чтобы вывести строку показывает, что в порядке сгенерировать первые 700 строк верхней части вниз выходное изображение птичьего глаза, приблизительно 50 строк входного изображения требуются. Это - приемлемое количество строк, чтобы сохранить использование память на чипе.
С полученным изображением вида с высоты птичьего полета может быть выполнено фактическое обнаружение маршрута. Существует много методов, которые могут быть рассмотрены с этой целью. Достигнуть реализации, которая устойчива, работает хорошо над потоковой передачей данных изображения и который может быть реализован в оборудовании FPGA/ASIC по разумной стоимости ресурса, этот пример использует подход, описанный в [1]. Этот алгоритм выполняет свертку полного образа с вертикально ориентированным первым порядком Гауссово производное ядро фильтра, сопровождаемое обработкой подобласти.
Сразу после отображения птичьего глаза входного изображения к выводу применяют операцию свертки с фильтром, разработанным, чтобы определить местоположение полос пикселей высокой интенсивности на темном фоне. Ширина ядра составляет 8 пикселей, который относится к ширине строк, которые появляются в изображении птичьего глаза. Высота установлена в 16, который относится к размеру пунктирных маркировок маршрута, которые появляются в изображении. Когда изображение птичьего глаза физически связано с высотой, подача и т.д. камеры, ширина, в которой маршруты появляются в этом изображении, внутренне связана с физическим измерением на дороге. Ширина и высота ядра, возможно, должны быть обновлены при работе системой обнаружения маршрута в разных странах.
Вывод ядра фильтра показывают ниже, с помощью струйной палитры, чтобы подсветить различия в интенсивности. Поскольку ядро фильтра является генералом, вертикально ориентировал Гауссову производную, из многих различных областей существует некоторый ответ. Однако для местоположений, где маркировка маршрута присутствует, существует сильный положительный ответ, расположенный рядом с сильным отрицательным ответом, который сопоставим через столбцы. Эта характеристика фильтра вывод используется на следующем этапе алгоритма обнаружения, чтобы определить местоположение допустимых кандидатов маршрута.
После свертки с Гауссовым производным ядром обработка подобласти вывода выполняется в порядке найти координаты, где маркировка маршрута присутствует. Каждая область состоит из 18 строк со схемой memory пинг-понга на месте, чтобы гарантировать, что данные могут постоянно передаваться потоком через подсистему.
Во-первых, HistogramColumnCount считает количество пороговых пикселей в каждом столбце по 18 областям строки. Высокое количество столбцов указывает, что маршрут, вероятно, присутствует в области. Это количество выполняется и для положительного и для отрицательных пороговых изображений. Положительные количества гистограммы смещаются, чтобы составлять ширину ядра. Кандидаты маршрута происходят, где положительное количество и отрицательные количества оба высоки. Это использует ранее отмеченное свойство свертки вывод, где положительные дорожки появляются рядом с отрицательными дорожками.
Внутренне, столбец, считая гистограмму генерирует управление, сигнализирующее, который выбирает 18 областей строки, вычисляет гистограмму столбца и выводит результат, когда готовый. Схема буферизации пинг-понга существует, который позволяет одной гистограмме читать, в то время как следующее пишет.
Как отмечено, когда маршрут будет присутствовать в изображении птичьего глаза, результат свертки произведет полосы высокой интенсивности положительный вывод, расположенный рядом с полосами высокой интенсивности отрицательный вывод. Положительные и отрицательные гистограммы количества столбцов определяют местоположение таких областей. В порядке усилить эти местоположения, положительное количество вывод задерживается 8 тактами (внутренний параметр, связанный с шириной ядра), и положительные и отрицательные количества умножаются вместе. Это усиливает столбцы, где положительные и отрицательные количества соглашаются, и минимизирует области, где существует разногласие между положительными и отрицательными количествами. Проект является конвейерным в порядке гарантировать высокую операцию пропускной способности.
При выводе Перекрытия и Умножают подсистему, peaks появляется, где существуют существующие маркировки маршрута. Пиковый алгоритм обнаружения определяет столбцы, где маркировки маршрута присутствуют. Поскольку ОСШ относительно высок в данных, этот пример использует простую КИХ-операцию фильтрации, сопровождаемую нулевым обнаружением пересечения. Нулевой Фильтр Пересечения реализован с помощью блока Discrete FIR Filter от DSP System Toolbox™. Это является конвейерным для операции высокой пропускной способности.
Нуль, пересекающий фильтр вывод, затем передается в Хранилище Доминирующая подсистема Маршрутов. Эта подсистема имеет максимальную память о 7 записях и сбрасывается каждый раз, когда новый пакет 18 строк достигнут. Поэтому для каждой подобласти 7 потенциальных кандидатов маршрута сгенерированы. В этой подсистеме Zero Crossing Filter вывод передан потоком через и исследован на потенциальные нулевые пересечения. Если нулевое пересечение действительно происходит, то различие между адресом сразу до нулевого пересечения и адресом после нулевого пересечения взято в порядке получить измерение размера пика. Подсистема хранит нулевые местоположения пересечения самым высоким значением.
Подсистема Обнаружения Маршрута выводит 7 самых жизнеспособных маркировок маршрута. Во многих приложениях мы больше всего интересуемся маркировками маршрута, которые содержат маршрут, в котором автомобиль является ведущим. Путем вычисления так называемых "Маршрутов Эго" на аппаратной стороне проекта мы можем уменьшать пропускную способность памяти между аппаратным и программным обеспечением путем отправки 2 маршрутов, а не 7 к процессору. Вычисление Маршрута Эго разделено в две подсистемы. Подсистема FirstPassEgoLane принимает, что столбец центра изображения соответствует середине маршрута, когда автомобиль правильно действует в контурах маршрута. Кандидаты маршрута, которые являются самыми близкими к центру, поэтому приняты как маршруты эго. Подсистема Удаления Выброса поддерживает среднюю ширину расстояния от маркировок маршрута, чтобы центрировать координату. Отклоняются маркеры маршрута, которые не являются в допуске текущей ширины. Выполнение раннего отклонения маркеров маршрута дает лучшие результаты при выполнении аппроксимирования кривыми позже в проекте.
Наконец, вычисленные маршруты эго отправляются в подсистему функции MATLAB CtrlInterface. Этот конечный автомат использует четыре входных параметров управляющего сигнала - включают, hwStart, hwDone, и swStart, чтобы определить, когда начать буферизовать, признать, что новая координата маршрута в 40x1 буферизует и наконец указывает к программному обеспечению, что все 40 координат маршрута были буферизованы и так подбор кривой маршрута, и наложение может быть выполнено. Сигнал dataReady гарантирует, что программное обеспечение не будет делать попытку маршрута, соответствующего, пока все 40 координат не были буферизованы, в то время как сигнал swStart гарантирует, что текущий набор 40 координат будет сохранен, пока подбор кривой маршрута не завершается.
Обнаруженные маршруты эго затем передаются подсистеме Подгонки и Наложения Маршрута SW, где устойчивое аппроксимирование кривыми и наложение выполняются. Вспомните, что птичий глаз вывод производится один раз приблизительно в два кадра, а не на каждом последовательном кадре. Аппроксимирование кривыми и наложение поэтому помещаются в активированную подсистему, которая только включена, когда новые маршруты эго производятся.
Подсистема функции MATLAB Драйвера управляет синхронизацией между аппаратным и программным обеспечением. Первоначально это находится в состоянии опроса, где это выбирает вход dataReady равномерно на кадр, чтобы определить, когда оборудование буферизовало полное [40x1] вектор координат маршрута. Если это происходит, это переходит в программное обеспечение, обрабатывающее состояние, где swStart и процесс выходные параметры сохранены высоко. Драйвер остается в программном обеспечении, обрабатывающем состояние, пока swDone вход не высоко. При наблюдении, когда процесс вывел циклы назад к входу swDone с промежуточным блоком перехода уровня, существует эффективно постоянный бюджет времени, заданный для подсистемы FitLanesandOverlay, чтобы выполнить подбор кривой и наложение. Когда swDone будет высок, Драйвер перейдет в состояние синхронизации, где swStart, как сохранилось, низко указывает к оборудованию, что обработка завершена. Синхронизация между программным и аппаратным обеспечением такова, что оборудование будет содержать [40x1] вектор координат маршрута до переходов сигнала swStart назад к низко. Когда это произойдет, dataReady вывод оборудования затем перейдет назад к низко.
Подходящая подсистема Маршрутов и Наложения включена Драйвером. Это выполняет необходимую арифметику, требуемую в порядке соответствовать полиному на данные о координате маршрута, полученные во входе, и затем чертит подходящий маршрут и координаты маршрута на изображение "Бердз Ай".
Подходящая подсистема Маршрутов запускается, RANSAC основывал соответствующую строке стандартную программу на сгенерированных кандидатах маршрута. RANSAC является итеративным алгоритмом, который создает таблицу inliers на основе меры по расстоянию между предложенной кривой и входными данными. При выводе этой подсистемы, существует [3x1] вектор, который задает полиномиальные коэффициенты, найденные стандартной программой RANSAC.
Подсистема Маркировок Маршрута Наложения выполняет операции визуализации изображений. Это накладывает маршруты эго и кривые, найденные соответствующей маршруту стандартной программой.
Модель включает два видеодисплея, показанные в вывод результатов симуляции. Отображение BirdsEye показывает вывод в деформированной перспективе после того, как кандидаты маршрута были наложены, полиномиальный подбор кривой был выполнен, и получившийся полином наложен на изображение. Отображение OriginalOverlay показывает BirdsEye вывод, деформированный назад в исходную перспективу.
Из-за больших форматов кадра, используемых в этой модели, симуляция может относительно занять много времени, чтобы завершиться. Если у вас есть лицензия HDL Verifier™, можно ускорить скорость симуляции непосредственно рабочим подсистема Детектора Маршрута HDL в оборудовании с помощью FPGA в Loop(TM).
Проверять и сгенерировать HDL-код сослались в этом примере, у вас должна быть лицензия HDL Coder™.
Чтобы сгенерировать HDL-код, используйте следующую команду.
makehdl('LaneDetectionHDL/HDLLaneDetector')
Чтобы сгенерировать испытательный стенд, используйте следующую команду. Обратите внимание на то, что генерация испытательного стенда занимает много времени из-за большого размера данных. Можно хотеть уменьшать время симуляции прежде, чем сгенерировать испытательный стенд.
makehdltb('LaneDetectionHDL/HDLLaneDetector')
Для более быстрой симуляции испытательного стенда можно сгенерировать испытательный стенд SystemVerilog DPIC с помощью следующей команды.
makehdltb('LaneDetectionHDL/HDLLaneDetector','GenerateSVDPITestBench','ModelSim')
Этот пример обеспечил понимание проблем разработки систем ADAS в целом с особым акцентом, заплаченным за ускорение критических частей проекта в оборудовании.
[1] Р. К. Сэцода и Моан М. Триведи, "Основанный на видении Анализ Маршрута: Исследование Проблем и Подходы для Встроенной Реализации", 2 013 Конференций по IEEE по Компьютерному зрению и Распознаванию образов.
[2] Видео от Набора данных Маршрутов Калифорнийского технологического института - Мохамеда Али, "Оперативное Обнаружение Маркеров Маршрута на Городских улицах", 2 008 IEEE Интеллектуальный Симпозиум Автомобилей - используемый с разрешением.