|
Professor Seleznov
|
Привет, Хабр! Меня зовут Дмитрий Горбунов, я ведущий инженер в AI-дивизионе в YADRO, работаю в команде SmartFab. Мы решаем задачи на собственном производстве полного цикла Фаб Дубна, включающее цеха по производству многослойных печатных плат до 7 класса точности, линии поверхностного монтажа и автоматизированные конвейерные линии сборки и тестирования продуктов компании.
Один из ключевых процессов в создании печатных плат — правильная сборка экземпляра: не перепутать слои, верно сопоставить элементы. Чтобы помочь сборщикам, мы разработали систему контроля. В ее основе — ML-модель с функцией компьютерного зрения, которая помогла добиться нулевого процента брака на этапе сборки. В статье расскажу, как разрабатывали «ассистента» для коллег с производства и какие функциональные и механические особенности есть у нашего решения.
Как собирают печатную плату
На производстве в Дубне собирают многослойные печатные платы из листов — заготовок фиксированного размера, заведомо больших, чем самая большая плата. На таких заготовках можно разместить несколько плат одновременно. Листы бывают двух типов:
- медные, двусторонние и достаточно тонкие листы, на которые нанесены элементы платы;
- промежуточные слои-диэлектрики — препреги.
«Сэндвич» из препрегов и медных листов называют «пакет»
Пакет собирают на специальных столах вручную. На столе лежит поддон с фиксаторами, рядом — инструкция по сборке, а по сторонам — стойки с листами и препрегами. На столе также есть зажимы, на которые ставят поддон — он нужен, чтобы после сборки перенести пакет. Также поддон крепится к столу специальными фиксаторами.
Фиксаторы поддона
Отмечу, что есть два вида сборки:
- прямая — от наибольшего четного значения номера слоя к меньшему (наименьшее значение — два);
- обратная — от нечетного меньшего к нечетному большему, то есть от третьего слоя к конечному n, который нам неизвестен.
Стол для сборки печатных плат
Чтобы понять нашу задумку контроля сборки с помощью ML, сначала расскажу, как вообще собирают печатную плату.
Смотреть видео →
Объясню по порядку, что происходит на видео:
- Укладывают стартовый лист из фольги, похожий на препрег.
- Укладывают слои.
- Листы устанавливают на фиксаторы.
- Сверху укладывают финальный слой.
- Пакет забирают вместе с поддоном состава.
Во время сборки можно допустить два вида ошибок:
- Ошибка ориентации слоя. Когда взяли нужный лист, но на выкладке повернули его неправильно. Например, отраженным слева направо, или сверху вниз, или одновременно оба варианта.
- Ошибка порядка набора слоев. Ситуация, когда на столе лежит лист не с тем номером, который ожидается. Например, при прямой сборке после слоя 10 положили 6 (хотя нужен 8) или любой другой лист, не соответствующий восьмому слою.
При этом отмечу, что, если положить лист 9, будет ошибка ориентации, так как на другой стороне 9 слоя будет 8, правильный слой.
Чтобы контролировать подобные ошибки, необходимо уметь детектировать и считывать следующие элементы:
- ключ — для определения ориентации;
- текстовое поле с номером слоя — для определения порядка сборки;
- текстовое поле с идентификатором типа плат — для фиксации собираемого пакета и интеграции с другими информационными системами;
- QR-код, который содержит тот же идентификатор.
Элементы, которые нужно считать при проверке
Перед нами стояла задача построить систему, которая сможет понять, что на столе происходит сборка, различить листы в пакете, найти ключевые элементы медного листа и считать необходимую информацию из найденных зон, пока человек собирает пакет.
Требования к системе
Система контроля сборки призвана функционировать в сложных условиях. Она должна быть гибкой и соответствовать ряду жестких ограничений.
Реагировать быстро
Одна из особенностей работы цеха — очень долгая обратная связь о наличии ошибок. Если пакет соберут неверно, об этом узнают только через несколько дней после запекания платы. Если в процессе тестирования платы обнаружится, что какие-то слои были собраны неправильно, вся плата придет в негодность — ее придется просто выкинуть. Эту ошибку уже будет невозможно исправить. Поэтому единственная возможность ее избежать — контроль во время сборки.
Не мешать сборщику
Оборудование контроля сборки не должно препятствовать работе. Сборщик ходит от стойки до стойки за слоями для пакета, поэтому система машинного зрения должна смотреть откуда-то слева, справа или сверху на стол, не мешая перемещениям. К тому же система контроля не должна усложнять процедуру сборки , заставляя сборщика совершать лишние действия в процессе работы.
Распознавать стадии работы
Стол многофункциональный, используется не только для сборки, но и для выполнения других операций — например, на нем могут храниться вещи. Поэтому нужно еще и уметь определять, а сборка ли происходит в данный момент.
Из этих требований исходят условия работы:
- Большое разрешение. Входное разрешение изображения должно быть большим. Мы используем камеру с ручной фокусировкой и разрешением 5500×3500 пикселей, потому что контрольные объекты довольно маленькие, а расстояние от камеры до стола составляет больше метра, чтобы не мешать сборке.
- Особенности монтажа. Чтобы построить такую систему, нужно подобрать оборудование, разработать крепления и механизм информирования об ошибке: визуальный и звуковой.
Разработка стенда: собираем удобную систему
Мы установили систему контроля на столах для сборки и прикрепили мониторы, на которых выводится информация о работе системы. В цеху также есть колонки, которые сигнализируют об ошибках. Камеру поставили довольно высоко, чтобы она не мешала сборщику, а мониторы находятся прямо перед глазами.
Слева и справа — конечный образ стенда, посередине — первичный
Когда построили стенд, незамедлительно начали этап сбора данных.
Примерная схема работы системы
Нам важно знать, какая именно стадия сборочного процесса происходит и происходит ли сборка вообще. Поэтому у нас есть система, которая постоянно следит за столом и контролирует происходящее. Система должна предотвращать два основных вида ошибок: неправильный порядок слоев и неправильную ориентацию листа.
На самом деле ошибок больше: лист можно неправильно положить тремя разными способами, а верно — только одним способом. Плюс существует большое количество вариантов ошибок с последовательностью, и все это умножается на два, так как режимов сборки несколько (прямой и обратный).
Сбор данных
В рамках этого этапа надо было наработать стартовый объем данных, чтобы затем построить алгоритмы машинного обучения. Находясь у истоков проекта, мы построили систему анализа кадра, основанную на эвристиках. Сравнивали текущие изображения с некоторым эталоном и принимали решение, что происходит на столе. Эти данные сохраняли и отправляли на наши серверы, чтобы их могла подхватить команда аннотации. С коллегами-аннотаторами разработали правила разметки, чтобы разметить данные видеопотока и использовать их для алгоритмов машинного обучения.
Впоследствии это простенькое правило аннотирования событий, происходящих в кадре, мы заменили на одну из тех моделей, которые следят за реальной сборкой, так как она более точная, позволяет нам более прецизионно собирать данные для дальнейших доработок экспериментов с моделями.
Определяем, что происходит на рабочем месте
Определение сцены стало нашим камнем преткновения, так как основная задача здесь — понять, что вообще происходит на рабочем месте.
Смотреть видео →
Фактически здесь решается задача классификации видеопотока. В видео видим несколько примеров сервисных классов, которые мы используем, чтобы различать события, происходящие в кадре. Мы знаем, когда на столе просто что-то лежит (это стационарное событие), а когда в кадр что-то вносят или убирают (это транзитные события). Эти данные нужны, чтобы контролировать, что именно и в каком порядке положили на стол.
Например, без транзитных состояний невозможно понять, почему мы видим восьмой лист, а через время — десятый. Это ошибка или процедура разборки?
Кроме того, на конвейере происходит много событий, а процедура сборки не всегда такая идеальная, как в видеоролике. Когда на производстве высокая загрузка и коллеги собирают много пакетов, они могут, например, выложить несколько препрегов разом, не разделяя их между собой. Или, например, не до конца фиксировать листы, потому что лист, который лежит сверху, всегда можно поправить с тем листом, который выкладывают следующим.
Безусловно, за счет выбора правильных компонентов и состоятельной обучающей выборки, можно на стороне системы частично устранить подобные отклонения от нормы. Однако, чтобы целиком их убрать, необходимо обновить должностные инструкции по сборке пакетов, а также «подружить» работу сборщиков и системы контроля. Совсем без вмешательства контролировать процесс не получится, так как если сборщик не взаимодействует с механизмом верификации, то от такой модели нет никакого толка. Дополнительных действий со стороны человека не понадобится, но уточнить операции необходимо, так как чем больше неопределенности в действиях человека, тем сложнее их интерпретировать и строить надежного помощника.
Как оценить качество моделей, которые работают с видеорядом
Ошибки бывают двух видов, первого и второго рода:
- Ошибка первого рода — система определяет, что стол занят, когда он на самом деле свободен.
- Ошибка второго рода — система определяет, что стол свободен, когда он на самом деле занят.
Такие ошибки можно контролировать разными методами оценки качества. Например, Precision или Recall, направленные на контроль ошибок первого и второго рода. Но мы будем использовать гармоническое среднее, или то, что учитывает оба типа ошибок, чтобы мы не говорили о том, чего нет, и не пропускали то, что есть на самом деле. Это метрики, которые можно посчитать по одному кадру.
Так как процедура сборки пакета занимает какое-то время, то предсказания моделей должны быть темпорально консистентны друг другу, чтобы на их основе можно было выстроить надежную систему анализа потоковых данных. Чтобы понимать, насколько хорошо модели ведут себя с учетом времени, есть специальные методы оценки качества работы моделей. Прежде чем перейти к описанию метрик, определимся, что такое «событие».
Событие — это состояние, в котором находится рабочая зона во время сборки пакета. Например, «внос препрега», «на столе лежит медный слой» и другие. Во время таких событий модель должна предсказывать один и тот же класс до тех пор, пока событие не сменится. Чтобы оценить качество работы модели в таких условиях, мы используем следующие методы:
- Intersection based method — метод на основе пересечения. Основан на пересечении предсказываемых событий и реальных событий. Под реальными тут может пониматься то, что было размечено нашей командой аннотации согласно разработанным правилам. На сколько процентов пересекаются реальные события с теми, которые модель предсказывает? В зависимости от процентного соотношения площади пересечения принимается решение о том, является ли событие ложным (неверно предсказанным) или правдивым.
- Collar based method — метод на основе допустимых границ. Ориентируется на то, попадает ли предсказываемое событие в допустимые границы начала и конца реального события.
Схема устройства методов
Это важно, потому что мы не хотим, чтобы одно событие сильно смещалось относительно другого. Дело в том, что события меняются достаточно быстро и требуется высокая степень оперативности от системы.
Результаты решения задачи «определение состояния сцены»
Эти значения — результат работы модели с учетом сглаживания предсказаний с помощью метода скользящего окна. Насколько хорошо получилось: есть куда расти, но текущий уровень качества достаточен для покрытия большей части сценариев работы стенда.
| Метрика |
Значение |
| Frame Accuracy |
97% |
| Frame precision macro |
94% |
| Frame recall macro |
97% |
| Collar Precision macro |
93% |
| Collar Recall macro |
98% |
| Intersection Precision macro |
82% |
| Intersection Recall macro |
94% |
Камера выдает 19 FPS, а скорость обработки модели — 125 FPS, успеваем обработать с запасом.
Поиск ключевых элементов
Нам нужно определить положение ключевых элементов на плате. Положение графических элементов различается от плате к плате, поэтому мы применили детектор.
Кроме того, систему с детектором проще поддерживать, чем ту, что основана на системе правил. Потому что при появлении новой платы нужно переписывать правило. А здесь за счет того, что в модель мы подаем все зоны интереса, где могут появляться элементы, мы можем распознавать вообще все элементы.
Обработка больших изображений
При выбранном положении камеры относительно рабочей поверхности разрешение съемки должно быть достаточно высоким, чтобы мелкие детали на листах (текст, ключ, QR-код) могли быть различимыми. Мы используем промышленную камеру с разрешением съемки 5500×3500. Но кадры такого размера в модели передавать не стоит, так как обработка большого кадра моделью займет приличное количество времени, а большая часть кадра не содержит полезной информации в разрезе задачи поиска ключевых элементов платы. Например, размер ключика — 40×100 пикселей, а текст занимает поле примерно на 400×100 пикселей. Так как камера жестко фиксирована относительно стола, листы платы всегда появляются приблизительно в одном и том же месте. Значит, потенциальные места появления ключевых объектов тоже можно вычислить. Поэтому мы вырезаем только ключевые регионы и обрабатываем уже их.
С чем могут быть связаны проблемы работы с кадрами в высоком разрешении?
- Если для решения задачи планировалось дообучать предобученные модели, то это сделать не получится, так как за счет разительной смены разрешения предобученные веса скорее будут мешать.
- Адаптация архитектуры модели под большое разрешение (если речь про свертки): как правило, при построении сверточных архитектур признаковое описание кадров сжимают, пространственно увеличивая размер векторного представления. Если в сцене одновременно есть и очень маленькие, и очень большие объекты, то нужно будет масштабировать существующие модели, делая их значительно глубже.
- Общее время обработки кадра. Вне зависимости от архитектуры объем вычислений возрастает соразмерно разрешению.
Выход из ситуации — обработка регионов интереса вместо всего кадра. Достаточно определить вероятные зоны появления необходимых объектов (например, статистически по имеющимся данным). По собранной информации определить зоны интереса. При обработке кадра вырезать их, объединять в батч и обрабатывать все зоны, связанные с кадром-батчем.
Такой подход позволяет сохранить высокую скорость работы — модель обрабатывает около 100 исходных кадров в секунду. При этом не происходит потери качества. При уровне уверенности модели в своем предсказании 50% получается средневзвешенное гармоническое среднее в районе 95%. Это достаточно высокий показатель, который позволяет обеспечить такое качество для построения систем промышленного уровня. А если говорить про применяемый для оценки качества моделей детектирования mAP@50-95, то он получается в районе 65%. Это тоже отличный результат.
Распознавание текстовых блоков (OCR)
Задача Optical Character Recognition (OCR) — распознавать текстовые блоки. Сейчас система умеет работать с трехсимвольным номером слоя.
Просвечивание листов
Для сборки плат используют двусторонние и достаточно тонкие листы. В результате символы на лицевой (по отношению к камере) стороне листа накладываются на символы с обратной стороны. Из-за этого считывать данные с этих полей довольно сложно.
Как символы лицевой и обратной стороны накладываются друг на друга
Тут можно применять разные методы предобработки кадров, но так как процедура сборки интерактивная, а результаты не определить заранее, то и алгоритм должен быть адаптивным. Время разработки такого алгоритма может оказаться очень большим.
Шрифт
На платах используется моноширинный шрифт, но он не предназначен для машинного чтения. Обучить модель на таком шрифте сложнее, а вероятность ошибки выше, потому что символы можно перепутать. Есть специальные наборы шрифтов, подходящие для машинного чтения, и поэтому мы с коллегами с производства договорились внести ряд изменений в текстовые поля, с которыми приходится работать. Во-первых, сделали выравнивание по левому краю, чтобы уменьшить объем пересекающейся области текста. Во-вторых, сменили текст на так называемый OCR-friendly, чтобы его было проще читать с помощью алгоритмов.
Сейчас мы распознаем символьные ошибки в номерах слоев с высокой точностью. Частота, с которой встречаются лишние символы (Character Error Rate), меньше 1%. А точность совпадения текстового поля с реально написанными символами — 97,7%, что тоже достаточно много, однако все еще недостаточно для надежной работы. Поэтому для верификации предсказаний проверяем, соответствует ли выдача модели ожидаемому паттерну распознаваемой фразы и аугментирование данных для инференса случайными смещениями выделяемого региона интереса (Test Time Augmentation). Это нужно для накопления посимвольной статистики, чтобы использовать моду в качестве предсказания. Таким образом удается получить точность более 99%.
Результаты внедрения
Система работает на производстве с сентября 2025 года, за время удалось проверить несколько тысяч пакетов. Мы внедряли систему в рабочий процесс по частям: сначала появился контроль ориентации слоев, позже контроль порядка набора слоев. Контролировать ориентацию значительно легче, чем порядок, так как требования к степени понимания сцены в таком случае сильно проще, поэтому и решили разбить поставку на части.
По итогам первой поставки удалось полностью исключить ошибки ориентации при сборке плат. Система четко и безошибочно выявляла дефекты сборки. Однако добавление контроля очередности сборки существенно усложнило систему, так как приходилось учитывать не только факт появления листа в пакете, но и процедуру набора пакета. Пакеты собирают люди, поэтому процесс не идет идеально. Так что требования к качеству работы алгоритмов распознавания сильно повышаются.
По итогам внедрения этапа «Контроль ориентации и порядка слоев» мы смогли поддержать порядок слоев и не пропустить ни одной ошибки сборки обоих типов. В работе системы контроля появились ложные срабатывания, доля которых достигает в среднем 14%, но они не приводят к ошибкам сборки, а на перепроверку у сборщика уходит незначительное время. Так что ложные срабатывания не отражаются на эффективности производства.
Несмотря на несовершенство системы, мы внедрили ее на производстве и получили первые результаты. Мы анализируем ошибки работы системы в опытной эксплуатации, чтобы постоянно расширять репрезентативность данных, на которых проводится моделирование, чтобы сделать алгоритмы контроля лучше. -Источник
|
