Игры и Люди

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

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

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

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

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

Google+

Кросс — компиляция для 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’е. Тесты показывают, что основная нагрузка на процессор возникает в алгоритмах оконтуривания. Предстоит соображать, как все это переносить на встраиваемую платформу…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Темная сторона КСА УВД Галактика

Встречаются два программиста — один пишет на Си, другой на Ада. Си-программист говорит: — Я буду бифштекс с луком

Анекдот понятный только для тех программистов, кто в теме )

Отображение воздушной обстановки на экране диспетчера. Какое программное обеспечение скрыто за монитором?

Разработка программного обеспечения для промышленных систем

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