Я понимаю, почему говорят, что данные сейчас являются самым ценным ресурсом в мире…
Самый ценный ресурс в мире
Это не первая моя попытка создать систему мониторинга на основе компьютерного зрения для 3D-печати. На самом деле я пытался сделать то же самое в качестве личного проекта прошлым летом, когда впервые начал глубже погружаться в машинное обучение. Будучи новичком в этой области, я столкнулся с многочисленными проблемами, включая почти 900 долларов США от Google Cloud за неосознанное использование их услуг. Конечно, будучи разоренным студентом университета, этот счет в 900 долларов был ужасающим, но я мог исправить это относительно быстро, и я легко нашел новые платформы с открытым исходным кодом, которые можно было бы использовать в качестве лучшей альтернативы. Моя самая большая проблема заключалась в том, чтобы найти хороший источник данных, поскольку не было уже скомпилированной коллекции изображений с ошибками печати. Это заставило меня искать изображения с помощью различных поисков изображений Google и даже прочесывать сабреддит r/FixMyPrint в поисках неудачных отпечатков. Первые несколько дней поиска дали только около трехсот примеров, и перспективы постоянно ухудшались. Дело в том, что большинство людей, похоже, не хотят фотографировать свои неудачи — кто бы мог подумать? После этого опыта я понимаю, почему говорят, что данные сейчас являются самым ценным ресурсом в мире. Из-за всего этого мне нужно было разработать лучший способ сбора качественных данных на этот раз.
Quinly — идеальный инструмент для массового сбора данных
Что-то, к чему у меня не было доступа во время моей первой попытки этого проекта, так это 3D-принтеры, оснащенные автоматикой Quinly. Использование принтеров, оснащенных системой Quinly, оказалось критически важным для этого проекта, так как это позволило мне непрерывно печатать и делать временные снимки различных сбоев печати, не сталкиваясь с какими-либо проблемами с авторскими правами. Попытка собрать данные самостоятельно на стандартном 3D-принтере заняла бы очень много времени и утомительна, поэтому я даже не подумал попробовать сделать это в первый раз.
Машинное обучение нуждается в данных
Как вы могли догадаться, машинное обучение сильно зависит от большого объема данных. В общем, для хороших моделей машинного обучения нужны сотни, если не тысячи репрезентативных изображений для каждой категории объектов. Для нашей конкретной модели нам может понадобиться даже больше, потому что каждая напечатанная модель может выглядеть по-разному. В большинстве случаев объекты одного класса различаются, но не так сильно, как 3D-печать. Мы хотим создать надежную и обобщенную модель обнаружения объектов, чтобы она могла надежно выявлять сбои, независимо от того, что люди решат распечатать. Вот почему важно, чтобы мы постоянно работали над улучшением наших моделей с помощью новых наборов данных, чтобы продвигать модель вперед.
Рекомендации по данным для модели обнаружения объектов
Кошки могут быть разного размера и цвета, но, как правило, их легко идентифицировать по ключевым характеристикам. 3D-отпечатки могут иметь очень разный внешний вид, что значительно усложняет задачу создания этой модели. Чтобы получить широкий спектр данных, мы попытались варьировать данные изображения, которые мы получаем, с рядом различных параметров. Конечно, мы уже варьируем различные типы режимов отказа. Некоторые из дополнительных соображений включают фон изображения и условия освещения, а также размер отпечатка, форму, цвет и расположение на кровати поверх дефектов печати.
Автоматизация сбора данных
Поскольку 3DQue уже автоматизировала задания на 3D-печать, мы подумали, что было бы правильно еще больше оптимизировать наш процесс сбора данных с помощью автоматизации. Для этого я создал несколько различных сценариев, которые создавали определенные сбои в G-коде, загружали файлы в Quinly и создавали интервальную съемку для каждого задания на печать. Дальнейшее объяснение того, как работают эти скрипты, можно увидеть ниже.
Дизайн для сценариев отказа
Чтобы автоматизировать создание сбоев 3D-печати, я создал пять скриптов Python, которые будут принимать входные файлы G-кода и изменять их для вывода G-кода с определенным типом сбоя. Каждый сценарий предназначен для определенного типа сбоя и выглядит следующим образом: spaghetti.py, layer_shift.py, extrusion.py, detach.py и clog.py. Я также создал модель Python под названием gcode.py для хранения и импорта некоторых полезных функций, которые я буду использовать в каждом из основных сценариев отказа.
Общая структура каждого из этих скриптов состоит из четырех основных частей: определение парсера аргументов, нескольких циклов пути к файлу, локатора уровня отказа и вставки или изменения G-кода. Все части, работающие вместе, позволяют сценарию одновременно вводить несколько файлов G-кода и либо указывать, либо произвольно выбирать параметры сбоя, такие как место для вставки кода сбоя и размер сбоя для выходного G-кода.
Парсер аргументов позволяет пользователям сценариев определять определенные параметры для конкретной ошибки печати в командной строке при запуске программы. В общем, все сценарии имеют флаги target, remove, layer, layer min, layer max и итерации. Существуют и более конкретные флаги, зависящие от конкретного типа сбоя.
В каждом скрипте есть три основных цикла, чтобы иметь возможность запускать несколько входных файлов G-кода, а также многократно повторять каждый файл. Это позволяет преобразовывать большие пакеты G-кода за одно выполнение, а также один файл G-кода иметь несколько вариантов каждого типа сбоя. Это делается путем определения диапазона с использованием флага итерации в самом внешнем цикле для многократного просмотра файлов. После этого он вводит оператор «with», который перебирает файлы во входном каталоге, чтобы определить, какие файлы там находятся. Наконец, он входит в каждый из определенных файлов и создает модифицированные файлы G-кода только для файлов с расширением .gcode.
Есть несколько функций, которые я создал, чтобы найти случайный или заданный слой для вставки модифицированного G-кода. Они определены в файле gcode.py и импортированы в каждый из конкретных сценариев отказа, поскольку это требуется в каждом сценарии. Две основные функции — это check_layer_count() и find_layer().
check_layer_count() просматривает содержимое входного файла G-кода, строка за строкой, чтобы найти максимальное количество слоев, а также отлавливает и исправляет ошибки, определяемые пользователем, путем сравнения их с максимальным количеством слоев.
find_layer() найдет номер строки в содержимом G-кода по известному номеру слоя. Позже этот номер строки можно использовать в качестве отправной точки, чтобы найти, когда вставить приведенный ниже G-код.
Точные шаги могут различаться в каждом конкретном скрипте, но, по сути, определенная строка G-кода находится с использованием начальной строки, полученной с помощью find_layer(), в качестве начала диапазона в цикле for. Затем операторы «если-иначе» используются для поиска ключевой информации или вставки строк G-кода.
Автоматическая загрузка скрипта GCODE
Чтобы автоматически загружать группы «ошибочного G-кода», я создал скрипт Bash, который может как загружать файлы G-кода с Google Диска в Quinly, так и ставить распечатки в очередь на Quinly. Это делается с помощью программы под названием rclone и API-интерфейсов Quinly. По сути, rclone позволяет подключать облачные сервисы к Raspberry Pi, который затем можно использовать для загрузки и скачивания файлов в облачный сервис и из него. В этом сценарии я использую rclone для загрузки группы файлов GCODE с Google Диска на Raspberry Pi. После того, как файлы сохранены локально, я могу загрузить их в Quinly, а затем поставить их в очередь в два этапа, используя две функции Quinly.
Сценарий автоматической покадровой съемки
Самый важный сценарий с точки зрения сбора данных — это сценарий timelapse.sh Bash, который я написал. Этот сценарий работает непрерывно в фоновом режиме Raspberry Pi и запускается после перезагрузки, поскольку он настроен как задание cron (cron — это программа планирования, которая может выполнять сценарии в фоновом режиме в зависимости от времени, которое вы установили для его запуска). Чтобы получить замедленную съемку каждого отпечатка, сценарий отслеживает различные состояния принтеров для выполнения определенных команд, которые запускают, останавливают и загружают замедленную съемку. Каждому набору изображений и видео также будет присвоено конкретное имя, которое включает имя файла G-кода, IP-адрес принтера и дату/время, чтобы вы могли получать замедленные снимки одного и того же файла без перезаписи любых предыдущих замедленных снимков. .
Текущий сбор данных
Использование этих скриптов в унисон позволяет нам получить гораздо больше данных за более короткий период времени. На данный момент сбор данных больше не является узким местом; теперь это, вероятно, аннотация данных. Поскольку мы получаем так много данных для каждого таймлапса, нам нужно просеять их и очистить, прежде чем мы сможем делать аннотации.
Следующий
Чтобы больше рассказать о нашем опыте работы с аннотациями, следующая статья из этой серии называется «Аннотации: обучение машины». Хотя машины продолжают становиться умнее, аннотация данных вручную по-прежнему используется для обучения большинства моделей обнаружения объектов. В отличие от классификации изображений, где маркировку обычно нужно выполнять только путем помещения изображений в именованную папку или добавления к имени самих изображений, аннотация обнаружения объектов требует дополнительных шагов. Для обнаружения объектов каждое изображение должно иметь ограничивающую рамку и метку для объекта, и каждое изображение может иметь несколько рамок и меток. Это, конечно, делает процесс более сложным и трудоемким. В настоящее время мы работаем над этой частью, пока тренируемся на изображениях, которые мы уже аннотировали, но мы ищем лучшие способы ускорить процесс. В этой статье я определю некоторые важные аспекты аннотирования, покажу программное обеспечение, которое я использую для аннотирования, и рассмотрю методы аннотирования, которые мы можем рассмотреть в будущем.
TL;DR:
Эта статья — третья из пяти частей, описывающих мой путь создания модели машинного обучения для обнаружения объектов, которая будет использоваться в программном обеспечении Quinly 3DQue. Здесь я немного поясню, как мы автоматизируем наш процесс сбора данных, используя несколько скриптов Python для создания неудачного G-кода и загружая эти файлы в Quinly, чтобы другой скрипт Bash делал таймлапс каждой печати автономно. Если вы хотите помочь нам собрать больше данных, обязательно пришлите нам фотографии ваших неудачных 3D-печатей!
