デトロイトのオートショーについて少し読んで、レーン出発警告がますます一般的になっているという事実について、ウェブカメラ、Python、OpenCV、および数日間のハードワークの形の単純なコンポーネントからこのシステムのプロトタイプを作成した経験を共有することを決めました瞑想:)
プロトタイプの作成の歴史を読んで、カットの下で見ることができます...（写真がたくさんあります...）
まえがき
すべては、「オートエレクトロニクス」と「画像処理」の2つのコースの最終プロジェクトを選択しなければならなかったという事実から始まりました。 怠け者として、私は両方のプロジェクトを横断せざるを得ず、時間を節約することができませんでしたし、いくつかの講義ではレーン出発警告について伝えられただけでした（正直なところ、私はまだ十分なロシア語を知りません。このシステムの短縮名なので、略語（LDW）を使用します）、そのようなことを自分でやりたいと思いました。
一般的な情報
それで、これは「車線逸脱警告」という名前の獣です。 そもそも、運転中、車はほとんどの場合車線にあり、車を離れるべきではありませんが、実際には、運転手は運転から気をそらされ、車は隣接する車線に移動し始める可能性があり、これは特に悲惨な結果につながる可能性があります対向車線に移動します。 National Highway Traffic Safety Administration（NHTSA）の統計によると、米国の高速道路でのすべての事故の40〜60％は、車が車線を離れるという事実に直接または間接的に関係しています。 これを防ぐために、人々は車線の車の位置を追跡し、車が車線を離れ始めた場合、ドライバーに信号を送るか、より積極的な行動を取ります：車が車線を離れないように、ハンドルを回すか、反対側の車輪にブレーキをかけます。 実際、そのようなシステムは完全に新しいものではありません;日本人は約10年前にいくつかのモデルでそれらを実験し始めました。 さらに、さまざまな企業が実装にまったく異なるアプローチを使用しました。前方または後方を見る通常のカメラと、下方を見下ろす赤外線カメラです。
実装
そのため、タスクは、高速道路での車の位置を特定し、ストリップを離れる場合に、ドライバーに最小限の変更を加えてドライバーに信号を送ることです。 私の場合、システムの基本は、GPSレシーバーからマウントに電気テープでねじ込まれ、バックミラーの近くのフロントガラスと膝の上にあるラップトップに設置されたWebカメラでした。
ビデオストリームを処理するために、OpenCVライブラリが伝統的に選択され、Pythonアルゴリズムを実装していました。
Pythonについて少し
ここでは、Pythonについて少し叙情的な広告の余談をします。 たまたまプロにたくさん書いたし、他にもたくさん書いたが、Pythonは私に出会ったことがなく、とても遅いと心から信じていた。 ビデオをリアルタイムで処理し、一定量のあらゆる種類の計算を行うことがすぐに必要でした。 しかし、少し先を行くと、印象はポジティブだったと言えます：書くのはとても簡単です（実際、私はPythonの勉強の2日目にこのプロジェクトを書き始めました）、彼はなんとかビデオを処理することができました（NumPyのようなライブラリを使わずに、データ配列とOpenCVを迅速に処理できます）、もう少し先を見ると、現在、私の研究プロジェクトの一部を書き換えており、OpenGLを使用すると300 fpsを取得します。 これについては、Pythonの広告は完全なものと見なすことができ、プロトタイプに使用できます。後悔することはありません。
最初の試み-カラーモデル
だから、私は背景からストリップを分離する試みから始めました。 最初に、最も単純なアプローチを試みました。分割ストリップのある種のカラーモデルを作成するには、各ピクセルからモデルまでのユークリッド距離を取得し、所定のしきい値を適用します。 一般に、このアイデアには意味がないわけではなく、かなり良い結果が得られます。
しかし、道路に影が現れるまで、そしてそれは非常に頻繁に現れます。 次に、次のようになります。
全体的には悪くはありませんが、カメラが定期的に露出を調整し（何らかの理由で手動で管理することができませんでした）、フレームの明るさを非常に深刻に変更します。 次のようになります（図では、明るさが大きく異なる2つの連続したフレームがあります）。
この問題を取り除くために、HSV色空間で作業するというアイデアが浮かびました。そこでは、色は特に輝度に依存しないため、シャドウと自動露出は影響しないと言われています。 一方で、アイデアは非常に合理的ですが、極端な輝度値では、トーンチャンネルに非常に多くのノイズが現れます。 その結果、次のようになります。
一般に、私はあらゆる状況で背景からストライプを分離しようとする試みに苦しみ、このアイデアはあまり良くないことに気づきました。 そして、私は多くの異なるフィルターとビデオ処理方法を使用しようとしましたが、モニターにはあらゆる種類のウィンドウが散らばっていて、次のような結果が得られました：
そのため、近くにさらに2台のモニターがあります:)
2回目の試行-仮想センサー
最初の試みが失敗した後、これは機能しないことに気付きましたが、基本的にどこかで完成したアルゴリズムを見たくありませんでした。 確かに、Googleの問題の最初のページの1つの写真を少しだましてスパイしたことがあります。
この写真から、柱のストリップ全体ではなく、選択された水平エリアのセクションを追跡しようとするいくつかの「仮想センサー」を使用するというアイデアが生まれました。
ここで、画像内の赤い横縞は、これらのセンサーの作業領域を示しています。 これらはすべて独立して機能するため、結果を相互にフィルタリングできます。 つまり ストリップが左側にあり、右側に1つあることを全員が示している場合、このセンサーがストリップがあることを100％確信していても、その結果は破棄されます。
各センサーは十分にスマートで、分割ストリップのモデルが含まれており、作業領域で検出しようとします。 実際には、このモデルは2つのプロパティを使用します：すでに慣れ親しんでいる色で、うまく機能しますが、必ずしもストリップの幅ではありません（ここでは、カメラが車内に異なって配置される可能性があるため、遠近法の歪みのために、すべてが単純ではありません） 、帯域幅を設定できないため、プログラムの最初の段階でセンサーが学習します）。 したがって、各フレームに対して、次のアルゴリズムが使用されます。
0）最初に、道路が見えるエリアにのみ画像をトリミングします。 これにより、パフォーマンスを向上させ、アルゴリズムをフードと空の反射と混同しないようにすることができます。
1）次に、画像全体にCannyを適用します。 これにより、自動露出や時々影を忘れることができます。
2）次に、各センサーについて：
2.1）すべての閉じた領域（両側が境界線で囲まれた領域）を探しています
2.2）幅がストリップの幅に等しい領域を探しています
2.3）そのような領域が複数ある場合（影などの問題により）、領域の平均色と分割ストリップのカラーモデルからの距離を考慮し、最も類似した領域を選択します。
各センサーの結果は次のとおりです（黒-分割ストリップ、白-道路）：
分割ストリップモデル
したがって、各センサーからのデータがあり、次のステップは分割ストリップの位置を決定することです。これを行うには、何らかの種類のモデルが必要です。 私はあまり哲学をしないことに決め、車の近くの分割ストリップを単に直線のセグメントとして想像しました。 確かにそれはまったく簡単ではないと言うことができますが、私は2次曲線を少し実験しましたが、大きな違いがないことに気付き、この悪い仕事を投げました。 その結果、私の分割ストライプは地平線上で時々交差しますが、それは怖くありません。 センサーからのすべてのデータを考慮するために、最小二乗法を使用します。これは、仮想センサーが分割ストリップと見なすすべてのセグメントの中央の入力を受け取ります。 最終的には、次のようになります。
カーポジショニング
分割レーンがどこにあるかを確認したら、車がレーンのどこにあるかを判断します。 それからかなり簡単な方法を思いつきました：ボンネットに近い水平線を取り、その上にいくつかのゾーンをマークし、この直線と分割線の交点を見つけ、これらの点を使用してストリップ内の車の位置を決定します。 交差点がどのゾーンにあるかに応じて、機械が分割ストリップにどれだけ近いかを知ることができ、そのような単純な方法でも非常に正確に判明します。 私は3つのゾーンを使用しています。緑-すべてが正常で、車は中央にあります。 オレンジ-すでに端に近づいています。 赤-すでにストリップに遭遇しています。 この全体は次のようになります。
さらに、これらのゾーンの位置の選択は、すべてが機械のサイズとカメラの位置に大きく依存するため、すでに移動の過程で行われます。 さらに、私の場合、これは次のように見えました：車は端の近くを移動し、車輪で車線にぶつかり、音に基づいて（反射器を介して移動）、赤いゾーンの境界が確立されます。 これは、車がすでに隣接車線に移動し始めた瞬間です。 ビデオの少し後、あなたはそれを聞くことができます。
実際、これでほとんど終わりです。ドライバーにそこで起こっていることを知らせるだけです。 これを行うために、機械の動きに向けられた矢印を示します。
テスト中
したがって、最も興味深いのはテストです。 最初に、開発されたプロトタイプが事前に記録されたビデオをどのように処理するかを見てみましょう。
分割ストリップの位置を正しく判断できなかったいくつかのフレームを除いて、すべてがそれほど悪くはありません。 さらに、そのような状況に対処することは可能でした。この場合、NumPyの最小二乗法の実装は例外をスローし、ストリップの古い位置を使用することができましたが、その時点では遅すぎて台無しになりました:)
さて、今、主なことは実際のトラックでのテストです：
そして、分割ストリップにあるリフレクターに当たる音を聞くことができる約束されたビデオがあります（ところで、テストだけでなく、非常に便利なことです）：
終わり
それだけです、そのようなシステムの簡単なプロトタイプはやるのが難しいとは言えませんが、車線がほとんど見えず、私の脳ですら、多くの場合、天候や道路状況で安定して動作させる方法は別の問題です私がどこへ行くのかほとんどわかりません。
もう1つの興味深い点は、あるレーンから別のレーンに移動するときにプロトタイプが非常に悪いと感じることです。 最初は正しい車線変更操作などを行うことを考えましたが、すべては明らかではありません：このシステムのタスクは、別の車線に行かないようにし、ドライバーが本当にそこに行きたいと思うものを理解するために、より多くの情報、たとえばデータが必要です方向指示器、ナビゲーションシステムからのデータ、レーダーなどを含めることについてですが、これはまったく別の話です。
もう一度言いますが、Pythonはプロトタイピングにとって素晴らしいことです。これは、C ++を長年にわたって書いてきた人だと言います（そして、言語でこれを確認せずにゼロから開発するために2日間、Cではそうしません）なんとか）。
PS：前のトピックを3次元ケトルで継続しなかったことをおizeびします。判明したように、3Dモニターは3Dには適していますが、2Dでは機能しないため、変更する必要がありましたが、このトピックが悪化しないことを願っています:)
PS2：ソースを忘れてしまった、彼らはgithubに住んでいる