 |
 |
Первый раз с обработкой видеосигнала под ОС QNX 4.25 нам пришлось столкнуться в 2002 году в проекте автоматизации гаражных модулей, производимых ОАО "Баррикады". Гаражный модуль представляет собой закрытую, оформленную в современном стиле конструкцию, пристраиваемую к любому зданию и состоящую из лифтового устройства и ячеек хранения машин. Высота пристройки 10 этажей, соответственно количество единиц паркуемого автотранспорта 20 штук. В данном проекте компания НПП "Автоматика-С" спроектировала и реализовала автоматизированную систему управления загрузки/выгрузки легковых автомобилей. В систему управления, основанную на универсальном SCADA пакете "СТАТУС-4", интегрирована дополнительная система визуального контроля габаритов автомобиля на лифтовой платформе, с автоматическим анализом видеоизображения на предмет корректности габаритов и положения автомобиля в допустимых пределах.
Необходимость создания дополнительной видеоподсистемы определили несколько причин:
1. Для повышения надежности работы оператору требовалась система визуального контроля площадки во время установки автомобиля в гаражный модуль, т.е. помимо всего процесса управления оператор визуально контролирует отсутствие людей в машине и т.д.
2. Высокие требования заказчика по компактности всей конструкции в целом, требовали предельно четкой установки автомобиля на лифтовую платформу. Возможная модификация конструкции позволила бы снизить точность позиционирования автомобиля на перемещающей платформе, но влекла за собой большие переработки конструкции и увеличение размеров комплекса.
3. Заложенные первоначально в проект оптические датчики, для замера габаритов автомобиля обладали сложной настройкой при монтаже и не могли дать полной оценки габаритов. В процессе монтажа выявились проблемы по точности позиционирования передатчика и соответствующего приемника на не жестко закрепленной конструкции подъемного механизма.
4. Стоимость системы из четырех видеокамер и программном обеспечении видеоподсистемы в полтора раз дешевле, системы с использованием оптических датчиков. Дополнительным плюсом было то, что общее видео наблюдение оператором уже предусматривалось проектом.
Стоит отметить, что, приступая к работе над новой подсистемой, мы не имели абсолютно никакого опыта работы с видеоданными.
Встал выбор оборудования для передачи видеоизображения в компьютер. Известно, что ОС QNX не может похвастаться большим количеством поддерживаемого оборудования, но в этот раз решение было найдено быстро. Санкт-Петербургская фирма ЗАО "МГП "ИМСАТ" разработала драйвер под ОС QNX 4.25 для карт видеозахвата, построенных на чипе Conexant BT848. Данный чип применяется в подавляющем большинстве недорогих плат захвата видеосигнала и TV-тюнерах, что позволяет без проблем приобрести необходимое оборудование. Стоимость простейших плат ввода изображения порядка 30$. Инсталляция драйвера предельно проста, с драйвером поставляется пример программы для начала работы, который позволяет написать первую программу получения изображении с камеры через пару часов после начала знакомства. Функциональные возможности драйвера позволяют регулировать: яркость, контрастность и разрешение изображения получаемого с видеокамеры.
После того как вопрос ввода изображения был решен, мы приступили ко второй части разработки - анализу изображения и соответственно стыковки подсистемы со SCADA пакетом.
Основной вопрос, как и что, анализировать на принимаемом с видеокамер изображении на предмет наличия посторонних предметов (в нашем случае - частей автомобиля) в опасных зонах.
Первоначально планировалось обойтись 3 видеокамерами для получения всей необходимой информации о положении и размере автомобиля на лифтовой площадке, но впоследствии стали использовать 4 видеокамеры и соответственно 4 карты видеозахвата.
Стоит отметить, что карты видеозахвата часто имеют два видеовхода, в ряде случаев 4. При необходимости, драйвер может работать со всеми 4 входами на одной карте захвата. Почему мы остановились на соотношении одна камера - одна карта видеозахвата? Причина во времени переключения между видеовходами на одной карте. Чип Conexant BT848 умеет работать только с одним видеовходом. В итоге, для установки четкой картинки на экране требуется 1-2 секунд, это связано с тем, что при переключении видеовхода карте требуется время на синхронизацию с передающим потоком. Такое время нас не устроило. Далее в статье все величины и цифры приводятся при работе системы в конфигурации 4 видеокамеры и 4 карты видеозахвата.
В процессе создания подсистемы анализа изображения было испробовано несколько методов. Все они основаны на том или ином методе анализа зон. На экране выделяются области изображения, в которых не должен присутствовать посторонний предмет или наоборот обязан находится, соответственно зоны называются аварийные или разрешенные. Позиции и размеры зон настраиваются после монтажа камер, при проведении пусконаладочных работ. В процессе работы подсистемы анализа, признаки наличия посторонних предметов в зонах передаются в базу оперативных значений SCADA системы "СТАТУС-4", под управлением которой происходит работа гаражного модуля. В случае расположения автомобиля в любой аварийной зоне блокируется возможность его перемещения на лифтовом механизме.
Работа с картой видеозахвата осуществляется с помощью драйвера, который открывает доступ к памяти карты при помощи механизма shared memory. На время работы, создается стандартное устройство ввода/вывода для возможных настроек работы камеры.
Пример процедуры инициализации:
// открытие устройства ввода/вывода для осуществления настроек камеры и проверки наличия драйвера
if((i=open("/dev/Bt848_0",O_RDONLY))<0){perror("open failed"); exit(1); }
// настройка уровня яркости камеры
if (qnx_ioctl(i,METEORSBRIG,&brigth,sizeof(brigth),rbuf,sizeof(rbuf))<0){ perror("ioctl Brigthness failed");exit(1);}
// открытие доступа к разделяемой памяти карты видеозахвата
fd=shm_open("Bt848_0",O_RDWR,0777);
mmbuf=(char *)mmap((caddr_t)0,size,PROT_READ,MAP_SHARED,fd,(off_t)0);
if(mmbuf==(char *)-1){ perror("mmap failed"); exit(1); }
return(0);
Инициализация виджета типа PtLabel_t, отвечающего за вывод изображения на экран:
PhArea_t area;
PtArg_t arg[10];
PhImage_t *diff;
PtWidget_t *widget;
// выделение памяти и инициализация структуры типа PhImage_t
diff=make_image(COLS,ROWS,3);
n=0;
area=widget->area;
area.size.w=COLS;
area.size.h=ROWS;
PtSetArg(&arg[n++],Pt_ARG_LABEL_TYPE,Pt_IMAGE,0);
PtSetArg(&arg[n++],Pt_ARG_LABEL_DATA,diff,sizeof(PhImage_t));
PtSetArg(&arg[n++],Pt_ARG_AREA,&area,0);
// применение настроек к виджету вывода изображения на экран
PtSetResources(widget,n,arg);
Обновление изображения у виджета выглядит следующим образом:
memcpy(diff,mmbuf,ROWS*COLS*3);
// анализ изображения
…
// "повреждение" виджета для его перерисовки
PtDamageWidget(widget);
Благодаря простоте получения данных и их выдачи на экран, дальнейшая работа с изображением, свелась к работе с байтовыми массивами, в которых, в формате RGB(3 байта на точку, один байт на каждый цвет), построчно, располагаются точки, составляющие изображение, к которым, остается только применить математические методы обработки.
Перед началом работы мы проанализировали ряд специализированных систем видеонаблюдения. Ниже приведенные алгоритмы, частично разработаны на их основе, частично разработаны с нуля.
Метод первый:
Создание эталона помещения по сигналу открытия ворот для въезда автомобиля и последующее сравнение эталона с помещенным в него автомобилем. Точнее сравнение не всей области эталона, а только предельно допустимых участков. Первый способ, который применен и… сразу минусы - появление автомобилей от белого до черного цветов сильно влияет на общую освещенность картинки, получаемой с камеры. Хотя, большинство видеокамер имеют автоматическую коррекцию освещенности и возможность ее отключения, ни в том, ни в другом случае приемлемых результатов достичь не удалось. Итог - практически не возможно сравнить эталонное изображение с текущим.
Метод второй:
Является развитием первого, за исключением того, что предпринимается попытка автоматической коррекции эталона по изменяющейся освещенности помещения. Итог - как и в первом методе неудовлетворительный.
Метод третий:
Развитие первых двух методов с фиксацией эталона. Добавляется создание на противоположных камерам объектах полос белого цвета в местах аварийных зон. Таким образом, появление посторонних предметов, на фоне полос ярко-белого цвета фиксируется гораздо лучше, что позволяет повысить точность сравнения с эталоном. Минусы прежние - зависимость от освещенности. Стоит отметить, что освещенность может меняться не только от въехавшего автомобиля, но и от восхода/захода солнца, т.к. внешний дизайн гаражных модулей предполагает использование полупрозрачных конструкций из пластика или стекла.
Метод четвертый:
Отличается от предыдущих трех. Появляется специальная дополнительная "эталонная белая" зона. При настройке, зона позиционируется на место, где присутствует полоса с эталонным белым цветом, но которое заведомо не может перекрыться въехавшим автомобилем. В этом методе мы перестаем фиксировать эталонное изображение, с которым происходило сравнение. Вместо эталона изображения производится расчет текущего эталона белого цвета по "белой" зоне при каждом обсчете. Далее происходит сравнение точек анализируемых зон с эталоном белого цвета. Плюсы метода - пропадает основная проблема изменения освещенности, т.к. пересчет эталона белого цвета происходит вместе с ее изменением. Может сложиться впечатление, что белую машину на белой полосе не будет видно, но это не так - контуры автомобиля имеют определенные изгибы и неровности ( не белый бампер, наконец), которые на видеоизображении передаются различными оттенками, отличными от белого.
Метод пятый:
Является усовершенствованием четвертого метода в том, что "белая" зона появляется для каждой из контролируемых зон. Причина - различная освещенность самих контролируемых зон в разных частях помещения и, как следствие, необходимость настройки "белой" зоны для каждой из них. На пятом методе мы и остановились, т.к. достигли удовлетворительного по точности результата.
Итоговые характеристики подсистемы анализа изображения:
1. Черно-белая камера с сенсором 1/3" , матрицей 500 на 482 точки, чувствительностью 0.01 Люкс.
2. Черно-белый формат отображения на экране монитора
3. Рабочее разрешение на экране по одной камере 320 на 240 точек
4. Удаление камеры от анализируемой области 3-5 метров
5. Точность определения объекта 3-5см
К подсистеме наблюдения выдвигалось еще одно требование - малый расход ресурсов компьютера, по причине того, что помимо наблюдения, на компьютере выполняются задачи управления гаражным модулем и эти задачи обладают первостепенной важностью. Специальных оптимизирующих действий к перечисленным выше методам не применялось, оценив итоговую загрузку работающей системы, мы посчитали это не целесообразным. Загрузка машины класса Celeron 600 со встроенной графической подсистемой на чипсете Intel 815(поддерживается драйверами Photon 1.14) составила 15-20%, при включенном анализе изображений по всем 4 камерам и одновременном выводе всех четырех изображений на экран. Период обновления изображения, по всем камерам, 2 раза в секунду. Отдельно отметим, что помимо работы видеоподсистемы на экране отображаются основные мнемосхемы для управления модулем.
Подводя итог, хочется отметить, что основная разработка подсистемы заняла порядка двух рабочих недель. Малый срок разработки был определен двумя моментами, первое, стабильным и простым взаимодействием прикладной программы с драйвером плат видеозахвата. Второе, графическая оболочка Photon и Photon Application Builder, которые, в совокупности, являются мощным и надежным инструментом разработчика.
ООО НПП Автоматика-С
e-mail: [email protected]
web: http://www.avts.ru
tel: (095)191-6210, 191-9553
Василий Бризицкий, руководитель отдела проектирования АСУТП.
ЗАО "МГП "ИМСАТ"
e-mail: [email protected]
tel: (812)259-9282
Василий Бризицкий
Промышленные контроллеры АСУ - 2004
|
|
