Об искусственный интеллект

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

По шагам я сначала удалил с телефона старую eSIM, а потом запросил ссылку на активацию новой, и её - тадам - оператор послал на номер этой eSIM, о чём мне и написал.

После недолгого выяснения оказалось, что инструкцию мне нагаллюцинировал и прислал ИИ чат-бот. Работает ли она? Ха-ха, конечно же нет

Спустя два дня переговоров с оператором и такой-то матери ссылку удалось исправить и переотправить.

Будующее такое яркое..

Об Ролодекс

(Полная версия статьи с картинками тут https://telegra.ph/Ob-Rolodeks-08-13)

Что вы знаете про Ролодекс?
Кто-то из читателей услышит это слово в первый раз, кто-то встречался ранее. Ролодекс это название определенной вещи, ставшее потом нарицательным. Вещь эта - персональный менеджер информации, PIM или CRM, и в до-компьютерную эру представляла из себя коробочку, крутилку с алфавитными закладками, куда можно было вставить визитку с краткими личными данными человека, адресом, телефоном, и чем вы могли бы быть друг другу полезны, а на обороте можно было добавить заметки.
Простая, тривиальная вещь, но почему-то она была в активной эксплуатации почти у каждого на столе, кого мы с вами теперь знаем как деятельного предпринимателя и успешного человека из прошлого.
Я не шучу: вот что писала Joann S. Liublin об этом в The Wall Street Journal:

"Мистер Рокфеллер заносил контактную информацию и детали каждой из своих встреч с более чем 100 000 людей со всего мира на индексные карточки размером 3 на 5 дюймов. Всего он накопил примерно 200 000 таких карточек, которые вставлялись в специально построенную для него Ролодекс-машину. Более полувека эта электронная машина высотой 5 футов стояла в его личном офисе Рокфеллер-центра в Нью-Йорке. Будучи главой банка Чейз Манхэттен и виднейшим филантропом, Рокфеллер отслеживал бесконечное количество связей с богачами и знаменитостями, простирающихся через границы, дисциплины и интересы, – от коллеги бизнес-титана Билла Гейтса до шаха Ирана, президента Джона Кеннеди, папы Иоанна Павла II и Нила Армстронга, первого человека, ступившего на Луну. Благодаря этой необычной системе записей он мог продолжить разговор с человеком, которого не видел уже много лет, как будто их последняя встреча была на прошлой неделе ... "Во время обеда в своем имении в 2015 году господин Рокфеллер подарил господину Киссинджеру копию его 35 карточек из Ролодекса. На них были заметки о сотнях их разговоров, прошедших со дня первой встречи в далеком 1955-м. Мистер Рокфеллер понял важность контактов во время своей службы в армейской разведке за рубежом..."

Выходит, нужная это вещь, ваш Ролодекс! Ну и теперь, с созданием персональных компьютеров необязательно быть Рокфеллером, чтобы заказать себе "специальную Ролодекс-машину", достаточно открыть блокнот, и начать писать туда, верно? Теперь каждый из нас оборудован, усилен невероятными возможностями. А вот давайте посмотрим..

Я начну с Windows. В первых выпусках Windows, прямо с 1.0, в системе действительно был в наличии электронный аналог Rolodex. Собственно, за этим он и был туда добавлен, чтобы вы использовали свой компьютер для своей пользы. Вы могли добавить туда карточку-визитку или просто заметку, а так же поискать в записях. Записи хранились в файлах. Чтобы мнемонически походить на бумажную картотеку, интерфейс мог быть немного настроен, а карточки можно было перебирать.

С версии Windows 3.11 в приложение добавили возможность OLE, так что вы могли внедрить прямо в карточку любой объект, типа скана, картинки, или даже целый Excel-лист, запись из ежедневника или адресной книги, ну и так далее, как это сейчас делает Word или OneNote, например. При этом формат хранения зачем-то поменяли так, что все предыдущие записи не могли быть импортированы в новый формат. С выходом 32-битной Windows NT приложение обновили, при этом опять поменяли формат так, что предыдущие записи не могли быть импортированы в новое приложение 🙂
С выходом Win 95 приложение вовсе перестало устанавливаться в систему по умолчанию. Его можно было скопировать с установочного диска, и запускать, если вы знали, где и что вам искать (MS уже не хочет, кстати, чтобы вы об этом помнили: https://web.archive.org/web/20150331004051/http://support.microsoft.com/en-us/kb/245157)

В какой-то момент, примерно с Windows 98 или ME, MS забросила приложение, вместо него предложив MS Schedule+, который шел в пакете с MS Office и даже мог импортировать старые карточки, правда, из-за измененного формата Unicode делал это неправильно. Правда, это приложение страдало от проблемы 2000 (на самом деле), и MS, зная о проблеме, не стали его переделывать, а забросили, в качестве альтернативы с 97 года продвигая использование контактной книги из MS Mail и Outlook (Express) с новыми крутыми вещами, типа поддержки лунных календарей и настройки автоматического уничтожения старых записей (YOUTHINKIMFUCKINGWITHYOU? IMNOTFUCKINGWITHYOU! https://microsoft.fandom.com/wiki/Microsoft_Outlook#Outlook_2002). Стоит ли уточнять, что альтернативой это можно назвать с огромной натяжкой? Так, мы лишились одной из программ, помогающей наладить и систематизировать нетворкинг, вместо него получив невротическую "контактную книгу". Кто в здравом уме и по своей воле заглядывает в контактную книгу Outlook?

Ладно, MS есть MS, от него ничего хорошего не жди. А что у Apple?
У Apple история еще интереснее. Понимая важность инструмента, Apple выпустили свой вариант под названием HyperCard, также бесплатно встраивая его в саму ОС. Однако, Apple шагнули еще дальше, и добавили к карточкам возможность привязать скрипты, элементы ввода кнопки, так что прямо в картотеке можно было организовать разнообразный мультимедиа-калейдоскоп. Кроме того, специальные карточки с преднаписанными скриптами, который могли быть добавлены в "ежедневник", оборудовали картотеку возможностью запрашивать данные из БД, читать устройства, расставлять сеть гиперссылок в карточках - этакое программирование без программирования. У "настоящих программистов" из Oracle настолько бомбануло, что они резко выпустили свой бесславный мультимедиа-аналог - Oracle Card - который спустя непродолжительное время был так же резко заброшен (https://en.wikipedia.org/wiki/Oracle_Media_Objects).
В общем, с одной стороны, Apple сделали всё, чтобы покрыть запросы максимально широкие, а с другой - превратить картотеку в инструмент программиста, этакий Powerpoint, который, как известно, рак любого серьезного дела. Ну а далее всё пошло по накатанной: в Mac OS X эту программу не пустили, так что многие современные пользователи и не знают, что она была.

Одни последовательно выбивали ноги из-под табурета вашего личного нетворкинга, другие сделали всё, чтобы вы делали "креатив & программирование", а не выстраивали отношения.

А вы ведете Ролодекс? Или для вас нетворкинг это синоним "заёбывать малознакомых людей приглашением на чашку кофе?"

08.2024: пока что еще не пересидели

Не я один отмечаю, что Скрам это потогонка: https://rethinkingsoftware.substack.com/p/why-scrum-is-stressing-you-out

В принципе, тут простыми словами и поменьше, чем я писал в 2020, но вектор примерно тот же

Об мышиное зрение

В связи с появлением у меня Intel Core Ultra 155H решил попробовать оседлать NPU, встроенный в него. Для тестирования использовал модельки YOLO, потому что они достаточно понятно написаны на Питоне, а также могут быть легко экспортированы во множество форматов.

Что касается inference — работает без проблем, всё ускоряется в 2-3 раза по сравнению с голым cpu таргетом. Для компиляции и запуска я использовал OpenVINO и готовую модель, датасеты для которой стащил с сайта Roboflow и все сразу заработало в дефолтной конфигурации.

Что касается обучения, то результат хуже.

Само по себе YOLO не умеет использовать для обучения ускорители, кроме CUDA (похоже). Есть некие проекты вроде:
1. Intel extensions for pytorch (ipex) - для CPU и XPU (дискретная карта Intel)
2. intel-npu-acceleration-library (npu)
3. DirectML для ускорения операций при помощи любого железа, поддерживающего opencl
4. Разные опенсорсные поделки, приземляющие openCL на железо.

Из всего этого списка я смог разобраться только со вторым пунктом, так что YOLO успешно стало тренироваться с загрузкой NPU на 35-50%. Также хочу еще попробовать п.1 для CPU. Как использовать встроенный iGPU для обучения я пока не нашел способов.

Результатом NPU я, скорее, недоволен — обучение ускоряется всего на 20-25% относительно голого CPU в моей конфигурации. С учетом перспектив п.1 с расширениями для CPU, которые потенциально могут ускорить итерации вдвое, NPU не выглядит как подходящий бэкенд для тренировки — видимо, сказывается недостаточное количество блоков в архитектуре. А вот запуск натренированной сетки — ускоряет заметно.

Про ipex напишу еще, если что-то получится.

Об мышиное зрение 2 /памятка для себя самого/

Так как не на каждое изделие можно взгромоздить системный блок, а распознавание картинки требует сложных вычислений, приходится выбирать что-то более портативное. Мой выбор пал пока на творения китайской Rockchip серии RK35xx, оснащенные нейроускорителем. Вариантов исполнения модуля доступно несколько, мне приглянулся самый простой Orange Pi.

Многочисленные тесты показывают на модельке YOLO v5 производительность вывода на кадре 640х640 пикселей такую:

* i7 7700k - 120ms
* i5 13600k - 80ms (npu)
* rk3566 - 100ms

> ПРИЕМЛЕМО <

Ниже пишу шаги, как дойти от готовой модели к работающей системе. Тренировку модели оставим за скобками. Я использовал Python 3.10.15 для всего.

1. Китайцы из Rockchip немного доработали модель YOLO, так что её input/output форматы не совместимы с оригинальной моделью. Причина написана в пункте 2. Код для тренировки модели, а так же код для детекции надо брать в репозитории самого Rockchip, а не у Ultralytics: https://github.com/airockchip/yolov5

2. Если вы сами тренировали модель на своих данных, предстоит её экспортировать из PyTorch в Onnx. Тут надо сделать небольшое отступление. Современные модели давно уже не просто матрицы весов, а целые программы для виртуальных машин, со своими байт-кодами. Они могут быть не совместимы между собой, хотя и используют общий базис операторов. Не все операции поддерживаются аппаратно Rockchip, именно для такой оптимизации модель видоизменена. Модели PyTorch (.pt) и вовсе могут включать в себя сериализованные питон-объекты. Чтобы привести модель к каноническому виду, нужен экспорт в какой-то нейтральный формат. Экспорт делается, как указано тут https://github.com/airockchip/yolov5/blob/master/README_rkopt.md Результатом будет модель формата ONNX. Это тоже промежуточный шаг на пути к плате.

3. Для симуляции работы модели на компьютере следует использовать библиотеку https://github.com/airockchip/rknn-toolkit2/tree/master/rknn-toolkit2, а для работы на плате https://github.com/airockchip/rknn-toolkit2/tree/master/rknn-toolkit-lite2
Библиотеки существуют только для Linux. Ubuntu 24 в WSL2 подойдет.
При этом в симуляции работает только ONNX модель, а на плате для использования ускорения только RKNN.
В исходниках можно найти код загрузки ONNX модели и конвертации её на лету в RKNN модель. Также в репозитории можно найти инструкции, как конвертировать ONNX в RKNN запуском скрипта.

4. Остальной код, включая препроцессинг и постпроцессинг изображений, одинаков и для симуляции, и для платы, и взят тут https://github.com/airockchip/rknn-toolkit2/blob/master/rknn-toolkit2/examples/onnx/yolov5/test.py.

После загрузки RKNN в ускоритель можно подавать в неё кадры и получать положительные результаты.

Картинки детектятся, Python круто, Orange Pi 3B тоже хороша.

Об OSD

Если вы умеете не только в цифровое, но и в аналоговое радио, то сделать прототип векторного OSD для своей fpv-камеры не составит труда. Кое-что добавить на экран с картинкой с композитного видео не помешает. Следующим постом я покажу картинку со схемой, а тут приведу описание. Что нам нужно для работы простого монохромного OSD - суметь в правильный момент вмешаться в формирование строки и кадра, и подтянуть напряжение в нужных точках на нужное время к питанию (это будет белая точка или к земле — это будет черная). Для того, чтобы это сделать, хватит atmega на кристалле 16 Мгц и несколько ширпотребных радиодеталей. Я буду рисовать белым.

Сначала из входного сигнала надо отсечь положительное смещение, потому что у разных камер оно разное, это делается конденсатором C1. После этого на R1 и D1 собрана схема восстановления положительной составляющей, которая поднимает сигнал до нужного нам уровня. На R2 и D2 собран генератор референсного напряжения порядка 0.56В. D1, D2 у меня это дешевые импульсные диоды 1N4148.

В итоге мы получаем на входе Comparator-A сигнал, который каждую строку и каждый кадр проседает до примерно 0.3В. Теперь потенциометром R3 на входе Comparator-B можно задать примерно 0.3 вольта, а на atmega настроить аналоговый компаратор, чтобы он генерировал прерывание по сравнению двух входов. В итоге мы получим, что в обработчике прерывания у нас есть момент начала гасящего импульса строки или кадра. Таймером мы считаем время, пока компаратор не вернется в исходное, и понимаем, это был ССИ или КГИ, и выставляем у себя переменные.

Итого, мы имеем номер строки на экране, понимаем начало кадра — и далее в обработчике прерывания компаратора осталось отработать эту информацию и нарисовать развертку. С таким медленным чипом, как Атмега, это непросто, и работать надо в реальном времени, так что лишего бюджета времени во время рисования линии нет даже на операцию настоящего деления - настоящее деление занимает 1/20 кадра по горизонтали — так что приходится пользоваться битовыми сдвигами или предрасчитывать ранее.

Собственно, зная, что нужно изобразить в данной точке строки экрана, загоняем соответствующие байты в SPI регистр. SPI на atmega, как вы помните, может разгоняться аж до половины тактовой частоты кристалла, и на каждый такт на выходе из него будет появляться бит, начиная со старшего. 1 будет рисовать белый участок линии, 0 — оставит картинку как есть. Чтобы
На частоте кристалла в 16МГЦ это позволит рисовать только сдвоенные пиксели относительно максимального разрешения PAL, то есть около 340 пикселов на экранную строку, но и это неплохо. Разрешение в 300+ линий по высоте остается. Самое сложное тут будет посчитать тайминги — каждая машинная операция идет в зачет, писать придется на Си или Ассемблере.

Кажется, мы тут применили знания из десятка разных предметов. А еще говорят, что программистам математика, физика, электроника не нужны..

Что рисовать на экране? Это уже что фантазия предложит. Кому-то нужны линии уровня, кому-то текст — для текста надо будет реализовать свой знакогенератор. Я добавил i2c-интерфейс, чтобы управлять картинкой при помощи SMBus-протокола.

Дальше будет принципиальная схема.

1. Здесь Sin и Sout совмещены. Если хочется их развести, понадобится буферный каскад, например, по каскодной схеме; мне не понадобилось. 2. Кто-то говорит, что генератор PWM в atmega + интегрирующая цепочка могут заменить потенциометр — возможно, но я не пробовал, может быть, вы попробуете

Об GPIO в линуксах

Как вы знаете, некоторые время назад в линуксе декомиссовали управление GPIO через псевдо-ФС /sysfs. Несмотря на то, что поддержка в целях совместимости сохраняется, использовать это ни в коем случае не надо. Вместо этого предлагается символьное устройство, на большинстве дистрибутивов это /dev/gpiochipX и ядерный интерфейс uapi к нему. А чтобы воспользоваться интерфейсом, лучше всего использовать libgpiod.

Если в Raspberry PI этот момент разобран достаточно подробно, то наш дорогой Xulong предоставил владельцев Orange PI самим себе, опубликовав только wiringOP и байндинги к разным языкам, который еще и работает из-под рута. И если в дистрибутиве Orange OS про i2c как-то подумали и есть инструкции, то про GPIO api там вообще ничего нет. Ну и ничего, мы справимся, щас покажу как.

Сначала надо поставить libgpiod посвежее подходящей версии. У меня Ubuntu 22.04, я качал предсобранный архив отсюда https://raw.githubusercontent.com/devdotnetorg/docker-libgpiod/HEAD/out/libgpiod-bin-2.1.2-ubuntu-22.04-aarch64.zip Но у автора есть шелл-скрипт, который позволит и версию выбрать, и собрать из исподников, если надо. Скачанное просто нужно распаковать в /usr как есть.

Дальше я поставил библиотеку для питона вот такой командой:
LINK_SYSTEM_LIBGPIOD=1 pip install gpiod
Переменная окружения тут говорит, что не надо тащить с собой никакие библиотеки, надо брать, что в системе есть.

По умолчанию доступ к GPIO есть только из-под рута, поэтому чтобы обычный юзер получил доступ, потребуется слегка настроить udev. Доступ необходимо дать к устройству, отвечающему за нужный вывод ( /dev/gpiochipX). Как определить нужное устройство в Orange Pi, тоже есть нюанс.

Открываем распиновку платы в документации, скажем, вывод (pin) 27 помечен как GPIO1_A0. Надеюсь, вы не активировали альтернативные функции — UART, I2C, SPI — в device tree через orangepi-config на этот вывод, и он доступен (проверьте командой gpio readall, рядом не должно светиться ALTx). GPIO1_A0 расшифровывается так:
1 - чип
A - банк выводов (A= 0, B = 1, C.., D..)
0 - номер вывода в банке.
Номер чипа = 1, номер линии (понадобится потом) = 8 * номер_банка + номер вывода. В моем случае chip = 1, line = 0, пригодится.

Делается это в моём случае так:

sudo groupadd gpiod
sudo usermod -aG gpiod orangepi
sudo echo '# udev rules for gpio port access through libgpiod
SUBSYSTEM=="gpio", KERNEL=="gpiochip1", GROUP="gpiod", MODE="0660"' > /etc/udev/rules.d/61-gpiod.rules

gpiochipX=gpiochip1, потому что у меня chip=1. После перезагрузки у пользователя orangepi, как состоящего в группе gpiod, будет доступ к нужному контроллеру.

Теперь в вашем скрипте управления умным изделием можно сделать так:

import gpiod
from gpiod.line import Direction, Value
LINE = 0
request = gpiod.request_lines("/dev/gpiochip1",
                             consumer="example",
                             config={LINE: gpiod.LineSettings(direction=Direction.OUTPUT, output_value=Value.ACTIVE)})
# ...
request.set_value(LINE, Value.ACTIVE)
# ..
request.set_value(LINE, Value.INACTIVE)

Если есть дополнения, то пишите тоже.

И Fairchild, и TI пытались основать производства в Японии ещё в начале 60-х, но наткнулись на жёсткое сопротивление MITI. В 1962 году MITI запретило Fairchild инвестировать в уже купленную в Японии фабрику, и неопытный Нойс попытался выйти на японский рынок через корпорацию NEC. В 1963 году руководство NEC, якобы действуя под давлением правительства Японии, добилось от Fairchild исключительно выгодных условий лицензирования, впоследствии закрывших Fairchild возможность самостоятельно торговать на японском рынке. Только после заключения сделки Нойс узнал, что президент NEC по совместительству председательствовал в комитете MITI, который блокировал сделки Fairchild. TI попыталась основать производство в Японии в 1963 году, уже имея отрицательный опыт переговоров с NEC и Sony. MITI в течение двух лет отказывалось дать определённый ответ на заявку TI (при этом вовсю воруя их микросхемы и выпуская у себя без лицензии), и в 1965 году США нанесли ответный удар, угрожая японцам эмбарго на ввоз электронной техники, нарушавшей патенты TI, и для начала забанив у себя на рынке Sony и Sharp.

Одна из статей Википедии по вроде как, узкой технической теме, которая читается как приключенческий рассказ:

https://ru.wikipedia.org/wiki/%D0%98%D0%B7%D0%BE%D0%B1%D1%80%D0%B5%D1%82%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D1%81%D1%85%D0%B5%D0%BC%D1%8B

Хорошо идет вместе с (и взаимно-дополнено текстами): https://habr.com/ru/companies/onlinepatent/articles/723104/

На последней TeamleadConf один из докладчиков пожаловался на то, что на их микросервисное монорепо, все писанное на Go, перестало хватать разработчиков -- буквально вот не могут найти на рынке, конкуренция жёсткая даже между командами внутри (ха-ха, кто мог подумать? Вот бы кто-то об этом раньше написал!)

А я в связи с этим предлагаю вспомнить один пост из этого канала трехлетней давности, из которого становится ясно, почему делать микросервисы, но все писать на одном языке (а монорепо значит с вероятностью 99% и моноязык) это потенциальная глупость и ошибка 👇

Об микросервисы в который раз

Ну, хорошо, всем продали микросервисы: дескать, и устройство системы понятнее из-за них, и two pizza team вообще стандарт в Гугл ИТ, значит, и нам надо тоже. И код можно писать на самом подходящем языке: хочешь, пишешь на php, не хочешь, пишешь на nodejs, что очень удобно (особенно потом сопровождать комплекс, написанный на 10 языках). А еще можно переписать за две недели маленький микросервис, любой. Ну круто же, правда?! А еще архитектура очень отказоустойчивая, и если один сервис упал, то остальные выживут (на практике - не работает никогда). И самое главное - можно МАСШТАБИРОВАТЬ приложения! О том, что монолит тоже можно масштабировать, тем более сейчас, когда железо ничего не стоит, молчат.

Но это все selling points для недоверчивых технарей, а я расскажу, почему на самом деле бизнес выбирает микросервисы. Причин всего две:
1. Быстрая проверка гипотез, которые в 9 из 10 случаев проваливаются - да, продакт-менеджеры тоже не боги. В случае монолита вы стоите перед непростым выбором: или вкладываться по полной в эксперимент (дизайн, код, тесты), который, скорее всего, будет выброшен, или на коленке слепить то, что рискует выстрелить, и тогда с этим поделием придется жить вечно в монолите. Какой вариант хуже? Оба хуже. В случае с микросервисами эксперименты не сильно трогают ядро системы, которая кормит всю компанию и их семьи.
2. Найм. В ситуации, когда средней компании найти хорошего разработчика за праздник, в случае микросервисной архитектуры можно нанимать вообще любых программистов, которые подвернулись, а не те, которые подходят по стеку или согласны работать с легаси и т.п.

Эти две причины пересиливают все сложности, связанные с МСА. А сложностей немало, от оркестрации до смены парадигмы владения системами.

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

Об remoteproc

В комментариях к предыдущему посту (https://www.tgoop.com/architect_says/501) задают резонный вопрос: если Atmega не успевает даже вовремя выполнять деление, как вообще писать более-менее производительный код? Ну, как -- брать более мощный процессор. Правда, с этим начинаются нюансы.

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

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

Во-первых, там установлен linux. Как заставить его забыть про 1 процессорное ядро, а на него повесить выделенную активность вне ОС -- это вопрос отдельного исследования. Да, есть Xenomai, есть китайский RROS, но всё равно это задача непростая.

Второе, и более сложное: несмотря высокую производительность ARM-ядра Cortex-Axx, оно менее детерминировано: тактовая частота в доменах плавает и троттлится, шиной доступа к периферии управляет арбитр, конвейер живет своей жизнью, как и механизм кэша, контроллер прерываний сам по себе сложнее, чем К580.
Между прочим, за одну микросекунду экран съезжает на 10 пикселей, мы себе не можем позволить дрожание (=неопределенность в обработке прерывания) даже в 500 нс.

Для решения такой ситуации ограниченными аппаратными средствами используется выделенное микроконтроллерное ядро, доступное как периферия и простое: никаких кэшей, никаких конвейеров, фиксированная частота, выделенный коммутатор шины: по сути, это микроконтроллер внутри процессора. Например, таким ядром оборудованы SoC Amlogic, TI или Allwinner. Иногда его могут назвать типа Power management core. Здорово, что в linux kernel начинают появляться зачатки подсистемы работы с ним: https://docs.kernel.org/staging/remoteproc.html

Работа с таким ядром темна и полна ужасов полна неожиданностей и "ОКР" (можно расшифровать как угодно). Слышал даже, что по этой причине некоторые поступающие к нам по параллельному импорту 😏 чипы остаются с отключенным ним, потому что на это просто нет документации, которую вендор передает за деньги и только особо избранным.

По многим китайским системам такая документация не только закрытая, но еще и есть исключительно на китайском.

..

СМОЖЕТ ЛИ НАШ ГЕРОЙ РЕШИТЬ ЭТУ ПРОБЛЕМУ? УЗНАЕМ В СЛЕДУЩИХ СЕРИЯХ

..
1.Сообщения у Kafka не удаляются брокерами по мере их обработки - данные в топиках могут храниться неделями, месяцами, годами.
2. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными потребителями и в разных контекстах
..

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

Причастных — с праздником

Об электропривод

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

Современные гаражные мастера поганых ИЗДЕЛИЙ в качестве него угорают по Ardupilot + PIХHAWK - связка проверенная, отлаженна. Почему он? Потому что имеет простой, деревянный код, ну и в целом адаптирована под самоуправление: например, есть планировщик миссий для автономного полёта. В полете оно напоминает надувной табурет, движется медленно, с грацией, однако задачу решает.

Тем не менее, в мире леталок своеобразным linux-ом остается ненавидимый мною бетафлайт, обладающий, как минимум, двумя родовыми травмами, препятствующими превращению в воздушное такси:
- Переполнение int32 счетчика времени после 2.7тыс секунд полета
- Аварийное отключение, встроенное в контур управления, в случае пропадания связи с пультом более чем на 500мс

Те, у кого было побольше времени (MILBETA), пошли простым путем и попробовали улучшить ситуацию, увеличив в 100 раз время самостоятельного полета, прежде чем автоматика отключит питание с винтов.

Но в целом ситуация решается на 100%, и вот каким образом. Я расскажу без подробностей, чтобы вы не хулиганили, но тот, кто хочет, по этой инструкции сделает, что надо.

Для передачи команд автопилота на борт полетного контроллера можно воспользоваться тем же самым USB-портом полетника, через который Betaflight-configurator позволяет настроить параметры. Те, кто пользовался им, знают, что при подключении через этот порт, полетник переходит в режим принудительного disarm, во избежание нехороших последствий.

Фактически же оказалось, что disarm это всего лишь расширение протокола MSP, которое активирует конфигуратор, и эта опция не обязательная, то есть её можно обойти, так что ИЗДЕЛИЕ прекрасно летает и с подключенным кабелем, весело обмениваясь через него данными. Как передавать команды через этот порт, можно легко найти в интернете - адаптеры для MSP протокола есть для многих языках, в крайнем случае, можно распитонить питоновый yamspy. Контроллер штатно реализует канал управления поверх MSP.

Через этот адаптер ваши PID-регуляторы внешнего цикла из автопилота будут слать и получать пакеты - частота размыкания верхнего контура управления в 20-40 Гц вполне адекватна для рамы, нагруженной 3-7 кг ПИЦЦЫ.

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

Плюс этой схемы ещё и в том, что в случае же отказа автопилота ИЗДЕЛИЕ превращается просто в электронное копьё, которое держит по акселлерометру последний полученный курс, пока его полёт не окончится.

-

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

Об NLP

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

https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/

Надумалось сыграть в Unreal Tournament, тот самый, из 1999 года. Оказалось, что D3D рендерер в Win11 работает отстойно, а софтверный рисует совсем не вдохновляюще, половина эффектов не видны.

Помогло решение, сделанное в свое время на века: эмулятор GLide->OpenGL в Win и движок 3dfx glide в самой игре. Всё летает, и картинка идеально соответствует той, что была тогда.

Умели, могли