Базовых классов
Целевые акустические события и фон
ИНДОР / АКУСТИЧЕСКИЙ ИНТЕЛЛЕКТ
Научили устройство
понимать звуки
Лай, разбитое стекло или шумная компания. Разработали модель и встроенное ПО, которые превращают звук в понятное событие прямо на устройстве.
Machine Learning Встроенное ПО Локальная обработка2026
Концептуальная иллюстрация обработки звука
01 / КОНТЕКСТ
Знать, что происходит.
Понимать, на что реагировать.
«Индор» создаёт систему мониторинга эксплуатации недвижимости. Владельцу или управляющему важно понимать, что происходит в помещении: например, шумит компания, лает собака или разбилось стекло.
Обычный порог громкости не объясняет причину шума. Телевизор, разговор и плач могут давать похожий уровень сигнала. Задача нашего проекта: добавить устройству распознавание звуковых событий и связать модель с логикой прошивки.
При этом анализ должен происходить на самом устройстве. Отправлять непрерывный аудиопоток на внешний сервер для классификации не предполагалось. Значит, модель нужно было не только обучить, но и подготовить к жизни в ограниченной памяти микроконтроллера.
Для VIQQ это проект на стыке машинного обучения, обработки сигналов и разработки встроенного ПО. Результат здесь проверяется не красивым графиком на ноутбуке, а поведением реального устройства.
ПРОЕКТ В ЦИФРАХ
От акустики
к логике события
Числа описывают устройство решения: какие звуки различает модель и как её ответ превращается в событие.
Служебных класса
Речь, медиа и сирены для отделения контекста
Уровня решения
Классификация и подтверждение события
Компактная модель
Квантованное представление для устройства
Визуализация платформы с сайта Индор
НАША ЧАСТЬ ПРОДУКТА
Интеллект внутри
физического устройства
Мы работали над акустическим модулем: моделью классификации, её запуском на микроконтроллере и программной обработкой событий.
Корпус, другие датчики и приложение составляют более широкую платформу заказчика. Этот кейс посвящён именно ML и встроенному ПО.
ESP32-S3целевая платформа
MEMS / I2Sцифровой микрофон
INT8квантованная модель
MQTTпередача событий
ОТ ПОТРЕБНОСТИ К АЛГОРИТМУ
Услышать громкость.
Или понять причину?
За одним показанием уровня шума могут стоять совершенно разные ситуации. Устройству нужен контекст, а человеку на другой стороне системы нужно осмысленное уведомление.
Лает собака
Важно отличить характерный звук от голоса, фоновой записи и других коротких сигналов. Один пик громкости этого не объясняет.
Разбилось стекло
Короткое событие требует другого подхода, чем длительный шум. Случайный импульс или искажённый сигнал не должны автоматически считаться подтверждением.
Шумит компания
Здесь важна последовательность окон и длительность ситуации. Решение нельзя строить на одном неуверенном предположении модели.
КЛЮЧЕВАЯ ИДЕЯ
Распознавание звука
начинается с того,
как его представить
Для человека звук существует во времени. Для модели мы превращаем его в набор признаков: выделяем окна и описываем распределение энергии по частотным полосам. Так у похожих на слух сигналов появляется структура, которую можно изучать и сравнивать.
02 / ИНЖЕНЕРНАЯ ЗАДАЧА
Модель должна работать
не только на компьютере
Уложиться в ресурсы
У микроконтроллера ограничены память и вычислительная мощность. Обученную сеть нужно адаптировать к устройству и оставить ресурсы для остальных задач прошивки.
Отделить событие от фона
Речь, музыка и похожие акустические паттерны мешают классификации. Важно проверять не только отдельное окно звука, но и последовательность результатов.
Передать управляемую систему
Команде заказчика нужны исходники, сборка и материалы по обучению, чтобы поддерживать решение и развивать его под собственные данные.
03 / КАК ЭТО РАБОТАЕТ
От звука в комнате
до события в системе
Сначала нужно услышать звук
MEMS-микрофон передаёт цифровой аудиосигнал по I2S. На этом этапе важны входной уровень и отсутствие перегрузки: искажённый звук меняет признаки, которые получит модель.
Из звука получается рисунок признаков
Сигнал разбивается на окна, нормализуется и представляется через спектральные признаки. Так модель получает структуру, которую можно сравнивать с обучающими примерами.
Компактная сеть оценивает класс
Квантованная модель работает на микроконтроллере через TensorFlow Lite Micro. Её ответ относится к текущему окну и остаётся промежуточной оценкой, а не готовой тревогой.
Решение принимает вся цепочка
Пороги и временные фильтры проверяют последовательность результатов. Только подтверждённое событие передаётся дальше через MQTT, отдельно от диагностических предположений модели.
Выберите этап, чтобы посмотреть его роль. Изображение иллюстрирует принцип, а не внешний вид оборудования.
Классификация одного кадра ещё не тревога.
В диагностическом логе могут появляться разные предположения модели. Событие формируется отдельным слоем логики, после проверки последовательности окон и условий срабатывания.
Схема упрощена для описания проекта. Классификация выполняется локально; для интеграции передаётся информация о событии.
ДАННЫЕ И ОБУЧЕНИЕ
Научить узнавать событие.
И не путать его с остальным.
Работу с моделью начали с целевых классов и подготовки аудиоматериалов. Для акустической классификации важны не только записи нужного звука, но и примеры того, что на него похоже. Иначе модели приходится выбирать целевой класс даже для сигнала, который к нему не относится.
В ходе проекта исходную классификацию расширили. К базовым классам добавились служебные категории для речи, медиа и сирен. Их задача в этой архитектуре: дать модели возможность отделять часть постороннего акустического контекста от событий, которые интересуют систему.
Затем модель адаптировали для запуска на устройстве. Квантование INT8 и TensorFlow Lite Micro позволили работать с компактным представлением сети, а настройки обработки входного сигнала пришлось согласовать с тем, как звук был представлен при обучении.
АудиопримерыЦелевые звуки и фон
ПризнакиСпектральное представление
Компактная модельЗапуск на микроконтроллере
ПроверкаДанные, сборка и устройство
04 / ВНУТРИ МОДЕЛИ
Разные звуки.
Разные спектральные рисунки.
Реальные графики из материалов проекта показывают представление аудио для шести базовых классов. Это примеры входных признаков, а не отчёт о точности распознавания.
Лай собаки
Разбитое стекло
Выберите два класса и сравните реальные примеры. Графики открываются в исходном размере.
Горизонталь: шаги времени. Вертикаль: индекс мел-фильтра. Цвет: квантованный уровень INT8. Графики можно открыть в исходном размере.
05 / РАБОТА С ОГРАНИЧЕНИЯМИ
Нейросеть плюс
инженерия сигнала
Качество устройства зависит от всей цепочки: от микрофона до опубликованного события. Поэтому итерации затрагивали и модель, и прошивку.
Адаптация модели под ESP32-S3
Использовали TensorFlow Lite Micro и квантование INT8. Согласовывали размер сети, нагрузку на устройство и качество классификации.
Работа с похожими звуками
Расширили классификацию служебными классами речи, медиа и сирен. Это позволяет отличать часть фоновых и похожих сигналов от целевых событий.
Калибровка и фильтрация
Дорабатывали нормализацию входа, сглаживание уровня звука, пороги и временное подтверждение. Калибровку измерительного тракта отделили от оценки класса моделью.
Проверка на оборудовании
Разбирали логи, обратную связь инженеров и поведение сборок на микрофоне INMP441. Проверяли сетевую логику, задачи прошивки и воспроизведение обучения на стороне заказчика.
06 / РЕЗУЛЬТАТ
От модели к передаваемому
программному решению
Разработали ML-модель и прошивку для локального распознавания акустических событий. Проект передан заказчику с исходниками и техническими материалами.
Модель на устройстве
Классификация на ESP32-S3 с учётом ресурсов микроконтроллера.
События для интеграции
Отдельная логика подтверждения и передачи событий через MQTT.
Основа для развития
Материалы по сборке, тестированию и обучению для команды заказчика.
Качество распознавания зависит от акустики помещения, микрофона и данных обучения. Добавление новых условий и снижение ошибок требуют проверки на соответствующих записях и, при необходимости, дообучения.
КАК МЫ ПРИШЛИ К РЕЗУЛЬТАТУ
Не одна сборка.
Цикл инженерных итераций.
Встроенный ML невозможно закончить только обучением сети. Данные, микрофон, прошивка и проверка на стороне заказчика должны сойтись в одну воспроизводимую цепочку.
- 01
Определили задачу и платформу
Разобрали нужные звуковые события, ограничения локального анализа и целевое оборудование. Подготовили основу для модели, которая должна работать внутри устройства.
- 02
Подготовили модель и встроили её в ПО
Прошли от аудиоданных и обучения до квантованной модели и её запуска на микроконтроллере. Отдельно связали классификацию с обработкой сигнала.
- 03
Разбирали поведение в реальных тестах
Получали логи и замечания инженеров, корректировали пороги, фильтры и служебные классы. Проверяли не только вывод модели, но и то, какое событие в итоге формирует устройство.
- 04
Доработали передачу и воспроизведение
У команды заказчика должна быть возможность собрать решение и работать с моделью самостоятельно. Поэтому завершение проекта включало инструкции, материалы обучения и обратную связь по воспроизведению.
ЧТО ОКАЗАЛОСЬ ВАЖНО НА ПРАКТИКЕ
Четыре детали,
которые меняют
поведение устройства
За внешне простым уведомлением скрывается несколько разных инженерных задач. Каждую пришлось проверять отдельно.
Микрофон может изменить знакомый звук
При перегрузке входного тракта сигнал искажается. На спектральном представлении появляются дополнительные компоненты, и модель получает уже не тот звук, на котором её обучали. Поэтому работа с входным уровнем и нормализацией была частью решения, а не настройкой «на потом».
Фон не должен скрывать длительное событие
Если порог привязан к растущему фону, продолжительный звук способен сам поднять планку срабатывания. В проекте разбирали эту связь и корректировали логику порогов для длительных событий, чтобы измерительная часть не противоречила логике распознавания.
Калибровка и уверенность модели отвечают за разное
Поправка уровня звукового давления относится к измерениям. Оценка класса относится к модели. Эти величины встречаются в общей логике принятия решения, но нельзя считать, что изменение одной автоматически делает другую точнее. Для диагностики важно видеть оба слоя.
Прошивка должна успевать делать и другую работу
Помимо классификации, устройству нужны сеть, настройки, индикация и обработка команд. В итерациях разбирали последовательность подключения MQTT и Wi-Fi, распределение памяти задач и контроль состояния стеков. Это такая же часть встроенного ML, как сама нейросеть.
ПЕРЕДАЧА ПРОЕКТА
Заказчик получает
не только бинарный файл
Для технологического продукта важна самостоятельность команды. Передача решения включала материалы, с которыми можно продолжать разработку, проверять сборки и возвращаться к обучению модели.
.tfliteМодель
для устройстваЛокальное распознавание
для устройстваЛокальное распознавание
01 / РАСПОЗНАВАНИЕ
От обучения к встроенной модели
Подготовленное представление сети для интеграции в прошивку и локальной классификации аудио. Размер и формат модели согласованы с ограничениями микроконтроллера.
- Квантованное представление INT8
- Интеграция через TensorFlow Lite Micro
- Оценка класса для входного окна
Часть переданного программного решения
</>Исходный код
прошивкиСигнал, логика, интеграция
прошивкиСигнал, логика, интеграция
02 / ИСХОДНИКИ
Код всей рабочей цепочки
Встроенное ПО связывает модель с микрофоном и логикой устройства. Команда может разбирать не только итоговое событие, но и поведение отдельных этапов.
- Обработка входного аудиосигнала
- Логика подтверждения событий
- Интеграция с сетью и MQTT
Для продолжения разработки на стороне заказчика
MLМатериалы
обученияРабота с моделью
обученияРабота с моделью
03 / РАЗВИТИЕ
Возможность возвращаться к обучению
Передача включала компоненты и инструкции по работе с моделью. Самостоятельное переобучение стало отдельным критерием проверки со стороны команды клиента.
- Материалы обучающей цепочки
- Параметры и пояснения к конфигурации
- Инструкции для воспроизведения
Новые условия требуют проверки на соответствующих данных
READMEТехническая
документацияСборка и проверка
документацияСборка и проверка
04 / ПЕРЕДАЧА ЗНАНИЙ
Понимать, как проверить результат
Пояснения помогают команде собрать проект, настроить измерительный тракт и правильно читать результаты тестирования.
- Сборка и калибровка
- Диагностика и работа с логами
- Различие предположений модели и EVENT
Содержание материалов показано без публикации закрытых исходников
ОБРАТНАЯ СВЯЗЬ
Что было важно
команде клиента
В конце работы фокус сместился с очередного билда на передачу знаний: сможет ли команда самостоятельно воспроизвести и переобучить модель. Это требование определяло, что должно войти в комплект передачи.
Нам сейчас важно удостовериться, что мы сможем переобучать модель самостоятельно.
Команда «Индор»Из рабочей переписки о передаче проекта, 20 октября 2026
ЧТО ПОКАЗЫВАЕТ ЭТОТ КЕЙС
ML становится продуктом,
когда соединяется с инженерией
Модель должна узнавать нужные звуки, прошивка должна правильно обращаться с сигналом, а команда должна понимать, как проверить и развить результат. В «Индор» мы работали со всей этой цепочкой.
ЕСТЬ ПОХОЖАЯ ЗАДАЧА?
Давайте разберём,
что должно понимать
ваше устройство
Расскажите, какой сигнал нужно обрабатывать, какое оборудование уже есть и в каких условиях оно будет работать. Если пока нет датасета или точного технического задания, начнём с задачи и доступных материалов.
Определим, что можно выполнять локально, какие данные понадобятся для обучения и как проверять результат на вашей стороне.
[01]
Портфолио
Другие проекты VIQQ
Наши проекты - это практическое подтверждение опыта. Здесь представлены кейсы, в которых мы решали задачи клиентов через цифровые инструменты: от сайтов и приложений до комплексных систем.
Интернет магазин
Разработка интернет-магазина. Уникальный дизайн, брендбук, личный кабинет, API, интеграции
Регата
Разработка корпоративного сайта инжиниринговой компании
Энова
Разработка мобильных приложений для клиентов и сотрудников, для нефтетрейдинговой компании
XTAXI
Цифровая экосистема службы такси. ERP и мобильные приложения для сервиса
Ais Elvise
Нейминг и интернет-магазин подарков: WooCommerce, ПВЗ и склады в трёх городах
Тут должен быть
ваш проект
ОТ ИДЕИ К РАБОТАЮЩЕМУ РЕШЕНИЮ
Обсудим следующий шаг
Пришлите описание задачи или расскажите, на каком этапе остановились. Поможем определить состав разработки и точку, с которой стоит начать.
Связаться с VIQQ
ВЗГЛЯД КОМАНДЫ
Комментарий
менеджера проекта
Главное в проверке: различать предположение модели и фактическое срабатывание устройства. На это Артур обращал внимание команды заказчика в ходе тестирования.
Из рабочей переписки по тестированию, 2 октября 2026