CC BY
147
УДК 004.932
МОДЕЛИРОВАНИЕ МЕТОДОВ СЖАТИЯ ВИДЕОИНФОРМАЦИИ В СИСТЕМАХТЕХНИЧЕСКОГО ЗРЕНИЯ
В. А. Бархоткин, П. А. Руденко, Н.А. Тюгай, А.И. Терентьев
Рассмотрены проблемы проектирования систем технического зрения, пути их решения, проведён анализ и моделирование методов сжатия видеоинформации, даны рекомендации по проектированию и отладке программной части системы технического зрения.
Ключевые слова: техническое зрение, видеопоток, сжатие, кодек, цифровой сигнальный процессор, визуализация, QNX, ffmpeg, x264.
В настоящее время большое распространение получили системы дистанционного управления (СДУ). Такие системы используются как в гражданской, так и в военной технике [1]. Например, дистанционный запуск автомобиля или дистанционное управление системой отопления здания, создают дополнительные удобства человеку. Беспилотные летательные или подводные аппараты, роботы-сапёры, наземные робототехниче-ские комплексы (РТК), создаваемые в интересах Министерства чрезвычайных ситуаций и Министерства обороны обеспечивают безопасность проведения работ в условиях опасных для жизни.
Для повышения эффективности дистанционного управления оператору необходимо получать данные о том, в каких условиях находится управляемый объект. Согласно [2] до 90 % информации человек получает при помощи органов зрения, а нахождение оператора на удаленном пункте управления (ПУ) лишает его возможности объективного восприятия окружающей обстановки в непосредственной близости от РТК. В СДУ всю визуальную информацию оператор получает от системы технического зрения (СТЗ), следовательно, одним из определяющих факторов качества управления, будут являться технические возможности таких систем.
Система технического зрения должна решать задачу получения визуальной информации, ее обработки, передачи и воспроизведения на ПУ. В рамках решаемой задачи будем считать, что СТЗ функционирует в рамках следующих ограничений:
1) передача информации осуществляется по цифровому радиоканалу с пропускной способностью до 10 Мбит/с;
2) дальность действия радиоканала не превышает 1000 метров;
3) визуализация информации должна осуществляться в цветном режиме;
4) разрешение видеопотока на экране оператора не ниже 720*576
точек.
Наличие требования использования радиоканала заданной пропускной способности может, на первый взгляд, показаться ограничивающим. Однако использование такого способа передачи есть и свои преимущества: цифровой канал устойчив к помехам, а отсутствие проводов в сочетании со специальными приемо-передающими устройствами позволяют сохранить высокую мобильность РТК в отличие, например, от проводной среды передачи данных
При разработке СТЗ следует использовать цифровую обработку видеосигнала. Это обеспечивает следующие преимущества:
1) улучшенная помехозащищённость;
2) широкие возможности цифровой фильтрации и повышения качества изображений;
3) возможность добавления в СТЗ новых функций, реализуемых программно (распознавание образов, слежение за движущимися объектами
[3]).
При передаче цифрового видеосигнала можно воспользоваться оценкой величины потока по формуле
^ = /-Ж • Н • s ,
где Г- величина потока, бит/с; f - частота следования кадров, кадр/с; Ж -ширина изображения, пиксел; Н - высота изображения, пиксел; 5 - размер одного пиксела, бит.
Таким образом, при передаче видеопотока с частотой 25 кадров в секунду разрешением 720*576 точек в кодировке ЯОБ888 (24 бита на каждый пиксель), трафик составит порядка 250 Мбит/с, что превышает допустимые значения, приведенные выше. Применение других форматов представления пикселей также не даст нужного результата (например, в формате УИУ422поток снизится в полтора раза, но все равно будет выходить за рамки допустимого). Одним из решений является применение сжатия с потерями. Недостатками такого решения будут:
1) необходимость определения компромисса между степенью сжатия и качеством изображения;
2) применение алгоритмов кодирования и декодирования приведет к росту вычислительной нагрузки, как на стороне объекта управления, так и на стороне оператора.
При построении системы технического зрения разобьем ее на три части: аппаратно-программный комплекс РТК, аппаратно-программный комплекс ПУ и интерфейс связи между ними (рис. 1). При таком подходе можно заниматься разработкой каждой части СТЗ независимо друг от друга, оставляя неизменным взаимодействие на протокольном уровне.
Рассмотрим разработку аппаратно-программного комплекса РТК. Одним из определяющих этапов проектирования является выбор алгорит-
ма сжатия видеоинформации. Выбранный алгоритм должен обеспечивать хорошее качество изображения, при наименьшей затрате вычислительных ресурсов. Для выбора алгоритма было проведено сравнительное тестирование различных кодеков. Тестовая последовательность изображений подвергалась сжатию и последующему визуальному осмотру (поскольку именно субъективное восприятие является определяющим при оценке качества видео). Испытания проводились на персональном компьютере следующей конфигурации:
- процессор IntelPentium® 4 CPU 3.00 ГГцГашйу(15) model(4) step-ping(3), L2 кэш 2048 КБ, HyperThreading, x86-64, MMX, SSE, SSE2, SSE3 начастоте 3000 МГц;
- материнская плата: ASUS P5P800-SE Rev l.xx;
- ОЗУ 1280 МбDDRSDRAM, 333 МГц;
- видеокарта Radeon 9200 PRO, 128 МБ, шина памяти 32 бита, 66
МГц;
- операционная система (ОС): GNU/Linux 3.0.0-1-amd64 с библиотеками «libc 2.13», «x264 0.118.2085+git8a62835-1», «libavcodec 53.5.0».
Рис. 1. Структурная схема СТЗ
При помощи утилиты ауеоёее, предназначенной для обработки аудио- и видеоданных ffmpeg [3], получались сжатые изображения, качество которых оценивалось визуально.
Примеры изображений представлены на рис. 2, а-г.
в г
Рис. 2. Примеры оцениваемых изображений: а - исходное изображение; б -результат сжатия кодеком ШЗРЕС, размер изображения 4070 байт; в - результат сжатия кодеком И264-Шга, размер изображения 4040 байт; г - результат сжатия кодеком И264, размер изображения 3320 байт
По результатам сравнения был выбран кодек Н264 как наиболее оптимальный по соотношению степени сжатия к качеству декодированного изображения. Дополнительными преимуществами выбранного алгоритма являются:
- использование сжатых ранее кадров в качестве опорных, поддерживается использование до 32 ссылок на другие кадры;
- гибкие функции чересстрочного сжатия;
- адаптивный выбор кодеком между размерами блока 4*4 и 8*8;
- независимое кодирование частей изображения, а также возможность посылать и получать их в произвольном порядке друг относительно друга, что может снизить задержку в приложениях реального времени, особенно при использовании на сетях, имеющих режим работы доставка
вне очереди.
Кроме этого, существует открытая кроссплатформенная версия данного кодека, распространяемая по лицензии GPL - x264 [4]. Для интегрирования алгоритма в программную часть можно воспользоваться библиотекой-надстройкой ffmpeg [3], также являющейся открытой и кросс-платформенной.
Рассмотрим разработку аппаратно-программного комплекса ПУ. В качестве вычислительного устройства автоматизированного рабочего места (АРМ) оператора предлагается использовать панельные ЭВМ, объединяющие в одном корпусе системный блок и жидкокристаллический монитор [5, 6].В качестве операционной системы будем использовать ОС реального времени (ОСРВ) QNX.
Программное обеспечение АРМ обеспечивает информационный обмен с подсистемами РТК, отображение информации на экране оператора, обработку состояний органов управления и передачу команд управления на РТК.
Одной из основных частей СТЗ является модуль визуализации видеоданных, поступающих от РТК. Для его разработки можно использовать компилятор языка С, входящего в состав ОСРВ QNX 6.5 [7]. Однако для повышения эффективности проектирования целесообразно использовать среду разработки QNX Momentics IDE, которая устанавливается на хост-систему под управлением Windows или Linux и имеет возможность сетевого подключения к клиентской машине на QNX, под которую разрабатывается проект. Данная IDE обладает удобным графическим интерфейсом, а также в ней существует поддержка компилятора языка C++.
Библиотеки для декодирования видеопотока собираются из исходных кодов, размещенных на официальных сайтах проектов (кодек x264 с сайта [4], надстройку ffmpeg с сайта [3]). Обе библиотеки написаны на языке C, что позволяет осуществлять их сборку в ОС QNX без установки дополнительных программ. Поскольку, библиотека ffmpeg является надстройкой над кодеками (обеспечивает удобный интерфейс к функциям кодирования/декодирования, выставления параметров, отслеживания ошибок), то и собирать библиотеки следует от уровня кодека вверх к уровню ffmpeg. Первой необходимо собрать библиотеку x264.
Несмотря на то, что библиотека x264 является кроссплатформен-ной, при сборке под QNX возникают проблемы, требующие корректировки структуры библиотеки и ряда дополнительных файлов. Связано это с тем, что большинство разработчиков используют более доступные и популярные ОС (Linux, BSD-системы, Windows). Следует отметить, что библиотека x264 обновляется ежедневно (в git репозитории доступны свежие сборки), поэтому некоторые из описанных ниже решений могут быть учтены в последующих релизах библиотеки.
В файлах x264.c, output/matroska.c и encoder/set.c присутствуют макросы X264_VERSION, однако компилятор их не может корректно обработать, из-за этого в данных файлах они не видны, что вызывает ошибку при сборке. Для устранения этой ошибки нужно доопределить макрос вручную. В данных файлах в начале программного кода нужно добавить определение:
#define X264_VERSION 'Version definition"
Текст замещающего выражения решающего значения не имеет, главное, чтобы макрос оказался определён.
Для устранения конфликтов с имеющимися определениями во встроенной библиотеке C из папки extras/ требуется удалить файлы stdint.h и inttypes.h.
В файле common/common.c необходимо внести следующие изменения:
#define atobool(str) ( name_was_bool = 1, x264_atobool( str, &b_error)) #define atoi(str) x264_atoi( str, &b_error ) /* добавляемстроки*/
+#ifdef_QNXNTO_
+#undefatof
+#endif /*_QNXNTO_*/
/* конец добавления */ #define atof(str) x264_atof( str, &b_error )
Данное исправление снимает определение функции atof, объявленное в библиотеках QNX, и переопределяет его на встроенную в кодек функцию x264_atof.
В файле configure необходимо добавить пункты для обработки
QNX:
fi
HAVE GETOPT LONG=0
+ *qnx*) + SYS="QNX" + define HAVE_MALLOC_H + HAVE_GETOPT_LONG=0 + CFLAGS="$CFLAGS -I\$(SRCPATH)/extras' + libm="-lm"
+
)
die "Unknown system $host, edit the configure"
thread="win32" fi
+ qNx)
+ cc_checkpthread.h -lc&& thread="posix" &&libpthread="-lc"
+ ;; *)
cc_checkpthread.h -lpthread&& thread="posix" &&libpthread="-
lpthread"
? ?
Выполнение указанных действий добавляет поддержку QNX для библиотекиx264, после этого конфигуратор будет корректно определять необходимые для построения библиотеки флаги для ОСРВ QNX.
В процессе сборки x264 под QNX производится проверка на включение файлов определения типов. Однако в QNX при подключении этих файлов определяется макрос _STDINT_H_INCLUDED, а не стандартный _STDINT_H (или его модификация _STDINT_H_), поэтому в файле x264.h нужно дополнить макрос проверки подключения этого файла, добавив проверку нового макроса:
#if ! defined(_STDINT_H) && !defined(_STDINT_H_) && \ + ! defined(_STDINT_H_INCLUDED) && \
! defined(_INTTYPES_H) && ! defined(_INTTYPES_H_) # ifdef _MSC_VER
После внесённых изменений можно собрать библиотеку. Процесс сборки является стандартным: сперва необходимо сконфигурировать библиотеку, для этого в терминале запускается скрипт конфигурации: sh configure --disable-asm --enable-shared,
означающий конфигурирование библиотеки для сборки, не используя ассемблерных команд и указывающий, что требуется разделяемая библиотека. Можно использовать и другие флаги конфигурации, описание которых можно получить командой shconfigure--help. После конфигурации можно начать сборку, используя команду make.
После завершения сборки библиотеки кодека можно перейти к сборке ffmpeg, исходный код которой доступен на официальном сайте [5]. В ней ничего исправлять не требуется, однако файл конфигурации требует запуска через bash, а не через стандартный shell. По умолчанию bash не входит в состав QNX 6.5, поэтому необходимо его установить. На сайте [8] можно найти описание установки приложений, однако эта инструкция заявляется для QNX 6.3. Для версии 6.5 необходимо загрузить ISO-образ диска (например, на хост-машину) и установить bash вручную. Дело в том, что формат файла .qpr представляет собой простой tar-архив, поэтому установка сводится к распаковке командой tar ^У7&мя_файла и перемеще-
нии бинарного файла в папку /bin. После этого можно переходить к bash непосредственно командой bash в терминале.
Запуск конфигурационного скрипта осуществляется через bash: ffmpeg^: bash ./configure --disable-yasm --enable-gpl --enable-libx264 --extra-cflags="-I /путь/к/х264^" --extra-ldflags="-L /путь/к/НЬх264^о" --disable-ffserver --disable-network.
Флаги конфигурации в данном случае означают следующее: --disable-yasm нужен, чтобы не использовать компилятор yasm (вместо него будет использоваться тот, который доступен по умолчанию),
--enable-gpl --enable-libx264 - указывает, что будет использоваться библиотека libx264, которая распространяется по лицензии GPL, --extra-cflags="-I /путь/к/x264.h"
--extra-ldflags="-L /путь/к/libx264.so" - необходимо, чтобы ffmpeg при сборке смогла найти используемые файлы от x264 (в качестве пути к файлам нужно указать путь, куда были собраны файлы библиотеки x264, путь можно указать как абсолютный, так и относительный),
--disable-ffserver --disable-network нужны, чтобы исключить ошибки при сборке сетевых приложений ffmpeg (которые не будут использоваться).
После завершения конфигурации сборка запускается командой
make.
В результате проделанных действий будут построены две библиотеки -ffmpeg и x264. Следует отметить, что библиотека ffmpeg состоит из нескольких частей, каждая из которых является отдельной библиотекой. Дальнейшие действия при разработке приложений, использующих эти библиотеки, не содержит ничего нового - используются стандартные флаги линковщика и компилятора. Стоит также отметить ещё раз, что описанные библиотеки написаны на языке C, поэтому, если основное приложение будет разрабатываться на языке C++, библиотечные заголовочные файлы необходимо включать внутри конструкции extern.
Это обусловлено тем, что, хотя C++ во многом вобрал в себя язык C, механизмы связывания функций в них различны, и подобная конструкция указывает компилятору на то, что функции из этих файлов хранятся в формате связывания C.
Рассмотрим аппаратную часть СТЗ. Структурная схема модуля видеозахвата представлена на рис. 3.
Восемь аналоговых камер передают сигнал на два четырехканаль-ных видео-АЦП TVP5158 со встроенным мультиплексором, с выхода которого сигнал поступает на высокопроизводительный процессор серии DaVinchi производства TexasInstruments. Предложенное решение имеет следующие особенности:
1) использование видео-АЦП на входе модуля позволяет использо-
вать аналоговые видеокамеры, как общего, так и специализированного назначения.
2) использование многоканальных АЦП TVP5158 с управлением по интерфейсу I2C позволяет реализовать аппаратное кодирование видеоинформации а также изменение таких параметров как яркость, контрастность, насыщенность изображения, позволяет менять цветовой баланс и производить преобразование цветного изображения в монохромное.
3) при необходимости к системе можно подключать дополнительные вычислительные устройства, поскольку каналы АЦП работают независимо друг от друга.
4) процессор TMS 320DM8168 линейки DaVinci содержит два ядра: ARM Cortex-A8 и DSP ядро, что позволяет использовать его для таких сложных вычислительных задач, как кодирование видео и обмен информацией с другими блоками по сети Ethernet.
Камера 1 — Камера 2 —
Камера 3-*
Камера 4 ►
Камера 5 -Камера 6 -Камера 7-Камера 8 -
TVP5158
четырёхканальный вцдео-АЦП
.TVP5158
. четырёхканальный . вцдео-АЦП мих 4-1
Видео 1-4
MUX 4-1
Управление К_по I2C_
Видео 5-6
Управление по I2C
Трансформатор интерфейса Ethernet
Ethernet
TMS320DM8168
DaVinci
ARM+DSP
Память DDR3-0
Память DDR3-1
Рис. 3. Структурная схема модуля видеозахвата
Программное обеспечение процессора осуществляет захват видео, сжатие видеоизображения, упаковку сжатой картинки в соответствии с используемым протоколом, отправку видеоданных по сети, а также приём, распаковку и формирование управляющих команд для видео-АЦП и кодека.
Применение кодека позволило сжать видеопоток до необходимого размера с сохранением хорошего качества изображения, что позволило осуществить передачу видеоинформации, не выходя за рамки ширины канала передачи данных, а найденные решения позволили использовать разработанное программное обеспечение на ОСРВ реального времени QNX.
Тестирование проводилось по следующей схеме: при помощи камеры, подключённой к модулю видеозахвата, получалось цветное изображение разрешением 720*576 точек, затем осуществлялось сжатие с применением кодека х264 и передача по сети ЕШегпйАРМ оператора, работающий под управлением ОСРВ QNX 6.5. Декодированный видеопоток отображался на экране оператора.
Оценка размера закодированного изображения является сложной задачей в связи с тем, что кодек х264 использует потоковое сжатие - выделяется кадр последовательности (он называется опорным или ключевым), кодируется, а последующие кадры кодируются не напрямую, а как разность между текущим и опорным. Частота следования опорных кадров является одним из важнейших параметров кодека - слишком большая их частота снижает эффективность сжатия, а слишком маленькая увеличивает риски потери большого фрагмента видео при повреждении одного лишь опорного кадра. Эффективность работы кодека оценивалась по величине потока видеоизображения. Результаты такой оценки приведены в таблице.
Результаты оценки работы кодека
Параметры кодека Средняя величина потока, Мбит/с Качество изображения
(исходное изображение, 25 кадров/с) 249 (расчётное значение) -
720*576, цветное изображение, 50 полукадров/с, каждый кадр - опорный 4 хорошее
720*288, цветное изображение, 25 кадров/с, каждый 50 кадр - опорный 2,5 хорошее
352*288, цветное изображение, 25 кадров/с, каждый 15 кадр - опорный 1 удовлетворительное
352*288, монохромное изображение, 25 кадров/с, каждый 15 кадр - опорный 0,7 удовлетворительное
Полученные результаты моделирования подтвердили, что применение кодека х264 значительно уменьшает видеопоток при достаточно хорошем качестве изображения. В дальнейшем можно еще оптимизировать работу кодека путём исследований влияния параметров кодека на качество получаемого изображения и величину потока данных.
Таким образом, предложенные решения по построению системы технического зрения могут быть использованы для робототехнических
комплексов различного назначения.
Работа выполнена при финансовой поддержке гранта Президента РФ для государственной поддержки молодых ученых - кандидатов наук (МК-7462.2013.10).
Список литературы
1. Программно-аппаратный комплекс управления автономным движением мобильного робота / В.Ф. Петров [и др.] // Известия ТулГУ. Технические науки. Вып. 11. Ч2. Тула: Изд-во ТулГУ, 2012. С. 143 - 148.
2. Волкова И. П. Роль зрения в жизнедеятельности человека и последствия его нарушения в психическом и личностном развитии. koleso.mostinfo.ru/sciencediscoveries_374_705 (20 мая 2008 г.)
3. Бархоткин В. А., Кочетков М.П.Идентификация параметров модели для решения задачи распознавания трехмерных объектов // Известия ТулГУ. Технические науки. Вып. 11. Ч2. Тула: Изд-во ТулГУ, 2012. С. 199 - 203.
4. http://www.ffmpeg.org/
5. http://www.videolan.org/developers/x264.html
6. http://www.elins.ru/catalog/
7. http://kbdisplay.com
8. http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html#POSIX
9. http://www.qnx.com/developers/articles/rel 1031 1.html
Бархоткин Вячеслав Александрович, д-р техн. наук, директор НИИ, bva@miee.ru, Россия, Москва, Зеленоград, Национальный исследовательский университет «МИЭТ»,
Руденко Павел Алексеевич, асп., rudenko.pavel. a@,gmail. com, Россия, Москва, Зеленоград, Национальный исследовательский университет «МИЭТ»,
Тюгай Николай Александрович, инженер, rudenko.pavel. a@gmail. com, Россия, Москва, Зеленоград, Национальный исследовательский университет «МИЭТ»,
Терентьев Алексей Игоревич, канд. техн. наук, старший научный сотрудник НИИ ВС и СУ МИЭТ, terentev@olvs. miee. ru, Россия, Москва, Зеленоград, Национальный исследовательский университет «МИЭТ»
MODELLING OF METHODS OF COMPRESSION OF THE VIDEO INFORMATION
IN SYSTEMS OF TECHNICAL SIGHT
V.A. Barhotkin, P.A. Rudenko, N.A. Tugay, A.I. Terentev
This paper describes problems of machine vision system design andpossible ways of theirsolution, contains comparative analysis of video information compression methods, machine vision software development and debugadvices, preliminary design results.
Key words: machine vision, videostream, compression, codec, digital signal processor, visualization, QNX, ffmpeg, x264.
Barhotkin Vyacheslav Alexandrovich, doctor of technical sciences, deputy director, bva@miee.ru, Russia, Moscow, Zelenograd, National Research University "MIET",
Rudenko Pavel Alekseevich, postgraduate, rudenko.pavel.a@,gmail.com, Russia, Moscow, Zelenograd, National Research University,
Tugay Nikolay Aleksandrovich, engineer, rudenko.pavel.a@gmail.com, Russia, Moscow, Zelenograd, National Research University,
Terentev Aleksey Igorevich, candidate of technical science, senior researcher, terentev@olvs. miee. ru, Russia, Moscow, Zelenograd, National Research University
УДК 623.4.01
МЕТОДИЧЕСКИЕ ОСНОВЫ СОЗДАНИЯ ТЯЖЕЛЫХ РОБОТИЗИРОВАННЫХ КОМПЛЕКСОВ СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ
С.Б. Симонов, В.Ф. Петров, Д.Н. Корольков, В.В. Беляев
Рассмотрены вопросы создания роботизированных дистанционно-управляемых машин специального назначения на базе существующих экипажных образцов бронетанковой техники. Предложена методика построения роботизированных безэкипажных объектов бронетанковой техники. Рассмотрен опыт создания системы дистанционного управления для тяжёлого роботизированного комплекса пожаротушения и спасательных робот.
Ключевые слова: система дистанционного управления, роботизация, безэкипажная машина, бронетанковая техника, специальная техника, пожарная машина.
Создание тяжелых роботов специального назначения возможно путём роботизации существующих экипажных образцов бронетанковой техники (БТТ). Для этого экипажный образец оснащается комплектом специализированной аппаратуры, которая вместе с пультом оператора образует систему безэкипажного управления (СБУ) и обеспечивает дистанционное или программное решение задач образцом БТТ.
Разработанный таким способом роботизированный комплекс имеет целый ряд преимуществ по сравнению со специализированными мобиль-
237
