(57)【要約】【課題】車線変更のためにドライバが安全確認を行った場合に、ドライバが脇見をしていると誤判定することを抑制する。【解決手段】ドライバ状態検出装置１は、車両８０のドライバの顔を撮影してドライバの顔画像を生成するドライバモニタカメラ１０と、顔画像に基づいてドライバの顔向き又は視線を検出する顔情報検出部２１と、ドライバの顔向き又は視線が脇見判定条件を満たした場合にドライバが脇見をしていると判定するドライバ状態判定部２２とを備える。ドライバ状態判定部は、車両の車線変更が行われる可能性が高いと判定した場合には、脇見判定条件を緩め又は脇見判定を行わない。【選択図】図３
2019087029.tif 000002
【特許請求の範囲】
【請求項１】
車両のドライバの顔を撮影して該ドライバの顔画像を生成するドライバモニタカメラと、
前記顔画像に基づいて前記ドライバの顔向き又は視線を検出する顔情報検出部と、
前記ドライバの顔向き又は視線が脇見判定条件を満たした場合に前記ドライバが脇見をしていると判定するドライバ状態判定部と
を備え、
前記ドライバ状態判定部は、前記車両の車線変更が行われる可能性が高いと判定した場合には、前記脇見判定条件を緩め又は脇見判定を行わない、ドライバ状態検出装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はドライバ状態検出装置に関する。
【背景技術】
【０００２】
従来、車両に設けられた撮像手段を用いて脇見等のドライバ状態を検出するための装置が知られている。例えば、特許文献１に記載の脇見判定装置では、撮像手段によって出力されたドライバの顔画像からドライバの視線を検出し、検出された視線が所定範囲外にある場合にドライバが脇見をしていると判定される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１２−０５８７６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、車両の車線変更が行われる場合、ドライバは安全確認のために視線を正面からずらして移動先の車線を見る必要がある。しかしながら、特許文献１に記載の脇見判定装置では、ドライバが安全確認のために横又は斜め後方を向いているにも拘わらず、ドライバが脇見をしていると判定されてしまう。
【０００５】
上記課題に鑑みて、本発明の目的は、車線変更のためにドライバが安全確認を行った場合に、ドライバが脇見をしていると誤判定することを抑制することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明では、車両のドライバの顔を撮影して該ドライバの顔画像を生成するドライバモニタカメラと、前記顔画像に基づいて前記ドライバの顔向き又は視線を検出する顔情報検出部と、前記ドライバの顔向き又は視線が脇見判定条件を満たした場合に前記ドライバが脇見をしていると判定するドライバ状態判定部とを備え、前記ドライバ状態判定部は、前記車両の車線変更が行われる可能性が高いと判定した場合には、前記脇見判定条件を緩め又は脇見判定を行わない、ドライバ状態検出装置が提供される。
【発明の効果】
【０００７】
本発明によれば、車線変更のためにドライバが安全確認を行った場合に、ドライバが脇見をしていると誤判定することを抑制することができる。
【図面の簡単な説明】
【０００８】
【図１】図１は、本発明の第一実施形態に係るドライバ状態検出装置の構成を示すブロック図である。
【図２】図２は、ドライバ状態検出装置を搭載した車両の内部を概略的に示す図である。
【図３】図３は、第一実施形態における脇見判定条件設定処理の制御ルーチンを示すフローチャートである。
【図４】図４は、第一実施形態におけるドライバ状態判定処理の制御ルーチンを示すフローチャートである。
【図５】図５は、第二実施形態における車線変更予測処理の制御ルーチンを示すフローチャートである。
【図６】図６は、第二実施形態におけるドライバ状態判定処理の制御ルーチンを示すフローチャートである。
【発明を実施するための形態】
【０００９】
以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下の説明では、同様な構成要素には同一の参照番号を付す。
【００１０】
＜第一実施形態＞
以下、図１〜図４を参照して、本発明の第一実施形態について説明する。図１は、本発明の第一実施形態に係るドライバ状態検出装置の構成を示すブロック図である。ドライバ状態検出装置１は、車両に搭載され、車両のドライバの状態を検出する。ドライバ状態検出装置１はドライバモニタカメラ１０及び電子制御ユニット（ＥＣＵ）２０を備える。
【００１１】
図２は、ドライバ状態検出装置を搭載した車両の内部を概略的に示す図である。ドライバモニタカメラ１０は車両８０（自車両）のドライバの顔を撮影してドライバの顔画像を生成する。ドライバモニタカメラ１０は車両８０の内部に設けられる。具体的には、図２に示すように、ドライバモニタカメラ１０は車両８０のステアリングコラム８１の上部に設けられる。図２には、ドライバモニタカメラ１０の投影範囲が破線で示されている。なお、ドライバモニタカメラ１０は、車両８０のステアリング８２、ルームミラー、メータパネル、メータフード等に設けられてもよい。また、ドライバ状態検出装置１は複数のドライバモニタカメラ１０を備えていてもよい。
【００１２】
ドライバモニタカメラ１０はカメラ及び投光器から構成される。例えば、カメラはＣＭＯＳ（相補型金属酸化膜半導体）カメラ又はＣＣＤ（電荷結合素子）カメラであり、投光器はＬＥＤ（発光ダイオード）である。また、夜間等の低照度時においてもドライバに不快感を与えることなくドライバの顔を撮影できるように、好ましくは、投光器は近赤外ＬＥＤである。例えば、投光器は、カメラの両側に配置された二個の近赤外ＬＥＤである。また、カメラには可視光カットフィルタのようなフィルタが設けられてもよい。ドライバモニタカメラ１０によって生成されたドライバの顔画像はドライバモニタカメラ１０からＥＣＵ２０に送信される。
【００１３】
ＥＣＵ２０は、読み出し専用メモリ（ＲＯＭ）及びランダムアクセスメモリ（ＲＡＭ）のようなメモリ、中央演算装置（ＣＰＵ）、入力ポート、出力ポート、通信モジュール等を備えたマイクロコンピュータである。本実施形態では、一つのＥＣＵ２０が設けられているが、機能毎に複数のＥＣＵが設けられていてもよい。ＥＣＵ２０は顔情報検出部２１及びドライバ状態判定部２２を有する。
【００１４】
顔情報検出部２１はドライバの顔情報を検出する。具体的には、顔情報検出部２１は、ドライバモニタカメラ１０によって生成されたドライバの顔画像に基づいてドライバの顔向き又は視線を検出する。
【００１５】
顔情報検出部２１は、例えば、以下の方法によってドライバの顔向きを検出する。顔情報検出部２１は、ドライバが正面を向いているときの顔形状データを予め記憶している。顔形状データは、一般的な人間の顔のデータであっても、ドライバ毎に取得されてもよい。顔形状データはＥＣＵ２０のメモリに記憶される。顔情報検出部２１は、生成されたドライバの顔画像と、顔形状データとのマッチングを行う。顔情報検出部２１は、両者の一致率が最大となるようにドライバの顔画像を回転させ、一致率が最大となるときの回転角度からドライバの顔向きを検出する。
【００１６】
また、顔情報検出部２１は以下の方法によってドライバの顔向きを検出してもよい。顔情報検出部２１は、ドライバの顔向きが異なる複数の顔形状データを予め記憶している。顔形状データは、一般的な人間の顔のデータであっても、ドライバ毎に取得されてもよい。顔形状データはＥＣＵ２０のメモリに記憶される。顔情報検出部２１は、生成されたドライバの顔画像と、複数の顔形状データとのマッチングを行う。顔情報検出部２１は、両者の一致率が最大となる顔形状データの顔向きをドライバの顔向きとして検出する。また、顔情報検出部２１は、特開２０００−９７６７６２号公報又は特開２００３−４４８５３号公報に記載されたような他の公知の手法によってドライバの顔向きを検出してもよい。
【００１７】
顔情報検出部２１は、例えば、以下の方法によってドライバの視線を検出する。顔情報検出部２１は、生成されたドライバの顔画像から顔領域を特定し、眼、鼻、口等の顔部品の特徴点を抽出することによって顔部品を検出する。さらに、顔情報検出部２１は、プルキニエ像（角膜反射像）の位置と瞳孔中心の位置とを検出し、プルキニエ像と瞳孔中心との位置関係に基づいてドライバの視線を検出する。なお、顔情報検出部２１は、プルキニエ像と瞳孔中心との位置関係と、検出されたドライバの顔向きとに基づいてドライバの視線を検出してもよい。
【００１８】
ドライバ状態判定部２２はドライバの状態を判定する。具体的には、ドライバ状態判定部２２は、顔情報検出部２１によって検出されたドライバの顔向き又は視線が脇見判定条件を満たした場合にドライバが脇見をしていると判定する。例えば、ドライバ状態判定部２２は、ドライバの顔向き又は視線が閾値時間以上閾値範囲外に維持された場合に、ドライバが脇見をしていると判定する。
【００１９】
ドライバ状態判定部２２は、ドライバが脇見をしていると判定した場合には、ドライバに警報を与える。例えば、ドライバ状態判定部２２はヒューマン・マシン・インターフェース（Human Machine Interface（ＨＭＩ））３０を介して視覚的又は聴覚的にドライバに警報を与える。ＨＭＩ３０は、ドライバと車両８０との間で情報の入出力を行うためのインターフェイスである。ＨＭＩ３０は、例えば、文字又は画像情報を表示するディスプレイ、音を発生させるスピーカ、ドライバが入力操作を行うための操作ボタン、タッチパネル、マイク等から構成される。
【００２０】
人間の眼には有効視野が存在するため、ドライバが右側を向いているときには左側の視野が狭くなり、ドライバが左側を向いているときには右側の視野が狭くなる。したがって、ドライバが左右両方の広い範囲を監視するためには、ドライバはできるだけ正面を向いている必要がある。このため、脇見判定の閾値範囲は、正面（０°）を中心とする所定範囲（例えば±２０〜４０°）に設定される。
【００２１】
一方、車両８０の車線変更が行われる場合、ドライバは安全確認のために顔向き又は視線を正面からずらして移動先の車線を見る必要がある。しかしながら、車線変更時にも脇見判定条件（閾値範囲及び閾値時間）が維持されると、ドライバが安全確認のために横又は斜め後方を向いているにも拘わらず、ドライバが脇見をしていると判定され、ドライバに警報が与えられる。また、ウィンカーが作動されて実際に車線変更が行われる前にも、ドライバによる安全確認が行われる場合がある。
【００２２】
このため、本実施形態では、ドライバ状態判定部２２は、車両８０の車線変更が行われる可能性が高いと判定した場合には、脇見判定条件を緩める。このことによって、車線変更のためにドライバが安全確認を行った場合に、ドライバが脇見をしていると誤判定することを抑制することができる。
【００２３】
車両８０が自動運転されている場合、自動運転システムによって必要に応じて車線変更が提案され、ドライバの承諾により車線変更が実行される。このため、ドライバ状態判定部２２は、自動運転システムによって車線変更が提案された場合に、車両８０の車線変更が行われる可能性が高いと判定する。
【００２４】
また、車両８０が先行車に接近した場合には、先行車との衝突を回避すべく、追越車線への車線変更が行われることが多い。このため、ドライバ状態判定部２２は、先行車との衝突余裕時間（ＴＴＣ：Ｔｉｍｅ  Ｔｏ  Ｃｏｌｌｉｓｉｏｎ）が所定時間以内である場合に、車両８０の車線変更が行われる可能性が高いと判定する。ＴＴＣとは、車両８０が先行車に衝突するまでの時間の予測値であり、車両８０と先行車との相対距離を車両８０と先行車との相対速度で除算することで得られる。
【００２５】
車両８０には他車両検出装置４０が設けられ、他車両検出装置４０の出力はＥＣＵ２０に送信される。他車両検出装置４０は車両８０の周囲の他車両を検出する。ドライバ状態判定部２２は、他車両検出装置４０の出力に基づいて、車両８０と先行車との相対距離及び車両８０と先行車との相対速度を算出する。他車両検出装置４０は、例えば、ミリ波レーダ、レーザレーダ、ステレオカメラ等である。
【００２６】
また、走行経路上で自車線が消滅する場合には、走行を続行するために車線変更を行う必要がある。このため、ドライバ状態判定部２２は、車両８０の進行方向の所定距離内で自車線が消滅する場合には、車両８０の車線変更が行われる可能性が高いと判定する。
【００２７】
車両８０にはナビゲーション装置５０が設けられ、ナビゲーション装置５０に記憶された情報はＥＣＵ２０に送信される。ナビゲーション装置５０は、ＧＰＳ受信機を有し、ＧＰＳ受信機によって車両８０の現在位置を検出する。また、ナビゲーション装置５０は地図情報を記憶している。地図情報には、道路の位置情報、道路の形状情報（例えばカーブと直線部との種別、カーブの曲率半径、道路勾配等）、合流地点、分流地点等の位置情報、道路種別等の情報が含まれる。
【００２８】
ドライバ状態判定部２２は、ナビゲーション装置５０から取得した情報に基づいて、自車線の消滅を検出する。例えば、走行中の道路の車線の数が減少すること又は合流によって自車線が消滅する。なお、ドライバ状態判定部２２は、車両８０の外部から受信した情報に基づいて自車線の消滅を検出してもよい。
【００２９】
また、走行経路上で自車線が走行不可となる場合には、走行を続行するために車線変更を行う必要がある。このため、ドライバ状態判定部２２は、車両８０の進行方向の所定距離内で自車線が走行不可となる場合には、車両８０の車線変更が行われる可能性が高いと判定する。
【００３０】
車両８０には道路交通情報受信装置６０が設けられ、道路交通情報受信装置６０によって受信される道路交通情報はＥＣＵ２０に送信される。道路交通情報受信装置６０は、事故、工事、災害、気象条件等による道路規制情報、渋滞情報等の道路交通情報を道路交通情報通信システムセンタのような外部の通信センタから受信する。なお、道路交通情報受信装置６０は車両８０と他車両との車車間通信によって道路交通情報を受信してもよい。また、ナビゲーション装置５０が道路交通情報受信装置として機能してもよい。
【００３１】
ドライバ状態判定部２２は、道路交通情報受信装置６０から取得した情報に基づいて、自車線が走行不可になることを検出する。例えば、工事、事故、火災、土砂崩れ、崩落等によって自車線が走行不可となる。
【００３２】
ドライバ状態判定部２２は、車両８０の車線変更が行われる可能性が高いと判定した場合には、例えば閾値範囲を拡張する。具体的には、ドライバ状態判定部２２は、車線変更によって車両８０が右側の車線に移動する可能性が高いと判定した場合には、右側（プラス側）の閾値範囲を拡張する。例えば、閾値範囲は＋１８０°まで拡張される。一方、ドライバ状態判定部２２は、車線変更によって車両８０が左側の車線に移動する可能性が高いと判定した場合には、左側（マイナス側）の閾値範囲を拡張する。例えば閾値範囲は−１８０°まで拡張される。
【００３３】
また、ドライバ状態判定部２２は、閾値範囲を拡張する代わりに、閾値時間を延長してもよい。例えば、閾値時間は、車線変更が終了するまでの予測時間よりも長い時間まで延長される。また、ドライバ状態判定部２２は閾値範囲を拡張し且つ閾値時間を延長してもよい。
【００３４】
＜脇見判定条件設定処理＞
以下、図３及び図４のフローチャートを参照して、ドライバ状態検出装置１を用いてドライバの脇見を検出するための制御について詳細に説明する。図３は、第一実施形態における脇見判定条件設定処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ２０によって所定の時間間隔で繰り返し実行される。本制御ルーチンでは、脇見判定条件（閾値判定及び閾値時間）が設定される。
【００３５】
最初に、ステップＳ１０１において、自動運転システムによって車線変更が提案されたか否かが判定される。自動運転システムによって車線変更が提案されなかったと判定された場合、本制御ルーチンはステップＳ１０２に進む。
【００３６】
ステップＳ１０２では、ＴＴＣが所定時間Ｔ１以下であるか否かが判定される。所定時間Ｔ１は例えば１〜５秒である。ＴＴＣが所定時間Ｔ１よりも長いと判定された場合、本制御ルーチンはステップＳ１０３に進む。
【００３７】
ステップＳ１０３では、車両８０の進行方向の所定距離内で自車線が消滅するか否かが判定される。所定距離は例えば１００〜８００ｍである。車両８０の進行方向の所定距離内で自車線が消滅しないと判定された場合、本制御ルーチンはステップＳ１０４に進む。
【００３８】
ステップＳ１０４では、車両８０の進行方向の所定距離内で自車線が走行不可になるか否かが判定される。所定距離は例えば１００〜８００ｍである。車両８０の進行方向の所定距離内において自車線が走行可能であると判定された場合、本制御ルーチンはステップＳ１０５に進む。
【００３９】
ステップＳ１０５では、閾値範囲が初期化される。すなわち、閾値範囲が拡張前の元の値に戻される。次いで、ステップＳ１０６では、閾値時間が初期化される。すなわち、閾値時間が延長前の元の値に戻される。ステップＳ１０６の後、本制御ルーチンは終了する。
【００４０】
一方、ステップＳ１０１〜ステップＳ１０４のいずれか一つのステップにおける判定が肯定された場合、車両８０の車線変更が行われる可能性が高いと判定され、本制御ルーチンはステップＳ１０７に進む。ステップＳ１０７では、予測される車線変更の移動方向が右側であるか否かが判定される。
【００４１】
例えば、自動運転システムによって右側への車線変更が提案された場合には、予測される車線変更の移動方向が右側であると判定される。一方、自動運転システムによって左側への車線変更が提案された場合には、予測される車線変更の移動方向が左側であると判定される。また、ＴＴＣが所定時間Ｔ１以下であり、追越車線が右側にある場合には、予測される車線変更の移動方向が右側であると判定される。一方、ＴＴＣが所定時間Ｔ１以下であり、追越車線が左側にある場合には、予測される車線変更の移動方向が左側であると判定される。また、自車線の消滅が検出され、移動先の車線が右側にある場合には、予測される車線変更の移動方向が右側であると判定される。一方、自車線の消滅が検出され、移動先の車線が左側にある場合には、予測される車線変更の移動方向が左側であると判定される。また、自車線が走行不可になることが検出され、移動先の車線が右側にある場合には、予測される車線変更の移動方向が右側であると判定される。一方、自車線が走行不可になることが検出され、移動先の車線が左側にある場合には、予測される車線変更の移動方向が左側であると判定される。
【００４２】
ステップＳ１０７において、予測される車線変更の移動方向が右側であると判定された場合、本制御ルーチンはステップＳ１０８に進む。ステップＳ１０８では、右側の閾値範囲が拡張される。次いで、ステップＳ１０９では、閾値時間が延長される。ステップＳ１０９の後、本制御ルーチンは終了する。
【００４３】
一方、ステップＳ１０７において、予測される車線変更の移動方向が左側であると判定された場合、本制御ルーチンはステップＳ１１０に進む。ステップＳ１１０では、左側の閾値範囲が拡張される。次いで、ステップＳ１１１では、閾値時間が延長される。ステップＳ１１１の後、本制御ルーチンは終了する。
【００４４】
なお、ＴＴＣが急激に減少した場合には追越車線への車線変更が行われる可能性が高いので、ステップＳ１０２において、ＴＴＣの単位時間当たりの減少量が所定値以上であるか否かが判定されてもよい。
【００４５】
＜ドライバ状態判定処理＞
図４は、第一実施形態におけるドライバ状態判定処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ２０によって所定の時間間隔で繰り返し実行される。本制御ルーチンでは、ドライバが脇見をしているか否かが判定される。
【００４６】
最初に、ステップＳ２０１において、ドライバモニタカメラ１０からドライバの顔画像が取得される。ドライバの顔画像はドライバモニタカメラ１０によって生成される。
【００４７】
次いで、ステップＳ２０２において、ドライバの顔画像に基づいてドライバの顔向き又は視線が検出される。例えば、ドライバの顔向き又は視線は、上述したいずれかの方法によって検出される。
【００４８】
次いで、ステップＳ２０３において、ドライバの顔向き又は視線が閾値範囲内であるか否かが判定される。閾値範囲は図３の制御ルーチンにおいて設定される。ドライバの顔向き又は視線が閾値範囲内であると判定された場合、本制御ルーチンはステップＳ２０８に進む。ステップＳ２０８では、積算時間ＥＴがゼロにリセットされる。ステップＳ２０８の後、本制御ルーチンは終了する。
【００４９】
一方、ステップＳ２０３において顔向き又は視線が閾値範囲外であると判定された場合、本制御ルーチンはステップＳ２０４に進む。ステップＳ２０４では、積算時間ＥＴが更新される。具体的には、積算時間ＥＴに微小時間Δｔを加算した値が新たな積算時間ＥＴとされる。積算時間ＥＴは、ドライバの顔向き又は視線が閾値範囲外に維持された時間である。積算時間ＥＴの初期値はゼロである。また、微小時間Δｔは本制御ルーチンの実行間隔に相当する値である。
【００５０】
次いで、ステップＳ２０５において、積算時間ＥＴが閾値時間Ｔｒｅｆ以上であるか否かが判定される。閾値時間Ｔｒｅｆは図３の制御ルーチンにおいて設定される。積算時間ＥＴが閾値時間Ｔｒｅｆ未満であると判定された場合、本制御ルーチンは終了する。
【００５１】
一方、積算時間ＥＴが閾値時間Ｔｒｅｆ以上であると判定された場合、本制御ルーチンはステップＳ２０６に進む。ステップＳ２０６では、ドライバが脇見をしていると判定される。次いで、ステップＳ２０７では、ＨＭＩ３０を介してドライバに警報が所定時間与えられる。次いで、ステップＳ２０８では、積算時間ＥＴがゼロにリセットされる。ステップＳ２０８の後、本制御ルーチンは終了する。
【００５２】
なお、図３のステップＳ１０６、ステップＳ１０９及びステップＳ１１１は省略されてもよい。この場合、閾値時間は車線変更の有無に関わらず一定にされる。また、図３のステップＳ１０５、ステップＳ１０８及びステップＳ１１０は省略されてもよい。この場合、閾値範囲は車線変更の有無に関わらず一定にされる。すなわち、車両８０の車線変更が行われる可能性が高いと判定された場合、閾値範囲及び閾値時間の少なくとも一方が変更される。
【００５３】
＜第二実施形態＞
第二実施形態に係るドライバ状態検出装置の構成及び制御は、以下に説明する点を除いて、基本的に第一実施形態に係るドライバ状態検出装置の構成及び制御と同様である。このため、以下、本発明の第二実施形態について、第一実施形態と異なる部分を中心に説明する。
【００５４】
第二実施形態では、ドライバ状態判定部２２は、車両８０の車線変更が行われる可能性が高いと判定した場合には、脇見判定を行わない。このことによって、車線変更のためにドライバが安全確認を行った場合に、ドライバが脇見をしていると誤判定することを抑制することができる。
【００５５】
＜車線変更予測処理＞
図５は、第二実施形態における車線変更予測処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ２０によって所定の時間間隔で繰り返し実行される。本制御ルーチンでは、車両８０の車線変更が行われる可能性が高いか否かが判定される。
【００５６】
ステップＳ３０１〜ステップＳ３０４では、図３のステップＳ１０１〜ステップＳ１０４と同様の判定が行われる。ステップＳ３０１〜ステップＳ３０４における全ての判定が否定された場合、車両８０の車線変更が行われる可能性が低いと判定され、本制御ルーチンはステップＳ３０５に進む。ステップＳ３０５では、車線変更フラグＦｒｃがゼロに設定される。なお、車線変更フラグＦｒｃの初期値はゼロである。ステップＳ３０５の後、本制御ルーチンは終了する。
【００５７】
一方、ステップＳ３０１〜ステップＳ３０４のいずれか一つのステップにおける判定が肯定された場合、車両８０の車線変更が行われる可能性が高いと判定され、本制御ルーチンはステップＳ３０６に進む。ステップＳ３０６では、車線変更フラグＦｒｃが１に設定される。ステップＳ３０６の後、本制御ルーチンは終了する。
【００５８】
＜ドライバ状態判定処理＞
図６は、第二実施形態におけるドライバ状態判定処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ２０によって所定の時間間隔で繰り返し実行される。本制御ルーチンでは、ドライバが脇見をしているか否かが判定される。
【００５９】
最初に、ステップＳ４０１において、車線変更フラグＦｒｃが１であるか否かが判定される。車線変更フラグＦｒｃがゼロであると判定された場合、本制御ルーチンはステップＳ４０２に進む。ステップＳ４０２〜ステップＳ４０９は、図４のステップＳ２０１〜ステップＳ２０８と同様であることから説明を省略する。なお、この場合、閾値範囲及び閾値範囲は予め定められている。
【００６０】
一方、ステップＳ４０１において車線変更フラグＦｒｃが１であると判定された場合、本制御ルーチンは終了する。すなわち、車両８０の車線変更が行われる可能性が高いと判定された場合、脇見判定が行われない。
【００６１】
以上、本発明に係る好適な実施形態を説明したが、本発明はこれら実施形態に限定されるものではなく、特許請求の範囲の記載内で様々な修正及び変更を施すことができる。
【符号の説明】
【００６２】
１    ドライバ状態検出装置
１０    ドライバモニタカメラ
２０    電子制御ユニット（ＥＣＵ）
２１    顔情報検出部
２２    ドライバ状態判定部
８０    車両
【図１】
2019087029.tif 000003
【図２】
2019087029.tif 000004
【図３】
2019087029.tif 000005
【図４】
2019087029.tif 000006
【図５】
2019087029.tif 000007
【図６】
2019087029.tif 000008