Как мы превратили iPhone в лабораторный микроскоп с ИИ и Бле

Введение

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

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

Несколько слов о продукте

Даже при современных анализаторах гематологии до 15% образцов по -прежнему требуется ручной обзор под микроскопом, особенно когда аномалии находятся в крови. Автоматизированные системы микроскопии существуют, но они стоят столько же, сколько крыло самолета, поэтому большинство лабораторий продолжают исследовать мазки крови вручную. Мы делаем это по -разному: наше решение превращает стандартный лабораторный микроскоп в цифровой сканер с автоматическим кормлением слайдов и захватом изображений - простым, доступным и эффективным. Мы разрабатываем это вместе с@ansaril3И команда вcelly.aiПолем

Комплект соединяется со стандартным лабораторным микроскопом, превращая его в цифровой сканер. Его аппаратные компоненты включают в себя:

• iPhone - управление системой, анализ ячеек
• Адаптер линз - подключение смартфона к окуляру микроскопа
• Роботизированная стадия - обеспечивает движение слайда, управление фокусом и переключение между образцами

Что касается программного обеспечения, система состоит из:

• мобильное приложение на iPhone
• контроллер на сцене
• веб -портал/облако

Мобильное приложение выполняет следующие задачи:

• обрабатывает поток изображения из камеры, обнаруживает, классифицирует и считает ячейки
• отправляет их на веб -сервер вместе с другими артефактами анализа
• контролирует движение роботизированной стадии, выполняя мазок в соответствии с предопределенным алгоритмом
• и также отвечает за конфигурацию и инициацию анализа, корректировки параметров камеры, просмотр краткого анализа отчета и других связанных задач

Веб -портал предназначен для просмотра результатов, подтверждения врача и экспорта отчетов. Нижевидеопоказывая, как все это работает вместе:

Немного контекста о гематологической диагностике

Первичный анализ, который мы проводим, - это микроскопия мазки крови. Это компонент полного количества крови (CBC), одного из наиболее распространенных и фундаментальных медицинских испытаний. Многие люди прошли это и видели подобные таблицы в своих результатах (источник):

При выполнении CBC образцы крови обрабатываются с помощью анализатора гематологии. Если устройство указывает на отклонение от нормы, образец проходит микроскопическое исследование.

Этот процесс выглядит следующим образом:

• Лабораторный техник кладет каплю крови на стеклянный слайд,
• Пятна его с использованием метода Романовского (или аналогичных альтернатив <) ¹, исправляет его,
• и визуально изучает подготовленный мазок под микроскопом.

Именно на этом этапе можно:

• обнаруживатьАномальные клеточные морфологии(такие как незрелые нейтрофилы, атипичные лимфоциты, бластоты),
• оцениватьзрелость, размер, гранулярность, включенияи другие параметры,
• и иногда даже делатьПредварительный диагнозПеред получением данных PCR² или Elisa³.

Но ручной анализ болезнен:

• это очень субъективно,
• зависит от опыта техника,
• люди склонны к усталости и ошибкам,
• И это не очень хорошо масштабируется.

Автоматизированные системы микроскопии превосходны, но они дорогие (начиная с 60000 $ и выше), поэтому более 90% лабораторий все еще полагаются на ручной метод!

Мы поставили перед собой цель создания доступного набора для автоматизации микроскопа (в течение нескольких сотен тысяч рублей), который может быть широко развернут в лабораториях. И вот где iPhone выходит на сцену.

[1] - Образец крови на слайде обрабатывается специальным пятном, разработанным Дмитрий Леонидович Романовский (1861–1921). Это пятно делает различные компоненты клеток крови более заметными под микроскопом, поскольку они окрашены в разные цвета

[2] - ПЦР (полимеразная цепная реакция) позволяет обнаружить даже очень небольшое количество генетического материала, такого как вирусы или бактерии, что имеет решающее значение для диагностики инфекционных заболеваний. Мы хорошо помним это из эпохи цикла

[3] - ELISA (иммуноферментный анализ, связанный с ферментами), используется, когда важно обнаружить присутствие специфических белков

На что способен iPhone

Когда мы говорим о «ИИ на смартфоне», большинство людей изображают такие вещи, как фильтры камеры, автозаполнение текста или чат -боты. Но современные iPhone-это мини-компьютеры с выделенными нейронными модулями, способными выполнять серьезные задачи-в нашем случае анализ крови в реальном времени. Давайте посмотрим на три ключевых компонента, которые делают это возможным:

• Графическая обработка (GPU).Используется для операций изображения: предварительная обработка, фильтрация, коррекция. Например: оценка размытия, коррекция цвета, удаление артефакта и другие конкретные задачи, связанные с графикой и анализом изображений.
• Нейронная обработка (NPU / Нейронный двигатель).Apple интегрирует нейронный двигатель в свои устройства, начиная с чипа A11 (iPhone 8/x), и из A12 (iPhone XR и более новее), уже можно выполнить5 триллиона операций в секунду на NPU(Вершины). На момент написания, последняя A17 Pro и A18/A18 Pro Chips способны на35 топовПолем Это используется для вывода моделей для обнаружения и классификации клеток, оценки фона образца и аналогичных задач, освобождая процессор/графический процессор.
• Центральная обработка (ЦП).Отвечает за общую логику, управление, обработку конфигурации, сериализацию/десериализацию, работу с API и файловой системой - по сути, все, что не подпадает под два предыдущих компонента.

Мы будем обсуждать это с помощью iPhone XR (A12 Bionic, 2018) в качестве своего рода базовой линии, хотя это уже старое устройство. Даже на этой модели мы смогли:

• обработать видеопоток на 50 кадров в секунду с камеры микроскопа,
• одновременно выполните вывод Coreml (~ 15 мс на кадр),
• одновременно сохранить данные на диск и синхронизировать с облаком,
• Сохраняйте температуру в приемлемых пределах (если приоритеты дросселирования и приоритизация задачи тщательно настроены).

Тем не менее, устройство может заметно нагреться и начать замедляться. Например, во время анализа мазков малярии, где необходимо обрабатывать более 100 ячеек в одном кадре, тепловое дроссельное дроссель начнется уже с вторым или третьим мазком - частота процессора падает, а задержки между границей и замедления будут. Кроме того, близкий контакт адаптера против задней панели устройства препятствует рассеянию тепла

На скриншоте ниже показан другой анализ, а не малярию, но здесь важно, как много обнаружений запускается на кадр.

В целом, на iOS можно контролировать тепловое состояние системы черезProcessInfo.processinfo.thermalstateПолем В нашей производственной среде мы никогда не достигли критического уровня, но серьезный уровень происходит регулярно при очень высокой нагрузке. Для измерений производительности мы использовали xcode profiler, который позволяет измерять ЦП, графический процессор и нагрузку на память, а также тепловое состояние:

А вот таблица значений термилиста с объяснениями из документации:

Полный термический анализ и анализ мощности заслуживает отдельной статьи - как я упоминал в начале, я не хочу заходить слишком глубоко здесь. На основеобщедоступные источники, можно примерно предположить, чтоСерьезныйСостояние соответствует 80–90 ° C на уровне чипа и около 40 ° C на поверхности.

IPhone работает с любымBluetooth низкая энергияустройства. Для других устройств есть отдельный поток, где устройство должно иметьMFI(Сделано для iPhone) Сертификация, работая через IAP2 (Apple Accessy Protocol) и т. Д. Короче говоря, это не наш случай.

Здесь полезно вспомнить основные роли и структуру протокола:

• Периферийное- Устройство, которое подключено к. Обычно периферийное устройство посылает данные или ожидает соединения (примеры: часы, термометр, монитор сердечного ритма).
• Центральный- Устройство, которое подключается к периферийному устройству. Он инициирует соединение, отправляет команды и получает данные.
• GATT (общий профиль атрибута)- Структура, с помощью которой устройства BLE обмениваются данными. GATT определяет, какие «поля» доступны, что можно прочитать, написано или подписано на уведомления.
• Услуги и характеристики- Данные в рамках подключения BLE структурированы в услуги (логические группы) и характеристики (конкретные параметры). Например, фитнес -трекер может иметь услугу сердечного ритма, которая включает в себя характеристику измерения частоты сердечных сокращений (текущая частота сердечных сокращений).

В нашем случае iPhone контролирует сцену с помощью своего встроенного модуля BLE, который распознается как периферийное устройство с пользовательской службой GATT и выполняет две задачи:

• Отправка команд движения на контроллер для оси XY и управления фокусом вдоль оси Z
• получение данных от контроллера (состояние, положение)

Говоря о тепловой нагрузке, соединение BLE не должно вносить заметный вклад. Согласно данным из кремниевых лабораторий в ихДокумент о потреблении мощности BLE, передача команд или статус приема на частоте 20 Гц (интервал 50 мс):

• приводит к увеличению менее 1 МВт. Типичное потребление питания iPhone XR составляет около 50–100 МВт. Добавление менее 1 МВт практически незначительно, особенно по сравнению с обработкой нейронной сети, использованием графического процессора и дисплеем.
• Радиоканал активен только в течение примерно 2% случаев, спит в остальное время.

Мы углубимся в детали работы приложения с модулем BLE и контроллером в разделе «Работая с моторизованной стадией».

Теперь несколько слов о камере. Мы используем первичную (широкоугольную заднюю) камеру: мы снимаем видео H.264 с разрешением 1280 × 720 и битрейт около 40 Мбит / с.

• Чем выше битрейт, тем больше данных на единицу времени → тем выше качество изображения. 40 Мбит / с довольно высоки для разрешения 1280 × 720 (HD). Этого более чем достаточно для анализа клеточной визуализации.
• H.264-это международный стандарт кодирования видео, также известный как AVC-расширенное видео-кодирование или MPEG-4 Часть 10. Он устраняет избыточные данные (как межкароне, так и внутриофроматическое сжатие), уменьшая битрейт и, следовательно, размер файла. (Между прочим, у нас также была задача записать видео всего анализа в целях отладки и проверки.)

Таким образом, мы заканчиваем не просто мобильным клиентом пользовательского интерфейса, а полностью проведенным устройством Edge-означает устройство, которое обрабатывает данные локально, без постоянного подключения к серверу.

Мобильное приложение

Теперь, когда мы рассмотрели аппаратную часть, давайте посмотрим, как все это работает на уровне приложения. Давайте начнем с определения задачи:

• Ввход, приложение получает поток кадров от камеры - поле зрения микроскопа, движущегося через мазок.
• Ввыход, приложение должно:
  • Обнаружение лейкоцитов (и других клеток в зависимости от анализа)
  • отображать обнаруженные объекты с ограничительными коробками (Bboxes)
  • выполнить подсчет клеток
  • Отправить данные в фоновом режиме на бэкэнд (изображения ячеек, сканирование, отдельные рамки)

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

1)Предварительная обработка рамкиПолем Это включает в себя коррекцию искажения, удаление артефакта, оценку уровня размытия, а также коррекцию света и цвета.

Например, каждый лабораторный или микроскоп имеет особые условия освещения, которые могут привести к неисправности нейронной сети. Здесь необходимо выполнить нормализацию баланса белого - направляя поле зрения в пустую область и инициируя регулировку баланса белого камеры.

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

2) обнаружить, классифицировать,исчитатьклетки без дубликатов

Например, на фото ниже некоторые дубликаты отмечены красным в одном из старых анализов:

3) Управляйте микроскопомтак что он правильно движется через слайд, переходит от одного слайда к другому и, что наиболее важно, фокусируется именно на слайде, обнаруживая, когда он выходит за пределы слайдов или земли на пустых областях.

4) загрузитьпартии ячеек в облако (снимки, метаданные), не блокируя обработку следующего анализа.

5) ПовторитеЭтот процесс n раз, так как анализ выполняется в партиях.

6)И выполнить все это без перегрева телефона.

Приложение развивалось типичным модом стартапа: было быстро объединено доказательство концепции, а затем усовершенствовано в MVP (минимальный жизнеспособный продукт), подходящий для пилотирования в лабораториях и подачи инвесторов. В результате архитектура приложения оказалась гибридной: некоторые экраны реализованы с использованием экранов MVP на основе UIKIT (модель View-Presenter), в то время как новые функции и интерфейсы записываются в Swift с MVVM (Model-View-ViewModel).

Мы используем сервисный уровень для изоляции бизнес -логики:CameraServiceВBluetoothControllerВAnalysisServiceПолем Все зависимости вводится либо через конструкторы, либо через контейнеры DI. С точки зрения реакционной способности и асинхронных цепей с подпискими на события, у нас был «эволюционный путь»: мы изначально приняли RXSWIFT, затем начали переходить на объединение, и с появлением асинхронного/ожидания, часть цепей, сдвинутые там. Результатом стал своего рода «Франкенштейн», но позже мы выделили эти компоненты в отдельные модули, чтобы в будущем мы могли просто поменять компонент для нового технического стека. Все приложение переплетается с подробным журналом, и для сложных случаев (особенно тех, которые связаны с обработкой кадров), мы используем NSLOGGER: он позволяет регистрировать не только текст, но и изображения, которые сохраняли нас более одного раза при отладке трубопровода по обработке сотовой связи перед отправкой данных на сервер.

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

Но давайте вернемся к обработке кадров и посмотрим на немного более подробную архитектурную диаграмму, чем на вышеуказанном:

• Анализ контроллера-Центр принятия решений: получает кадры и запускает обработку в рамке.
• Служба камеры- получает необработанный поток рамы от камеры, преобразует его и передает его вперед.
• Контроллер микроскопа- контролирует контроллер микроскопа.
• Рамовый трубопровод- цепочка, состоящая из нескольких этапов:
  • Предварительная обработка- коррекция, фильтрация
  • Обнаружение- Объект объекта/ячейки
  • Считает- Подсчет уникальных объектов
  • Постобработка- Окончательная фильтрация и подготовка к визуализации
• UI- Отвечает за отображение результатов пользователю в режиме реального времени (ограничивающие ящики, статистика, оповещения).
• Загрузчик- Синхронизирует артефакты анализа (снимки, ячейки, конфигурация) с бэкэнд.

Что касается менеджера зависимостей: мы изначально использовали кокопод (которые ввелиРежим обслуживания и остановил активную разработкуПо состоянию на 2024 г.), но позже ввел SPM (Swift Package Manager). Некоторые услуги (компьютерное зрение, Bluetooth, утилиты) были перемещены в модули SPM. Были также попытки разделить код OBJC/C ++ на отдельные XCFrameWorks, но не было достаточно времени, чтобы разобраться, поэтому мы оставили этот код в основном проекте. OBJC был необходим в качестве обертки вокруг C ++, чтобы ее можно было вызвать от Swift. Это привело к классам OBJC ++: их интерфейсы являются чисто OBJC, что позволяет Swift взаимодействовать с ними, в то время как их реализации смешивают код OBJC и C ++. Это было раньшеSwift поддержал прямые вызовы C ++Полем

Я должен упомянуть, что я далеко не гуру в алгоритмах C ++ и компьютерного зрения, но мои обязанности включали получение базового понимания и портирования алгоритмов и эвристики с Python, где была проведена большая часть наших исследований и разработок. Я опишу некоторые из тех ниже.

Задачи

Удаление искажения

Один из адаптеров демонстрировал оптический артефакт искажения на изображении. В результате ячейка, которая должна появляться вокруг, будет выглядеть удлиненной или деформированной, особенно по краям кадра. Мы использовали калибровку с сетью шахматной доски иCV :: undistort ()Чтобы восстановить геометрию кадра:

1. Мы откалибруем камеру - снимая изображения шахматной доски/сетки с известной геометрией.

2. OpenCV вычисляет:

   1. Матрица камеры k (параметры проекции)
   2. Коэффициенты искажения d = [K1, K2, P1, P2, K3,…]

3. Применяем cv :: undistort () или cv :: initundistortrectifymap () + remap ():

   1. Это вычисляет, где каждая точка «должна была приземлиться» в действительности
   2. Изображение «выпрямлено» обратно, чтобы исправить геометрию

Позже адаптер был заменен - ​​этот шаг был удален.

Определение позиции на слайде

Чтобы точно подсчитывать клетки, крайне важно знать их координаты как можно точнее. ВвидеоЗдесь вы можете увидеть, что происходит, когда определение смены неверно.

Первоначально мы попытались вычислять относительный сдвиг между двумя кадрами и суммировали абсолютный сдвиг. Мы проверили несколько подходов:

• Классический метод регистрации изображений посредством фазовой корреляции на основе быстрого преобразования Фурье. Мы реализовали это в OpenCV и даже использовалиЯблоко ускоряетсяПолем
• Методы, основанные на локальных клавиатурах с дескрипторами: серфинга, SIFT, ORB и других.
• Оптический поток
• Apple Vision встроенVntranslationalImageRegistrationRequest

С одной стороны, у нас были некоторые предположения:

• Масштабирование или ротации не было
• Оптически: чистый, разблемый мазок, без пустых областей

Несмотря на это, все еще были проблемы из -за изменений в освещении, фокусировке, накоплении ошибок, резких смен, шума или артефактов на изображении.

Это привело к таблице сравнения, подобной приведенной ниже:

Вот ваш точный перевод предоставленной таблицы и текста:

Для каждого варианта мы пытались найти оптимальную конфигурацию с точки зрения точности и производительности для сравнения с эталонным сдвигом: мы разнообразные разрешения изображения, параметры алгоритма и различные настройки оптики камеры и микроскопа. Ниже приведены пара графиков из таких экспериментов.

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

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

Подсчет клеток

По сути, задача подсчета клеток - это конкретный случай отслеживания объектов и дедупликации: «Чтобы определить, что такое ячейка, избегайте его дважды, избегать перегрузки, а не пропустить необходимые ячейки - все в фракциях секунды, в реальном времени через камеру и работая на аппаратном обеспечении телефона». Вот как мы это решили:

1. Обнаружение объекта. Мы используем нейронные сети для обнаружения объектов в кадре (ограничивающая коробка, BB). Каждый BB имеет свой собственный показатель доверия (уверенность в сети) и класс ячеек.

Для борьбы с фоновым шумом и ложными положительными, мы применяем быстрое фильтр:

• на основе цвета: например, по интенсивности или цветовой диапазоне. Например, здесь, слева, красная выделение отмечает эритроцит - но нейронная сеть изначально классифицировала его как лейкоцит.
• Тем не менее, цветовые фильтры вступили в игру впоследствии, и это было отфильтровано.

Красная выделение отмечает эритроцит, отброшенный фильтрами.

• Геометрический: мы отказываемся от объектов, размеры которых выпадают вне типичных размеров клеток.

• Мы также отказываемся от клеток, которые частично выходят за пределы кадров - это не интересно для нас

  

2. Подсчет уникальных объектов. Некоторые BBS можно подсчитать более одного раза за одну и ту же ячейку, поэтому важно обнаружить такие случаи и подсчитать их только один раз. В какой -то момент мы были вдохновлены руководством из Mturk, который описывает два варианта:

   Вариант 1: Сравните расстояния между центрами BB - если новый BB слишком близок к одному уже записанным, это, вероятно, «та же» ячейка.

   Вариант 2: Рассчитайте IOU (пересечение над Union, Jaccard Index) - метрика для перекрытия между прямоугольниками. Если новый BB значительно перекрывается с существующим, мы считаем его только один раз.

В целом, необходимо поддерживать отслеживание объектов между кадрами, особенно если мы вернемся к ранее отсканированным районам мазода. Здесь опять же, очень важно точно определить положение на слайде - в противном случае весь счет падает по канализации.

Оцифровка

Одной из задач была оцифровка сканирования, по сути, создание программного гистологического сканера для мазода. На фото ниже показано, как это выглядит: стрелки указывают на движение, используемое для построения сканирования, где мы снимаем кадры и зашивают их в одно большое изображение.

Движение поля зрения через мазок

Здесь снова точное определение положения было критически важным, за которым следовал плавное строчки.

Стоит отметить, что изначально у нас не было моторизованной сцены, и она полагалась на ручную навигацию. Представьте, что вы пытаетесь собрать мозаику из сотен фрагментов. Если вы пропустите координаты, мозаика оказывается смещена.

Вот как выглядели первые эксперименты: прыжковые поля зрения, швы, различия в освещении, пустые пространства.

Слева - карта с неровной яркости и экспозицией, где «швы» видны на рамных соединениях. Справа - неравномерно сшитые изображения ткани с зазорами.

Или, например, пользователь сканирует мазок, быстро движущийся по нему - некоторые области в конечном итоге размыты (Motion Blur). Мы попытались отказаться от таких кадров, если они не соответствовали приемлемому порогу размытия или если сдвиг не может быть рассчитан для них.

Размытые рамки, наложенные на сканирование во время резкого движения

Постепенно мы продвинулись к следующему подходу:

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

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

Работа с моторизованной стадией

Теперь - подробности о соединении между iPhone и моторизованной стадией: как мы общаемся через BLE, какие команды мы отправляем, и как мы настроили автофокусировку. Мобильное устройство подключается через Bluetooth к контроллеру на сцене и перемещается по координатам XYZ. Точнее, это сама сцена, которая движется, но с точки зрения изображения, наблюдаемого через объективное объектив мобильным устройством, похоже, что движение происходит через слайд.

Наша этап также построена на заказ-не потому, что мы «хотим сделать все сами», а потому, что коммерческие решения начинаются с 10 000 долларов, и это не шутка. Мы наняли дизайнерское бюро и построили нашу собственную версию примерно за 800 долларов. Это оказалось значительно дешевле, потому что один из инженеров со временем заметил, что конструкция на стадии моторизованного микроскопа подозрительно напоминает 3D -принтер. Такая же кинематика XYZ, те же самые шаговые двигатели, те же рельсы. В результате мы используем массовые и недорогие компоненты, но адаптированы к нашим конкретным требованиям. Структурно, сцена состоит из трех частей: сама платформа XY, блока фокусировки (ось Z, где двигатель прикреплен к ручке тонкой фокусировки), а также блок управления-контроллер, который получает команды через Bluetooth и отправляет их на шаговые двигатели. Все это работает в сочетании с мобильным устройством.

Компоненты стадии моторизованного микроскопа

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

Протокол связи

Как интерфейс Bluetooth, мы используемHC-08доска. Модуль BLE работает по умолчанию в режиме текстового терминала, что означает запросы и ответы, просто проходят вперед и назад. Для конфигурации и системных задач (изменение имени, скорость связи) используются в командах.

Сам контроллер запускает прошивку на основе GRBL, используяG-кодкоманды Основные сценарии здесь:

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

GRBL имеет свой собственный набор команд, которые начинаются с$символ, например:

• $H- Домашняя или калибровка и поиск аппаратного нуля через предельные переключатели. Обычно выполняется при начальном запусках, а затем по мере необходимости, если во время движения возникает значительная накопленная ошибка.
• $J=<command>- Режим бега, который имитирует управление джойстиком. Сама команда должна описать относительное движение вдоль всех оси. Пример такой команды:$J=G21G91Y1F10
  • G21- подразделения в миллиметрах
  • G91- относительное позиционирование
  • Y1-Движение вдоль оси Y на 1 миллиметре
  • F10- скорость движения.
• ?- Запрос статуса GRBL. Возвращает строку с ключевыми параметрами машины. Пример ответа:<Alarm|MPos:0.000,0.000,0.000|FS:0,0|Pn:XYZ|WCO:-5.300,0.000,-2.062>

Мы заинтересованы в первых двух параметрах:

• статус Это может быть «холодный», «бег» или «тревога».
• MPos- Текущая позиция сцены.

Я не буду слишком глубоко вдаваться в GRBL и протоколы управления сценическим управлением - это материал для отдельной статьи. Короче говоря: GRBL-это прошивка с открытым исходным кодом из мира ЧПУ, идеально подходящая для управления трех осевыми системами (xy+z) с помощью простых команд G-кода. Мы выбрали самый простой возможный модуль BLE-HC-08-чтобы избежать работы с MFI и IAP. Для нас было важно, чтобы iPhone мог надежно отправлять команды и получать обновления статуса с минимальной задержкой, без значительного увеличения стоимости комплекта.

Задачи

Автофокус

Ранее я упомянул фокусировку. Этот процесс периодически выполняется во время сканирования мазода, потому что образец применяется неравномерно, что особенно заметно при высоких увеличениях. Необходимо контролировать уровень размытия и регулировать фокус во времени. Вот как это работает.

На графике ниже показаны взаимосвязь между уровнем фокуса и временем. Мы начинаем с размытого изображения, постепенно перемещая сцену в оптимальную позицию фокусировки.

Сканирование

Я уже упоминал оцифровку сканирования на мобильной стороне. Здесь стоит отметить, что оцифровка может быть выполнена при разных увеличениях: от 5x до 40x. При более низком уровне масштабирования легче ориентироваться и обнаружить границы мазода, в то время как при более высоких увеличениях становятся видимыми клеточные детали.

В нашем случае мы работаем с двумя уровнями:

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

   

   

2. Сканирование мазода при увеличении 20 -кратного увеличения (или другого уровня). Алгоритм сканирует и сохраняет изображения для последующей сборки в одну карту. Сканирование доходит до линии за пределами границ мазода. Фотография снимается для сшивания, когда:

   1. Изображение в фокусе
   2. Контроллер находится в состоянии холостого хода, то есть не движется

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

Заключение

Этот проект продемонстрировал, что даже смартфон с 2018 года может выполнять задачи, которые ранее требовали настольных компьютеров, серверов и дорогих автоматизированных микроскопов. Конечно, все еще осталось много скусов: от сбора наборов данных до настройки настройки. Если вам интересно, я был бы рад покрыть это отдельно. Не стесняйтесь задавать вопросы, поделиться своим собственным опытом, и, возможно, вместе мы создадим последующее наблюдение или погрузитесь в конкретные аспекты. Спасибо за чтение!

👋 Давайте подключимся!

Ансар

• Электронная почта:ansaril3g@gmail.com
• LinkedIn:Ансар Жали
• Телеграмма: @celly_ai

Амин

• Электронная почта:amin.benarieb@gmail.com
• LinkedIn:Амин Бенариб
• Telegram: @aminbenarieb