На заводах ИИ мы внедрять умеем, а нормального кота сгенерить не смогли. Штош
Комментариев под прошлым постом было много, ответить каждому мы физически не успеем. Но ответить хочется. Поэтому короткий инженерный разбор: с цифрами, фактами и долей самоиронии.
Про “чёрный короб”
Да, идея хорошая и часто действительно спасает. Но у нас было три метра конвейера, по которому летят зеркальные листы со скоростью 2 м/с. А пыль, тепло, вибрации и необходимость обслуживать оптику делают «чёрный ящик» скорее лабораторным решением, чем промышленным.
Про поляризацию и металл
«Поляризаторы на металле не работают!» — писали вы. И вы… почти правы. На идеально зеркальной поверхности эффект действительно слабый. Но на загрязнённых, частично матовых и неидеальных листах он даёт до 15–20 dB подавления бликов. Не магия — просто физика, немного геометрии и много проб и ошибок.
Про “дешёвого человека с глазами”
Мы тоже любим людей с глазами. И даже работаем вместе.
Система не заменяет оператора — она отсекает рутину, где глаз устаёт, а блик обманывает. Раньше контролёр тратил на проверку одного листа около 6–8 секунд и при этом пропускал до 10–12% микродефектов.
Теперь камера справляется за 1.2 секунды, а доля спорных случаев, которые уходят на ручную проверку, не превышает 3–5%. Вместо бесконечного «вглядывания в зеркало» оператор теперь проверяет только то, где нейросеть не уверена — и делает это в разы быстрее.
Так что не «человек против машины», а человек + машина против скуки и брака.
Про “азов фотографии”
Да, теперь мы знаем про них чуть больше, чем хотели 😅 Но инженерка в цехе — это не студия с софтбоксом. Там дрожит пол, летит пыль, мигает строб, а под ногами едет металл. Так что каждый миллиметр света, поляризации и выдержки был добыт потом и кофеином.
Про “всё равно не автономно”
Справедливое замечание. Промышленное CV пока действительно не живёт без инженеров — но и не должно. Как и любая сложная система, оно развивается итерационно: данные → обучение → адаптация → стабильность. Главное, что теперь инженеры на линии решают не “почему камера не видит”, а “как улучшить метрики”.
На сладкое
Теперь точно знаем, что идеальных данных не бывает, что FTP живёт дольше всех, и что на заводе «хорошее освещение» — это инженерное чудо, а не кнопка в настройках.
Спасибо всем, кто спорил, шутил и предлагал решения — ваши комменты были лучшим продолжением истории, чем любой отчёт по внедрению❤️
Больше живых кейсов моя команда разбирает в новом ТГ-канале https://t.me/brains2up Подписывайтесь, если хотите чаще читать про настоящий ИИ.
а я сегодня дымоход проектировал. короче слушай. труба только нержавейка 1 мм. меньше - прогорит и ненадежно. уличная часть только сендвич. из печки выход 100 мм. в магазине в наличии только сендвич 115/190 (не очень стандартный размер). печка высотой 620. выходной патрубок на высоте 730. от него вертикально пойдет 100 мм труба 0.5 метр. сборка (внимание) по конденсату. папа внизу мама сверху. итак. труба 0.5 м - шибер (0.1 м) - труба 1м - отвод 45 градусов - труба 1 м (уходит под углом 45 градусов в стену и выходит на улицу). поскольку труба идет под углом, меняя длину трубы мы сможем подобрать высоту установки монтажной площадки под сендвич и расстояние от стены чтоб не попасть в свес крыши. итого. длина наклонного участка 1 м. и высота дымохода увеличится на косинус (cos) 45 шрадусов. т.е. нп 0.707 м. просуммировав все длины получаем высоту установки монтажной площадки 2.97 метра и расстояние от стены ~ 0.4 м. идем на озон и закупаем соответствующие компоненты. так же удачно получилось, что основной кронштейн для монтажной площадки (на которой будет стоять 3х метровый сендвич) будет крепиться не в обычный газоблок, а в армопояс. итого дымоход будет высотой ~ 6 метров и тяга прогнозируется неплохая. используемые инструменты freecad для эскиза, озон для заказа. докер и питон не понадобились, но под рукой держу на всякий.
Всем привет! Меня зовут Алексей, я руковожу компанией, которая занимается разработкой с применением ИИ-технологий. Сам я тоже погружен в разработку, но больше доверяю это своей команде – нам удалось собрать команду классных профи. Истории из нашей совместной работы я и планирую рассказывать в своем блоге.
Cегодня делюсь историей одного из наших разработчиков – о внедрении компьютерного зрения на реальном производстве.
Первый день на линии выглядел почти комично. Стоим втроём в касках, над конвейером — новая промышленная камера с глобальным затвором (5 Мп, FOV ~0,6 м), а под ней со скоростью 2 м/с уезжают листы с зеркальным блеском. Оператор рядом фыркает:
— «Ну и где твои умные нейросети? Вон же царапина!»
На экране вместо царапины — пересвеченный до насыщения белый блик: без перекрёстной поляризации и со слишком длинной выдержкой он превращается в «идеальный» объект для детектора. Алгоритм радостно машет флажком: «дефект!». Таких ложных срабатываний за смену набегало сотни; настоящие микротрещины и сколы тонули в засветках и смазе.
С этого момента стало ясно: впереди не «проект на пару недель», а марафон, где придётся бороться не только с кодом, но и с реальностью цеха — вибрациями, пылью, бликами и древним MES, говорящим по OPC/Modbus.
Зачем всё это
Один крупный производственный заказчик (линия резки листового материала: зеркальная поверхность, скорость ~2 м/с) решил автоматизировать контроль дефектов.
Раньше инспекция была ручной — оператор просматривал каждый лист.
На старте задача выглядела так:
Ставим камеру над линией: Basler ace2, 5 Мп, глобальный затвор; C‑mount 12 мм; FOV ≈ 600 мм; аппаратный триггер от энкодера; экспозиция 30–50 мкс; импульсный LED 630 нм с перекрёстной поляризацией.
Режем изображение на тайлы: 1024×1024 px с overlap 20%; deskew по кромке листа; маска бликов.
Возвращаем результаты в MES/SCADA: JSON → XML/FTP (атомарный rename) с переходом на OPC UA; координаты дефектов в мм, sheet_id, статус OK/NOK.
Спойлер: из этого получился трёхмесячный марафон — свет, крепёж, синхронизация и интеграции заставили сервера дрожать, а нас — прокачать инженерный дзен.
Сюрприз №1: Светит, но не туда
Проблема: освещение и блики
На раннем этапе мы выяснили, что камера стабильно видит… блики, а не дефекты. Промышленное освещение оказалось агрессивным: холодные направленные прожекторы, паразитные отражения от оборудования и зеркальная поверхность листов. Сенсор клиппился по яркости, и каждый пересвеченный блик принимался за дефект. На старте ловили до 32% ложноположительных срабатываний.
Что сделали
Свет и поляризация: заменили направленные прожекторы на диффузный купольный/низкоугловой свет под ~45°; поставили линейные поляризаторы на источник и анализатор на объектив под 90° (подавление бликов до ~15–20 dB). Перешли на узкополосные LED 625–660 нм.
Экспозиция и синхронизация: включили строб с импульсом 30–50 мкс под триггер энкодера; глобальный затвор, постоянный токовый драйвер без 50/60 Гц мерцания. Отключили автоэкспозицию/автогейн/автобаланс; гамма = 1.0, фиксированный gain.
Экраны и окклюзии: установили матовые чёрные экраны по бортам и над камерой, убрали паразитные отражения от рам и кромок.
Онлайн-мониторинг яркости: ввели контроль доли насыщенных пикселей (P255) и динамического диапазона; кадры с P255 > 0.5% автоматически помечаются и не идут в инференс; гистограммы логируются.
Вывод: оптика и свет — не «поправим в коде». Схему освещения, поляризацию, строб и крепёж нужно закладывать до начала разработки модели — это даёт порядок выигрыша по качеству сразу.
Сюрприз №2: Камера не дружит с резкостью
Проблема: микровибрации и автофокус
Камера стояла над станком, всё казалось стабильным. Но каждые 30–40 секунд появлялась дрожь, тонкие дефекты «смазывались». Причина — микровибрации от привода/роликов (≈25–35 Гц) и отсутствие автофокуса при фиксированном рабочем расстоянии.
Что сделали
Механика/крепёж: вынесли камеру на жёсткий кронштейн с виброизоляторами (fₙ ≈ 9–12 Гц, демпферы Shore A 30–40), отвязали от корпуса станка, добавили массу и развязку кабелей. Резонансные пики выше 60 Гц подавлены, передача вибраций < 0.3.
Фокус: настроили фикс‑фокус на рабочее расстояние по slanted‑edge (MTF50 вырос с ~0.28 до ~0.36 cyc/px), зафиксировали кольцо (lock‑screw) и метки положения; регламент пересмотра при смене температуры/света.
Экспозиция: привязали экспозицию к стробу 30–50 мкс — при 2 м/с смаз ≤ 0.1 мм.
IMU‑контроль: поставили 6DoF‑датчик (1 кГц); логируем события при |ω|RMS > 0.8°/с или Δугла > 0.05° за 200 мс; при срабатывании помечаем кадры и уведомляем оператора.
Онлайн‑метрика резкости: Tenengrad/Laplacian в ROI; кадры ниже τ исключаются из инференса или запрашивается повтор.
Вывод: стабильная механика и фикс‑фокус столь же критичны, как и модель. Развязка вибраций, короткая экспозиция и онлайн‑контроль резкости делают детектор предсказуемым
Сюрприз №3: один тайл — два дефекта и половина чужого листа
Ожидали: лист идёт ровно и по центру. Реальность: заезд под углом, частичное перекрытие соседним листом, дрейф по диагонали. В итоге один тайл нередко содержит две кромки разных листов — модель «плывёт» в предсказаниях.
Что сделали
Маркеры и привязка к движению: наклеили ретрорефлективные метки по краям ленты; считывание в NIR (850 нм) с аппаратным триггером от энкодера (5k PPR). Детектируем leading edge и боковые кромки; дрожание меток < 0.5 мм.
Лидар + фотодатчики: ToF-лидар 1 кГц для контроля lateral offset, три фотошторки по ширине для детекта перекрытия/наличия листа. События уходят в PLC и в CV-пайплайн; допуск смещения ±3 мм, время реакции < 5 мс.
вычисляем гомографию и выполняем deskew; сетка тайлов якорится к кромке, а не к «сырому» кадру;
при перекрытии строим маску «серой зоны» вдоль шва (15–25 px): увеличиваем overlap, нежёстко понижаем вес предсказаний в NMS, логику объединения делаем по sheet_id;
Слежение за листом: sheet_id по импульсам энкодера; пересборка карты дефектов в координатах линии, чтобы MES получал стабильные ROI.
Вывод: физическое позиционирование нужно дублировать алгоритмами CV. У «железа» иногда свои планы, поэтому привязка к энкодеру, маркеры, лидар и дескью — обязательны для стабильного тайлинга и корректной агрегации предсказаний.
Сюрприз №4: Модель любит однотипные дефекты, а у нас каждый раз сюрприз
Проблема: разнообразие артефактов
Обучались на 15 классах дефектов. В проде всплыли неожиданные: пятна клея, отпечатки перчаток, стружка, насекомые, следы чистки и др. За первый месяц зафиксировали 37 новых типов, отсутствовавших в трейне.
Что сделали
Активное выявление «неизвестных» (OOD): отправляем в разметку тайлы при низкой уверенности (conf < τ), высокой энтропии, а также при расхождении ансамбля и классического CV; дополнили energy-score по логитам и расстоянием Махаланобиса в признаковом пространстве.
Еженедельная разметка и инкрементальное обучение: выгружаем 8–12k «неопознанных» тайлов/нед. в LabelStudio (κ ≥ 0.82), дообучаем с rehearsal (30% старых данных), частично замораживаем backbone, применяем дистилляцию знаний и калибровку температурой.
Управление таксономией: «прочее/ nuisance» как буферный класс; промоутим в полноценный класс при ≥200 размеченных примеров и precision ≥ 0.7 на валидации. Зоны с низкой уверенностью помечаем в UI для ручной проверки.
Вывод: CV — это не «обучил и забыл», а непрерывный цикл. Активный OOD-поток, регулярная разметка и инкрементальное обучение с гибридными эвристиками дают управляемость при появлении новых артефактов без деградации по базовым дефектам.
Сюрприз №5: API-интеграция с MES — это уже не про CV, но боль
Проблема: древняя MES-система
Документации нет. REST/GraphQL нет. Только XML-файлы по FTP, которые MES опрашивает раз в несколько секунд. Частые проблемы: частичные чтения, дубликаты, «зависшие» файлы, непредсказуемые задержки.
Что сделали
Прокси-адаптер JSON→XML + надёжная файловая шина
CV выдаёт JSON с sheet_id, ts, speed, списком дефектов (bbox в мм, класс, уверенность).
Адаптер формирует XML по согласованной схеме, пишет атомарно: сначала в outbox/*.xml.part, затем rename в *.xml; после чтения MES кладёт *.ack.
Каталоги: outbox/ → processing/ → done/, ошибки в error/ с ретраем (экспоненциальная задержка, максимум 5 попыток), дедуп по sheet_id.
Кодировка UTF‑8 (без BOM), CRLF по требованию MES. Имя файла: INS_L1_20250912T101532Z_123456.xml.
Мониторинг и SLA для FTP-интеграции
Тайм-аут чтения: если через 30 с нет *.ack — алерт (Prometheus/Alertmanager → Teams/Slack), автоперекладка файла в processing/ не повторяется до разборки инцидента.
Метрики: end-to-end задержка (CV→MES), число «подвисших» файлов, ретраи, доля дубликатов, размер очереди. Трассировка по sheet_id.
Безопасность: при возможности SFTP; иначе FTPS (TLS), учётка с минимальными правами и chroot.
Узлы: ns=2;s=estralin/Sheet/{sheet_id}/Result, .../Defects (массив структур с bbox в мм и классом). Семплирование 100–200 мс, очередь 128, подтверждение обработкой статуса.
Фолбэк: при недоступности OPC UA — автоматический возврат на файловую шину, чтобы не терять данные
Вывод: интеграции — это отдельный проект. Согласуйте протоколы/схемы и SLA с IT-заказчика до старта, закладывайте атомарность, дедуп, мониторинг и фолбэк-канал; при возможности переходите на OPC UA с шифрованием.
Технологии и стек
Камера: Basler ace2 (GigE, mono, global shutter, 5 MP @ 60 fps), C‑mount фикс-объектив 12 мм (F/4), FOV ≈ 600 мм, масштаб ≈ 0.20 мм/пкс. Аппаратный триггер от энкодера 5k PPR, экспозиция 30–50 мкс, строб узкополосного LED 630 нм с перекрёстной поляризацией; гамма 1.0, фиксированный gain.
Модели: YOLOv5m (тайлы 1024×1024, overlap 20%), препроцессинг OpenCV (deskew по Sobel/Hough, CLAHE, маска бликов). Инференс ONNX Runtime CUDA/FP16; p50 7.8 мс/тайл, p95 11.2 мс/тайл (RTX A2000). Итог по листу p95 < 90 мс при 2 м/с. Качество: mAP50 0.96, F1 0.91, FPR 3.1% на холдауте.
Разметка: LabelStudio, экспорт COCO/YOLO; двойная валидация, κ=0.84; гайдлайны по классам/границам; класс «nuisance/прочее» для OOD до промоушена.
Интеграция: Python FastAPI (/infer, /healthz) → JSON; адаптер JSON→XML с атомарным rename и *.ack для legacy-FTP; основная шина — OPC UA (SecurityMode=SignAndEncrypt, Basic256Sha256), узлы ns=2;s=estralin/Sheet/{id}/Defects. Фолбэк на файловый канал.
Мониторинг: Prometheus + Grafana. Метрики: p95/p99 инференса, очередь, GPU util/mem, доля клиппинга (P255), FPR/recall по сменам, OOD rate, задержка CV→MES/OPC. Алерты по таймаутам ACK (>30 с), росту FPR, падению FPS/энкодера.
Деплой: On‑prem, Docker (Compose), NVIDIA Container Toolkit, закрепление версий драйверов/библиотек, healthchecks, автоперезапуск, локальный inference (latency‑critical), офлайн‑буферизация результатов и ретраи.
Финальные цифры
Хотелось показать таблицей, поэтому просто скриншот
Что мы поняли
Оглядываясь назад, понимаем: часть проблем мы могли предсказать. Вот несколько инсайтов, которые пригодятся тем, кто только собирается внедрять CV на производстве.
Не верить в «идеальные данные»
Пыль/блики/вибрации — норма. Введите авто‑контроль качества кадров: P255 ≤ 0.5%, средняя яркость в окне [90;160], резкость (Tenengrad) > τ, доля «горячих» пикселей ≤ 0.05%.
Мониторьте дрейф окружения: деградация света (−5…−8%/мес), смещение экспозиции, рост шума; алерты и напоминания на очистку оптики каждые 8 ч или при падении SNR < 24 dB.
Реплицируйте «грязную реальность» в данных: еженедельно добавляйте 5–10% свежих OOD‑тайлов, аугментации под бликами/смазом/пылью; калибровка порогов раз в смену.
Закладывать бюджет на «внезапности»
Резерв времени: +20–30% к срокам на интеграции/железо; бюджет: +10–15% на запасные части (камеры, БП, драйверы света, кабели).
Операционные SLO: p95 инференса < 100 мс/тайл, p95 CV→MES < 1.2 с, потери данных 0, дедуп по sheet_id, MTTR инцидента интеграции ≤ 15 мин.
Дежурство и плейбуки: on‑call 24/7 для линии, сценарии на «камера/энкодер/свет/OPC/FTP упал», фолбэк на файловую шину, офлайн‑буфер ≥ 24 ч.
Общаться с технарями на месте
Совместно с цехом: выбор света/крепежа/экранирования, допустимые окна простоя, точки триггера от энкодера, маршруты кабелей, HSE‑требования.
Формализовать SAT/UAT: чек‑листы по классам дефектов, выборки на 1–2 смены, критерии приёмки (precision/recall/FPR), график регламентных чисток и перекалибровок.
Напоследок
Компьютерное зрение в промышленности — меньше про «красоту модели» и больше про свет, крепёж, синхронизацию и протоколы. Если идёте в прод, готовьтесь к реальному миру — тому, где рядом со Stack Overflow открыта вкладка «как дернуть автофокус через Modbus» и список запасных кабелей на складе.
Случалось ли у вас такое, что чего-то хочется, но денег нет? Вот и у меня вчера случилось подобное.
Я захотел себе коробку передач для руля Defender, но денег нет, да и не очень то хочется их тратить на КП. Решил я собрать эту коробку передач сам. Пошёл смотреть что у меня есть, а ничего кроме пары Arduino и ESP у меня собственно и нету.
Нужно извращаться по другому. Что любят все DIYщики? Правильно - колхоз. У меня моё извращенство даже даже колхозом назвать сложно, это какой-то уже другой уровень :D
Решил, что буду отслеживать всё через OpenCV вебкой. Звучит странно, да? Но вы ещё не видели самой конструкции.
А вы что ожидали?)
Извините все, кого я сейчас довёл до слёз. Остальные, кто ещё в состоянии воспринимать этот бред, могли уже заметить, что на "рычаге" КП есть красный круг. Его то я камерой и отслеживаю.
К сожалению тут не полный колхоз, т.к. веб камера есть не у всех, но и тут есть решение. Скачайте любое приложение из интернета чтобы камеру телефона как веб-камеру использовать, таких там навалом.
Дальше, ставим камеру прямо над КП. Если она будет чуть под углом, ничего страшного, главное чтоб видела рычаг в любом положении. Можно повесить на монитор, или на полку над монитором, как это сделал я.
Теперь самое сложное позади. Берём код с моего Github. Там где-то будет gear_detector.py. Ну и ставим все нужные библиотеки, они в requirements.txt. Потом запускаем код, проходим калибровку передач и радуемся! Код будет зажимать кнопку на виртуальном контроллере в зависимости от передачи.
Как оно выглядит
Вот так выглядит сама программа, процессор сильно не кушает(около 5%), Яндекс браузеры не устанавливает. Если коробку сильно не двигать, то работает вполне чётко.
Если вы тоже по каким-то причинам надумаете собирать ТАКОЕ, то всегда буду рад помочь в комментариях.
Добро пожаловать в этот увлекательный урок, в котором мы научимся создавать мультипликационный фильтр для изображений с помощью OpenCV и JavaScript. К концу этого урока вы сможете создать свой собственный мультипликационный фильтр и применить его к любому изображению, которое вам нравится. Мы углубимся в код, объясним каждый шаг и предоставим файлы с готовым кодом для тех, кто изучает визуальные эффекты.
Вещи, которые вы узнаете:
Настройка структуры папок проекта
Создание HTML-файла для ввода и вывода изображений
Стилизация HTML с помощью CSS для визуально привлекательного интерфейса
Реализация фильтра мультфильмов с использованием OpenCV и JavaScript
Отображение отфильтрованного изображения и предоставление пользователям возможности его загрузить
Структура папок проекта:
Для начала создайте новую папку проекта и создайте пустые файлы:
index.html
style.css
script.js
opencv.js
Либо скачайте мой архив с готовыми файлами по ссылке, копируем их на ваш сервер или хостинг, подключаем css и js в файле index.html и запускаем свой сайт по пути хттпс://вашсайт.ру/index.html
Видеоурок
Поздравляем! Вы успешно создали мультипликационный фильтр для изображений с помощью OpenCV и JavaScript. Следуя этому уроку, вы научились применять методы обработки изображений для создания художественных эффектов на изображениях. Теперь вы можете использовать эти знания для изучения других фильтров и эффектов обработки изображений и даже интегрировать их в свои собственные проекты.
Спасибо за лайки, комментарии, подписку и просмотр <3
Камеры видеонаблюдения стали для многих стран обыденностью, например в Китае, они могут свисать гроздьями, через каждые 5 метров, по улице. Но в провинции России это все еще может быть в новинку. Я отношусь к видеонаблюдению по большей мере положительно. Ведь вид камеры, даже превентивно может предотвратить хулиганство (однажды я использовал муляжи камер в офисе:)), а главное это возможность контролировать объект наблюдения.
Этот пост про монтаж уличной камеры, на стену многоквартирного дома и программную реализацию - вывод изображения, без использования стандартной программы, оптимизацию, для размещения на raspberry pi.
Монтаж
Коробка
Внутри помещения, я уже успешно использовал камеры фирмы vstarcam, по этому, лояльное отношение, подтолкнуло сделать заказ на али vstarcam CS64. Забегая вперед скажу, что это не лучший выбор - мыльная картинка, как будто нет даже заявленных 3 МегаПикселей. План таков: повесить на внешнюю стену электрическую распределительную коробку, внутрь нее поместить блок питания, на крышку прикрепить камеру. Сигнал передается по wi-fi, питание - провести кабель через раму окна.
Примерный бюджет: ip-камера 3500р., коробка 600р., винтики-гаечки (продаются в леруа на развес) 5р., кабель/вилка/клеммы 200р.
Порядок работ:
Блок питания закинут в коробку(не стал его там крепить), отрезан кабель питания. На клеммы прикрутил новый кусок кабеля(брал его с запасом, но в итоге понадобилась только половина), кабель вывел из коробки;
В крышке коробки(она съемная), просверлил 4 отверстия и закрепил на ней камеру болтами с гайками;
Вылез из окна во внешний мир и под окном просверлил отверстия в стене, вбил дюпеля. Прикрутил открытую коробку, из которой, пока что, болтается моток кабеля.
Взял крышку с камерой, продел и подключил внутрь коробки кабеля(питание и не нужный lan), закрыл крышку, таким образом смонтировав камеру.
Просверлил в пластиковой раме окна отверстие наружу и всунул в него кабель питания, положил кабель канал, обрезал кабель до нужной длины и прикрутил вилку. Получилось довольно сурово, но это и к лучшему :)
Улица
Мотивом для дальнейшей части повествование было желание поделится с соседями видом со стены, ну и желание разобраться как захватывать видеопоток. Не было желания объяснять старшему поколению, как работает стандартное приложение eye4, по этому я решил реализовать веб страничку. Деплой будет на, уже обитавшую для домашних проектов, raspberry pi 4 4Gb.
В спецификации камеры было указано что она умеет в rtsp, его и выбрал. ip адрес камеры было просто вычислить в настройках маршрутизатора и задать его статичным. Предварительно надо было получить ссылку на видеопоток - а его нет! Я аж вспомнил nmap, а то мало ли с портом промахнулся. В документации нет ни слова, оказывается, в отличии от предыдущих моделей, в программе eye4, зайдя в настройки камеры надо включить опцию "незащищенный пароль". И как то напахнуло старыми китайскими девайсами, с непонятными настройками.
eye4
Итоговая ссылка rtsp://admin:password@192.168.0.119:10554/tcp/av0_0 Можно проверить ее подключившись например vlc Пароль задавался в фирменной утилите.
Код
Программная часть будет использовать python (не судите строго, только год приручаю питона:)). Веб фреймворк Flask был выбран из-за простоты (для одностраничника больше и не надо); Для оптимизации, захват и генерацию кадров было решено разделить на разные процессы, с помощью multiprocessing (в надежде, что это поможет хилому rpi); Для захвата кадров видеопотока и их кодирования, оказалось лучшим вариантом будет использование библиотеки OpenCV.
Шаблон, состоит из нескольких тегов хтмл и думаю в объяснении не нуждается, по скрипту пройдемся более детально.
Здесь фласк приложение, при открытие страницы клиентом, обращается к генератору кадров, который выбирает изображение, постоянно создаваемое в отдельном процессе, захватывая видеопоток камеры.
Кеширование реализовано с помощью глобальной переменной last_frame, которая для обмена между процессами представляет из себя manager(данные внутри обернуты в list, так как это условие его использования). Это позволяет не генерировать для каждого нового клиента уникальные данные, они смотрят одни и те же картинки, не увеличивая нагрузку.
Сначала запускается процесс p, это позволит параллельно создавать кадры, не нагружая основной процесс.
Далее запускается фласк приложение app.run. Блок try, я добавил для того что бы нормально обработать ctrl-c в терминале. По его завершению, происходят методы завершения созданного процесса.
Функция создания кадра cache_frames. Именно в ней происходит основная нагрузка, которую надо оптимизировать, для маломощного одноплатника. Будем резать качество! Если у Вас будет довольно мощный сервер, вероятно не стоит повторять все советы(оставив хотя бы нормальное разрешение). Для начала я пробовал снижать частоту кадров, это приводило к появлению старых кадров и очевидному замедлению воспроизведения. Обнулить буфер камеры в VideoCapture можно только вытащив из него все кадры. Запускать cap.grab() в цикле это действенный механизм, но это приводит к недопустимой для меня нагрузке. В моей камере есть второй поток с более низким разрешением, это позволило снизить разрешение без cv2.resize, что существенно уменьшило нагрузку, позволив оставить штатную частоту кадров камеры. Все эти моменты могут различаться в разных моделях камер. Давайте пройдемся по строкам главной функции. Сначала мы открываем видеопоток(cap) и узнаем какой у него fps. Далее идет цикл в котором мы читаем кадр(cap.read). Закомментирована строка с изменением размера, так как удалось это сделать на стороне камеры. Далее происходит кодирование в jpeg, с уменьшением качества(imencode). По итогу мы преобразуем массив в необработанную строку байтов, так как именно такой результирующий вид требуется, и размещаем в наш кеш last_frame. Цикл каждый раз засыпает, что бы снизить нагрузку, интервал чуть выше фпс, что бы вычитывать все кадры из буфера камеры. По выходу из цикла ресурсы видеопотока будут освобождены(release).
Функция generate, при подключении клиента, генерирует хттп mjpeg ответ изображения с кадрами из кеша, который будет отображаться в браузере.
Вы можете заметить, что здесь нет работы над стабильностью. Например если соединение с камерой пропадет на время, скрипт просто сломается и такие ситуации надо обрабатывать.
Так же стоит провести работу по адаптации для нормального wsgi сервера. Это сделано, что бы не раздувать текущий текст и на своем гитхабе я постараюсь выложить доработанную версию.
Перекинув файлы на распберри пай и запустив их, нагрузка составила:
Я посчитал, что чуть более 20% использования cpu(BCM2711), хороший результат, не стеснит остальные проекты.
Осталось только пробросить порт на маршрутизаторе и можно делиться видео наблюдениями. Соседи рады, я рад :-)
Этот текст я написал, так как увидел скудность ру доков по rtsp+python. Возможно кого то это мотивирует на эксперименты с наблюдением и обработкой видеозахвата:) Всем удачи!
Уважаемые коллеги по цеху, представляю вашему вниманию один из моих DIY проектов: простой робот с видео камерой, управляемый с персонального компьютера (или ноутбука) с любой точки мира с помощью программного обеспечения собственной разработки Arduino Robot Control (ARC). Программа отлично подойдет для робофестов и соревнований по робототехнике.
Его величество робот
DIY робот
Интерфейс программы управления ARC
Робот собран на основе одного из самых дешевых DIY конструкторов, который я нашел на алиэкспресс, в основе управления Arduino совместимая плата Wemos D1 на базе ESP8266., шасси, два самых обычных 5 вольтовых DC мотора, датчик расстояния HC-SR04, ну и собственно набор проводов... в общем, руль сиденья и колеса присутствуют... все в лучших традициях. Робот управляется с персонального компьютера или ноутбука на базе операционной системы Windows c помощью кнопок клавиатуры через программу ARC по средствам WiFi соединения. Видео с робота на компьютер также передается по Wi-Fi. Для того, чтобы повторить мой проект вам ничего не нужно программировать, необходимо просто собрать конструктор, подключить все провода и произвести пару интуитивно понятных настроек в интерфейсе программы ARC - весь процесс показан в полной видео инструкции.
Базовые функциональные возможности робота:
Управление роботом по Wi-Fi c персонального компьютера или ноутбука;
Автоматический объезд препятствий;
Переключение скоростей (три режима);
Передача видеопотока с камеры робота в интерфейс программы;
Распознавание лиц человека с помощью компьютерного зрения.
Идея программы состоит в том, чтобы превратить ваш персональный компьютер или ноутбук, работающий на основе операционной системы Windows 7/10/11 в универсальный пульт управления DIY роботами на базе контроллеров семейства Arduino., функциональные возможности позволяют использовать программу для участия в робофестах и соревнованиях. ARC позволяет создать ваш робопроект не написав ни единой строчки arduino кода и по большому счету пользователю необходимо всего лишь правильно собрать робота из конструктора, подключить провода согласно схеме проекта и произвести базовые настройки с помощью конфигуратора встроенного в программу., для загрузки программы управления на вашего робота даже не потребуется установка Arduino IDE и танцы с кодом., весь процесс максимально автоматизирован...
Базовые функциональные возможности программы ARC:
Распознавание лиц с помощью компьютерного зрения с голосовой озвучкой OpenCV;
Поддержка интерфейсов управления роботом: WiFi в режиме AP, WiFi в режиме STA, MQTT, радиоканал nRF24L01;
Поддержка одновременного подключения и передачи видео в интерфейс программы (до 3-х камер одновременно). Можно использовать любые Wi-Fi камеры с поддержкой RTSP или HTTP потоков, также поддерживаются FPV камеры;
Встроенный конфигуратор проектов и компилятор кода arduino;
Встроенный готовые шаблоны проектов DIY (на текущий момент добавлено 3 готовых шаблона);
Распознавание QR кодов с помощью компьютерного зрения OpenCV;
Езда по линии с помощью компьютерного зрения OpenCV;
Встроенный конфигуратор и монитор радиоканалов nRF24L01;
Логирование процесса управления роботом;
Видеозапись всего процесса управления роботом из интерфейса программы;
Передача данных с датчиков установленных на роботе на онлайн треды в интерфейс программы (до 20-ти сигналов ввода/вывода);
Анимация управления роботом и скорости на базе 3d модели (возможен вывод положения на 3d модель по осям X,Y,Z c гироскопа робота).
TODO лист программы ARC:
Добавления универсального шаблона который позволит управлять любыми DIY роботами на базе Arduino и гибко настраивать привязку команд с клавиатуры компьютера для реализации ваших собственных Arduino проектов без привязки к конкретному шаблону, то есть код программы уже придется писать самостоятельно;
Добавление прочего функционала по запросу пользователей...
По любым вопросам работы программы со мной можно связаться по почте: aabilityuk@mail.ru
Примечания
*Для возможности управления роботом не из домашней сети WiFi, а через интернет с любой точки, необходимо использовать/подключить статический IP адрес на роутере либо сконфигурировать DDNS сервис, а также настроить проброску портов (Port Forwarding) на роутере.
Слова благодарности
Хочу поблагодарить моего товарища программиста из Москвы Алексея за помощь в создании программы Arduino Robot Control на всех этапах: графика, система регистрации, настройка и установка библиотек и многое другое!!!
Заключение
Это мой первый пост на Pikabu, постарался изложить все кратко и без воды, основные детали проекта показал на видео, надеюсь что материал будет полезен. Если идея найдет отражение, в последующих постах планирую выложить видео и описание других готовых робопроектов. Благодарю за внимание, готов ответить на ваши вопросы.
