Термопринтер Zebra: печать из МоегоСклада под Ubuntu/Linux

Пришло очередное время пополнения инструментария. В хозяйстве появился принтер этикеток Zebra ZD410 — как оказалось вещь крайне нужная, потому что печатать таблицы на клейкой бумаге — это сущий ад. В онлайн — сервисе «МойСклад», который мы используем как облегченную версию 1С, есть функционал печати термоэтикетки для каждого товара из справочника. Вначале я не обращал на него никакого внимания, но с покупкой термопринтера вспомнил про эту фичу и попробовал сделать распечатку. Первая же попытка показала, что эта опция носит чисто декоративный характер.

Нет, конечно же сама этикетка формируется, причем как ods файл. Можно сохранить ее и попробовать распечатать из LibreOffice на вновь обретенном термопринтере Zebra: только ничего толкового из этого не вышло. Также не помогло расхваленное в сети приложение gLabels. С другой стороны, делать это не особенно и хотелось: в оплаченные возможности термопринтера входят самостоятельное формирование шрифтов, штрихкодов и даже логотипов, что очень полезно с точки зрения быстродействия. Правда для этого пришлось погружаться в язык разметки ZPL. И вот что из этого получилось.

У вас есть план, мистер Фикс?

Наш план будет таков. Во первых, нужно подкрутить шаблон термоэтикеток МоегоСклада таким образом, чтобы он не формировал графическое изображение штрихкода, а оставил просто его численное значение (принтер нарисует штрихкод сам). Также я выкинул печать артикула товара — это ни к чему. К плюсу сервиса «МойСклад» относится то, что поддержка оперативно реагирует на вопросы, во всяком случае на изменение и доработку шаблонов печати. Так получилось и в этот раз: мне прислали шаблон, который требуется. К сожалению, заменить избыточный ods файл на plain text они не могут — ну и не надо, сами справимся.

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

Заходим в карточку товара и жмем печать с новым шаблоном термоэтикетки. Вежливо соглашаемся сохранить ods файл куда — нибудь. Конечно, тут было бы полезно сразу перехватить данные каким — нибудь скриптом, но мне не хотелось сильно погружаться в API броузера. Дальше, жмем на ods правой клавишей мышки, где в меню уже предусмотрительно прописан наш скрипт, после чего скрипт получает файл, преобразует его для начала в csv, а потом уже в файл разметки zpl. Этот файл скрипт отдает принтеру. Все!

Сказано — сделано, начинаем претворять план в жизнь.

Установка термопринтера Zebra ZD410 на Ubuntu/Linux

Само собой, вначале нужно установить принтер. Как обычно, под Linux все запускается или сразу (хвала принтерам HP), или с недетской кривизной, которая сопровождается поиском и установкой драйверов (злосчастный Canon, который взяли только из-за белого цвета — уступка женскому коллективу). На этот раз обошлось: после подключения Зебры по usb принтер обнаружился и встал нормально. Его я назвал — ни за что не догадаетесь — «Zebra». Вот как он выглядит в моей Убунте:

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

Среди принтеров появляется новый — ZebraRaw, и только с ним мы будем работать дальше.

Уже сейчас мы можем напечатать что — нибудь, например сделаем тестовый файлик test.zpl

и пошлем его на принтер:

после чего вылезет этикетка с распечаткой.

Все, принтер работает, поехали дальше.

Главный скрипт

Не отвлекаясь пока на детали, сразу начну со скрипта. Скрипт сделан на bash’е и принимает в качестве аргумента имя ods файла термоэтикетки, который как вы помните мы выгрузили с МоегоСклада. Вот он (zebraconv.sh):

Скрипт содержит три существенных пункта. Первое — это преобразование из ods формата в csv, в котором в свою очередь содержится только наименование товара, его цена и численное значение штрих — кода. Это преобразование выполняет команда unoconv.

Второе — это подстановка данных полученных из csv в zpl — шаблон. Эту задачу выполняет Perl — скрипт zebraconv.pl. Zpl шаблон этикетки хранится в нем же.

И наконец третье — это собственно печать zpl шаблона с подставленными значениями. Перед печатью bash скрипт спросит еще количество копий, которое требуется.

Остальное в скрипте — это создание временных csv и zpl файлов в директории /tmp с последующим их удалением, чтобы не засорять систему. Как видно из логики скрипта, основная нагрузка на создание файла для печати ложится на Perl скрипт zebraconv.pl. Почему именно Perl? Просто по старой памяти и потому, что это самый подходящий язык для всяческих манипуляций с текстом. Правда, особо существенных манипуляций не было, перловый код выглядит топорно (наверняка есть более элегантное решение, которое не было использовано из-за недостатка времени), но все работает.

Формирование zpl файла для печати из шаблона

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

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

Собственно сам перловый скрипт (zebraconv.pl) выглядит так:

Шаблон сидит в переменной $template. Длинная строчка под тегом GFA содержала описание рисунка логотипа, и для удобства чтения кода я ее укоротил (пропавшая часть была на месте троеточия). Как вы наверное догадались, конструкции типа <— —> это placeholders, т.е. местоблюстители для переменных, которые будут подставлены из csv файла.

Скрипт работает так. На его вход поступает трехстрочный csv файл, который в цикле while разбивается на строки и заносится в список @str. С помощью выражения поиска/замены (три строчки содержащие конструкцию вида =~ s/ищем placeholder/данные для замены/) в переменную $template попадают данные из csv файла: наименование товара, цена и штрихкод.

Шаблон с подставленными значениями направляется на выход скрипта.

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

Ubuntu desktop: контекстное меню

Как вызвать свой скрипт и скормить ему файл, кликнув на файле правой клавишей мышки? В недрах системы есть каталог /usr/share/applications, где живут файлы с расширением .desktop. Они как раз и отвечают за попадание в контекстное меню.

Берем любой файл за образец и сохраняем его в этом каталоге под именем zebra.desktop:

Запись Name содержит строку, которую будет показывать меню Убунты. Самая главная запись это Exec: она показывает путь к нашему главному скрипту zebraconv.sh. Параметр %f будет содержать имя файла.

Я добавил MimeType для ods файлов, чтобы меню срабатывало только на ods файлы и не светило на всех остальных. Предолжение Terminal=true подразумевает, что скрипт будет запускаться в окне терминала (что нам и нужно).

Перегружаемся, ищем наш ods файл, кликаем правой клавишей мыши… и ничего не происходит. Почему? Есть маленькая засада: чтобы все это работало, нужно помимо всего прочего, чтобы наш скрипт был прописан в главном меню системы. Для этого идем в Приложения -> Системные утилиты -> Параметры -> Главное меню и создаем в любом месте элемент со ссылкой на полный путь нашего скрипта. После этого все заработает.

Принтер печатает очень шустро. Ну на эксперименты я половину бобины потратил, а что поделаешь.

ToDo: сделать обработку ошибок.

 

Нейронный автокодер / Neural Autoencoder: отбрасывая лишнее

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

В примере с дядюшкой Ляо мы использовали метод главных компонент PCA, чтобы абстрагироваться от нетвердой походки нашего персонажа и попытаться выяснить главное: куда собственно он направляется. Это конечно не единственный метод удаления избыточной информации: в области нейроподобных сетей сходную функцию несут такие интересные устройства, как автокодеры (Autoencoder).

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

Бутылочное горлышко

Автокодер — это нейронная сеть, которая выглядит следующим образом. Слева как обычно подаются входные данные, справа — выход сети. Соответственно, присутствует входной слой (input layer) и выходной слой (output layer). Размерность выходного слоя точно такая же как и входного. Внутренние слои, которые по традиции называют скрытыми — hidden layers (вот еще одно название, сбивающее с толку) представлены всего одним слоем.

Нейронный автокодер, Neural Autoencoder

Автокодер / Autoencoder.
Layer L1: входной слой
Layer L2: скрытый слой
Layer L3: выходной слой

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

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

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

Есть что терять

Таким образом, автокодеру есть что терять, и чтобы очистить входной сигнал (изображение например) от несущественных деталей с одной стороны, и не расплескав донести существенные части до выхода — с другой, нужно подсказать автокодеру как это делать. Как это принято в мире нейронных структур, да и человеческого общества, это происходит с помощью обучения. Натаскивая нейронную сеть на разные виды изображений, ее весовые коэффициенты модифицируются таким образом, чтобы оставить только ключевую, существенную информацию на выходе.

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

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

\| x \| ^{2} = \sum_{i=1}^{100} x_{i} ^{2} \leq 1

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

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

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

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

Неслучайное в случайном

Вот тут и наступает самый интересный момент. На рисунке ниже (позаимствованном из той же замечательной статьи) показано, какие закономерности увидел автокодер во входных данных.

Результат работы нейронного автокодера

Не знаю, как у вас, но у меня это вызывает ассоциацию создания некоего порядка из хаоса. Как будто ты присутствуешь при рождении первоэлементов, из которых потом будет построена вся вселенная 🙂

Чему же научился наш Autoencoder? На рисунке видно, как он выделяет границы освещенности исходя из самых разных положений. При этом шумовая, или «отбеленная» информация подавлена: мы совершенно четко видим регулярные структуры, которые могут в дальнейшем использоваться для распознавания объектов или сигналов. Из-за ограниченной размерности скрытого слоя, или бутылочного горлышка автокодер вынужден упрощать входные данные; а путь к упрощению только один: найти закономерности, которые позволяют хранить данные об этих закономерностях в сжатом виде в структуре самого автокодера.

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

Офшорная радиолокация

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

Так в конторе, где я поднимал новый радиопеленгатор, исчез отдел который занимался источниками питания, а также исчезли сектор разрабатывающий микро — ЭВМ и группа специализирующаяся на проводных модемах. Зато появились программисты, работающие под FreeBSD, возникла Linux — культура и задняя часть шкафов и блоков перестала напоминать кросс АТС со своей мощной кабельной разводкой.

Глубокая кооперация является самоочевидной для западных разработчиков, у которых нет никаких проблем с использованием ресурса многочисленных специализированных компаний, разбросанных по всему миру. Для серьезных заказчиков, в том числе военных (США), данная парадигма была зафиксирована под названием COTS. Какое — то время в отечественной разработке также начал приживаться такой выигрышный подход. Однако со временем в родных пенатах  вызрела очередная диалектическая спираль, возвращающая разработку целиком и полностью на отечественную почву. Этот процесс получил неудачное название «импортозамещения», а поскольку в глубинное импортозамещение никто не верил и похоже и не собирался ему следовать, использование иностраных компонентов начало маскироваться под перебитые шильдики, измененную «на отечественную» документацию на изделия, неимеющие_аналогов_в_мире.

Здесь я расскажу историю влияния «импортозамещения» на разработку одного аэродромного обзорного радиолокатора — АОРЛ. Многие узнают в этой истории свои собственные характерные черты, поэтому ее даже можно считать типичной. Прежде чем начать повествование, сделаю еще одно уточнение: самым ценным в использовании ресурса кооперации, по моему глубокому убеждению, является не приобретение решений и компонентов, а получение доступа к технологии и процессу разработки. Касаемо последней, самый главный вопрос будет звучать «как это сделано?», а «почему это сделано именно так?». Обратите внимание на разную информационную емкость ответов на эти вопросы: в первом случае мы получаем только единственно правильный ответ, а во втором помимо этого ответа несколько десятков решений, которые были отброшены в процессе исследований. И это есть самое ценное в разработке: почему было выбрано именно это решение.

Только для членов клуба

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

В любом случае, разработка РЛС — это на самом деле школа, которая существует не один десяток лет. И когда в этот клуб постучалась новая российская фирма (назовем ее так — компания А), сразу возникли все эти вопросы: и про школу, и заделы, и про опыт работы. И тут, забегая вперед, выяснились интересные вещи. Оказывается, чтобы успешно работать на российском рынке, всех этих инженерных премудростей — опыта работы, технической истории, заделов — иметь не обязательно. Что действительно важно это иметь хорошую историю отношений с заказчиком. С этим проблем как раз таки не было: компания А поставляла средства управления воздушным движением, такие как радиопеленгаторы, вторичные радиолокаторы, маяки DVOR, системы связи и системы ILS/DME. Но в продуктовой линейке компании А был небольшой, но существенный пробел: отсутствовал первичный аэродромный обзорный радилокатор S-диапазона: АОРЛ.

Но и тут ломать голову не пришлось — отсутствие собственного продукта при здоровом коммерческом подходе это не проблема. Компания А пошла давно опробованным методом: если нет собственной разработки, то ее можно просто купить. Купить можно даже историю работы на этом рынке, если кому-то не нравится подозрительная краткость существования на нем. С таким багажом — приобретенный продукт и красивая история — успех гарантирован.

Приобретение технологий или торгово — закупочная деятельность?

Заголовок немного режет глаз: благородное понятие «технологии» соседствует с фразой, которая вызывает ассоциации с колхозным рынком и торговлей овощами и фруктами 🙂 . На самом деле и то и другое просто разные модели построения бизнеса.

В первом варианте технологии приобретаются, усваиваются и становятся частью собственного процесса разработки. Часто приобретение идет рука об руку с наймом носителей этих технологий. Это позволяет продолжать разработку с более высокого уровня и хранить собственные ноу-хау. Так, например, за время моей работы в системном телекоммуникационном интеграторе лучшей в классе решений Fault Management была небольшая компания Micromuse. Она была приобретена IBM и ее продукт был включен в линейку ИБМовских решений Tivoli. Специалисты Micromuse также перешли в IBM: помню, как искрили взаимоотношения между новой креативной командой и солидным древним менеджментом IBM. В конце концов, все притерлось.

Во втором варианте, нацеленном на производство и продажу, полноценную разработку сохранить не удается. В конце — концов команда инженеров — разработчиков схлопывается до одного человека, который и сопровождает эту систему. В корпоративной терминологии этот человек по факту является Product Manager’ом: решает текущие вопросы с производством, отвечает на вопросы в процессе развертывания и эксплуатации, согласует замены. Развивать продукт он уже не в состоянии.

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

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

Наша компания А пошла по торгово — закупочному пути. До сих пор все работало отлично, если говорить о существующих продуктах: так, по средствам связи разработка была заказана и приобретена у маленькой специализированной фирмы; вторичная локация появилась благодаря приобретению НИИ, который работал в этой области, заодно и приплюсовали 50 лет истории («50 лет на рынке радиоэлектронных разработок» — звучит здорово и на сайте и в рекламной брошюре, не правда ли?). ILS/DME были разработаны в другой маленькой компании — тут даже разработку выкупать не пришлось, достаточно было переманить ключевых специалистов, а разработка уже автоматом пришла вместе с ними. Средства управления воздушным трафиком — купили другую небольшую компанию программистов. Радиопеленгатор вообще разрабатывала внешняя команда.

Ну в общем так и есть: торгово — закупочный кооператив в чистом виде )

Единственное с чем пришлось помучиться самим — это радиомаяк DVOR. Приобрести разработку было не у кого, поэтому маяк делали с нуля по Thales’овским описаниям, что заняло 10 лет с лишним. Да и разработку эту завершенной назвать трудно: вибраторы с пассивных заменялись на активные, образцы менялись от поставки к поставке, своих передатчиков не было, а покупные выходили из строя, не шла заявленная дальность действия: в общем единственный опыт собственной разработки оказался неудачным.

Только вот у кого приобрести разработку радиолокатора, когда отечественные НИИ и КБ не горят желанием растить молодого конкурента? Точно также как и раньше: у маленькой специализированной фирмы, только не отечественной а зарубежной. Какая в сущности разница? Сказано — сделано, и мы в ходе нашей истории перемещаемся в солнечную Италию.

Италия — страна локаторов

В ходе этого проекта я провел большое количество времени в Риме. Каждый раз когда меня встречали в аэропорту, уже в машине мы начинали дискуссию и споры по тому, как надо делать этот радиолокатор. Я до сих пор с удовольствием вспоминаю эту часть своей работы, которая так разительно отличалась от торгово — закупочной суеты в конторе. Подозреваю что собственно сама разработка так и не была понята конторой до конца («что там локатор делать — в книжках все давно разжевано» — эта буквальная цитата одного из топов компании А красной нитью проходила через весь проект 🙂 ). В проекте я получил уникальный опыт в европейской команде профессионалов, в которой было интересно все: используемые технологии управления, разработки, взаимоотношений. В короткие сроки мы разработали прототип аэродромного обзорного радиолокатора S-диапазона, учитывающий компромиссы стоимости и сроков, создали схему кооперации и логистики по комплектующим, определили источники узконаправленных технологий… но я несколько забежал вперед.

Фирма с которой я работал в проекте была действительно небольшой, и область деятельности у нее была несколько иной. Но это только на первый взгляд. Создатель этой маленькой компании, будучи разработчиком радиолокационной техники в Selex’е, прошел все ступени до топ — менеджера, после чего удалился от корпоративной суеты, купил здание в Риме и основал свою компанию. Его команда — тоже инженеры Selex’а с большим опытом разработки. Коллеги босса, или друзья (в Италии трудно отделить коллег от друзей) которые являются профессионалами в антенной локационной технике, теперь также возглавляют маленькую симпатичную компанию, которая поставляет спутниковые антенны и оборудование к ним. В общем, я попал в такой профессиональный сгусток знаний и технологий по радиолокационной технике, которая была воплощена в большом количестве поставляемых изделий, как гражданских, так и военных для разных стран мира.

Философия проекта

Применимо ли понятие философии к проекту? Безусловно, если мы принимаем базовые принципы и подходы, по которым будем строить наш проект. Какие принципы — такие сроки, бюджет и реализация. В результате многочисленных жарких споров и дискуссий, которые проходили в большой светлой комнате, окна которой выходили на via Tiburtina, под чашечку крепкого итальянского кофе было решено идти следующим путем:

  • АОРЛ должен обеспечивать дальность 80 NM при ЭПР 5 м2 , вероятности обнаружения 80% и вероятности ложной тревоги 10-6;
  • радиолокатор будет использовать как режим одночастотных, так и многочастотных импульсов, во втором случае используется две или более частоты из 10 возможных в диапазоне 200 МГц. Для многочастотного режима первый импульс длительностью 10 мкс используется для зондирования целей на коротком расстоянии — 8 NM или 15 км (Short Range Pulse), остальные длительностью 100 мкс — для обнаружения целей на большой дальности — вплоть до 80 NM (Long Range Pulse).
  • антенна локатора как наиболее критичный узел будет собственной разработки. Типовые компоненты СВЧ тракта, такие как ответвители, ограничители, вращпереход, малошумящие усилители будут покупными в соответствии с идеологией COTS. Там, где компоненты требуют дополнительного специфицирования — будут разработаны заказные спецификации;
  • пьедестал вместе с устройством юстировки и электромеханическим приводом — также собственной разработки;
  • антенна будет выполнена со смещенным вниз облучателем, чтобы не затенять рефлектор и уменьшить уровень боковых лепестков. Неизбежное усложнение конструкции будет компенсировано технологичностью реализации и точным выдерживанием профиля рефлектора с использованием разрабатываемой технологической остнастки;
  • антенна будет формировать два луча: главный — на передачу и прием, и вспомогательный — только на прием. Вспомогательный отличается от главного измененной диаграммой в вертикальной плоскости (расположена выше), что позволяет подавить переотражения от земли для близко расположенных целей и обеспечить лучшее обнаружения целей, расположенных высоко в ближней зоне. Локатор будет позволять работать с режимом главного, вспомогательного луча или используя их попеременно;
  • ряд узлов, которые являются хорошо известными в реализации, но которые требуют ресурсы, для ускорения проекта приобретаются готовыми и в процессе разработки заменяются на узлы собственной разработки. Под это определение попала вся синтезирующая часть локатора: генератор опорных колебаний STALO, генератор waveforms, синтезаторы опорных частот. Эти устройства были представлены покупными стандартными компонентами из линейки National Instruments LabView, что позволило на первом этапе сосредоточиться на задачах обработки сигнала используя тот факт, что опорные сигналы и последовательности формируются с метрологической точностью;
  • передающий тракт — с использованием твердотельных усилительных 2 КВт модулей своей разработки, исключающие полный отказ передающего тракта при отказе одного из выходных СВЧ транзисторов модуля (техника Graceful Degradation);
  • для тракта обработки сигнала была принята платформа VPX, которая по своим характеристикам позволяет организовать высокоскоростной параллельный обмен между модулями и платами. Но самое главное: VPX стандартизирует форм — фактор этих модулей, под который выпускается большая номенклатура плат, и не только протоколирует обмен по шине, но и предусматривает для этой шины готовые интерфейсные элементы на базе ПЛИС с разъемами. Таким образом, приобретая плату VPX с установленной ПЛИС, задача шинного обмена полностью переходит в плоскость работы с драйвером шины, что существенно облегчает и сокращает разработку;
  • принято принципиальное решение делать только один перенос частоты из S-диапазона 2.6 — 3.0 ГГц на промежуточную частоту 640 МГц. Реализовать такой однократный перенос позволяют высокопроизводительные покупные модули АЦП, которые с помощью мезонинной архитектуры будут устанавливаться на платы VPX.

Разгон и торможение

Когда находишься в едином философском поле, дальше продвигаться уже гораздо проще 🙂 В ходе проекта были разработаны функциональные схемы всех узлов, а также определены перечни всех покупных узлов. Была полностью разработана конструкторская документация на антенну и пьедестал. Оставался открытым важный вопрос разработки программного обеспечения, и поскольку контора решила создать экономию по этой статье бюджета, со временем в проекте стало нарастать финансовое напряжение. Изначально это напряжение незримо присутствовало благодаря тому, что весь бюджет итальянской части проекта по сумме соответствовал стоимости только одного серийного радиолокатора! Другими словами, первое же поставленное изделие отбивало стоимость всей разработки. Трудно сказать, что было этому причиной: то ли итальянская фирма рассчитывала на дальнейшую разработку (на подходе был вторичный радиолокатор и современная антенна для него), то ли сыграли необоснованные надежды на дальнейшее участие в проекте — бюджет проекта составлял очень скромную величину.

Претендовать на интеллектуальную собственность или хотя бы на авторство разработки итальянцы не могли: платежи по главным контрактам на эскизно — технический проект контора проводила с офшорных безымянных фирм. Дальше — больше: контора оказалась не в состоянии разрабатывать начинку функциональных узлов, как это было предусмотрено контрактом: от радиотракта до ПО на ПЛИС и пыталась переложить разработку на итальянцев. Но самый торт произошел когда пошли санкции на поставку хайтек оборудования и возникло пресловутое импортозамещение. Это полностью противоречило идеологии разработки, основанной на COTS компонентах; и контора не мудрствуя лукаво, сделала следующий шаг: вменила в обязанность исполнителя предоставить КД на эти покупные компоненты с тем, чтобы иметь возможность производить их самостоятельно. Не знаю, где итальянцы могли достать документацию например на такой сложный узел как вращпереход, и где и как контора собиралась его производить, но все эти события собранные в кучу привели к одному: отношения начали портиться и контора решила продолжать этот проект самостоятельно.

Итальянская компания приступила к работе в далеком 2012 году и выдала результаты, включая полную КД на антенну к весне 2013 года. Антенну изготовили на специализированном заводе в Неаполе и привезли в РФ, но не тестировали: так и не был создан требуемый полигон. Работы по остальной части РЛС идут еле-еле. С начала работы прошло уже 5 лет, а опытного образца до сих пор нет. Ну ничего, DVOR делали лет 10 с лишним, почему локатор должен получиться быстрее?

Проект получился слишком объемным, чтобы можно было его переварить в торгово — закупочной схеме. Как ни крути, а без специалистов не обойтись — а их как раз таки нет. Сказанное совсем не означает, что у изделия нет коммерческой перспективы: главное чтобы антенна крутилась на кузове — «вот это я понимаю — локатор!» (прав был главный инженер итальянской фирмы, когда говорил про stupid rotation piece of metal), поэтому можно легко продать заказчику первый экземпляр и потом доводить его до ума на позиции. В случае с первым DVOR так и было.

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

  • малошумящие СВЧ усилители;
  • мощные и надежные СВЧ транзисторы;
  • вращпереходы, ограничители мощности;
  • высокоскоростные АЦП — более 100 млн. выборок в секунду (на которые подозрительные буржуи заставляют оформлять документы конечного пользователя);
  • производительные DSP процессоры, специально разработанные для радиолокационных приложений;
  • модули и компоненты VPX.

Веселые картинки

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

PSR, Primary Radar Antenna, S-band Radar, Антенна первичного радиолокатора, Аэродромный обзорный радиолокатор S-диапазона, АОРЛ

Опытный образец антенны первичного радиолокатора S-диапазона перед отправкой в РФ. Антенна изготовлена и собрана на заводе в Неаполе. Конструкторская документация разработана итальянской стороной.

На рисунке выше — красавица антенна, разработанная в рамках проекта. Конструкторская документация разрабатывалась итальянцами в Pro Engineer далее портировалась в Solid Works для того чтобы с ней могли работать в конторе.

Далее, на рисунке функциональная схема приемного тракта радиолокатора. Принятые сигналы с основного и вспомогательного канала промежуточной частоты 640 МГц оцифровываются в 2-х АЦП модуля DDC, которые располагаются на FMC соединителе платы VPX 3U. С помощью быстродействующей ПЛИС производится цифровой перенос двух входных сигналов целей на цифровую промежуточную частоту. На этой же плате происходит сжатие входных импульсов.

В сигнальном процессоре SP реализован алгоритм MTD: Moving Target Detection, или как его называют в отечественной литературе — СДЦ, селекция движущихся целей. Основу сигнального процессора составляет банк цифровых доплеровских фильтров.

В процессоре RP происходит обнаружение целей с заданными вероятностями и выделение координатной информации.

 

Radar Data Processing, PSR, Primary Radar, S-band Radar, Первичный радиолокатор, Аэродромный обзорный радиолокатор S-диапазона, АОРЛ

Тракт обработки радиолокатора состоит из 4-х VPX модулей:
DDC, Digital Downconverter: цифровой перенос частоты;
SP, Signal Processor: сигнальный процессор;
CB, Control Board: плата контроля;
RP, Radar Processor: обнаружитель целей и plot extractor

На этом рисунке показан фрагмент схемы, иллюстрирующей прохождение основного и вспомогательного приемного сигнала. Развязка приемных цепей от мощных выходов усилителей производится циркулятором. Кроме этого, на входе каждого из каналов стоит быстродействующий ограничитель мощности, защищающий входы малошумящих усилителей от проникновения мощного импульса. Сами усилители имеют коэффициент усиления 30 дБ и уровень собственного шума 0.7 дБ. Последний параметр имеет ключевое значение: чем ниже уровень шума, тем меньшую мощность требуется излучать в эфир.

Radar Data Processing, PSR, Primary Radar, S-band Radar, Первичный радиолокатор, Аэродромный обзорный радиолокатор S-диапазона, АОРЛ

СВЧ тракт АОРЛ. Циркулятор обеспечивает развязку передающих цепей, используются малошумящие усилители

При разработке АОРЛ было уделено большое внимание моделированию важных цепей и алгоритмов. Так, на этих диаграммах с помощью специального ПО просчитывалась диаграмма направленности антенны в зависимости от формы рефлектора, расположения облучателей, длины волны и многоих других факторов. На диаграмме видны ДН основного и вспомогательного луча, а также уровень лепестков в горизонтальной плоскости. Расчеты подобного типа имеют критическое значение: после изготовления антенну не подправишь!

Radar Data Processing, PSR, Primary Radar, S-band Radar, Первичный радиолокатор, Аэродромный обзорный радиолокатор S-диапазона, АОРЛ

Результаты моделирования антенной системы АОРЛ S-диапазона

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

Псевдокогерентная РЛС / Coherent-on-receive: обработка сигнала

РЛС, Псевдокогерентный радиолокатор, Псевдокогерентный радар, Coherent-on-receive, Coherent oscillator, COHO

Радиолокатор П-10

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

Древние РЛС метровых и дециметровых диапазонов монструозных размеров, такие как например П-10, начало разработки которых теряется в 50-х годах прошлого столетия, должны были занять почетное место в соответствующих музеях компаний — разработчиков и производителей. Вместе с этими комплексами можно было забыть и про магнетроны с конскими излучаемыми мощностями — несколько десятков кВт и фазовую настабильность этих магнетронов. Однако, с развитием stealth технологий радионевидимости летательных аппаратов стало очевидным, что невидимость обеспечивается как раз в частотных диапазонах современных РЛС, а в метровых диапазонах старых локаторов «невидимые» цели видны. Это породило повторный всплеск интереса к старым РЛС; в частности некоторые из них проходят модернизацию и находят своих заказчиков.

Помимо упомянутых преимуществ, у метровых РЛС есть еще одно: относительная неуязвимость для антирадарного вооружения, поскольку антенна пассивной головки самонаведения (ГСН) ракеты быстро теряет свою эффективность в нижней части диапазона: в отличие от наземной метровой РЛС с большой антенной системой, ГСН не может себе позволить иметь такие размеры.

Поскольку РЛС данного типа как правило содержат магнетрон в передающем тракте, который не поддерживает внешнюю синхронизацию и работает на «плавающей» частоте (точнее, на частоте на которой произойдет самосинхронизация магнетрона), нужны специальные методы для поддержания когерентности тракта. Когерентный тракт, как известно, позволяет выделить доплеровское смещение частоты в отраженном сигнале, что обуславливает эффективность селекции движущихся целей (СДЦ).

Coherent-on-receive, или псевдо — когерентный радиолокатор

Для решения этой задачи в традиционных метровых РЛС использовали следующий трюк. Поскольку магнетрон излучает импульс на нестабильной частоте, надо было сделать «снимок» этого импульса, или сохранить его в памяти. Естественно, в те времена (1950 годы!) ни о какой оцифровке и речи не было, и реализация могла быть только аналоговой. На рисунке ниже приведена принципиальная электрическая схема такого тракта («по материалам зарубежной печати», естественно). Видно, что по сравнению с ламповой техникой П-10 мы наблюдаем транзисторные каскады плюс логические элементы, что показывает некий прогресс в технологиях. Но сама реализация — точно такая же, как и в ламповом варианте.

Прежде чем обратить внимание непосредственно на схему, обрисуем общую идею метода. При формировании излучаемого импульса, помимо отправки в антенно — фидерный тракт, он синхронизирует когерентный генератор (естественно, с необходимым ослаблением). В зарубежной литературе такой генератор носит название COHO (Coherent Oscillator). Генератор имеет собственную частоту колебаний, лежащую в диапазоне частотных отклонений магнетрона, но после окончания синхронизирующего импульса ему приходится определенное время «раскачиваться» на частоте импульса синхронизации, и что важнее — с сохранением фазовой привязки. Естественно, со временем генератор уйдет на собственную частоту и фаза разбежится; достаточно лишь чтобы это произошло уже после того, как вернется импульс, отраженный от цели. При поступлении отраженного импульса генератор будет выполнять роль опорного для фазового детектора, который уже будет выделять доплеровское смещение.

Такая «ненастоящая» когерентность у нас именуется псевдокогерентностью, а в зарубежной литературе эту технику приема именуют «coherent — on — receive».

Теперь — к схеме. Тракт основного сигнала я выделил жирной линией.

РЛС, Псевдокогерентный радиолокатор, Псевдокогерентный радар, Coherent-on-receive, Coherent oscillator, COHO

Приемный тракт РЛС с когерентным генератором (кликните для увеличения)

Перед поступлением на вход схемы, зондирующий импульс магнетрона (для нас он уже синхронизирующий) переносится на промежуточную частоту (ПЧ) 30 МГц и попадает на вход разветвителя DC1. С верхнего по схеме выхода разветвителя сигнал ПЧ через линию задержки поступает на вход усилителя Q1. Линия задержки нужна для того, чтобы успела сработать логика запуска COHO. Эта логика реализована на нижней части схемы и начинает свою работу также с поступления импульса ПЧ. Присутствие импульса обнаруживается с помощью амплитудного детектора Q7 и далее в логическом блоке формируется ряд временных последовательностей для управления запуском генератора. Как работают эти последовательности — буду рассказывать в при изложении работы основного тракта, для чего возвращаемся к тому, на чем остановились — на линии задержки.

С выхода линии задержки импульс ПЧ поступает на вход усилителя Q1, который как раз предназначен для раскачки генератора, реализованного на транзисторе Q3, этим синхронизирующим импульсом. Как видно по схеме, усилитель Q1 — управляемый со стороны эмиттерной цепи, которая нагружает один из выходов логического блока. Логическая цепь управления должна пропустить к генератору не весь зондирующий импульс, а только его часть, которая соответствует относительно стабильной фазе магнетрона. Эта логика, как и последующая, является фиксированной — временные соотношения жестко заданы RC цепочками одновибраторов логического блока.

С выхода Q1 синхронизирующий импульс поступает на собственно COHO генератор Q3, задающая цепь которого выполнена на основе параллельного колебательного контура с настроечной цепью конденсаторов. Здесь мы наблюдаем второе вмешательство логического блока в работу тракта, на этот раз воздействие производится на генератор через ключ Q8. Посредством ключа логический блок отпирает генератор в тот момент времени, когда создаются наиболее благоприятные условия для синхронизации. При этом заметим, что ключ Q8 в открытом состоянии (соответствующем блокировке генератора) демпфирует колебательный контур, что обеспечивает «стирание» колебаний предыдущего импульса.

С этого момента генератор COHO непрерывно работает в фазе с импульсом, который был сформирован магнетроном. Его выход через цепь эмиттерных повторителей Q4, Q5 (чтобы не нагружать схему генератора) поступает на выход устройства.

Теперь, к моменту прихода отраженного от цели импульса, у нас будет недолговечный, но вполне рабочий источник «когерентных» колебаний.

Очевидно, что импульс цели также будет перенесен на частоту 30 МГц, где за дело примется уже фазовый детектор СДЦ.

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

Цифровой тракт Coherent-on-receive: ADC + FPGA + ARM

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

Coherent-on-receive prototype, COHO digital implementation

Прототип тракта Coherent-on-receive

Плата содержит два канала АЦП (ADC) и два канала ЦАП (DAC). Частота дискретизации и формирования — 125 МГц. Управление записью/считыванием производит ПЛИС/FPGA  с соответствующим API, логика работы приложений реализована на процессоре ARM, также находящемся на плате.

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

Оба импульса подаются на входы 2-х канального АЦП с помощью кабелей, которые хорошо видны на фото, и начиная с этого момента у нас работает Coherent-on-receive, или псевдокогерентный тракт обработки. Конечно, шлейфовые ВЧ кабели можно было сделать покороче и поприличнее, но использовал те которые у меня были.

Входной тракт обработки не использует никакой «внутренней» информации о времени формирования импульсов и работает строго независимо от передающей части.

С частотой выборки 125 Msamples/s на каждый период входной частоты ПЧ 30 МГц приходится 4 отсчета, что в общем то вполне достаточно  для полноценного воспроизведения импульса. Я не использовал фильтры и усилители для полноты картины — это все будет уже в реальном блоке обработки. В приложении для ARM, которое я написал на Си (один день на код и неделю разбираться как работает синхронизация), опорный импульс обнаруживается пороговой схемой, после чего начинает работать внутренний счетчик отсчетов. Производится полная запись опорного импульса, и далее — импульса цели, который поступает с задержкой.

Как видно, в нашем модернизированном варианте зондирующий импульс запоминается буквально, без кавычек, причем быстродействие платы позволяет это сделать в реальном времени. Точнее, быстродействие обеспечивает FPGA, которая работает строго  синхронно с преобразователями ADC/DAC через кольцевой буфер, а доступ к этому буферу уже получает асинхронная часть платы — процессор ARM.

Накопленные отчеты отправляются на host компьютер по IP сети, где приложением на Python’е выполняется квадратурная корреляционная обработка импульса цели и визуализируются данные. Вот как выглядит работа платы:

РЛС, Псевдокогерентный радиолокатор, Псевдокогерентный радар, Coherent-on-receive, Coherent oscillator, COHO

Зондирующий импульс и импульс цели в псевдокогерентной обработке

На диаграмме слева, показаны сигналы на двух входах АЦП платы. Ширина зондирующего и соответственно отраженного импульса соответствует 1 микросекунде. Поскольку частота ПЧ составляет 30 МГц, каждый радиоимпульс содержит около 30 периодов этой частоты. Частота выборки — 4 отсчета на период. Красным цветом показан зондирующий импульс. Он выглядит более коротким; это связано с задержкой работы триггера, который определяет начало этого опорного импульса. Будем считать, что мы вырезали часть времени, на которой работа магнетрона нестабильна. Импульс цели показан зеленым цветом, он приходит с задержкой около 0.5 мкс.

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

ToDo

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

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

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

Кросс — функция неопределенности: два способа получения

В применении к задачам пассивной радиолокации, в конечном счете двумерное изображение радиолокационной обстановки формируется с помощью кросс — функции неопределенности (ФН):

\Psi(\tau,f) = \sum_{t}\,s(t + \tau)\, r^*(t)\,e^{j2\pi ft} (1)

Приставка «кросс» означает, что в отличие от классической ФН одного сигнала, выражение содержит взаимную функцию неопределенности сигнала s(Δt, Δf), переотраженного от цели с приобретенной задержкой Δt и доплеровским сдвигом частоты Δf, и опорного сигнала r(), формируемого местным радиоокружением (базовой станцией).

Каким образом посчитать это выражение? Существует два подхода к этой задаче; они определяются тем, каким образом мы представляем физический смысл этого соотношения. Рассмотрим два варианта группировки элементов выражения (1) — A и B, которая отражает наше представление о том, каким образом производится обработка сигналов:

Кросс - функция неопределенности, Cross Ambiguity Function

План A: перебор в частотной области

Начнем с представления A. В этом представлении, помеченным синим цветом, формула представляет собой в чистом виде запись корреляционной функции двух сигналов. Первый сигнал — это сигнал цели s(), сдвинутый по частоте на величину f с помощью экспоненциального множителя. Второй сигнал — комплексно-сопряженный опорный r().

Тогда алгоритм нахождения двумерной кросс-ФН получается таким: для каждой частоты f находим корреляционную функцию сигнала цели, смещенного на частоту f, и опорного сигнала. Набор таких корреляционных функций в пространстве частот f составит 2D пространство кросс-ФН.

Поскольку наш алгоритм рано или поздно заземлится на определенной аппаратной платформе, что предусматривает наличие эффективного вычислителя БПФ, будем искать корреляционные функции не в лоб, а с использованием преобразования Фурье. Псевдокод на Питоне/numpy, соответствующий сценарию A, будет выглядеть следующим образом:

БПФ для опорного сигнала ref вычисляется только один раз, поскольку он не меняется по ходу действа. Сдвинутый по частоте сигнал rot подвергается преобразованию Фурье и перемножается с комплексно — сопряженным БПФ опорного сигнала. Корреляционная функция находится как обратное БПФ этого произведения.

Не считая однократного БПФ опорного сигнала, в этом варианте мы должны выполнить БПФ в количестве, соответствующем количеству доплеровских частот, которые представляют для нас интерес. Плюс столько же обратных преобразований Фурье (многовато получается, однако).

В результате, матрица af будет содержать набор корреляционных функций для каждой частоты f, то есть кросс — функцию неопределенности. Данный метод можно назвать методом с перебором в частотной области.

План B: перебор во временной области

У нас в запасе есть еще план B, отмеченный красным цветом. При такой группировке произведение s()r() выглядит как самостоятельная функция, и тогда все выражение до боли напоминает преобразование Фурье от этой функции. Да что там напоминает — так оно и есть. Мы должны выполнить столько БПФ, сколько временных задержек сигнала мы собираемся рассматривать. При этом никакого обратного БПФ выполнять не нужно.

Алгоритм на псевдокоде будет использовать перебор во временной области:

В данном сценарии, БПФ используется столько раз, сколько используется временных задержек сигнала, представляющих интерес.

A vs B

С точки зрения быстродействия сценарий B выглядит поинтереснее, хотя с точки зрения физического смысла выполняемой обработки сигнала он не такой прозрачный, как сценарий A. Мы упустили из виду еще один существенный фактор, влияющий на время выполнения: размер выборки для операции БПФ.

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

И в этой ситуации сопоставление эффективности этих сценариев становится не таким простым делом…

 

Кросс — компиляция для Raspberry Pi

Не так давно случилось событие, которое вернуло мой интерес к малютке Raspberry Pi. Были открыты спецификации чипа GPU, в результате чего была реализована идея выполнить быстрое преобразование Фурье (FFT) на видеопроцессоре. В результате народ написал тестовый код, и быстродействие по сравнению с выполнением на ARM возросло в 10 раз. Очень даже неплохо! Для тестирования 2D FFT, что нужно для функции неопределенности, я решил заранее подготовиться и оборудовать рабочее место. Об этом данный пост.

Donwload

Для загрузки берем минимальный дистрибутив Raspibian Jessie Lite, что означает что мы добровольно отказываемся от графики на RPi. Да и зачем она нужна?

Дальше все по инструкции, распаковываем образ и копируем его на SD карту.

Я сразу сделал еще одну вещь: вызвал GParted  и раздвинул второй раздел до конца флешки. Если этого не сделать, моя 16 Гб SD карта выглядела как маленькая 2-х гигабайтная.

Поскольку я использую с RPi WiFi свисток, или донгл, пока еще SD карта в компьютере, сразу настроим беспроводную сеть в файле /etc/wpa_supplicant/wpa_supplicant.conf

Мы не будем подключать к RPi клавиатуру и монитор: работаем только удаленно. Можно было бы уже извлечь SD и воткнуть ее в RPi. Несмотря на то, что сеть поднимется, нас ждет засада: сейчас по умолчанию ssh на плате не работает, поэтому к ней не доступиться.

Поэтому не будем торопиться и выполняем workaround: создаем в разделе boot пустой файл ssh. Это сигнал загрузчику, что нужно запустить сервер ssh при загрузке.

Теперь отмонтируем карту, вставляем в RPi, включаем питание и заходим по ssh. IP адрес или имя можно найти на WiFi маршрутизаторе.

Следующие шаги

Быстро пробежимся по тому что надо сделать сразу на будущее.

1. Чтобы не вводить каждый раз пароль для ssh:
ssh-copy-id pi@raspberry.local

2. raspi-config: устанавливаем локаль, часовой пояс, включаем ssh на постоянно.

3. apt-get update, apt-get upgrade: обновляем систему, при этом подтянется firmware. Теперь уже не обязательно запускать rpi-update как раньше.

4. Ставим apt-get install vim, делаем его удобоваримым корректируя /etc/vim/vimrc:

5. Позаботимся о Питоне:

Пока все. Дальше, чтобы каждый раз не ждать сборки проекта на RPi (все будет очень медленно) и не мучить флешку, настроим кросс — компиляцию. Компилировать будем на моей машине под Ubuntu. Чтобы не гонять файлы на RPi и обратно, поднимем каталог под NFS и сделаем его доступным со стороны RPi по сети. Тогда вся работа, а именно редактирование и сборка перемещаются на хост машину. Запускать надо будет только на самой RPi.

Поднимаем NFS

Делаем на host — компьютере, т.е. на моей машине под Ubuntu:

Добавляем в /etc/exports строчку

Здесь /home/user/rpi/public это директория, которую мы открываем для внешнего доступа. В этой директории и будем дальше копаться с кросс — компиляцией.

Перезапускаем NFS подсистему /etc/init.d/nfs-kernel-server reload. Как видите, я со стартовыми скриптами по старинке. NFS сервер готов.

Делаем на target — компьютере, т.е. на Raspberry Pi:

Добавляем в /etc/fstab строчку

Здесь:

  • myhost.local: имя хост — компьютера, который у нас под Ubuntu;
  • /home/user/rpi/public: директория на хост — компьютере, которую мы будем видеть, само собой она должна быть точно такой же, как прописано на host компьютере;
  • /home/pi/cross: директория на RPi, которую надо создать.

Теперь все что мы будем творить на хост машине в директории /home/user/rpi/public, будет видно на целевой машине — RPi в директории /home/pi/cross. Сразу уточню для ясности: если отключить хост — машину, то директорая /home/pi/cross на целевой машине окажется пустой.

Перегружаем RPi, чтобы произошло автоматическое монтирование этой директории.

Кросс — компиляция

Для кросс — компиляции нужен компилятор, который будет создавать исполняемые файлы в формате архитектуры armhf (процессор ARM, реализация плавающей запятой — аппаратная). И не только компилятор: компоновщик, архиватор библиотек и прочие инструменты.

Кроме этого, нужна специальная ветка h — файлов и библиотек, также заточенная под armhf — так называемый toolchain. Вручную ворочать этими ветками с длинными названиями тяжело, поэтому пойдем простым путем. Не помню откуда, но у меня на хост — компе живет директория arm-bcm2708. Это как раз инструменты для RPi, которые я скачал в незапамятные времена. Из под этой директории отрастают ветки, в которых и будет копаться компилятор — ему виднее, где что лежит. Все инструменты и toolchain там уже есть. Надо только грамотно подключить все это к нашему проекту.

Для этого берем и делаем унифицированный makefile:

Все, что вам нужно поправить под себя в этом файле — это первая строчка. В результате делаем make — и скомпилируется программа hello, состоящая из исходников hello.c и hello.h.

После сборки hello тут же появится в директории /home/pi/cross.

Проверяем, что это такое:

Как раз то что нужно!

Еще раз, чтобы не путаться: редактируем файлы и делаем make на host машине (ради этого все и затевалось с кросс — компиляцией и доступом по NFS), запускаем — на target машине. Если вы попытаетесь запустить исполняемый файл архитектуры ARM на Intel машине, получите сообщение об ошибке:

Рабочее место мы создали, теперь будем двигаться в сторону GPU FFT …

 

 

Программа создания радиосети JTRS для боевого управления и ее провал

JTRS, SDR, Software Defined Radio

Взаимодействие компонентов JTRS. Как все красиво выглядело вначале

Программа JTRS — Joint Tactical Radio System должна была увязать сетью цифровой радиосвязи все виды и рода вооруженных сил США. Радиостанции, выполненные по технологии SDR, могли быть выполнены в носимом и возимом варианте; предусматривалось применение как в сухопутных войсках, так и в ВВС и ВМФ.

Программа стартовала в 1997 году, на НИОКР было выделено 6 млрд. долларов. После того как деньги были израсходованы, программа была закрыта. После этого была попытка оживить JTRS, которая опять-таки закончилась очередным закрытием в 2012 году.

И как это бывает в затянувшихся проектах, пока все ожидали результатов JTRS, военное ведомство США тем временем было вынуждено приобретать обычные средства связи, что вылилось в дополнительные 11 млрд. долл. Само собой, после появления в войсках радиостанций JTRS эти вновь купленные средства связи должны были быть списаны.

Таким образом, в результате 15 лет, потраченных впустую и минус 17 млрд. долларов. Что пошло не так?

Какая связь нужна

Совершенно очевидно, что на поле боя без связи — никуда. Перед глазами сразу появляются картинки из советских фильмов, когда связист накручивает индуктор телефона ТА-57 и кричит в трубку под грохот разрывов: «Тополь, тополь, я береза, дайте огня по высоте безымянной!». Только в современности двусторонняя связь отходит в прошлое. Появилось модное слово — сетецентричность, хотя зачем выдумывать новые сущности? И так ясно, что это должна быть сеть связи, поверх которой работают системы боевого управления.

Эти системы, при том же количестве ресурсов — танков, артиллерии, беспилотников, авиации и так далее — позволяют достичь двукратного преимущества за счет только информационного обмена, координации и управления. Пример: локатор на соседней позиции засекает разведывательный БЛА противника и определяет его координаты. Координатная информация тут же идет командиру подразделения, над которым завис беспилотник — вплоть до трека реального времени на командирском планшете. Командир дает команду другому узлу визуально опознать БЛА, после чего получает на свой планшет возможную классификацию БЛА и его фото. После этого идет запрос к серверу баз данных, в результате чего командир получает информацию по боевым и разведывательным возможностям беспилотника. Весь этот блок данных — тип БЛА, его местоположение в реальном времени и его ТТХ — идет в вышестоящий узел сети для принятия решения. Если принимается решение поразить цель, то аналогично данные идут зенитному расчету.

Очевидно, что наладить подобное взаимодействие без помощи развитых средств связи немыслимо. И такие средства связи предполагалось создать с помощью JTRS. Большим подспорьем в этом проекте явилась технология Software Define Radio, SDR. С помощью нее все проблемы формирования излучаемого сигнала — частоты, мощности, модуляции уходили в программную область компьютера радиостанции. Так же и по отношению к радиоприему: большая часть тракта обработки принимаемого сигнала — демодуляция, декодирование, передача данных и голоса — теперь также приходилась на программную область. И этот подход до сих пор оправдал себя на практике вплоть до наших дней: любой мобильник представляет из себя SDR устройство. Чего же не хватило программе JTRS для того, чтобы быть успешной?

Евангелие от создателя продукта

Ключевая особенность JTRS заключалась в том, радиостанции создавались как программируемые устройства с возможностью дальнейшего апгрейда и развития софта, а также чтобы создавать новые приложения, которые могут стать необходимыми в будущем. Для того, чтобы разрабатывать ПО для каждого из вида радиосигналов (waveforms), требуется участие квалифицированных инженеров / программистов третьих сторон, то есть из команд, которые не являются частью больших компаний — исполнителей проекта. Необходимость подобного привлечения уже никто не оспаривает после того как военные  обожглись на создании своей собственной операционной системы: задача по написанию и отладке более 15 миллионов строк кода (значение приведено для версии ядра Linux от 4.0) оказалась неподъемной ни за какие деньги, и поэтому с тех пор используются ОС, которые разрабатываются на коммерческом и открытом рынке.

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

Особенность самоподдерживающегося тренда состоит в том, что участники или вкладываются в успешный тренд и количество их увеличивается, либо они спрыгивают с тонущего корабля. Это хорошо понимали в таких компаниях как Microsoft и Apple, где для создания позитивного самоподдерживающегося тренда работают специальные люди — «евангелисты». Евангелист  сосредотачивается на том, чтобы привлечь сторонних разработчиков программного обеспечения, чьи ранние инвестиции (личным ресурсом) в инструменты, повторно используемые компоненты и приложения имеют решающее значение для запуска тренда. Если завоевать симпатии комьюнити не получится, то дальше идти бесполезно: продукт умрет.

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

В недрах программы JTRS была рождена стандартная программная платформа: Software Communications Architecture (SCA), которой должны были соответствовать все программные разработки. В результате между идеологией этой платформы и стилем разработки, принятым на открытом рынке возникли непримиримые противоречия, которые приведены в этой таблице:

JTRS — типичная разработка для военных с соответствующим подходом 
Характерные особенности программы JTRS Подходы в военной области Подходы на коммерческом рынке
Стандартная платформа Заказывается централизованно, ограниченный объем поставок регулируется также централизованно Выбирается владельцами бизнеса на основе признанных стандартов и протоколов, объем поставок большой
«Военный» процесс разработки Большие команды разработки

Высокий порог вхождения: дороговизна инструментов разработки

Фокус на соответствие требованиям и правильность

Небольшие гибкие команды

Малые вложения в инструменты разработки, как правило бесплатные лицензии

Фокус на сокращение времени выхода продукта на рынок

«Военный» жизненный цикл изделия Длительный жизненный цикл

Стоимость сопровождения превышает стоимость разработки

Короткий жизненный цикл

Стоимость разработки и производства преобладают

Создатели RCA определили жизненный цикл SDR радиосредств, созданных на ее основе — 10 лет. Это значит они заглянули на 10 лет вперед и решили, что военные радиостанции будут современными и актуальными и в конце этого срока. Между тем, когда начиналась разработка JTRS, не было таких технологий как WiFi, 3G и 4G, и потоковая передача видео через Интернет. Лучшие военные умы создавали каналы цифровой связи скоростью аж 9600 бод. За это время жизнь ушла далеко вперед: WiFi стал массовым, народ смотрит потоковое видео с разрешением HD, что раньше нельзя было себе представить (и все это без технических заданий), а JTRS с добротными ТЗ осталась далеко позади.

Платформа RCA оказалась настолько сложной, что отпугнула многих внешних разработчиков ПО, которые могли бы создавать приложения для нее (вместо самоподдерживающегося тренда военные просто отпихнули чужих специалистов). Далее, RCA использовала древнюю технологию обмена данными Corba, что предполагает наличие программного интерфейсного модуля Corba в каждом сменном блоке. Это не проблема для тех блоков которые содержат процессор, под который разработка ПО ведется на языке высокого уровня. Однако, для ПЛИС, а также подобных низкоуровневых устройств, имеющих весьма специфическую архитектуру и систему команд, поддержка стека протокола Corba оказалось сложной и насла дополнительные накладные расходы, связанные со сложностью разработки и потерей быстродействия при передаче данных.

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

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

Вы видели блоки в мобильнике?

JTRS, SCA

Типичная сборка Ground Mobile Radio: набор блоков соединенных шиной SCA

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

Как мы сейчас уже знаем, в противоположность такому подходу в коммерческих радио-продуктах используются чипы с высокой степенью интеграции, что исключает необходимость механической компоновки узлов и использования шины обмена (RCA), что связано с дополнительными потерями по быстродействию. В рамках коммерческого подхода радиочастотный модуль объединяется с преобразователями АЦП/ЦАП (аналоговый чип), в то время как в цифровом чипе совместно работают процессор общего применения и DSP/FPGA. Так например выполнена архитектура OMAP процессоров Texas Instruments.

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

В результате архитектура JTRS была не только сориентирована на узкий круг специализированных исполнителей, но также и не использовала распространенные COTS решения огромного коммерческого рынка приложений, по причине своей жесткости. В результате открытый рынок, использующий собственные рентабельные стандарты, ушел далеко вперед (а что не уйти, если все деньги и лучшие специалисты — на этом рынке?)

И это все только на этапе разработки. На этапе обслуживания и сопровождения закрытые решения также обещали лечь тяжелым бременем на эксплуатацию.

Идея о том, что многообразие передаваемых и принимаемых сигналов — waveforms будет поддерживаться в программной области, а оборудование будет стандартизированным и его номенклатура будет ограниченной, вначале выглядела прекрасной. Далее, однако, выяснилось, что радиостанция — это все-таки инженерный, а не программисткий продукт. Программные модули для разных типов FPGA не получилось использовать за счет условной компиляции — для каждого типа ПЛИС пришлось писать свой код. Радиотракты (как и антенны) были сильно зависимы от диапазона и ломали архитектуру оборудования, а следом — соответственно начинала плыть архитектура ПО.

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

Кризис концепции и методологии — больше чем технические проблемы

Как вам нравятся предсказатели будущего, которые знают, каким будет мир через 10 лет, какое к этому времени будет железо, софт и технологии? Куда пойдет вектор развития? Вы представляете это ТЗ, которое рассчитано на 10 лет вперед?

Ладно, техническое задание — это конкретика. Поговорим о более философских вещах — концептуальных основах проекта. На концепции, как на фундаменте, стоят архитектуры, протоколы и технические решения JTRS. Одним из краеугольных камней программы было положение о том, что меняя программное обеспечение в FPGA, можно сократить номенклатуру плат и достичь реализации всего многообразия waveforms. Намек понятен: железо дорого и хлопот с ним много, его надо производить, поддерживать и ремонтировать, а софт — штука простая, один раз написал и прошивай все подряд.

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

Методология исполнения JTRS как проекта также была раскритикована и названа главной причиной провала. Хотя проект развивался вполне в соответствии с принятыми в то время правилами Waterfall, или как сейчас его называют традиционной разработки (это то, как привыкли работать у нас и работают до сих пор). Идея методологии Waterfall (посмотрите на картинку и поймете почему это называется водопадом) очень проста: все необходимые действия надо выполнять последовательно.

В программе JTRS подобных блоков и субблоков было конечно гораздо больше, чем на картинке.

Традиционная методология разработки Waterfall. Проект движется, мир меняется

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

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

Вдумайтесь! Тринадцать лет те, которым предстояло эксплуатировать эти радиостанции, не имели возможность высказаться и повлиять на процесс разработки. И когда тринадцать лет спустя в войсках увидели эти результаты, новые современные радиостанции JTRS получили нелицеприятную оценку «radio that weighed as much as a drill sergeant, took too long to set up, failed frequently, and didn’t have enough range» (радио весит столько же, сколько мой сержант-инструктор, слишком долго настраивается, часто отказывает и не дает дальности, которая нужна).

Что у нас?

Конечно, все что было сказано про боевое управление и связь относится также и к отечественным реалиям. Хронология получилась такая: в конце 2012 года появилось сообщение о том, что в войска начнут массово поступать цифровые радиостанции VI поколения «Азарт — П1». Конечно, нумерация поколений впечатляет, или может они ведут свое начало с искровых передатчиков?

Процесс появления новой радиостанции вызвал бурное обсуждение в комьюнити. Далее, в новости этого года было сказано, что радиостанции «Р-187П1 удалось не просто догнать, но и по некоторым позициям превзойти зарубежные образцы». Видимо, речь идет о той же радиостанции в портативном исполнении; в сети информация по возимому варианту отсутствует. В этой же новости было сказано, что радиостанция уязвима к средствам РЭБ и что к 2021 году будет производиться «сверхзащищенная» ее версия. Что-то мне подсказывает, что дополнительных версий будет еще много…

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

Судя по всему, работы продолжаются, хотя очевидно и не с таким размахом как JTRS. Будем надеяться, что отечественные разработчики сделали выводы по результатам этой программы. В свое время было много отсылок на JTRS, типа «вот у американцев целый сетевой проект», потом отклики поутихли.

Оптическая система посадки: обнаружение ВПП

Промежуточный этап работы подсистемы обнаружения и сопровождения взлетно — посадочной полосы (ВПП). Для беспилотного аппарата (БЛА), или дрона, с учетом чувствительности к действию ветра, критически важно отрабатывать отклонения от глиссады. Для этого нужна автоматизированная система посадки, которая работает в реальном времени: оператор просто может не успеть.

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

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

«Приблизительно» означает, что мы сохраняем высокий уровень ложной тревоги обнаружения, чтобы сохранить снизить вероятность пропуска. Вероятность ложной тревоги снижается в результате более жесткого алгоритма, результат работы которого — на правом фрейме. Тут все немного сложнее.

Начнем по порядку. Каждый опознанный контур приводится к характерной точке ландшафта  — Featured Point (FP). Эти точки проявляют тенденцию к относительно стабильному существованию во времени; ну и само собой они могут смещаться относительно камеры в зависимости от маневров БЛА. В этом собственно и содержится главная информация: динамика изменения положения FP относительно камеры.

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

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

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

Софт сделан на Python’е. Тесты показывают, что основная нагрузка на процессор возникает в алгоритмах оконтуривания. Предстоит соображать, как все это переносить на встраиваемую платформу…

Методы кодирования сигналов нейронных сетей: инженерия природы

В технологиях нейроподобных сетей (НПС) делаются определенные предположения о том, как кодируются сигналы, циркулирующие внутри НПС. При этом почему-то предполагается, что природа будет использовать аналоговые сигналы в том виде, к которым мы привыкли, и есть даже попытки «натянуть» наши компьютерные бинарные представления на НПС.

Как же на самом деле кодируются сигналы в реальной нейронной сети — в головном мозгу животного или человека, и как их можно интерпретировать? В последнее время появились очень интересные биологические исследования работы нейронов. В них авторы рассматривают проблему в основном под биологическим углом зрения, что соответствует их специализации. Поскольку мы инженеры, нам в свою очередь весьма интересны методы, которые природа выбрала для кодирования сигналов. И как обычно, очень хочется задать главный вопрос, на который кроме разработчика ответить некому: не только узнать, как сделано, а получить ответ на вопрос: почему сделано именно так?

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

Результаты современных исследований

В этой обширной обобщенной статье Neural population coding: combining insights from microscopic and mass signals, которая в свою очередь использует результаты 119 научных работ в этой области, подведены промежуточные итоги исследований сигналов нейронных сетей. Картинку я взял тоже оттуда. Статья датирована мартом 2015 года.

Посмотрим на все это с точки зрения кодирования и обработки сигналов.

Реакция нейронов на различные символы. Картинка из статьи Neural population coding: combining insights from microscopic and mass signals

Не будем сильно углубляться в биологическую специфику методики экспериментов. Нас интересуют наблюдения и результаты.

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

Давайте сразу начнем сомневаться: почему собственно для исследований наблюдались всего несколько нейронов. Насколько эти данные могут характеризовать поведение оставшихся? Этот подход оправдан, потому что как я скажу дальше, наблюдается большая корреляция между выходными сигналами множества нейронов в такой группе. Да, мы будем по привычке использовать понятие «выходной сигнал» нейрона. Биологи называют его spike — импульс, а группу называют популяцией нейронов. Поэтому поведение одного отобранного нейрона хорошо характеризует целую группу.

Следующее сомнение — почему импульсы обозначены черточками с равновеликой амплитудой? Мы можем согласиться с тем, что ширина импульса не критична, но амплитуда, один из важных информационных параметров? Есть такая гипотеза: природа полностью забила на амплитуду. Это объяснимо, потому что в этой электрохимической системе трудно поддерживать правильные уровни сигналов. К тому же индивидуум может закинуть себе в пасть нечто, что полностью перемешает все уровни сигналов в мозгу )

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

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

Теперь снова взглянем на картинку.

Информационные параметры сигнала

Для того, чтобы передавать информацию посредством импульсов — spikes, необходимо использовать модуляцию параметров сигнала. Наблюдаем следующие методы кодирования параметров модуляции (перевод терминов мой, более близкий к инженерной области чем к биологической):

Firing Rate (темп выдачи сигнала). Количество, или интенсивность выходных импульсов определяет, на какую картинку реагирует нейрон. Нейрон A имеет «узкую настройку» и поэтому реагирует только на ромбик. Настройка нейронов C и D «шире» и больше предпочитают другие символы, а на ромбик реагируют вяло. Нейрон D вообще не дает никакой полезной информации и просто тупо реагирует на все картинки (может это стробирующий импульс?).

Relative Timing (взаимная задержка). Как видно по картинке, хотя нейроны B и C реагируют как на квадратик, так и на звездочку одинаковым количеством импульсов, для звездочки нейрон C дает задержку по времени. Чем не фазовая импульсная модуляция?

Periods of Silence (нулевой уровень).  Отсутствие информации — тоже информация. Своим молчанием нейрон A говорит о том, что ромбик в поле зрения отсутствует.

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

Комплементарность

Нейроны могут нести дополнительную, или комплементарную информацию по отношению к другим нейронам. В этом случае они увеличивают выходной сигнал (Firing Rate) когда наблюдают «свою» картинку, но также обладают способностью уменьшать его, когда вместе со своей картинкой присутствуют другие. Для чего это нужно?

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

Межнейронная корреляция Firing Rate

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

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

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

Такая своеобразная модуляция параметров выходного шума входным сигналом дала повод предположить, что это отдельный способ кодирования, дополнительный по отношению к Firing Rates. Почему бы и нет? В конце концов, нам известны такие шумоподобные сигналы, которые модулируются полезной информацией — например, CDMA. Шум шумом, но за счет кодового разделения можно вытащить информацию, которая требуется.

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

Тайная школа нейронных наук

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

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

Еще одна загадка: как нейронная сеть узнает о том, что она работает правильно, и меняет свой алгоритм в зависимости от обнаруженных ошибок? Может, когда мы обнаруживаем, что сделали что-то не то и в ответ бьем себя по лбу, это и есть та обратная связь которой недостает? ))

Разведывательный полет

Видео советую смотреть в разрешении 720p или 1080p

Беспилотная тема выходит из лаборатории на свежий воздух. В результате кооперации с энтузиастами летающих моделей состоялся летный эксперимент — своего рода разведка боем. Он преследовал сразу несколько целей:

  • получение качественного видео, имитирующего взлетно — посадочную полосу (ВПП) с расположенными на ней маркерами. В качестве ВПП была отснята автострада;
  • проход над «ВПП» под различными углами, высотами и имитация захода на посадку;
  • получение данные телеметрии и создание подсистема их визуализации в реальном времени.

Все это — для дальнейшей обработки автопилотом оптической посадки, что и является основной целью данного проекта.

Результаты обработки эксперимента были сведены в два клипа длительностью около одной минуты. На первом клипе — данные с камеры, на втором — показания приборной панели, полученные по результатам телеметрии. Клипы были синхронизированы по времени, насколько это возможно.

Итак, рассказываю про эксперимент, что и как )

Борт

В качестве беспилотника взяли имеющийся в наличии Phantom 4. Это квадрокоптер, которому автоматическая посадка особо не нужна. Но мы все равно решили полетать на нем, чтобы иметь возможность сделать несколько проходов и обеспечить качество картинки. Фантом управлялся с отдельного пульта, к которому был подключен планшет Samsung/Android.

Когда дело дойдет до автоматической посадки, будем облетывать свое. Например это:

IMAG3305

Иди даже вот это:

IMAG3306

Энтузиасты свое дело знают!

Камера

На Фантоме установлена камера Go Pro с разрешением HD. Камера стабилизирована на карданном подвесе, есть возможность управления углом наклона. Мы выставили около 30° вниз, чтобы лучше было видно дорогу с маркерами.

Видео с камеры идет на экран приложения планшета, и также записывается приложением в формате mp4 целым файлом. Видео также записывается на SD карту которая вставляется в квадрокоптер, на карте я обнаружил несколько MOV файлов с размером около 2 Гб каждый.

Тут возникла первая проблема: частота фреймов Go Pro — 120 кадров в секунду, мои кодеки на Ubuntu неправильно определяли ее (как 30 fps) и соответственно попытка понизить frame rate до 30 кадров в секунду не увенчалась успехом. Потом я нашел другой способ: в видеоредакторе kdenlive использовал фильтр, который понижает скорость воспроизведения в четыре раза. В конечном счете, я просто взял mp4 файл который записался в планшете и работал с ним.

Вторая проблема касается синхронизации видео и телеметрии. В определенный момент соответствие картинки и данных компаса и высотомера расходились. Я предполагаю, что оператор Фантома не включал соответствующие режимы записи видео или телеметрии на некоторых взлетах/посадках. Это предположение основывается на том, что суммарная длительность видео и время лога телеметрии различались в полтора раза. Этот вопрос предстоит изучить более детально.

Софт

На планшет я установил приложение DJI Go, в котором можно получать изображение с камеры квадрокоптера. Покопавшись в файловой системе,  нашел лог телеметрии. Его формат неизвестен, но есть возможность перекодировки в csv. Для парсинга лога я воспользовался сервисом сайта healthydrones.com.

Были оставлены только данные, которые представляют интерес: координаты в виде широта/долгота, данные компаса, высоты, угол наклона камеры и метки времени. Лог выглядел примерно так:

Лог телеметрии БПЛА

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

Для обработки лога и визуализации полета «по приборам» было написано Qt приложение, которое разбирало лог синхронно с временными метками и отображало информацию на «приборах» кокпита. В качестве таких приборов были применены замечательные виджеты QFlightInstruments.

Индикация организована следующим образом. Данные высоты не калибровались. Они отображаются на отдельном индикаторе и на комбинированном индикаторе авиагоризонта.

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

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

В правом верхнем углу — отметка даты и времени.

На панели есть еще один индикатор, который пока не используется. На него будет выводится посадочная информация — отклонение БПЛА от глиссады. Это позволит оператору вести посадку как в ручном режиме, так и контролировать посадочный автопилот.

ToDo

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