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

Задача

Контролировать нанесение маркировки на типографии.

У большинства представление о типографии - это там, где книги печатают, ну еще визитки, кружки... Будучи студентом я в таких чертежи печатал)

Что же меня ждало в действительности - так это тяжелые роли со стикерами, картонной упаковкой, алюминиевой фольгой и огромные печатные машины, мотающие ее со скоростями до 300 метров в минуту. Глазом даже не видно что идет печать - скорость насколько большая, что все смазывается, увидеть печать помогают только стробоскопы.

Контроль маркировки заключался в верификации кода DataMatrix, о котором я уже писал ранее:   Верификация DataMatrix Чес...  @Хабр

Фотографии типичной типографии, производящей упаковку:

Вводные данные:

13 ручьев (линий печати вдоль полотна)

120-150 м/мин - средняя скорость печати

Расположение кодов - меняется в зависимости от дизайна (вряд, в шашку и т.д.)

360 мм - ширина полотна

10*10 мм - размер кода маркировки (20х20 точек)

Аналитика

Типовые решения

На рынке подобные задачи уверенно решали подходом "в лоб" - на каждый код - своя камера, с которой ПО уже напрямую оценивает нанесение кода.

Такое решение хорошо своей простотой. Но минусов у него кратно больше, а именно:

1. На типографии печатали до 13 ручьев - а это аж 13 камер в ряд! Что и накладно и сложно в настройке.

2. Необходимость Ручного перемещения камер по рядам с кодами (ручьям)

3. Калибровка. По задаче мы должны сделать средство измерения, а значит его надо будет юстировать и калибровать. Откалибровать 13 камер можно, хоть и трудно. Но влияние оператора может в какой-то момент сбить настройку объектива и "начинай сначала: Билеты, завод, калибруй"

Выбранное решение

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

Что такое линейная камера и как она работает:

У линейной камеры длинный и узкий сенсор разрешением 2 х 4096 пикс. В высоту она снимает всего 2 пикс. НО она их может накапливать на встроенном FPGA и выдавать привычным прямоугольным кадром, поэтому обработка изображения с нее ничем не отличается от привычной матричной камеры.

Расчёты

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

Что мы считали:

1. Требуемое разрешение на код маркировки. Для оценки качества маркировки нужно разрешение на модуль кода не менее 4х пикселей. Модуль у нас 0,5 мм.

   Итог: Разрешение на поверхности материала с кодом должно быть 8 пикс/мм. Доступная нам камера имела сенсор 4096 пикс, с разрешением 8 пикс/мм снимет 512 мм, что более чем достаточно (ширина рулона по ТЗ = 360 мм).

2. Скорость камеры. По даташиту наша камера снимает 24 кГц или 24 000 линий (пикселей по вертикали) в сек. Переводим в скорость: 24 000 / 8 = 3 м/сек или 180 м/мин. Чего тоже достаточно (скорость печатной машины до 150 м/мин)

3. Оптика. Тут все достаточно просто, общаемся с поставщиком оборудования, нам все подбирают под габариты задачи. Имхо - у них опыта большое.

4. Свет. Аналогично, как и с оптикой. Свет для технического зрения вообще штука сложная, а в случае линейной камеры к нему еще и много требований: Нулевое мерцание, равномерная засветка, компактность, долговечность.

5. Энкодер. Самый главный датчик во всей системе. Он позволяет синхронизировать съемку камеры и материала. Таким образом печатают на 60 м/мин - камера присылает кадры реже, так как медленнее снимает ее строка пикселей (реже приходит "тригер") К нему требования 3: Надежность, разрешение более 8 имп/мм (из п.1) и подходящее напряжение.

6. Скорость распознавания. Максимальная нагрузка в кодах в минуту: 13 000 кодов в минуту.

7. Железо. Не мелочились - взяли сразу 2х процессорный сервер с 64 ГБ ОЗУ и сетевыми картами от Intel. Бюджет позволяет, а обычных ПК хватает на год работы под такой нагрузкой.

Собираем прототип

В лаборатории из алюминиевого профиля создаем простую раму, размещаем оборудование, подключаем перемотчик этикеток. И закидываем сразу ленту с огромным количеством этикеток.

А теперь начинается самое интересное - Распознавание и оптимизация.

ПО начинали писать на C#, так как под рукой был хороший пример из библиотеки MVTec Halcon, которую мы используем для распознавания.

Имеем: Бесконечно прилетающие друг за другом кадры. Мы подобрали для себя их высоту в 240 пикс, тем самым на максимальной скорости в наше ПО прилетает 100 кадров в секунду (или 1 ГБит/с снимков) Создаем для них буфер и наслаждаемся мерцающими картинками с кодами.

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

Что внедрили для оптимизации:

1. Обучение по ручью. Коды занимают от 5 до 30% всей поверхности материала. Соответственно - удаляем не интересные области (используем ROI) программно. Это значительно облегчило кадр + появилась возможность бит распознавание на потоки, чем естественно мы воспользовались

2. Используем все возможности библиотеки по оптимизации. Задаем очень точно все параметры распознавания кодов (коих в ней 20+). Естественно выносим их во внешний конфиг файл - мало ли что надо подкрутить.

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

4. Не забываем про буферы. Так как система не реального времени, и даже не мягкого реального - любой процесс может подвиснуть на доли секунды и все сломать. ОЗУ на сервере с запасом, смело делаем буферы на прием кадров в 1000 кадров и вешаем его отдельным потоком. Синхронизация всего чуда - стала для нас отдельным квестом, но справились и работает безупречно.

   Итого: на выходе имеем серверное приложение, готовое к нагрузкам до 140 000 кодов/мин. Что полностью закрывает ТЗ клиента. Данные о кодах отправляются по TCP, а работает оно полностью в автоматическом режиме с двух кнопок на панели оператора.

   

Боевое крещение

Заказываем красивый корпус. Все жестко крепим, так как вибрации очень серьезные. И едем на типографию тестироваться на реальную печатную машину

Итог: С помощью линейной камеры получилось создать решение, которое оказалось значительно надежнее и проще в эксплуатации. Да, с ПО под нее пришлось "повозиться" - но в этом даже есть и плюс - 99% редких проблем это программные, а решать их из офиса/коворкинга куда приятнее, чем на производстве.

Спасибо, что дочитали до конца! Желаю успехов в ваших разработках и буду рад, если данный материал оказался вам полезным. По вопросам можете писать мне в ЛС.