Диагностика гула в колесе смартфоном: порядковый анализ вибрации Audi Q7 с помощью ИИ Claude
Метод универсален и работает на любом современном автомобиле — BMW X5, Mercedes GLE, Range Rover, Tesla Model Y, Volvo XC90, Porsche Cayenne, VW Touareg, Ford Ranger, Toyota Land Cruiser. Марка значения не имеет: физика вращения колеса одинакова для всех.
Проблема, которую не видит бортовая электроника
Современный премиум-автомобиль напичкан датчиками. Audi Q7 4M считывает скорость каждого колеса 48 раз за оборот, знает продольное и поперечное ускорение кузова, высоту подвески в четырёх точках, положение каждого клапана пневмосистемы. Диагностический сканер выдаст сотни параметров в реальном времени.
И при этом бортовая система принципиально не способна ответить на вопрос «почему на 55 км/ч появился гул».
Причина в архитектуре. Датчики детонации на блоке двигателя — это широкополосные пьезоакселерометры с полосой 1–20 кГц, ровно то, что нужно для виброанализа. Но ЭБУ обрабатывает их сигнал внутри, в узком окне около верхней мёртвой точки каждого цилиндра, и наружу отдаёт только результат: угол коррекции опережения зажигания. Сырого потока нет ни в одном протоколе.
Датчики ускорения кузова доступны как значения, но читаются через UDS запрос-ответ со скоростью 5–20 значений в секунду на все параметры сразу. По теореме Котельникова это потолок 2–10 Гц. Дефект колеса на 50 км/ч сидит в районе 6–25 Гц. Спектр построить физически невозможно — не хватает частоты дискретизации на порядок.
Вывод, который важно принять сразу: штатная электроника автомобиля спроектирована для управления, а не для виброанализа. Это ограничение не конкретного сканера, а самой архитектуры автомобильных шин данных. Механические дефекты качения бортовая система не видит и увидеть не может.
Здесь и появляется место для внешнего измерения и ИИ-обработки.
Почему я вообще за это взялся
Я работаю инженером в компании Mind4Ship, которая занимается предиктивной диагностикой судового оборудования. Мы вешаем промышленные датчики шума и вибрации на подшипники, редукторы и валы, снимаем спектры, прогоняем через алгоритмы и предупреждаем поломку до того, как она случится. Дефект подшипника видно за недели до отказа — по характерным ударным импульсам в спектре огибающей.
Когда в собственном Audi Q7 3.0 TDI на пневмоподвеске появился гул в районе правого заднего колеса, реакция была профессиональной: это ровно та задача, которую я решаю на работе, только объект другой.
Но мне стало интересно другое. Можно ли сделать то же самое бытовыми средствами? Без промышленных акселерометров за €600 штука, без анализатора, без выездной бригады. Смартфон, школьная физика и современный ИИ — хватит ли этого, чтобы поставить диагноз до визита в сервис?
Дальше — как это получилось.
Первый тупик: приложения, которые «диагностируют сами»
На YouTube полно роликов про NVH-приложения. Ставишь на телефон, едешь, приложение говорит «у вас дисбаланс переднего левого». Красиво.
Изучил самое популярное — NVH от Vibrate Software, $99.99. У него база из 276 источников вибраций, готовые вердикты «причина — следствие — решение». Версия для iOS обновляется, есть базы моделей до 2026 года, поддержка 303 электромобилей.
И тут первое важное решение, которое определило весь дальнейший метод.
Такое приложение продаёт не измерение, а справочник. Оно берёт спектр, находит доминирующий порядок, ищет его в базе и выдаёт список из десятков возможных причин. Оно не покажет, из какого угла машины идёт вибрация. Оно не даст сырых данных. Оно не позволит проверить собственную гипотезу.
Как специалист по ИИ я понимал: мне нужен сырой поток с акселерометра. Имея его, я обработаю данные любым алгоритмом и получу ответ точнее, чем любая готовая база. Не имея — я заложник чужих порогов и чужой логики.
Поэтому вместо справочника за $99 я взял инструмент за €12.
Выбор инструмента: приложение, которое просто пишет данные
Остановился на CarNVH (Android, com.motordoktor.carnvh). Логика выбора чисто техническая:
| CarNVH Pro €12 | NVH Vibrate $99 | |
|---|---|---|
| Экспорт сырых данных | есть | нет |
| Спектр огибающей | есть | нет |
| Spectral kurtosis | есть | нет |
| Микрофон до 10 кГц | есть | нет |
| Ось в порядках оборота | есть | нет |
| Спектрограмма 2D | есть | нет |
| База «276 причин» | нет | есть |
Восьмикратная разница в цене — и по измерительным возможностям дешёвый инструмент объективно богаче. Envelope-анализ и kurtosis, которыми ловят подшипник, у дорогого приложения отсутствуют вообще.
Проверка железа — этап, который все пропускают
Покупать телефон под задачу я не стал. Дома без дела лежал Samsung Galaxy A51 — остался как запасной аппарат после смены основного. Идеальный кандидат: выделенное устройство, которое не жалко приклеить скотчем к полу багажника.
Но прежде чем платить за приложение, нужно было убедиться, что железо вообще годится.
Задача: узнать реальную частоту дискретизации акселерометра. Спецификации тут врут — производители на средних моделях часто режут частоту в системном слое, хотя сам чип умеет тысячи герц. Плюс начиная с Android 12 система по умолчанию ограничивает датчики планкой 200 Гц.
Инструмент: бесплатное приложение phyphox, эксперимент «Спектр ускорения». Оно прямо показывает частоту сбора данных, считать ничего не надо.
Результат на A51: 506 Гц, частота Найквиста 253 Гц.
Проверим, хватает ли этого. Для Q7 на 255/55 R19 при 55 км/ч колесо делает 6.65 оборота в секунду:
| Источник | Частота |
|---|---|
| 1× колеса | 6.6 Гц |
| 3-й порядок колеса | 20 Гц |
| Подшипник, наружное кольцо | 23–30 Гц |
| Кардан | 40–60 Гц |
| Двигатель 2× при 2500 об/мин | 83 Гц |
Всё нужное лежит ниже 100 Гц. По Найквисту требуется 200 Гц, есть 506 — запас в пять раз. Телефон годится, покупать ничего не нужно.
Вывод для повторяющих метод: сначала померяйте phyphox, потом платите за софт. Пять минут проверки решают, будет ли у вас измерение или мусор.
Настройка, которая решает всё
В CarNVH есть галочка «Request High Sampling Rate». Она запрашивает системное разрешение HIGH_SAMPLING_RATE_SENSORS. Без неё Android режет поток до 200 Гц независимо от возможностей железа.
Остальные критичные настройки:
- Окружность колеса. Для 255/55 R19: диаметр = 19 × 25.4 + 2 × (255 × 0.55) = 763.6 мм, окружность геометрическая 2399 мм, рабочая с учётом проседания под нагрузкой ≈ 2300 мм
- Порядки колеса: включить 0.5, 1, 2, 3 — иначе приложение рисует маркер только на первом
- Логарифмическая ось X — выключить для вибрографика (на линейной шкале гармоники встают равномерной гребёнкой, которую видно мгновенно) и включить для шумового (там охват 10 Гц–10 кГц)
- Autoscale Y — выключить, зафиксировать 0.2 м/с². Иначе две записи невозможно сравнить по амплитуде
- Number of local maxima: 5
Крепление
Это половина точности измерения, и здесь ошибаются чаще всего.
Телефон крепится жёстко к полу или порогу, экраном вверх, длинной стороной вперёд, на двусторонний скотч 3M VHB или плотную липучку.
Место установки определяет, что вы получите на выходе. Я в первой поездке положил телефон по центру пола багажника — это оказалось ошибкой, которую стоит не повторять.
Центр багажника равноудалён от обеих задних арок, поэтому вибрация от левого и правого колеса приходит туда примерно одинаково. Такая запись даёт всё, кроме одного: она отвечает на вопросы «есть ли дефект», «какой это порядок» и «связан ли он с двигателем», но не отвечает, какое из двух колёс виновато. Ради этого потом приходится ехать заново.
Правильно с самого начала:
- Первая запись — телефон вплотную к той арке, откуда предположительно идёт шум. Не по центру, а сдвинуть максимально в сторону подозреваемого колеса, насколько позволяет пол багажника.
- Вторая запись — у противоположной арки. Тот же маршрут, та же скорость, тот же фиксированный масштаб Y, ту же ориентацию телефона.
Сравнение амплитуды на целевой частоте между двумя записями и даёт сторону: где выше, там дефект. Разница обычно кратная, ошибиться сложно.
Автомасштаб при этом должен быть выключен в обеих записях — иначе приложение подгонит шкалу под каждую поездку отдельно и сравнение потеряет смысл.
Что не работает: держатели на присоске и гибкой ноге (механический фильтр, срезает всё выше 20 Гц и добавляет собственный резонанс), сиденье и коврик с ворсом (поролон гасит именно нужный диапазон), рука (тремор кисти даёт устойчивый пик 8–12 Гц — я это увидел на первом же тесте).
Оси после крепления: Z вертикально — главная для подшипника и биения, Y вдоль машины, X поперёк, важна в тесте с перекладкой.
Запись: маршрут и первые грабли
Схема простая: включил запись стоя, проехал маршрут не трогая телефон, вернулся, остановил, сохранил. Разделять поездку на файлы не нужно — всё разбирается потом по времени и оборотам.
Маршрут на 4–6 минут:
| Отрезок | Действие | Что даёт |
|---|---|---|
| 0–1 мин | Стоя, двигатель работает | базовая линия, гармоники двигателя |
| 1–2 мин | Разгон плавно | видно, растёт пик линейно или это резонансный горб |
| 2–3 мин | Постоянная скорость, гладкий асфальт | чистый спектр |
| 3–4 мин | Накат на нейтрали | отделяет качение от трансмиссии |
| 4–5 мин | Постоянная скорость, шершавый асфальт | там, где слышен дефект |
| 5–6 мин | S-повороты плавно влево-вправо | перекладка нагрузки, определение борта |
Первые грабли: файл получился 145.7 МБ за 4.2 минуты. Текстовый формат, полная точность float, три оси на 500 Гц плюс микрофон на 5.7 кГц. Загрузить такое в чат с ИИ нельзя, открыть в Excel нельзя, обработать вручную нельзя.
Вторые грабли: GPS не записался. Приложению не хватило разрешения на точное местоположение. Записались только обороты двигателя через OBD-адаптер — 679 значений с частотой 3 Гц.
Обе проблемы решились программно, и вторая неожиданно оказалась подарком.
Инструмент 1: подготовка данных
Написал скрипт nvh_prep.py (код — в репозитории метода). Задача — превратить 145 МБ сырья в несколько мегабайт, пригодных для анализа, ничего при этом не потеряв.
Что он делает:
Разбирает формат. CarNVH пишет .txt с разделителем «точка с запятой» без кавычек и .csv с запятой и полем данных в кавычках. Скрипт определяет формат сам.
Склеивает перекрывающиеся кадры. Приложение пишет не непрерывный поток, а окна по 256 отсчётов с шагом около 52 мс. Соседние окна перекрываются: новых отсчётов в каждом всего 26 из 256. Скрипт находит сдвиг корреляцией и восстанавливает непрерывный сигнал.
Считает реальную частоту дискретизации. Не по общей длительности (даёт завышение из-за джиттера), а по отношению «новых отсчётов на кадр» к шагу времени между кадрами. Получилось ровно 500.0 Гц — то есть High Sampling Rate действительно сработал.
Отбрасывает микрофон. Он занимает основную часть объёма, а для разделения «шина против подшипника» решающий канал — акселерометр.
Режет на отрезки по 20 секунд, равномерно по всей записи, и отдельно сохраняет все записи OBD целиком.
Результат: вместо 145.7 МБ — отчёт на 17 КБ, сегменты на 2.6 МБ и OBD-данные на 20 КБ.
Инструмент 2: порядковый анализ
Второй скрипт, nvh_analyze.py, делает собственно диагностику. Логика в четыре шага.
Шаг 1. Тест на привязку к двигателю
Ключевая идея всего метода, и она даёт ответ раньше любого спектра.
Все источники вибрации делятся на два класса: привязанные к оборотам двигателя (опоры, демпфер, навесное, выхлоп) и привязанные к скорости движения (колёса, шины, подшипники, кардан).
Разделить их можно одним манёвром — кикдауном. При резком нажатии газа обороты подскакивают вдвое, а скорость за пару секунд почти не меняется. Если частота пика пошла за оборотами — источник в двигателе. Если осталась на месте — источник в качении.
Вот что показали мои данные:
| Сегмент | Обороты | Частота пика |
|---|---|---|
| 3 | 1184 → 2418 | 13.00 → 13.00 Гц |
| 6 | 777 → 2070 | 5.00 → 11.00 Гц |
| 2 | 717 → 1788 | 25.00 → 14.50 Гц |
Средний рост оборотов: ×2.39. Средний сдвиг частоты: ×1.00.
Обороты выросли более чем вдвое — частота не сдвинулась. Двигатель, коробка и кардан исключены за одну итерацию, без единой разборки.
Шаг 2. Порядковый анализ
Дальше берётся отрезок с установившейся скоростью — скрипт выбирает его сам по критерию «максимальная амплитуда при минимальном разбросе оборотов». У меня это 20 секунд на 51 км/ч.
Спектр раскладывается по кратным частоты вращения колеса:
Порядок частота Z X Y Z/фон
1x 6.45 Гц 0.1020 0.0252 0.0192 2.3
2x 12.25 Гц 0.4416 0.0574 0.1205 10.1
3x 18.20 Гц 0.0705 0.0111 0.0039 1.6
4x 24.70 Гц 0.1170 0.0264 0.0178 2.7
5x 30.50 Гц 0.0830 0.0471 0.0230 1.9
Дополнительно считается добротность главного пика: Q = 122, ширина по уровню −3 дБ всего 0.10 Гц. Это узкая дискретная линия, а не резонансный горб. Для сравнения, на разгоне по неровному асфальту Q падает до 1.4 — вот это резонанс подвески, и его нельзя путать с дефектом.
Шаг 3. Анализ огибающей — проверка на подшипник
Дефект подшипника — это не вибрация, а ударные импульсы. Они проявляются как модуляция высокочастотной несущей, и ловятся только через демодуляцию: полосовой фильтр, преобразование Гильберта, спектр огибающей.
Скрипт делает это в полосах 60–240 и 100–240 Гц и ищет дискретные линии. Важнейший признак: частоты дефектов подшипника нецелые относительно оборота колеса — наружное кольцо обычно 3.5–4.5×, внутреннее 5.5–6.5×. Целые порядки к подшипнику отношения не имеют.
В моих данных максимальный пик огибающей — 8.6 медиан фона, дискретных линий нет. Подшипник исключён.
Шаг 4. Вердикт
Скрипт сопоставляет доминирующий порядок с механической причиной и сравнивает амплитуду с порогами (0.30 м/с² — заметно, 0.50 — дефект).
Результат и ошибка, которая чуть не увела в сторону
Первый прогон дал неверный ответ, и стоит показать почему.
Скрипт нашёл доминирующую линию на 12.25 Гц и по умолчанию принял её за первый порядок колеса. Из этого следовала скорость 101 км/ч и диагноз «дисбаланс».
Диагноз был бы неверным. При окружности 2.30 м первый порядок на 60 км/ч равен 7.25 Гц — а я на этой поездке быстрее 60 не ехал. Значит 12.25 Гц не может быть первым порядком физически.
Единственная сходящаяся версия: 12.25 Гц — это второй порядок, первый равен 6.125 Гц, скорость ≈ 51 км/ч.
Проверка независимым путём, через трансмиссию:
- обороты колеса при 6.125 Гц = 368 об/мин
- общее передаточное отношение = 1460 / 368 = 3.97
- пятая передача 8HP: 1.285 × 3.204 главная пара = 4.12
Расхождение 4% — в пределах допуска на окружность шины. Пятая передача на 51 км/ч при 1460 об/мин абсолютно нормальна. Версия подтвердилась.
Пересчитанная картина:
- Первый порядок: 0.083 м/с², практически на уровне фона → дисбаланс исключён
- Второй порядок: 0.442 м/с², в 10 раз выше фона → доминирует
- Направление: 71% вертикаль → радиальная неравномерность, не боковая
Второй порядок колеса при чистом первом означает: эллипсность шины, износ по двум противоположным точкам, деформация обода в двух точках или начало расслоения брекера.
Совпадение с симптомами полное. Гул появляется на 50–60 км/ч — измерено ровно на 51. На газ не реагирует — доказано кикдауном. Диапазон узкий — 12.25 Гц попадает в зону собственной частоты неподрессоренной массы задней оси, поэтому именно там дефект раскачивается сильнее всего, а выше и ниже уходит из резонанса.
Балансировка тут не поможет: она правит первый порядок, а он чист. Нужен замер радиального биения на станке, отдельно диск и колесо в сборе.
Роль ИИ в этой работе
Стоит быть точным, потому что вокруг темы много магии.
ИИ не «услышал поломку». Claude не заменил ни датчик, ни станок для замера биения.
Что он реально сделал:
- Задал требования к измерению. Расчёт необходимой частоты дискретизации от частот дефектов, требования к креплению, набор манёвров в маршруте — всё это определяется физикой задачи, и ошибка здесь обесценивает любую последующую обработку.
- Написал оба инструмента. Скрипты разбора перекрывающихся кадров и порядкового анализа с преобразованием Гильберта — это несколько часов работы вручную, здесь заняло минуты.
- Провёл сам анализ. Тест на привязку к двигателю через кикдаун, расчёт добротности, envelope-анализ, сверка передаточных отношений — вся аналитическая часть.
- Поймал собственную ошибку по одной реплике. Фраза «я больше 60 не разгонялся» полностью изменила интерпретацию: диагноз переехал с первого порядка на второй, с дисбаланса на эллипсность. Это ключевой момент — ИИ проверяет гипотезу против физики, а не защищает её.
Разделение труда получилось честным: человек даёт контекст и физические ограничения, ИИ считает и проверяет непротиворечивость. Без реплики про 60 км/ч диагноз был бы красивым и неверным.
Итог: что стоит метод
| Позиция | Цена |
|---|---|
| CarNVH Pro | €12 |
| phyphox | бесплатно |
| Смартфон | старый A51, лежал дома |
| OBD-адаптер | уже был, и в итоге не понадобился |
| Скрипты | написаны один раз, переиспользуемы |
| Итого | €12 |
Против $99.99 за приложение-справочник, которое не отдаёт сырых данных, и против визита в сервис с формулировкой «что-то гудит сзади».
Метод переносится на любой автомобиль без изменений. Меняются только два числа: окружность колеса и передаточные отношения. Физика вращения одинакова для Audi Q7, BMW X5, Mercedes GLE, Range Rover, Tesla Model Y, Volvo XC90, Porsche Cayenne, VW Touareg, Ford Ranger, Toyota Land Cruiser и любой другой машины.
Для Range Rover, Q7, Touareg, Cayenne и других внедорожников на пневмоподвеске есть одно дополнительное условие: всю поездку держать один режим высоты. Смена клиренса меняет углы карданного вала и нагрузку на подвеску, что делает записи несравнимыми.
Для электромобилей метод работает даже лучше: двигатель не шумит, механические источники слышно как в лаборатории, а тест на привязку к оборотам не нужен вовсе.
Что дальше
Следующий шаг — определение стороны, и здесь я расплачиваюсь за телефон, положенный по центру багажника. Такая точка равноудалена от обеих арок и борт не выделяет. Нужны две записи со сдвигом к правой и к левой арке, одна скорость, один фиксированный масштаб. Разница амплитуд на 12.25 Гц покажет колесо.
И обязательный контрольный замер после ремонта: тот же участок, та же скорость, те же настройки. Если пик на 12.25 Гц упал до уровня фона — дефект устранён объективно, а не «вроде тише стало». Именно так работает предиктивная диагностика на судах, и ровно этот принцип полностью переносится на автомобиль.
Скрипты nvh_prep.py, nvh_analyze.py и полное техническое описание метода опубликованы на GitHub: github.com/gptariacom/car-nvh-order-analysis (MIT).
Автор — инженер Mind4Ship, предиктивная диагностика судового оборудования.
Нравится этот кейс?
Запустите похожий проект — опишите «хочу такое же», и исполнители пришлют рабочие прототипы. Ссылка на этот кейс уже будет в брифе.
Заказать похожий проект