USB3Vision и GenICam. Взгляд изнутри. I

    Введение


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

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

    До 2006 года не существовало стандарта создания таких систем. Это привело к тому, что на рынке обосновалось большое кол-во устройств от разных производителей, которые были разработаны по внутренним закрытым стандартам компаний. Потребителям приходилось придерживаться одного производителя камер, так как переход к другому производителю требовал перехода и на другое программное обеспечение для новых камер. Все это выливалось в необходимость заново подготавливать производство для работы. Требовалась универсальность как самих камер, так и программного обеспечения для них. В 2003 году Европейская Ассоциация Машинного Зрения (EMVA) и ведущие производители в этой области объединились для создания общего, исчерпывающего стандарта управления камерами машинного зрения. Спустя некоторое время появился интерфейс GenICam.

    Интерфейс расшифровывается как Generic Interface Camera, но, логичнее, называть его протоколом или стандартом, т.к. он накладывается поверх интерфейсов передачи данных. GenICam задает единый для всех камер API, при помощи которого происходит управление устройством. Также, он определяет структуру прошивки управляющего контроллера камеры, что немаловажно. Благодаря всему этому, появилась возможность в использовании разных камер машинного зрения с разным управляющим ПО. Причем универсальность не ограничивается заменой камеры на другую с аналогичным физическим интерфейсом, например USB3.
    GenICam задал направление развития камер машинного зрения, которому отрасль следует и, вероятнее всего, будет следовать еще долго.

    Цель GenICam


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



    Рис. 1 — принцип GenICam

    Составляющие модули


    Стандарт поделен на взаимосвязанные модули. Далее, будет кратко дано пояснение к каждому модулю.

    GenApi


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

    GenTL


    Generic Transfer Layer. Необходим для определения устройства системой и коммуникации с одним устройством или с несколькими. Помимо этого, предоставляет средства для передачи потоковых данных от камеры к хосту. Модуль в большей степени относится к управляющему ПО хоста, т.к. камера, в подавляющем большинстве случаев, является ведомым устройством. Обеспечив рабочую связку из GenApi и GenTL можно гарантированно получить программный проект начального уровня для работы с камерой.

    GenCP


    Передача управляющих данных через GenTL осуществляется в соответствии с протоколом GenCP. Generic Control Protocol определяет вид посылок от хоста к устройству и формат ответного сообщения от устройства к хосту. Данный протокол ориентирован на пакетную передачу данных и работает по принципу — отправка команды, ожидание подтверждения с отслеживанием времени ожидания.

    SFNC


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

    CLProtocol


    Предоставляет API для взаимодействия GenApi и интерфейса CameraLink. Подробнее разбирать этот модуль мы не будем, т.к. в дальнейших частях речь пойдет об интерфейсе USB3.

    Заключение


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

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

    Ну. И что?
    Реклама
    Комментарии 17
    • 0
      Интересная тема, планируете серию про сам стандарт или библиотеки (например github.com/AravisProject/aravis) тоже затронете?
      • 0
        Пока планирую про стандарт. После, хотел привести пример доступной реализации камеры в коде и железе. Библиотеки затрону, но скорее всего, очень поверхностно.
      • 0
        Как GeniCam соотносится с ONVIF?
        • 0
          Никак, это разные стандарты. На базе GenICam работают системы машинного зрения, а ONVIF предназначен для IP-камер.
          • 0
            Понятно, спасибо. Сходу было не очевидно.
        • 0

          Уважаемый Автор!
          Вы пишите :"Помимо усиления используются и другие опции если это позволяет электроника. GenApi необходим для описания функционала камеры и ее параметров, например, ширины и высоты кадра в пикселях".


          В этой связи прошу сообщить, является ли в GenApi "конфигурирование камер" статической или может изменяться от кадра к кадру?
          Например позволяет ли данный или иной модуль совместно со специальной камерой на одном кадре строить BMP кадр -отображение прямоугольного изображения всего поля зрения объектива камеры с определенной угловой разрешающей способностью, оцифровывать и отправлять по одному адресу, а в следующем кадре BMP выводить только небольшую прямоугольную часть изображения с заданными угловыми координатами его центра и отправлять следующий кадр на другой адрес.
          Затем снова BMP кадр всего поля зрения объектива ..., затем ВМР кадр небольшой части изображения с новыми угловыми координатами центра этой части?

          • 0
            Если следовать стандарту, а ему лучше следовать, то задача в примере будет решена неверно.
            Каждая посылка видеоданных содержит в себе, помимо самих видеоданных, заголовок и окончание пакета.
            В них имеется информация о кадре, который отправляется в хост.
            После того, как хост даст команду, разрешающую потоковую передачу, заголовок и окончание пакета изменить будет
            уже нельзя. Их можно будет изменить только после окончания приема данных и выдачи хостом сигнала остановки.
            Потребуется время на изменение информации о кадре и, возможно, за это время начнется новый кадр, который будет пропущен. Если нет требования в неразрывности потока в котором выделяется окно интереса, то такой вариант подойдет. На счет разных адресов. Как я понял это адреса буферов в памяти компьютера.
            Разные буфера, теоретически, сделать можно, но тут нужно углубиться в GenTL, а я, к сожалению, занимаюсь только аппаратной частью камеры и прошивкой контроллера USB.
            • 0
              Каждая посылка видеоданных содержит в себе, помимо самих видеоданных, заголовок и окончание пакета.
              В них имеется информация о кадре, который отправляется в хост.

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

            • 0
              С одной стороны, у интерфейса GenTL есть понятие Stream, которое означает что камера способна отсылать более чем один поток изображений, и, наверное, в теории, можно настроить камеру так как вы сказали.
              Вопрос лишь в том, найдется ли такая камера, которая это будет поддерживать… честно, я таких камер не знаю, хотя в нашей компании мы (вроде) пытались сделать нечто подобное, причем только на одном потоке (но тут получатель был один). На сколько это было успешно — не знаю.
              Так же, в стандарте GEV (и скорее всего U3V, я просто его изнутри не копал) с каждым кадром приходит header и trailer которые сообщают размер, смещение, формат пикселя, временнУю метку и прочее для каждого кадра.
              Соответственно в общем случае, размер кадра не фиксирован, и может изменяться (ну вы понимаете, куда вас пошлют лентяи программисты, которых заставят отслеживать размер каждого кадра и менять выходной канал в соответствии с новым кадром :) ) — но это в пределах одного потока, который приходит по одному адресу (хотя в GEV никто не запрещает этому адресу быть Broadcast или Multicast).
              • 0
                в нашей компании мы (вроде) пытались сделать нечто подобное, причем только на одном потоке

                Как бы узнать результаты работы. Вдруг успешно?

                • 0
                  Быстрый поиск по открытой документации на сайте производителя показал только CameraLink камеру.
                  Цитата из документации:
                  The dual video mode allows two independent acquisition
                  frames (Frame A and Frame B) to be programmed with independent control of exposure
                  time, area of interest (AOI), subsampling, gain, offset and wide dynamic range parameters.


                  То есть с «железной» точки зрения задача решена… только вот «заданное разрешение» задается все таки до начала захвата… вернее задать-то можно когда угодно, только вот когда желаемый кадр придет?
              • 0
                И еще уточняющий вопрос, указаные в вашем вопросе изменяемые параметры, это, как я понимаю AOI (Area of interest — OffsetX, OffsetY, Width, Height). Вас только AOI интересует или просто первый пришедший на ум параметр?
                Если только AOI — то тогда, в общем случае, не вижу необходимости заморачиваться, проще в такой задаче получить полный кадр и дальше программно работать только с заданым подкадром.
                • 0

                  В первой части моего сообщения выражаю Вам благодарность за ссылку, по которой пройду немедленно после получения доступа к "безлимитному Интернету".
                  В отношении вопроса, то ответ -конечно меня интересует "область интереса" (AOI).
                  Это одна из двух задач.
                  Однако идти по более простому варианту получения видео изображения "области интереса" из полного кадра мне, в свете рассматриваемой статьи, не интересно.
                  Дело в том, что по моим прогнозам площадь "области интереса" менее 5% от площади всего изображения. Поэтому мне привлекательнее сократить время считывания "области интереса" непосредственно камерой по сравнению со временем считывания полного кадра в 20 раз.
                  В этом я предполагаю будет гешефт. который можно будет использовать.
                  Конечно, если мне не удастся найти соответсвующую камеру, купить и настроить, то придется идти по Вами предложенному пути.

                  • 0
                    Не могу говорить о GigE Vision и CameraLink, т.к. работаю с USB3. При инициализации хостом устройства на USB, хост, в том числе, запрашивает параметры канала передачи видеоданных. Создаются так называемые эндпоинты(конечные точки). У хоста имеется свой эндпоинт(точка) и у устройства, а между ними создается канал передачи. В дескрипторе, который описывает эндпоинт четко зафиксирован максимальный размер данных, который может быть передан устройством в рамках одной посылки. Вам необходимо переключаться от вывода полного кадра к выводу только области интереса. Если вы хотите оптимизировать передачу данных, то вам нужно будет переинициализировать эндпоинт канала передачи видеоданных и внутренние буфера контроллера с новыми параметрами. Это влечет за собой перезагрузку устройства и новое подключение к хосту. Проще всего не менять настройки эндпоинта и продолжать принимать полный кадр с последующей обработкой на хосте. Либо, изначально определиться с размером области интереса и настроить передачу под нужные параметры и выводить только AOI.
                    • 0
                      Если вы хотите оптимизировать передачу данных, то вам нужно будет переинициализировать эндпоинт канала передачи видеоданных и внутренние буфера контроллера с новыми параметрами. Это влечет за собой перезагрузку устройства и новое подключение к хосту.

                      Эм… может я конечно что-то в чем-то не понимаю (как я говорил, я U3V не копал), но мне кажется это неправильным и нелогичным — а если мы хотим поменять разрешение кадра? Это что же, перегружать камеру? А значит терять тщательно подобранные параметры камеры (например время экспозиции и настройки триггера)?
                      Исходя из того, что я вижу в наших исходниках — хост и камера договариваются об аналоге MTU, и дальше камера передает Leader + N*MTU + FinalTransfer + Header, из которых и собирается кадр.

                      Ну вот, собственно и подтверждение: www.visiononline.org/userAssets/aiaUploads/file/USB3_Vision_Specification_v1-0-1.pdf (не исключаю что старый, просто первый попавшийся в гугле)
                      5.2 Streaming Mechanism
                      5.2.3 Payload Sequence
                      The SI Payload Transfer Size, SI Payload Transfer Count and SI Payload Final Transfer1
                      Size and SI Payload Final Transfer2 Size registers describe the host´s requirements
                      concerning payload data layout. If the device has less payload data to send than expected by the
                      host it must complete the outstanding transfer(s) using short or zero-length packets.
                      The payload is divided into “equal sized blocks” + “final transfer1”+ “final transfer2”.
                      Properties of “equal sized blocks” are described by SI Payload Transfer Size and SI Payload
                      Transfer Count.
                      The maximum size of payload data in bytes the device may send can be calculated as follows:
                      maximum_size_of_payload_data_in_bytes = SI Payload Transfer Size * SI Payload Transfer
                      Count + SI Payload Final Transfer1 Size + SI Payload FinalTransfer2 Size


                      Таким образом, изменение размера кадра ведет к изменение TransferCount и FinalTransferSize 1/2, но никак не перезагрузке USB
                      • 0
                        Речь идет именно об оптимизации потока.
                        Поэтому мне привлекательнее сократить время считывания «области интереса» непосредственно камерой по сравнению со временем считывания полного кадра в 20 раз.

                        Если область интереса умещается в один буфер эндпоинта и там остается свободное место, то, при необходимости оптимизации передачи данных, следует поменять настройки эндпоинта и прикрепленных к нему буферов для того, чтобы не передавать лишние байты. Но если в оптимизации потребностей нет, все остается как есть и AOI будет собираться с лишними байтами в буферах — Leader + Payload + Trailer. Конечно же перезагрузка камеры логически не укладывается в GenICam.
                        Можно сказать, что это пример подстройки канала передачи под AOI для оптимизации потока. Необходимо изначально выбрать удобный размер эндпоинта, т.к. для изменения его настроек в самом простом случае следует изменить прошивку контроллера для работы с новыми параметрами. А это, как понимаете, вообще неудобно.
              • 0

                GenTL это всё-таки Transport Layer.
                GenICam, как стандарт, описывает только формат xml файла который определяет, по какому регистру лежит тот или иной параметр.
                Так же среди прочих "модулей" вы не назвали модуль PFNC, без которого прием и передача изображения была бы не возможна, но, как и SFNC это только список рекомендаций по именованию параметров.
                Ещё есть огромный недостаток в полной не связанности модулей GenTL и GenICam, и, зачастую, оторванности стандартов U3V, GEV и CameraLink друг от друга…
                Хотя CameraLink он вообще не от мира сего… Стандарт который описывает только физику, а про программное обеспечение они практически забили.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое