導入 この記事では、AIベースの血液細胞認識を搭載したロボット顕微鏡のためのiOSアプリケーションを開発する私の経験を共有したい - それがどのように構築されたか、私たちが取り組まなければならなかった課題、私たちが直面した落とし穴、そしてiPhoneがどのようにラボツールとして使用できるか。 これは、認証またはセルフィーにフィルターを適用するためのアプリケーションを持つもう一つのタスクリストではありません - ここでの焦点は、顕微鏡の眼鏡からビデオストリーム、ニューラルネットワーク、ハードウェア相互作用、Bluetooth制御スライドの動き、そしてこれらすべてがiPhone上で直接実行されています。 A Few Words About the Product 現代の血液分析装置でさえ、顕微鏡の下で手動検査を必要とするサンプルの15%は、特に血液に異常が見つかった場合に必要です。自動顕微鏡システムは存在しますが、飛行機の翼と同じくらい費用がかかりますので、ほとんどの研究室は手動で血液の塗料を検査し続けています。我々はそれを異なります:我々のソリューションは標準の実験室顕微鏡を自動スライド供給および画像キャプチャを搭載したデジタルスキャナーに変換します。 and the team in . アンダルト3 セルビア キットは標準の実験室顕微鏡に接続し、デジタルスキャナーに変換します。 iPhone - システム制御、セル分析 レンズアダプター - スマートフォンを顕微鏡の眼鏡に接続する ロボットステージ - スライドの動き、焦点制御、サンプル間の切り替えを可能にします。 ソフトウェア側では、システムは: iPhone でのモバイルアプリケーション ステージ上のコントローラー Web ポータル / Cloud モバイルアプリケーションは以下のタスクを実行します。 カメラからの画像ストリームを処理し、細胞を検出、分類し、数える これらをウェブサーバーに送信し、その他の分析アーティファクトと共に ロボットステージの動きを制御し、事前に定義されたアルゴリズムに従ってスプレースキャンを実行する また、構成および分析の開始、カメラパラメータの調整、簡潔な分析レポートの閲覧、その他の関連タスクの責任を負います。 ウェブポータルは、結果を見るために、医師の分析の確認、報告の輸出を目的としています。 すべてがどのように共に働いているかを示す: 動画 A Bit of Context About Hematological Diagnostics 血液検査(血液検査)は、血液検査(血液検査)で、血液検査(血液検査)は、血液検査(血液検査)で、血液検査(血液検査)で、血液検査(血液検査)で、血液検査(血液検査)で、血液検査(血液検査)で、血液検査(血液検査)を行っています。 ) : 源泉 CBCを実行する際、血液サンプルは血液分析器を通じて処理されます。デバイスが正常値からの偏差を示す場合、サンプルは顕微鏡検査を受けます。 このプロセスは次のように見えます。 実験室の技術者は、ガラスのスライドに一滴の血を置く。 ロマノフスキーの方法(あるいは類似の代替方法)を用いて、それを修正し、 そして、顕微鏡の下で準備された塗料を視覚的に調べます。 それはまさにこの段階で、あなたがすることができます: abnormal cell morphologies (such as immature neutrophils, atypical lymphocytes, blast cells) を検出する。 成熟度、サイズ、粒状、含有量およびその他のパラメータを評価する。 時には、PCR2またはELISA3のデータを取得する前に初期診断をすることもあります。 But manual analysis is painful: 非常に主観的で、 技術者の経験により、 人間は疲れや過ちに苦しみ、 うまくスケールしない。 自動顕微鏡システムは優秀ですが、高価(6万ドル以上から始まります)なので、実験室の90%以上が手動の方法に依存しています。 私たちは、実験室で広く展開できる手頃なマイクロスコープ自動化キット(数十万ルーブル以内)を作成することを目標にしました。 [1] - スライド上の血液サンプルは、ドミトリー・レオニドビッチ・ロマノフスキー(Dmitry Leonidovich Romanowsky, 1861–1921)によって開発された特別な斑点で処理されています。 [2] - PCR(ポリメラゼチェーン反応)は、感染症の診断に不可欠なウイルスやバクテリアなどの非常に小さな量の遺伝材料を検出することを可能にします。 ELISA(Enzyme-Linked Immunosorbent Assay)は、特定のタンパク質の存在を検出するために重要な場合に使用されます。 What the iPhone Is Capable Of 「スマートフォン上のAI」について話すと、ほとんどの人はカメラフィルター、テキスト自動補充、またはチャットボットのようなものを想像しますが、現代のiPhoneは、真剣なタスクを実行できる専用のニューラルモジュールを持つミニコンピュータです - 私たちの場合、リアルタイムの血液細胞分析です。 グラフィック処理ユニット(GPU) 画像操作に使用される:プレプロセッサ、フィルタリング、訂正. たとえば:バブル評価、カラー訂正、アーティファクト除去、およびグラフィックおよび画像分析に関連する他の特定のタスク。 Appleは、A11チップ(iPhone 8/X)から始めて、A12(iPhone XRおよびそれ以降)から、NPU(TOPS)で1秒あたり5兆件を超える操作を実行する可能性があります。 書く時点で、最新のA17 ProおよびA18/A18 Proチップは35TOPSの能力を持っています。 これは、細胞検出と分類、サンプルの背景評価、および同様のタスクのためのモデルの推定に使用されます。 Central Processing Unit (CPU) 全体的な論理、コントロール、構成処理、序列化/deserialization、APIとファイルシステムで作業する - 基本的に前2つのコンポーネントに含まれないすべてのもの。 iPhone XR (A12 Bionic, 2018) をベースラインとして使用して、これがすでに古いデバイスであるにもかかわらず、これについて話し合うつもりです。 顕微鏡カメラから50fpsのビデオストリームを処理し、 同時に CoreML 推定を実行する(フレームあたり ~ 15ms) 同時にデータをディスクに保存し、クラウドと同期し、 温度を許容可能な範囲内で保つ(ドロトリングとタスク優先順位が慎重に設定されている場合)。 それにもかかわらず、デバイスは顕著に加熱し、減速し始める可能性があります. たとえば、マラリアの塗料の分析中に、1つのフレームで100個以上の細胞を処理する必要がある場合、第二または第三の塗料の時点で熱ガルトリングが始まります - CPU 周波数が低下し、インターフェースの遅延や遅延が現れます。 下のスクリーンショットは、マラリアではなく、別の分析を示していますが、ここで重要なのは、どのくらいの検出がフレームごとに引き起こされるかです。 一般的に、iOSでは、システムの熱状態をモニタリングすることができます。 私たちの生産環境では、Critical レベルに達したことはありませんが、Serious レベルは非常に高い負荷の下で定期的に発生します。 ProcessInfo.processInfo.thermalStateについて 以下は、ドキュメンタリーからの説明を含む thermalState 値の表です。 Thermal State Recommendations System Actions Nominal No corrective action required. — Fair Temperature is slightly elevated. Applications may proactively begin power-saving measures. Photo analysis is paused. Serious System performance is reduced. Applications should decrease usage of the CPU, GPU, and I/O operations. ARKit and FaceTime lower the frame rate (FPS). iCloud backup restoration is paused. Critical Applications should reduce CPU, GPU, and I/O usage and stop using peripheral devices (e.g., the camera). ARKit and FaceTime significantly lower the frame rate (FPS). ノミネート 修正措置は必要ありません。 — フェア 温度はわずかに上昇し、アプリケーションは積極的に電力節約措置を開始することがあります。 写真分析は中断。 真剣 アプリケーションは、CPU、GPU、I/O 操作の使用量を減らす必要があります。 ARKit と FaceTime はフレームレート (FPS) を低下させます. iCloud バックアップの復元が中断されます。 批判 アプリケーションは、CPU、GPU、I/Oの使用を削減し、外部デバイス(例えばカメラ)の使用を停止する必要があります。 ARKitとFaceTimeは、フレームレート(FPS)を大幅に低下させます。 完全な熱および電力分析は別々の記事に値する - 私が最初に述べたように、私はここであまり深く行きたくありません。 ということは、大体、仮定できるのは、 状態は、チップレベルで80～90°C、表面で約40°Cに相当します。 Publicly Available ソース Serious iPhone はすべてのものと共に機能します。 デバイス. 他のデバイスには別々のフローがあり、デバイスには (Made for iPhone) 認証、iAP2 (Apple Accessory Protocol) を介して動作します。 Bluetooth 低エネルギー MFI ここでは、プロトコルの基本的な役割と構造を思い出させるのに役立ちます。 通常、外部はデータを送信するか、接続を待つ(例:時計、熱計、心拍モニター)。 Central は、外部に接続するデバイスで、接続を開始し、コマンドを送信し、データを受信します。 GATT(Generic Attribute Profile) — BLEデバイスがデータを交換する構造. GATTは、どのような「フィールド」が利用可能で、何が読み取れるか、何が書かれるか、または通知にサブスクリプトできるかを定義する。 サービスと特性 — BLE 接続内のデータは、サービス(論理的グループ)と特性(特定のパラメータ)に構成されています。例えば、フィットネス トラッカーには、心拍数測定特性(現在の心拍数)を含む心拍数サービスがあります。 私たちのケースでは、iPhoneは、カスタマイズされたGATTサービスを持つエピフェラとして認識される内蔵のBLEモジュールを通じてステージを制御し、2つのタスクを実行します。 動作コマンドをXY軸のコントローラに送信し、Z軸のフォーカスコントロールを 管理者からのデータの受信(状態、位置) 熱負荷について話すと、BLE接続は顕著に貢献すべきではありません。 コマンドを送信するか、または20Hzの周波数(50msの間隔)でステータスを受信する。 BLEの消費電力について iPhone XRの典型的なエネルギー消費量は約50～100mWで、1mW未満の増加は、特にニューラルネットワーク処理、GPU使用、およびディスプレイに比べるとほとんど無意味です。 ラジオチャンネルは時間の約2パーセントしか活発で、残りの時間は眠っている。 BLEモジュールとコントローラとのアプリの作業の詳細については、「Motorized Stage で作業」セクションで詳しく説明します。 私たちは、主な(広い角度の)背面カメラを使用します:私たちは、1280×720の解像度と約40 MbpsのビットレートでH.264ビデオをキャプチャします。 The higher the bitrate, the more data per unit of time → the higher the image quality. 40 Mbps is quite high for a resolution of 1280×720 (HD). It’s more than sufficient for cell analysis imaging. H.264 は AVC - Advanced Video Coding または MPEG-4 Part 10 とも呼ばれる国際的なビデオエンコーディング規格で、過剰なデータ(フレーム間およびフレーム内での圧縮)を排除し、ビットレートおよび結果としてファイルサイズを減らします。 したがって、私たちは単にモバイルUIクライアントではなく、完全なエッジデバイス、すなわちサーバーへの常時接続なしで、ローカルにデータを処理するデバイスである。 Mobile アプリケーション ハードウェア部分をカバーした今では、このすべてがアプリケーションレベルでどのように機能するかを見てみましょう。 入力時に、アプリケーションはカメラからフレームのストリームを受け取ります - 顕微鏡の視野が塗料を横切る。 At the , the application must: output detect leukocytes (and other cells depending on the analysis) display detected objects with bounding boxes (BBoxes) perform cell counting send data in the background to the backend (images of cells, the scan, individual frames) 上記の図で示されているように、すべてがカメラフレームの周りを回っています - 検出、スライドのナビゲーション、およびクラウドに送信する必要があるアーティファクトの決定はすべてそれに依存します。 これには、歪みの訂正、アーティファクトの除去、バラバラレベル評価、および光と色の訂正が含まれます。 1) Preprocess the frames たとえば、各実験室または顕微鏡には特定の照明条件があり、神経ネットワークが機能不全を引き起こす可能性があります。ここでは、ホワイトバランスの正常化を実行する必要があります - 視野を空の領域に指向し、カメラのホワイトバランスの調整を開始することによって。 また、カメラの設定が適用される前に検出が並行して開始されたため、色のカリブレーションなしで細胞をポータルに送信したというバグも発生しました。 そして 複製なしの細胞 2) Detect, classify, count たとえば、下の写真では、古い分析の1つでいくつかの複製が赤に表示されています。 スライドを正しく移動し、スライドから別のスライドに移行し、最も重要なことは、スライドに正確に焦点を当て、スライドの境界を超えたり、空の領域に着陸した場合を検出することです。 3) Control the microscope 次回の分析の処理をブロックすることなく、細胞のバッチをクラウドに(スナップショット、メタデータ)送信します。 4) Upload このプロセス n 回、分析はバッチで行われる。 5) Repeat そして、これらすべてを携帯電話を過熱することなく実行します。 6) アプリケーションは典型的なスタートアップファッションで進化した:コンセプトの証明がすぐに組み合わされ、研究室でのパイロットや投資家へのピッチャーに適したMVP(Minimum Viable Product)に改良された結果、アプリケーションのアーキテクチャはハイブリッドになった:一部のスクリーンはUIKitベースのMVP(Model-View-Presenter)スクリーンを使用して実装され、新しい機能やインターフェイスはSwiftでMVVM(Model-View-ViewModel)で書かれている。 私たちは、ビジネス論理を分離するためにサービス層を使用します。 で、 で、 すべての依存性は、構造体またはDIコンテナを通じて注入されます。イベントサブスクリプションを持つ反応性と非同期チェーンに関しては、「進化の道」がありました:最初はRxSwiftを採用し、その後、Combineに移行し始め、async/awaitの登場と共に、チェーンの一部がそこに移動しました。結果は「フランケンシュタイン」の一種でしたが、後でこれらのコンポーネントを別々のモジュールに分離しましたので、将来、新しいテクノロジーステックのためのコンポーネントを単に交換することができます。 アプリケーション全体は詳細なログと交わり、そして複雑なケース(特にフレーム処理に関連するケース)のために、NSLoggerを使用します:それはテキストだけでなく、 CameraService BluetoothController AnalysisService テストについての記事は、分析の個々の部分を嘲笑し、望ましい状態を迅速に設定することから、テストについて書くことができます。 (ちなみに、私にはA 分析の個々のステップをシミュレートし、統合およびユニットテストですべてをカバーする。 ProcessInfo 小さな技術メモ しかし、フレーム処理に戻り、上記よりも少し詳細な建築図を見てみましょう。 分析コントローラ - 意思決定センター:フレームパイプラインでフレームを受け取り処理を開始します。 Camera Service - カメラから原色フレームストリームを受け取り、それを変換し、それを前進させます。 Microscope Controller - 顕微鏡のコントローラを制御します。 — a chain consisting of several stages: Frame Pipeline — correction, filtering Preprocessing — object/cell detection Detection — counting unique objects Counting — final filtering and preparation for visualization Postprocessing UI - リアルタイムでユーザーに結果を表示する責任(境界ボックス、統計、警告) Uploader — synchronizes analysis artifacts (snapshots, cells, config) with the backend. Uploader — 分析アーティファクト(スナップショット、セル、config)をバックエンドと同期します。 依存症マネージャーに関しては、当初はCocoaPods(入力したもの)を使用しました。 2024年以降)にSPM(Swift Package Manager)を導入したが、いくつかのサービス(Computer Vision、Bluetooth、ユーティリティ)がSPMモジュールに移行された。ObjC/C++コードを個々のxcframeworksに分離しようとする試みもあったが、すべてを整理するのに十分な時間はなかったので、主なプロジェクトにそのコードを残した。ObjCはC++の周囲を包装するために必要だったので、Swiftから呼ばれることができた。これはObjC++クラスにつながった:そのインターフェイスは純粋にObjCであり、Swiftはそれらと相互作用することを可能にし、実装はObjCとC++コードを混合する。 . maintenance mode and stopped active development Swift が C++ への直接通話をサポート 私はC++とコンピュータビジョンアルゴリズムのグゥーラとは程遠いが、私の責任は、私たちのほとんどのR&Dが行われたPythonからアルゴリズムやエウリスティクスを基本的に理解し、ポートすることにあった。 タスク 歪みの除去 アダプタの1つは、画像に光学的歪曲のアーティファクトを表示した結果、丸く表示されるべきセルは、特にフレームの端に向かって長くまたは歪んだように見えます。 フレームのジオメトリーを復元するには: OpenCV の cv::undistort() We calibrate the camera — capturing images of a chessboard/grid with known geometry. OpenCV computes: the camera matrix K (projection parameters) distortion coefficients D = [k1, k2, p1, p2, k3, …] We apply cv::undistort() or cv::initUndistortRectifyMap() + remap(): this computes where each point “should have landed” in reality the image is “straightened” back to correct geometry 後で、アダプターを交換しました - このステップは削除されました。 Determining Position on the Slide スライド上の位置の決定 細胞を正確に数えるためには、できるだけ正確にその座標を知ることが重要です。 ここでは、変更決定が間違った場合に何が起こるかを見ることができます。 動画 最初は、2 つのフレーム間の相対的な転換を計算し、絶対的な転換を合計してみました。 Fast Fourier Transform に基づく段階相関を介して古典的な画像登録方法で、OpenCV でこれを実装し、Apple Accelerate も使用しました。 現地キーポイントに基づく方法:SURF、SIFT、ORB、その他。 OPTIC FLOW Apple Vision のインストール VNTranslationalImageRegistrationRequest 一方で、私たちはいくつかの仮定を持っていました: スケールやローテーションは存在しなかった。 optically: a clean, unblurred smear, without empty areas. 光学的に:クリーンで不明瞭な塗料、空の領域なし それにもかかわらず、照明の変化、焦点、蓄積されたエラー、突然の転換、騒音、または画像のアーティファクトの原因で問題が発生しました。 これにより、以下のような比較テーブルが作成されました。 以下は、提供されたテーブルとテキストの正確な翻訳です。 Method Advantages Disadvantages Usage Notes Speed Comment FFT + cross-correlation (OpenCV, Accelerate) Very fast, global shift detection, simple to implement Accumulates error, not robust to abrupt shifts Requires images of identical size, suitable for “pure” shifts Very high Used as the primary method SIFT High accuracy, scale/rotation invariant Slow, used to be non-free Excellent for diverse scenes with texture and complex transformations Slow Experimental option SURF Faster than SIFT, also scale/rotation invariant Proprietary, not always available Slightly better suited for real-time but still “heavy” Medium Experimental option, especially since under patent ORB Fast, free, rotation invariant Sensitive to lighting, not robust to scale changes Works fairly well for image stitching High Before we moved stitching to the cloud, we had versions using this Optical Flow (Lucas-Kanade) Tracks movement of points between frames, good for video Doesn’t handle global transformations, sensitive to lighting Best in videos or sequences with minimal movement Medium We experimented with this for digitization (stitching) of images Optical Flow (Farneback) Dense motion map, applicable to the whole image Slow, sensitive to noise Good for analyzing local motions within a frame Slow We experimented with this for digitization (stitching) of images Apple Vision (VNTranslationalImageRegistrationRequest) Very convenient API, fast, hardware-optimized In our case, accuracy was poor Perfect for simple use cases on iOS/macOS Very high We tried it and abandoned it FFT + cross-correlation (OpenCV, Accelerate) 非常に速く、グローバルな変更検出、実装しやすい Accumulates error, not robust to abrupt shifts. 急激な転換に強力ではありません。 同じサイズの画像が必要で、「純粋な」シフトに適しています。 Very high 主な方法として使用 SIFT 高精度、スケール/回転不変 Slow, used to be non-free. ゆっくり、かつては自由でなかった。 テクスチャーと複雑な変形の多様なシーンに最適 ゆっくり 実験選択 SURF SIFTより速く、またスケール/回転不変 所有者: Not Always Available リアルタイムに適しているが、まだ「重い」 メディア 実験的な選択肢、特に特許の下で ORB 速く、自由に、回転不変 照明に敏感で、スケール変動に強くない 画像シッチングのためにかなり良く機能します。 高い 私たちが雲にシッチを移す前に、私たちはこれを使用するバージョンを持っていました。 Optical Flow (Lucas-Kanade) フレーム間の点の動きを追跡し、ビデオに良い グローバルな変革を処理しない、照明に敏感 最小限の動きを持つビデオやシーケンスで最適 メディア 私たちは、画像のデジタル化(シッチング)のためにこれを実験しました。 Optical Flow (Farneback) 全画像に適用可能な密集したモーションマップ ゆっくり、騒音に敏感 フレーム内の地元の動きを分析するのに適しています。 ゆっくり We experimented with this for digitization (stitching) of images Apple Vision (VNTranslationalImageRegistrationRequest) 非常に便利なAPI、高速、ハードウェア最適化 私の場合、正確性は貧弱でした。 iOS/macOS でのシンプルな使用ケースに最適 とても高い 我々はそれを試み、それを捨てた。 それぞれのオプションでは、参考変数と比較するための精度とパフォーマンスの面で最適な構成を見つけようとしました:私たちは画像の解像度、アルゴリズムパラメータ、カメラと顕微鏡の異なる光学設定を変更しました。 And here’s what the debugging process looked like for detecting keypoints, which we later intended to use for calculating the shift. その結果、ロボットステージが当社のシステムに導入されると、コントローラからの座標を使用し、その後CVエウリスティクスを使用して精製しました。 細胞数 基本的に、セル数の課題は、オブジェクト追跡とデドプライクションの特定のケースです:「セルが何であるかを識別し、それを2回数えるのを避け、過度の数えを避け、必要なセルを逃さないでください - 一秒の割合で、カメラを介してリアルタイムで、電話のハードウェアで実行しています。 Object Detection. We use neural networks to detect objects in the frame (Bounding Box, BB). Each BB has its own confidence score (network confidence) and cell class. 私たちは、フレーム内のオブジェクト(Bounding Box, BB)を検出するためにニューラルネットワークを使用しています。 背景騒音と偽ポジティブに対処するために、我々は速いフィルタリングを適用します: たとえば、左側に赤いハイライトが赤血球を表していますが、神経ネットワークは最初にそれを白血球と分類しました。 しかし、カラーフィルターはその後登場し、フィルターを外しました。 A red highlight marks an erythrocyte discarded by the filters. geometric: we discard objects whose sizes fall outside typical cell dimensions. we also discard cells that partially extend beyond the frame edges — those are of no interest to us Counting unique objects. Some BBs may be counted more than once for the same cell, so it’s important to detect such cases and count them only once. At one point, we were inspired by a guide from MTurk that describes two options: Option 1: Compare the distances between BB centers — if a new BB is too close to one already recorded, it’s likely “the same” cell. Option 2: Calculate IoU (intersection over union, Jaccard Index) — the metric for overlap between rectangles. If a new BB overlaps significantly with an existing one, we count it only once. 一般的には、フレーム間のオブジェクトトラッキングを維持する必要があります、特に以前スキャンされたスプレーの領域を再度閲覧する場合です. Here again, it is critically important to accurately determine the position on the slide — otherwise, the entire count goes down the drain. スプレーの位置を正確に決めることは非常に重要です。 デジタル化 課題の1つは、スキャンをデジタル化し、本質的にソフトウェアベースのヒストロジー・スキャナーを作成することでした。下の写真は、それがどのように見えるかを示しています:矢印はスキャンを構築するために使用された動きを示し、そこで私たちはフレームをキャプチャし、それらを1つの大きな画像にまとめます。 スムーズを通して視野のフィールドの動き ここで再び、正確な位置決定は非常に重要であり、それに続いてシームレスなシッチングが行われました。 最初、我々はエンジンステージを持たず、手動のナビゲーションに頼っていたことに注意すべきである。何百もの断片からモザイクを組み合わせようとしていると想像してください。 ここでは、最初の実験がどう見えたか:視野のジャンプフィールド、シーム、照明の違い、空のスペース。 左 - 不均衡な明るさと曝露のマップ、そこで「シーム」はフレームの交差点で見ることができます。 または、たとえば、ユーザーがスプレーをスキャンし、それを迅速に移動します - いくつかの領域はバラバラになります(Motion Blur)。 Blurred frames overlayed on the scan during abrupt movement. 突然の動きの際にスキャンに覆われた混乱したフレーム 徐々に、以下のアプローチへと進みました。 さまざまなフレーム解像度およびカメラ構成で、さまざまな方法を使用して、デバイスにシッチング、さまざまな方法を用いて、スキャンがクラウドに組み立てられ、モバイルデバイスがカリブレートホワイトバランスと曝露を有するフレームを送信するソリューションに最終的に到達しました。 以下は、構成に応じて個々のフレーム処理コンポーネントの処理速度を測定する方法の例です:カメラ設定、選択したアルゴリズム、およびそのパラメータ。 モーターサイドステージで働く 現在、iPhoneとエンジンステージの接続についての詳細は、BLEを通じてどのようにコミュニケーションするか、どのようなコマンドを送信するか、および自動焦点をどのように設定するかです。モバイルデバイスは、ステージ上のコントローラにBluetoothを介して接続し、XYZ座標に沿って移動します。より正確に言えば、ステージ自体が移動しますが、モバイルデバイスがレンズレンズを通して見た画像の視点から、移動がスライド上に起こっているように見えます。 私たちのステージはカスタマイズされたものではなく、「すべてを自分で作りたい」からではなく、商業的なソリューションは1万ドルで始まりますが、それは冗談ではありません。私たちはデザイン局を雇い、約800ドルで独自のバージョンを建てました。それは、エンジニアの1人が、エンジニア化された顕微鏡のステージが疑わしく3Dプリンターに似ていることに気づいたため、大幅に安くなりました。同じXYZの動態、同じステップエンジン、同じレールです。結果として、私たちは大量生産され、安価なコンポーネントを使用していますが、私たちの特定の要件に適合しています。構造的には、ステージは3つの部分から構成されています:XYプラットフォーム自体、焦点ブロック(Z- Motorized Microscope Stageのコンポーネント 手動ステージの動きのために、私たちは仮想ジョイスティック(画面上のユーザーに動きボタンを表示)を使用します - これは校正およびシステム設定シナリオで使用されます。 Communication Protocol 通信プロトコル Bluetooth インターフェイスとして、私たちは BLE モジュールは、テキスト端末モードでデフォルトで動作するため、リクエストと応答は単に前進して前進するだけで、構成やシステムタスク(名前変更、通信速度)では AT コマンドが使用されます。 HC08 コントローラ自体は、GRBLに基づいてファームウェアを実行し、 主なシナリオは、以下です。 Gコード 接続を初期化する(電話がステージが接続されていることを検出する必要があります) スライドをスキャンする(すべての軸に沿ってステージを移動する) 停止/再起動スキャン 例外的な状況を処理する: 制限スイッチに到達し、動きを中断し、コマンドバッファオーバーフローがあります。 GRBLは、最初のコマンドから始まる独自のコマンドセットを持っています。 例えば、シンボル: $ $H - homing or calibration and seeking the hardware zero via limit switches. Usually performed at initial startup and later as needed if significant accumulated error occurs during movement. ハードウェアゼロをリミットスイッチを通じて検索する。 — Jogging mode, which simulates joystick control. The command itself should describe relative movement along all axes. An example of such a command: $J=<command> $J=G21G91Y1F10 — units in millimeters G21 — relative positioning G91 — movement along the Y-axis by 1 millimeter Y1 — movement speed. F10 トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > 私たちは最初の2つのパラメータに興味があります: それは「Idle」、「Running」または「Alarm」かもしれません。 MPos - ステージの現在の位置。 要するに、GRBLはCNCの世界のオープンソースファームウェアであり、単純なGコードコマンドを通じて3軸システム(XY+Z)を制御するのに最適です。 タスク 自動フォーカス 以前、私は焦点化について言及しました。このプロセスは、サンプルが不均衡に適用されるため、塗料スキャン中に定期的に実行されます、これは特に高い拡大時に顕著です。バブルレベルを監視し、焦点を時間に調整する必要があります。 下のグラフは、焦点レベルと時間の関係を示します. We start with a blurred image, gradually moving the stage to the optimal focus position. 焦点レベルと時間の関係を示します。 スキャン 私はすでに、モバイル側のスキャンをデジタル化することをすでに言及しました。ここでは、デジタル化は異なる拡大で行うことができます: 5x から 40x. より低いズームレベルでは、マッチの境界線を移動し、検出しやすくなりますが、より高い拡大では、細胞細部が目に見えるようになります。 私たちのケースでは、2つのレベルで働きます: Boundary detection at 4x magnification. The algorithm scans the entire slide, determines the smear area, and generates a boundary map for the next stage. The output is something like a heat map. For example, from the low-magnification image on the left, we obtain a matrix that we then use to plan the steps for navigating at higher magnification: Scanning the smear at 20x magnification (or another level). The algorithm scans and saves images for subsequent assembly into a single map. Scanning proceeds line by line, within the boundaries of the smear. A photo is captured for stitching when: the image is in focus the controller is in an idle state, i.e., not moving ユーザーが毎回オブジェクトを切り替える必要がないように、当社はバッチ内のすべてのスライドを同時に境界検出およびスキャンし、以前のバッチを平行にクラウドにアップロードします。 結論 このプロジェクトは、2018年のスマートフォンでさえ、これまでデスクトップ、サーバー、高価な自動顕微鏡を必要としていたタスクを処理することができることを示しました。もちろん、データセットの収集から精巧な曝露設定に至るまで、まだまだ多くのことが残っています。もしあなたが興味があるなら、私はそれらを別々にカバーすることを喜んでいます。ご質問をし、ご自身の経験を共有し、おそらく一緒にフォローアップを作成したり、特定の側面に深く浸透したりします。 コネクタしよう! アンサー メッセージ:Ansaril3g@gmail.com リンク:Ansar Zhalyal テレグラム: @celly_ai アミン トップページ > トップページ > トップページ > トップページ アミン・ベナリブ Amin Benarieb メッセージ: @aminbenarieb
