運転を台無しにしたバグたち
この記事では、comma.aiのopenpilotシステムで発生したいくつかの面白いバグを紹介します。右寄り、車線の誤認識、カーブでの内側進入、ブレーキ時の画像ぼやけ、高速道路での速度収束不良、訓練時と実行時のパディング不一致などが含まれます。これらのバグを修正することで、運転性能が大幅に向上しました。
ソフトウェアにはバグがつきものであり、通常、悪いソフトウェアはアルゴリズムの選択が悪いのではなく、バグが原因で悪くなります。openpilotも例外ではありません。長年にわたり、私たちはエキサイティングな新しい機械学習技術を導入することで大きな進歩を遂げてきましたが、運転の改善のほとんどは、明白なバグを発見して修正することからもたらされました。この記事では、これまでで最も面白いバグをいくつか紹介します。
右寄り
2017年、commaは成熟した企業ではありませんでした。ユーザーは少なく、ログの品質は低く、トレーニングでは無次元のバリデーション損失以外の指標はなく、クローズドループのシミュレーションテストもありませんでした。その結果、運転中に気づいた明らかな問題以外は、openpilotで何が起こっているのかほとんどわかりませんでした。Slackメッセージからもわかるように、運転モデルがわずかに右寄りになる傾向があることを何ヶ月も認識していましたが、根本原因や満足のいく説明は見つかりませんでした。
年末までに、この偏りの主な原因を突き止めました。モデルは将来の運転軌跡と車線を予測するように訓練されていました。これらのターゲットは、ジャイロ測定や他のセンサーに依存するローカライザーでグランドトゥルースが付けられていました。ジャイロには通常バイアスがあり、使用していたAndroidスタックは、デバイスが静止していることを検出するとバイアスを自動的に補正していました。つまり、openpilotが起動して車が停止しているときはバイアスが適切に補正されていました。しかし、車が動き出すと、openpilotデバイスが発熱してバイアスが変化しましたが、デバイスが再び静止することはなかったため、バイアスは補正されませんでした。バイアスの温度相関はすべてのデバイスで同様であったため、すべてのデータが同じ方向に歪みました。より包括的なローカライザーを導入してバイアスを正確に考慮することで、この問題は修正されました。
車線の誤認識
2019年、明確な車線がある道路で車が車線を逸脱するという謎の苦情が寄せられるようになりました。当時、openpilotはまだ運転判断に車線に依存していたためです。画像が示すように、これらのケースでは、不可解にも車線の中央に車線を検出していました。同様のケースをさらに探したところ、すべての例が明るい日光の状況で発生していることがわかりました。
同じ欠陥を持つトレーニングデータの例をいくつか調べると、問題は明らかになりました。特定の照明条件では、太陽光がボンネットに反射して明るい白い領域が現れ、これがグランドトゥルーススタックで車線マーキングとして検出され、車のすぐ前方にあるため、道路の中央の車線として再構築されていました。車線検出器にこれらの例のより良いグランドトゥルースを追加し、検出器を再トレーニングして、修正を含む新しい運転モデルを訓練しました。
カーブでの内側進入
2020年10月、openpilotがカーブで内側の車線を横切るという苦情がいくつかありました。例を調べたところ、すべて夜間の長い緩やかなカーブで発生しており、運転モデルによるパスと車線の予測がすべてカーブの内側に偏っていました。
グランドトゥルースの調査により、これらのケースではローカライザーが車の動きを誤って計算していることがわかりました。ローカライザーのデバッグにより、ヘッドライトが長く連続した車線に当たると、ビジュアルオドメトリーに問題が生じることが明らかになりました。ORB特徴検出器は、ヘッドライトの照明に基づいてエッジを選択し、それが車両とともに移動します。つまり、ORB検出器が追跡する他の特徴がほとんどないシーンでは、ローカライザーはこれらの誤った特徴のみに依存するため、一貫してカーブの内側に偏ることになります。よりスマートなORB特徴マッチングと外れ値除去によりこの問題は修正され、再トレーニングされたモデルが苦情に対応しました。
ブレーキで画像がぼやける
スマートフォンのカメラは、ボイスコイルアクチュエーターを使用してレンズを動かし、焦点調整を行います。つまり、レンズは焦点位置に剛体で取り付けられているわけではなく、バネで取り付けられており、アクチュエーターで力を加えることで焦点移動が行われます。これはまた、デバイスに急激な加速度がかかると、慣性力によって焦点がずれ、焦点を維持するためにアクチュエーターで補償力を加える必要があることを意味します。
2019年に使用していたOnePlus端末では、この焦点ずれを補償するアルゴリズムがありました。その後、Leeco端末に切り替えましたが、焦点アルゴリズムを再評価することはありませんでした。結果として、この補償アルゴリズムは新しいデバイスで加速中に著しいぼやけを引き起こしており、これらの端末には焦点補償は全く必要ありませんでした。このアルゴリズムは、まさに防ぐべきことを引き起こしていたのです！
高速道路モデルの収束不良
openpilotにエクスペリメンタルモードが導入されたとき、高速道路で適切な速度に断固として加速または減速しませんでした。代わりに、定常状態では、初期化された速度で走行し続けるだけでした。そのため、例えば、誰もいない長い高速道路を時速55マイルで永遠に走り続ける可能性がありました。
openpilotの運転モデルは、運転シミュレーターでオン・ポリシーで訓練されます。シミュレーターへの入力は6自由度の姿勢変化であり、アクション（加速度と曲率）の代わりにこれを使用することで、シミュレーションの物理をより細かく制御できます。モデルがブレーキと加速を学習するためには、シミュレーションに多くのピッチノイズを追加する必要があることに気づきました。
調査の結果、これはピッチと加速度の緊密な結合によるものでした。通常の車両では、加速はピッチ運動を引き起こします。つまり、加速は適切なピッチ変化を伴ってシミュレートされなければなりません。シミュレーターにおけるこのリアリズムの欠如は、そこで訓練される学生モデルに悪用される可能性があります。以下の結果が示すように、シミュレートされた加速中に現実的なピッチ運動をシミュレートすることでこれらのアーティファクトを修正したところ、速度収束テストでモデルの性能が大幅に向上しました。
実行時性能が訓練時と一致しない
このバグは非常に素晴らしいので、4回も書きました。長年にわたり、openpilotはさまざまなカメラとマウント構成をサポートしてきました。その結果、モデルが訓練された画像サイズよりも小さい画像しか利用できない構成がありました。これを機能させるには、モデルの望ましい入力サイズに合わせて画像をパディングする必要がありました。訓練時と実行時のパディングが同じであることが不可欠ですが、推論スタックと訓練スタックは完全に分離されています。長年にわたり、それぞれが頻繁に変更され、互いに一致するようにテストされることはほとんどありませんでした。
以下は、パディングが実行時と訓練時で異なり、出力を劣化させたすべてのバグのバリエーションです：2021年、2024年、2026年（2回）。
振り返って
2017年から多くのことが変わりました。現在のツールとインフラストラクチャーがあれば、これらのバグの多くは本番環境に到達する可能性は低いでしょう。しかし、私たちは今後も多くの愚かなバグを書くでしょう。そして、もしあなたがそれらのバグを修正することに興味があれば、ぜひここで働きに来てください。
——Harald Schäfer、comma.ai CTO