(57)【要約】      （修正有）【課題】撮像装置を用いてドライバの飲食動作を検出する。【解決手段】ドライバ監視装置１は、車両のドライバの顔を撮影して画像を生成する撮像装置２と、画像からドライバの顔を検出する顔検出部３１、顔検出部によって顔が検出された場合に画像に基づいてドライバの顔向きを推定する顔向き推定部３２及び顔検出部によって顔が検出されない場合に、顔が検出されない原因を判定する原因判定部３３を有するＥＣＵ３と、を備える。顔検出部は、画像から顔の特徴点を抽出することによって顔を検出する。原因判定部は、顔の検出状態が検出から非検出に変化したときに、検出状態が検出から非検出に変化するまでの所定数の画像において、顔向き推定部によって推定された顔向きが正面であり且つ顔検出部によって顔の下方領域の特徴点が抽出されていない場合には、顔が検出されない原因がドライバの飲食動作であると判定する。【選択図】図１
2019212226.tif 000002
【特許請求の範囲】
【請求項１】
車両のドライバの顔を撮影して画像を生成する撮像装置と、
前記画像から前記顔を検出する顔検出部と、
前記顔検出部によって前記顔が検出された場合に前記画像に基づいて前記ドライバの顔向きを推定する顔向き推定部と、
前記顔検出部によって前記顔が検出されない場合に、該顔が検出されない原因を判定する原因判定部と
を備え、
前記顔検出部は、前記画像から前記顔の特徴点を抽出することによって前記顔を検出し、
前記原因判定部は、前記顔の検出状態が検出から非検出に変化したときに、該検出状態が検出から非検出に変化するまでの所定数の前記画像において、前記顔向き推定部によって推定された前記顔向きが正面であり且つ前記顔検出部によって前記顔の下方領域の特徴点が抽出されていない場合には、前記原因が前記ドライバの飲食動作であると判定する、ドライバ監視装置。
【請求項２】
前記ドライバに警報を与える警報部を更に備え、
前記警報部は、前記原因が前記ドライバの飲食動作であると判定された場合には、前記原因が前記ドライバの飲食動作以外であると判定された場合に比べて、前記ドライバへの警報を抑制する、請求項１に記載のドライバ監視装置。
【請求項３】
前記警報部は、前記顔の検出状態が未検出である状態が閾値時間継続した場合に前記ドライバに警報を与え、
前記警報部は、前記原因が前記ドライバの飲食動作であると判定された場合には、前記原因が前記ドライバの飲食動作以外であると判定された場合に比べて、前記閾値時間を長くする、請求項２に記載のドライバ監視装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はドライバ監視装置に関する。
【背景技術】
【０００２】
従来、ドライバの異常（居眠り、脇見、離席等）を検出すべく、車両に設けられた撮像装置を用いて車両のドライバを監視する装置が知られている（例えば特許文献１）。斯かる装置では、撮像装置によって生成されたドライバの画像からドライバの顔が検出され、検出された顔に基づいてドライバの顔向き等が推定される。
【０００３】
しかしながら、ドライバが異常である場合、例えば、ドライバがスマートフォン等を見ている場合、ドライバが離席している場合等には、ドライバの顔が検出されない。この場合、ドライバの状態を正常にすべく、ドライバに警報が与えられる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−２１７６９３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、ドライバは車両の走行中に飲食を行うことがある。ドライバによって飲食が行われると、飲食物によってドライバの顔が隠され、ドライバの顔が検出されない場合がある。しかしながら、ドライバの飲食によってドライバが異常であると判定されてドライバに警報が与えられると、ドライバが不快に感じるおそれがある。
【０００６】
上記課題に鑑みて、本発明の目的は、撮像装置を用いてドライバの飲食動作を検出することにある。
【課題を解決するための手段】
【０００７】
本開示の要旨は以下のとおりである。
【０００８】
（１）車両のドライバの顔を撮影して画像を生成する撮像装置と、前記画像から前記顔を検出する顔検出部と、前記顔検出部によって前記顔が検出された場合に前記画像に基づいて前記ドライバの顔向きを推定する顔向き推定部と、前記顔検出部によって前記顔が検出されない場合に、該顔が検出されない原因を判定する原因判定部とを備え、前記顔検出部は、前記画像から前記顔の特徴点を抽出することによって前記顔を検出し、前記原因判定部は、前記顔の検出状態が検出から非検出に変化したときに、該検出状態が検出から非検出に変化するまでの所定数の前記画像において、前記顔向き推定部によって推定された前記顔向きが正面であり且つ前記顔検出部によって前記顔の下方領域の特徴点が抽出されていない場合には、前記原因が前記ドライバの飲食動作であると判定する、ドライバ監視装置。
【０００９】
（２）前記判定部は、前記状況が発生したときに、前記所定期間において前記画像が不鮮明であることが検出された回数又は頻度が所定値以上である場合に、前記原因が前記撮像装置にあると判定する、上記（１）に記載のドライバ監視装置。
【００１０】
（３）前記警報部は、前記顔の検出状態が未検出である状態が閾値時間継続した場合に前記ドライバに警報を与え、前記警報部は、前記原因が前記ドライバの飲食動作であると判定された場合には、前記原因が前記ドライバの飲食動作以外であると判定された場合に比べて、前記閾値時間を長くする、上記（２）に記載のドライバ監視装置。
【発明の効果】
【００１１】
本発明によれば、撮像装置を用いてドライバの飲食動作を検出することができる。
【図面の簡単な説明】
【００１２】
【図１】図１は、本発明の第一実施形態に係るドライバ監視装置の構成を示すブロック図である。
【図２】図２は、ドライバ監視装置を搭載した車両の内部を概略的に示す図である。
【図３】図３は、ドライバが飲食を行うときの画像を時系列に示す図である。
【図４】図４は、第一実施形態における顔検出処理の制御ルーチンを示すフローチャートである。
【図５】図５は、第一実施形態における顔向き推定処理の制御ルーチンを示すフローチャートである。
【図６】図６は、第一実施形態における原因判定処理の制御ルーチンを示すフローチャートである。
【図７】図７は、第一実施形態における警報処理の制御ルーチンを示すフローチャートである。
【図８】図８は、第二実施形態における警報処理の制御ルーチンを示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下の説明では、同様な構成要素には同一の参照番号を付す。
【００１４】
＜第一実施形態＞
以下、図１〜図７を参照して、本発明の第一実施形態について説明する。
【００１５】
＜ドライバ監視装置の構成＞
図１は、本発明の第一実施形態に係るドライバ監視装置の構成を示すブロック図である。ドライバ監視装置１は、撮像装置２及びＥＣＵ（電子制御ユニット）３を備え、車両のドライバを監視する。
【００１６】
図２は、ドライバ監視装置１を搭載した車両の内部を概略的に示す図である。車両１０は、例えば自動走行が可能な自動運転車両である。撮像装置２は、車両１０のドライバの顔を撮影して画像を生成する。撮像装置２はいわゆるドライバモニタカメラである。
【００１７】
撮像装置２は車両１０の内部に設けられる。具体的には、図２に示すように、撮像装置２は車両１０のステアリングコラム１１の上部に設けられる。図２には、撮像装置２の投影範囲が破線で示されている。なお、撮像装置２は、車両１０のステアリング１２、ルームミラー、メータパネル、メータフード等に設けられてもよい。
【００１８】
撮像装置２はカメラ及び投光器を備える。カメラは、レンズ及び撮像素子を含み、例えばＣＭＯＳ（相補型金属酸化膜半導体）カメラ又はＣＣＤ（電荷結合素子）カメラである。投光器は、ＬＥＤ（発光ダイオード）であり、例えばカメラの両側に配置された二個の近赤外ＬＥＤである。ドライバに近赤外光を照射することによって、夜間等の低照度時においてもドライバに不快感を与えることなくドライバの顔を撮影することができる。また、近赤外以外の波長成分の光を除去するするバンドパスフィルタがカメラの内部に設けられ、近赤外ＬＥＤから照射される赤色波長成分の光を除去する可視光カットフィルタが投光器の前面に設けられる。
【００１９】
撮像装置２の動作はＥＣＵ３によって制御される。例えば、撮像装置２は、車両１０のイグニッションスイッチがオンであるときに、所定間隔で繰り返しドライバの顔を撮影する。撮像装置２によって生成された画像（以下、単に「画像」と称する）は撮像装置２からＥＣＵ３に送信される。
【００２０】
＜ドライバ監視装置の制御＞
ＥＣＵ３は、車両１０に設けられたマイクロコンピュータであり、各種制御を実行する。ＥＣＵ３は、ＲＯＭ（読み出し専用メモリ）及びＲＡＭ（ランダムアクセスメモリ）のようなメモリ、ＣＰＵ（中央演算装置）、電源回路、入力ポート、出力ポート、通信モジュール等を備える。本実施形態では、メモリに記憶されたコンピュータプロフラムをＣＰＵが実行することによって、ＥＣＵ３は、顔検出部３１、顔向き推定部３２、原因判定部３３及び警報部３４として機能する。なお、本実施形態では、一つのＥＣＵ３が設けられているが、機能毎に複数のＥＣＵが設けられてもよい。
【００２１】
顔検出部３１は、画像を撮像装置２から受信し、画像からドライバの顔を検出する。基本的には、ドライバの状態が正常である場合、すなわち走行中の車両１０の周囲の監視義務をドライバが果たしている場合には、ドライバの顔が撮像装置２のカメラの画角内に入り、ドライバの顔が検出される。一方、ドライバが異常である場合に、例えば、ドライバが自分の体又は所有物によって撮像装置２のレンズを塞いでいる場合、ドライバがスマートフォン等を見ている場合、ドライバが離席している場合等には、ドライバの顔が検出不可能となる。
【００２２】
顔検出部３１は画像からドライバの顔の特徴点を抽出することによってドライバの顔を検出する。例えば、顔検出部３１は、抽出可能な特徴点の数が所定値以上である場合にはドライバの顔を検出し、抽出可能な特徴点の数が所定値未満である場合には、ドライバの顔を検出しない。また、顔検出部３１は、顔の特徴点から顔部品を検出し、所定の顔部品（例えば眼及び鼻）が検出可能である場合にはドライバの顔を検出し、所定の顔部品が検出不可能である場合にはドライバの顔を検出しなくてもよい。
【００２３】
顔向き推定部３２は、顔検出部３１によってドライバの顔が検出された場合に画像に基づいてドライバの顔向きを推定する。顔向き推定部３２は、画像からドライバの顔の角度を算出し、ドライバの顔の角度が所定値以下である場合に、ドライバの顔向きが正面であると推定する。顔向き推定部３２は、例えば、顔のヨー角及びピッチ角が±１０〜３０度以内である場合に、ドライバの顔向きが正面であると推定する。顔のヨー角は、ドライバが顔を左右に振る方向の角度であり、顔のピッチ角は、ドライバが顔を上下に振る方向の角度である。
【００２４】
顔向き推定部３２は、例えば以下のように画像からドライバの顔の角度を算出する。顔向き推定部３２は、ドライバの顔の角度が０度であるときの顔形状データと、画像の顔領域とのマッチングを行う。顔形状データは、一般的な人間の顔のデータであっても、ドライバ毎に取得されてもよい。顔形状データはＥＣＵ３のメモリに記憶される。顔向き推定部３２は、顔形状データと画像の顔領域との一致率が最大となるように画像の顔領域を回転させ、一致率が最大となるときの回転角度をドライバの顔の角度として算出する。
【００２５】
なお、顔向き推定部３２は、公知の他の方法によってドライバの顔向きを推定してもよい。例えば、顔向き推定部３２は、正面を向いているドライバの顔画像を大量に学習し、ディープラーニング等の手法によってドライバの顔向きを推定してもよい。
【００２６】
原因判定部３３は、顔検出部３１によってドライバの顔が検出されない場合に、顔が検出されない原因を判定する。図３は、ドライバが飲食を行うときの画像を時系列に示す図である。図３には、４枚の画像が示され、画像の番号の順に画像が生成されている。各画像に示される黒丸の印は、顔の特徴点を示している。なお、これら特徴点は一例であり、特徴点の位置及び数は、図３に示される位置及び数と異なっていてもよい。
【００２７】
図３の４番の画像から分かるように、ドライバが飲食物（この例では缶ジュース）を顔の正面付近に移動させると、飲食物によってドライバの顔の大部分が隠される。この結果、４番目の画像では、顔検出部３１によってドライバの顔が検出されない。したがって、ドライバの顔が検出されない原因として、上述したドライバの異常に加えて、ドライバの飲食動作も考えられる。
【００２８】
車両１０の走行中にドライバが飲食を行う場合、ドライバは正面を向く傾向にある。このため、ドライバが飲食を行おうとしているときにドライバの顔が検出されている場合には、ドライバが正面を向いている可能性が高い。また、通常、ドライバは下から上に飲食物を移動させる。このため、ドライバが飲食を行うとき、顔の全ての特徴点の中で顔の下方領域の特徴点が先に抽出不可能となる。
【００２９】
そこで、本実施形態では、原因判定部３３は、ドライバの顔の検出状態が検出から非検出に変化したときに、過去の画像において、顔向き推定部３２によって推定された顔向きが正面であり且つ顔検出部３１によって顔の下方領域の特徴点が抽出されていない場合には、顔が検出されない原因がドライバの飲食動作であると判定する。過去の画像は、ドライバの顔の検出状態が検出から非検出に変化するまでの所定数の画像である。また、顔の下方領域は、画像の顔領域における下半分の領域であり、例えば口の領域である。上記の制御によれば、撮像装置２を用いてドライバの飲食動作を検出することができる。
【００３０】
警報部３４は、車両１０に設けられたＨＭＩ（ヒューマン・マシン・インターフェース（Human Machine Interface））等を介して、ドライバに警報を与える。また、警報部３４は、ドライバの顔が検出されない原因がドライバの飲食動作であると判定された場合には、この原因がドライバの飲食動作以外であると判定された場合に比べて、ドライバへの警報を抑制する。このことによって、飲食時に警報が与えられることによるドライバの不快感を低減することができる。
【００３１】
例えば、警報部３４は、ドライバの顔が検出されない原因がドライバの飲食動作であると判定された場合にはドライバに警報を与えず、この原因がドライバの飲食動作以外であると判定された場合にはドライバに警報を与える。また、警報部３４は、ドライバの顔が検出されない原因がドライバの飲食動作であると判定された場合には、この原因がドライバの飲食動作以外であると判定された場合に比べて、警報の強度（例えば音量、文字の大きさ等）を小さくしてもよい。
【００３２】
＜顔検出処理＞
以下、図４〜図７のフローチャートを参照して、ドライバ監視装置１の制御について詳細に説明する。図４は、第一実施形態における顔検出処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ３によって所定の実行間隔で繰り返し実行される。所定の実行間隔は、例えば、撮像装置２からＥＣＵ３に画像が送信される間隔である。
【００３３】
最初に、ステップＳ１０１において、顔検出部３１は撮像装置２から画像を受信する。次いで、ステップＳ１０２において、顔検出部３１は画像からドライバの顔の特徴点を抽出する。
【００３４】
次いで、ステップＳ１０３において、顔検出部３１は、検出条件が満たされるか否かを判定する。例えば、顔検出部３１は、ステップＳ１０３において抽出された特徴点の数が所定値以上である場合には検出条件が満たされると判定し、そうでなければ検出条件が満たされないと判定する。また、顔検出部３１は、ステップＳ１０３において抽出された特徴点から顔部品を検出し、所定の顔部品（例えば眼及び鼻）が検出可能である場合には検出条件が満たされると判定し、そうでなければ検出条件が満たされないと判定してもよい。
【００３５】
ステップＳ１０３において検出条件が満たされると判定された場合、本制御ルーチンはステップＳ１０４に進む。この場合、ドライバの顔の検出が可能であるため、ステップＳ１０４では、顔検出部３１はドライバの顔を検出する。すなわち、顔の検出状態が検出となる。
【００３６】
一方、ステップＳ１０３において検出条件が満たされないと判定された場合、本制御ルーチンはステップＳ１０３をスキップしてステップＳ１０５に進む。この場合、ドライバの顔が検出不可能であるため、顔検出部３１はドライバの顔を検出しない。すなわち、顔の検出状態が非検出となる。
【００３７】
ステップＳ１０５では、顔検出部３１は顔の検出情報をＥＣＵ３のメモリに記憶する。具体的には、顔検出部３１は、ステップＳ１０１において受信された画像について、顔の検出状態と、非抽出の顔の特徴点の位置とをＥＣＵ３のメモリに記憶する。ＥＣＵ３のメモリでは、これら情報に対応する画像の総数が所定数以下になるように、記憶された情報が古い画像から順に削除される。
【００３８】
＜顔向き推定処理＞
図５は、第一実施形態における顔向き推定処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ３によって所定の実行間隔で繰り返し実行される。所定の実行間隔は、例えば、撮像装置２からＥＣＵ３に画像が送信される間隔である。
【００３９】
最初に、ステップＳ２０１において、顔向き推定部３２は、顔検出部３１によってドライバの顔が検出されたか否かを判定する。ドライバの顔が検出されたと判定された場合、本制御ルーチンはステップＳ２０２に進む。ステップＳ２０２では、顔向き推定部３２は上記のいずれかの方法によってドライバの顔向きを推定する。
【００４０】
一方、ステップＳ２０１においてドライバの顔が検出されなかったと判定された場合、本制御ルーチンはステップＳ２０２をスキップしてステップＳ２０３に進む。ステップＳ２０３では、顔向き推定部３２は、ステップＳ２０２において推定された顔向きをＥＣＵ３のメモリに記憶する。ＥＣＵ３のメモリでは、顔向きが記憶された画像の総数が所定数以下になるように、記憶された情報が古い画像から順に削除される。なお、ドライバの顔向きが推定されなかった場合（ステップＳ２０２がスキップされた場合）には、ドライバの顔向きとして正面以外の所定の顔向きがＥＣＵ３のメモリに記憶される。
【００４１】
＜原因判定処理＞
図６は、第一実施形態における原因判定処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ３によって所定の実行間隔で繰り返し実行される。所定の実行間隔は、例えば、撮像装置２からＥＣＵ３に画像が送信される間隔である。
【００４２】
最初に、ステップＳ３０１において、原因判定部３３は、ＥＣＵ３のメモリに記憶された検出情報に基づいて、顔の検出状態が検出から非検出に変化したか否かを判定する。顔の検出状態が検出から非検出に変化しなかったと判定された場合、本制御ルーチンは終了する。一方、顔の検出状態が検出から非検出に変化したと判定された場合、本制御ルーチンはステップＳ３０２に進む。
【００４３】
ステップＳ３０２では、原因判定部３３は、ＥＣＵ３のメモリに記憶された顔向きの情報に基づいて、過去の画像において顔向き推定部３２によって推定されたドライバの顔向きが正面であるか否かを判定する。過去の画像は、ドライバの顔の検出状態が検出から非検出に変化するまでの所定数の画像である。なお、所定数は１であってもよい。すなわち、過去の画像は、ドライバの顔の検出状態が非検出に変化する直前の一つの画像であってもよい。
【００４４】
ステップＳ３０２において過去の画像においてドライバの顔向きが正面であると判定された場合、本制御ルーチンはステップＳ３０３に進む。ステップＳ３０３では、原因判定部３３は、ＥＣＵ３のメモリに記憶された検出情報に基づいて、過去の画像において顔検出部３１によって顔の下方領域の特徴点が抽出されていないか否かを判定する。
【００４５】
ステップＳ３０３において過去の画像において顔の下方領域の特徴点が抽出されていないと判定された場合、本制御ルーチンはステップＳ３０４に進む。ステップＳ３０４では、原因判定部３３は、ドライバの顔が検出されない原因がドライバの飲食動作であると判定する。ステップＳ３０４の後、本制御ルーチンは終了する。
【００４６】
一方、ステップＳ３０２において過去の画像において顔向きが正面以外であると判定された場合、又はステップＳ３０３において過去の画像において顔の下方領域の特徴点が抽出されたと判定された場合、本制御ルーチンはステップＳ３０５に進む。ステップＳ３０５では、原因判定部３３は、ドライバの顔が検出されない原因がドライバの異常であると判定する。ステップＳ３０５の後、本制御ルーチンは終了する。
【００４７】
＜警報処理＞
図７は、第一実施形態における警報処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ３によって所定の実行間隔で繰り返し実行される。所定の実行間隔は、例えば、撮像装置２からＥＣＵ３に画像が送信される間隔である。
【００４８】
最初に、ステップＳ４０１において、警報部３４は、顔検出部３１によってドライバの顔が検出されたか否かを判定する。ドライバの顔が検出されなかったと判定された場合、本制御ルーチンはステップＳ４０２に進む。
【００４９】
ステップＳ４０２では、警報部３４は、原因判定部３３によって判定された原因がドライバの飲食動作であるか否かを判定する。原因判定部３３によって判定された原因がドライバの飲食動作以外であると判定された場合、本制御ルーチンはステップＳ４０３に進む。ステップＳ４０３では、警報部３４はＨＭＩ等を介してドライバに警報を与える。ステップＳ４０３の後、本制御ルーチンは終了する。
【００５０】
一方、ステップＳ４０１においてドライバの顔が検出されたと判定された場合、又はステップＳ４０２において原因判定部３３によって判定された原因がドライバの飲食動作であると判定された場合、ドライバに警報が与えられることなく、本制御ルーチンは終了する。
【００５１】
なお、警報部３４は、ステップＳ４０２において原因判定部３３によって判定された原因がドライバの飲食動作であると判定された場合には、ステップＳ４０２において、原因判定部３３によって判定された原因がドライバの飲食動作以外であると判定された場合に比べて、警報の強度（例えば音量、文字の大きさ等）を小さくしてもよい。
【００５２】
＜第二実施形態＞
第二実施形態に係るドライバ監視装置の構成及び制御は、以下に説明する点を除いて、基本的に第一実施形態に係るドライバ監視装置の構成及び制御と同様である。このため、以下、本発明の第二実施形態について、第一実施形態と異なる部分を中心に説明する。
【００５３】
ドライバによる飲食が長時間継続されると、ドライバの注意力が低下し、ひいては車両１０の安全性が低下するおそれがある。このため、ドライバによる飲食が長時間継続された場合には、飲食の中止をドライバに促すことが望ましい。
【００５４】
第二実施形態では、警報部３４は、ドライバの顔の検出状態が未検出である状態が閾値時間以上継続した場合に、ドライバへ警報を与える。また、警報部３４は、ドライバの顔が検出されない原因がドライバの飲食動作であると判定された場合には、この原因がドライバの飲食動作以外であると判定された場合に比べて、ドライバへの警報を抑制する。具体的には、警報部３４は、ドライバの顔が検出されない原因がドライバの飲食動作であると判定された場合には、この原因がドライバの飲食動作以外であると判定された場合に比べて、閾値時間を長くする。このことによって、飲食時に警報が与えられることによるドライバの不快感を低減しつつ、長時間の飲食を抑制することができる。
【００５５】
＜警報処理＞
第二実施形態においても、第一実施形態と同様に図４〜図６の制御ルーチンが実行される。また、第二実施形態では、図７の制御ルーチンの代わりに図８の制御ルーチンが実行される。図８は、第二実施形態における警報処理の制御ルーチンを示すフローチャートである。本制御ルーチンはＥＣＵ３によって繰り返し実行される。
【００５６】
最初に、ステップＳ５０１において、警報部３４は、顔検出部３１によってドライバの顔が検出されたか否かを判定する。ドライバの顔が検出されたと判定された場合、本制御ルーチンは終了する。ドライバの顔が検出されなかったと判定された場合、本制御ルーチンはステップＳ５０２に進む。
【００５７】
ステップＳ５０２では、警報部３４は、原因判定部３３によって判定された原因がドライバの飲食動作であるか否かを判定する。原因判定部３３によって判定された原因がドライバの飲食動作以外であると判定された場合、本制御ルーチンはステップＳ５０３に進む。ステップＳ５０３では、警報部３４は、予め定められた初期値に閾値時間を設定する。
【００５８】
一方、ステップＳ５０２において原因がドライバの飲食動作であると判定された場合、本制御ルーチンはステップＳ５０４に進む。ステップＳ５０４では、警報部３４は、閾値時間を初期値よりも長い値に設定する。初期値よりも長い値は予め定められる。
【００５９】
ステップＳ５０３又はステップＳ５０４の後、ステップＳ５０５において、警報部３４は、ドライバの顔の検出状態が未検出である状態が閾値時間継続したか否かを判定する。ドライバの顔の検出状態が未検出である状態が閾値時間継続していないと判定された場合、本制御ルーチンは終了する。
【００６０】
一方、ステップＳ５０５においてドライバの顔の検出状態が未検出である状態が閾値時間継続したと判定された場合、本制御ルーチンはステップＳ５０６に進む。ステップＳ５０６では、警報部３４はＨＭＩ等を介してドライバに警報を与える。ステップＳ５０６の後、本制御ルーチンは終了する。
【００６１】
以上、本発明に係る好適な実施形態を説明したが、本発明はこれら実施形態に限定されるものではなく、特許請求の範囲の記載内で様々な修正及び変更を施すことができる。
【符号の説明】
【００６２】
１    ドライバ監視装置
２    撮像装置
３    ＥＣＵ
１０    車両
３１    顔検出部
３２    顔向き推定部
３３    原因判定部
３４    警報部
【図１】
2019212226.tif 000003
【図２】
2019212226.tif 000004
【図３】
2019212226.tif 000005
【図４】
2019212226.tif 000006
【図５】
2019212226.tif 000007
【図６】
2019212226.tif 000008
【図７】
2019212226.tif 000009
【図８】
2019212226.tif 000010