Игры и Люди

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

От игрушек детства мы движемся к другим. Здесь — об этом.

Алхимия игры включает несколько ингредиентов.

Рецептура состоит из Миров, по которым можно путешествовать; не все из них достаточно хорошо населены. Дело — это Игрушка одного из миров.

Объединяя видимые и сокрытые элементы, Алхимия выступает и как самостоятельный Игрок.

Google+

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

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

\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, типа «вот у американцев целый сетевой проект», потом отклики поутихли.

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

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

В левом фрейме обычное видео из интернета, иллюстрирующее

Читать дальше

Целых три истины

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

«Эль Сид совместно с войском Аль Мутамида — эмира Севильи,

Читать дальше

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

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

Как же на самом деле кодируются сигналы в реальной нейронной сети

Читать дальше

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

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

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

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

Читать дальше

Собственные числа и векторы в поиске закономерностей. Метод главных компонент

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

Что поделаешь, это еще одно напоминание о том, что человеческий глаз — это совершенное средство обработки данных.

В этом примере прямая —

Читать дальше

Если у вас нет дома: краткий курс бытия от Лао-Цзы

Если у вас нет дома, Пожары ему не страшны, И жена не уйдёт к другому, Если у вас нет жены.

Если у вас нет тёти, То вам её не потерять, И если вы не живёте, То вам и не умирать.

Оркестр гремит басами, Трубач выдувает медь. Думайте сами, решайте сами — Иметь или не иметь.

Читать дальше

Пассивный радиолокатор с нейроподобной ФАР

В пассивном радиолокаторе есть функция определения направления прихода сигнала DOA (Direct of Approach). Знание углового положения источника сигнала и помехи позволяет повысить однозначность определения координат цели на эллипсах равновероятного местоположения. В дополнение к уже рассмотренным адаптивным методам, попробуем реализовать нейроподобный подход к задаче определения DOA.

На вход нейроподобной сети (НПС) будем подавать сигнал с элементов

Читать дальше