Видение на основе событий и фреймов: практическое сравнение

Что такое фреймовое видение?

Кадровое зрение захватывает сцену в виде полных изображений через равные промежутки времени, например 30, 60 или 120 кадров в секунду. Каждый кадр содержит плотную пространственную информацию, что делает обычные камеры идеальными для распознавания объектов, анализа цвета, проверки, картографии и большой экосистемы программного обеспечения, построенной на основе тензоров изображений.

Компромисс заключается в том, что каждый кадр перемещает по конвейеру полное изображение независимо от того, изменилась сцена или нет. Для быстрого цикла принятия решения время экспозиции, период кадра, считывание показаний датчика, транспортировка, преобразование изображения и вывод - все это способствует сквозной задержке. Высокая частота кадров уменьшает интервал выборки, но обычно увеличивает пропускную способность, трафик памяти, мощность и тепловую нагрузку.

Что такое событийное видение?

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

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

Как датчик изображения на основе событий меняет путь данных

Полезная справочная система отображает весь путь от сбора данных с датчиков, фильтрации и обработки до выходных данных приложения. Инструментируйте эти границы, чтобы требования по задержке и скорости передачи данных можно было оценивать на всех этапах.

Ключевое архитектурное различие заключается не просто в «более быстрой камере и более медленной камере». Традиционный конвейер машинного зрения часто начинается с полного буфера изображения. Конвейер, основанный на событиях, может начать обработку отдельных событий или небольших окон событий сразу по их прибытии. Это позволяет выполнять фильтрацию, выравнивание временных меток, логику интересующей области и функции движения рядом с датчиком, не дожидаясь полного кадра.

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

Видение, основанное на событиях, и видение, основанное на фреймах

Задержка: измерение от датчика до принятия решения, а не одного компонента

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

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

Программное обеспечение для машинного зрения на основе событий и рекомендации по SDK

Стек программного обеспечения для машинного зрения на основе событий обычно требует настройки устройства, декодирования событий, обработки временных меток, фильтрации, визуализации, записи и воспроизведения. Полезное видение на основе событий SDK должно также упростить синхронизацию внешних триггеров и других датчиков, проверять частоту событий и воспроизводить захваченную последовательность во время разработки алгоритма.

Для производственных систем программное обеспечение должно выходить за рамки настольного компьютера SDK. Команды должны определить, как события перемещаются в ресурсы FPGA, MCU, MPU или NPU; как хранится калибровка; как синхронизируется время; и как можно воспроизвести полевые журналы. Если алгоритм преобразует события в накопленные кадры, окно накопления становится явным компромиссом между задержкой и информацией.

Где полезно видение событий

Типичные приложения видения на основе событий включают высокоскоростное отслеживание целей, роботизированные манипуляции, оптический поток, анализ вибрации или движения, быстрый промышленный контроль и автономное восприятие в сценах с большими изменениями яркости. Самыми сильными вариантами использования обычно являются те, где тонкая временная структура напрямую улучшает решение, а не просто заменяет традиционную камеру.

Событийное видение оборонных и автономных платформ

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

Когда гибридная архитектура камеры лучше

Многие практические системы выигрывают от комбинирования модальностей. Фреймы могут обеспечивать семантический контекст и удобочитаемые образы, в то время как события привносят временные детали. Тепловые, инерционные датчики или датчики дальности могут повысить надежность. Fusion особенно полезен, когда приложению требуется одновременно вопрос «что это?» и «когда именно и как оно переместилось?»

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

Практическая эталонная архитектура видения на основе событий

Эталонная система может размещать детерминированную фильтрацию и работу с метками времени в FPGA, вывод искусственного интеллекта в NPU или ускорителе, сервисы приложений в MPU, а надзор в MCU или ядре реального времени. Выбор правильного раздела зависит от частоты событий, архитектуры модели, пропускной способности памяти и внешних интерфейсов. Наш FPGA против NPU против MPU Руководство по Edge AI объясняет это разделение более подробно.

Контрольный список выбора

• Определите максимально допустимую задержку принятия решения датчиком.
• Измерьте ожидаемую скорость движения, дальность освещения и активность сцены в наихудшем случае.
• Решите, требуется ли абсолютная интенсивность изображения, цветность или удобочитаемое видео.
• Оцените пропускную способность и объем памяти как для типичных, так и для наихудших сцен.
• Подтвердите зрелость алгоритма, набора данных и видения на основе событий SDK.
• Планируйте синхронизацию с кадровыми, тепловыми, инерционными или внешними источниками запуска.
• Проведите тестирование всего конвейера перед остановкой вычислений, базовой платы и теплового проектирования.