PyTorchとArduino UNOで自作するE2E自動運転ミニカー

このシステムは市販車と同じように役割を分ける。重いAI処理はPC（車載AI SoCの代役）で動かし、マイコン（Arduino UNO、車両制御MCUの代役）がモーターを駆動する。両者の接続は車載CANやEthernetではなく、HC-05モジュール経由のBluetoothだ。コードはPythonファイル4つとArduinoスケッチ1つで構成され、モデルはNVIDIAのPilotNetを縮小したもので、前進・左・右の3つの動作のいずれかを出力する。

記事の大半は著者が遭遇した落とし穴の説明に割かれている。遅延はカメラ、Wi-Fi、推論、Bluetooth、Arduinoの各接続点で積み重なり、見落としやすい原因が2つある。OpenCVが古いフレームをバッファリングすることと、超音波センサーのブロッキング呼び出しpulseIn()だ。デフォルトのタイムアウトのままだと制御ループ全体が止まりうるため、短縮が必要となる。pulseInのタイムアウトは25msに設定されている。著者はまた、データ収集時と走行時で部屋の照明が変わるとモデルの精度が落ちること、学習時のColorJitterが効果的であることも指摘している。

ここで重要なのは、この玩具そのものよりも、それが示すパターンだ。AIの判断を遅延のあるリンク経由で物理的なモーターに伝えると、車が手のひらサイズでも実車サイズでも同じ構造的な難しさが表面化する。著者が掲げる原則は、AIから独立した下位マイコンにフェイルセーフを置くというもので、これはどちらにも当てはまる。これを再現する人にとって鍵となるのは、収集した走行データの品質とバランスだろう。モデルは高い精度を示しながら、カーブを曲がれないことがあるからだ。記事によれば部品代は数千円だという。