JP2022156503A - 車両のわき見監視装置 - Google Patents

Abstract

【課題】車両において、ドライバといった乗員のわき見の判定についての確からしさを高める。【解決手段】わき見監視装置１０は、車両１の乗員を含む撮像画像を撮像可能な撮像デバイス３６と、撮像画像に基づいて乗員のわき見を判定する判定部３４と、を有する。判定部３４は、乗員が向く可能性がある視認範囲を分割する複数のエリア４１～４８の中から、撮像画像において乗員が向いているエリアを判定し、判定したエリアごとの判定処理により、乗員のわき見を判定する。【選択図】図５

Description

本発明は、車両のわき見監視装置に関する。

特許文献１、２は、車両のドライバといった乗員についてのわき見を判定する車両のわき見監視装置を開示する。

特開２０１８－１０８７８４号公報 特開２０２０－０７７２２０号公報

ところで、ドライバといった乗員のわき見を判定する場合、基本的に、乗員の顔の向きに基づいてわき見を判定することになる。しかしながら、乗員の本当の視線方向は、顔の向きと異なる可能性がある。たとえば乗員は、顔を車両の進行方向である正面へ向けながら、視線を車内へ向けることができる。
このため、ドライバといった乗員のわき見の判定についての確からしさを高めるためには、顔の向きである顔方向に加えて、たとえば視線方向についても併せて判定に用いることが考えられる。しかしながら、乗員の視線は、撮像画像において必ずしも判定に用いることができる状態で撮像されるとは限らない。たとえば乗員が撮像デバイスとは逆へ顔を向けてしまうと、撮像デバイスの撮像画像に眼球を適切に含めることができない。この場合、顔方向と視線方向とに基づいたわき見の判定をしてしまうと、適切に撮像されていない眼球に基づいて視線方向を誤り、その結果としてわき見の判定を誤る可能性が高まる。

このように車両では、ドライバといった乗員のわき見の判定についての確からしさを高めることが求められている。

本発明に係る車両のわき見監視装置は、車両の乗員を含む撮像画像を撮像可能な撮像デバイスと、前記撮像画像に基づいて乗員のわき見を判定する判定部と、を有し、前記判定部は、乗員が向く可能性がある視認範囲を分割する複数のエリアの中から、前記撮像画像において乗員が向いているエリアを判定し、判定した前記エリアごとの判定処理により、乗員のわき見を判定する。

好適には、前記判定部は、乗員の顔が向いている顔方向を、前記撮像画像から特定し、乗員が向く可能性がある視認範囲を分割する複数のエリアの中から、特定した顔方向が向いているエリアを判定する、とよい。

好適には、前記視認範囲は、少なくとも、前記車両の進行方向の正面エリアと、前記正面エリアの周囲の周辺エリアとに分割される、とよい。

好適には、前記視認範囲は、少なくとも前記車両のピッチ方向または上下方向において複数の前記エリアに分割され、または、少なくとも前記車両のヨー方向または左右方向において複数の前記エリアに分割される、とよい。

好適には、前記判定部は、前記撮像画像に基づいて、乗員の顔が向いている顔方向とともに眼球が向いている視線方向を特定し、前記エリアごとの判定処理では、判定した前記エリアについての前記視認範囲での位置に応じて異なる判定処理を実行する、とよい。

好適には、前記判定部は、前記視認範囲を分割する複数の前記エリアの一部では、特定した前記顔方向と前記視線方向との双方を用いて、乗員のわき見を判定し、前記視認範囲を分割する複数の前記エリアの残りの一部では、特定した前記顔方向と前記視線方向との中の前記顔方向を用いずに前記視線方向のみを用いて、乗員のわき見を判定し、前記視認範囲を分割する複数の前記エリアの残部では、特定した前記顔方向と前記視線方向との中の前記視線方向を用いずに前記顔方向のみを用いて、乗員のわき見を判定する、とよい。

好適には、前記視線方向を用いずに前記顔方向のみを用いて乗員のわき見を判定する前記エリアは、前記視認範囲を前記車両のヨー方向または左右方向において分割する複数の前記エリアの少なくとも１つとして設けられる、とよい。

好適には、前記顔方向を用いずに前記視線方向のみを用いて乗員のわき見を判定する前記エリアは、前記視認範囲を前記車両のピッチ方向または上下方向において分割する複数の前記エリアの少なくとも１つとして設けられる、とよい。

本発明では、車両の乗員が向く可能性がある視認範囲について、複数のエリアが分割して設定されている。そして、車両の乗員を含む撮像画像を撮像可能な撮像デバイスの撮像画像に基づいて乗員のわき見を判定する判定部は、乗員が向く可能性がある視認範囲を分割する複数のエリアの中から、撮像画像において乗員が向いているエリアを判定し、判定したエリアごとの判定処理により、乗員のわき見を判定する。これにより、乗員のわき見は、各エリアと乗員との相対位置関係に応じて、エリアごとに設定されている判定処理により判定することが可能になる。乗員のわき見は、乗員が向く可能性がある視認範囲の全体において一律の判定処理により判定する必要が無くなる。
これに対し、乗員のたとえば顔や眼球の撮像状態は、乗員が向いている方向に応じて変化する。このため、仮にたとえば判定部が、乗員が向く可能性がある視認範囲の全体において一律のわき見の判定処理により判定する場合、乗員が向いている方向についてのわき見の判定の確からしさは、乗員が向いている方向によっては低下してしまう可能性がある。たとえば、わき見の判定処理が、顔の向いている顔方向と眼球の向いている視線方向との双方を用いた一律の判定処理であり、撮像画像において眼球がその視線方向を判別することができない状態で撮像されている場合、判定部は、眼球の向いている視線方向が撮像画像において不確かにしか特定できないことに起因して、わき見の判定を誤まってしまう可能性が生じ得る。
本発明では、乗員が向く可能性がある視認範囲を複数のエリアに分割して、そのエリアごとに異なる判定処理を実行可能であるため、このようなわき見の判定誤りの可能性を低減することが可能になる。本発明では、乗員のわき見の判定についての確からしさを高めて、わき見の判定誤りを抑制することが期待できる。

図１は、本発明の実施形態に係るわき見監視装置が適用される自動車の模式的な平面図である。 図２は、図１の自動車の模式的な縦断面図である。 図３は、図１の自動車においてわき見監視装置として機能する制御システムの説明図である。 図４は、図３の乗員監視装置のＣＰＵによる、乗員監視制御のフローチャートである。 図５は、本実施形態による図４のわき見判定についての詳細なフローチャートである。 図６は、ドライバの視認範囲を上下方向に分割する一例の複数のエリアの説明図である。 図７は、ドライバの視認範囲を左右方向に分割する一例の複数のエリアの説明図である。 図６および図７による複数のエリアを組み合わせ方の一例の説明図である。 図９Ａは、顔方向エリアがＦＲエリアと判定される場合に用いられるわき見判定処理の説明図である。 図９Ｂは、顔方向エリアがＦＦエリアと判定される場合に用いられるわき見判定処理の説明図である。 図９Ｃは、顔方向エリアがＦＣエリアと判定される場合に用いられるわき見判定処理の説明図である。 図９Ｄは、顔方向エリアがＦＳエリアと判定される場合に用いられるわき見判定処理の説明図である。 図９Ｅは、顔方向エリアがＦＬエリアと判定される場合に用いられるわき見判定処理の説明図である。

以下、本発明の実施形態を、図面に基づいて説明する。

図１は、本発明の実施形態に係るわき見監視装置が適用される自動車１の模式的な平面図である。
図２は、図１の自動車１の模式的な縦断面図である。
自動車１は、車両の一例である。

図１および図２の自動車１は、車体２を有する。車体２には、車室３が設けられる。車室３には、自動車１に乗るドライバなどの乗員が着座する複数列のシート４が設けられる。車室３において前列のシート４の前となる前部には、自動車１の車体２の左右方向へ延在するダッシュボード５が設けられる。ダッシュボード５には、ステアリングホイール７と、後述する乗員監視装置１１の車内カメラ３６とが設けられる。車室３の前面には、ダッシュボード５の上側に、フロントガラス６が設けられる。
車内カメラ３６は、ダッシュボード５の左右方向の中央部分に設けられる。
ステアリングホイール７は、ドライバが着座するシート４の前に位置するように、ダッシュボード５の左側部分に設けられる。
車体２の左右方向の中央部分には、ルームミラー８が設けられる。
ドライバは、自動車１のステアリングホイール７、アクセルペダル、ブレーキペダル、シフトレバーなどを操作して、自動車１の走行を操作する。

図３は、図１の自動車１においてわき見監視装置として機能する制御システム１０の説明図である。
図３の制御システム１０は、乗員監視装置１１、ＵＩ装置１２、走行支援装置１３、駆動装置１４、制動装置１５、操舵装置１６、および、これらが接続される車内ネットワーク１７、を有する。

車内ネットワーク１７は、自動車１のためのたとえばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＬＩＮ（Ｌｏｃａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｎｅｔｗｏｒｋ）に準拠した有線の通信ネットワークでよい。車内ネットワーク１７は、ＬＡＮなどの通信用ネットワークでも、これらを組み合わせたものであってもよい。車内ネットワーク１７の一部には、無線方式の通信ネットワークが含まれてもよい。車内ネットワーク１７に接続される各種の装置１１～１６は、車内ネットワーク１７を通じて、相互にデータを送受する。車内ネットワーク１７において送受されるデータは、たとえば暗号化されて、送信元の装置のＩＤ、送信先の装置のＩＤ、を付加されたパケットデータとして、車内ネットワーク１７を通じて送受されてよい。

駆動装置１４は、たとえば動力源を有し、自動車１を加速させるための駆動力を発生する。駆動装置１４は、ガソリンやエタノールを燃焼する内燃機関、蓄電電力などを用いる電気モータ、水素を用いる動力源、または、これらを組み合わせたハイブリットの動力源による駆動力を発生するものでよい。駆動装置１４は、たとえばアクセルペダルの操作量に応じた駆動力を発生してよい。

制動装置１５は、たとえばブレーキ装置を有し、自動車１を減速停止させるための制動力を発生する。制動装置１５は、たとえばブレーキペダルの操作量に応じた制動力を発生してよい。

操舵装置１６は、たとえば操舵機構を有し、自動車１の進行方向を変更する。たとえばステアリングホイール７の操作量に応じた操舵量により、自動車１の進行方向を変更してよい。

走行支援装置１３は、ドライバの操作を支援して、自動車１の走行を制御する。走行支援装置１３は、ドライバの操作量に対応する制御指令を、駆動装置１４、制動装置１５および操舵装置１６へ出力しても、ドライバの操作量から調整した制御指令を、駆動装置１４、制動装置１５および操舵装置１６へ出力しても、ドライバの操作量がない自動運転状態において駆動装置１４、制動装置１５および操舵装置１６へ制御指令を出力しても、よい。

ＵＩ装置１２は、ドライバなどの乗員とのユーザインタフェース装置である。ＵＩ装置１２には、たとえば操作デバイス２１、表示デバイス２２、音入力デバイス２３、音出力デバイス２４、といったユーザインタフェースデバイスが接続される。
表示デバイス２２は、たとえば液晶デバイスである。表示デバイス２２は、ダッシュボード５の左右方向中央部分や、ドライバの前側位置などに設けられてよい。
操作デバイス２１は、たとえば液晶デバイスの表示画面に重ねて設けられるタッチパネル、各種のボタン、スイッチでよい。
音入力デバイス２３は、たとえばマイクロホンである。
音出力デバイス２４は、たとえばスピーカである。
このようなＵＩ装置１２は、制御システム１０の他の装置１１，１３～１６から取得した情報を、表示デバイス２２や音出力デバイス２４から出力してよい。
また、ＵＩ装置１２は、操作デバイス２１に対する操作、または音入力デバイス２３への音声指示があると、それに応じた情報を生成して、制御システム１０の他の装置１１，１３～１６へ出力する。

乗員監視装置１１は、自動車１の車室３においてシート４に着座しているドライバを含む乗員を識別して監視する。ドライバなどの乗員は、安全のために基本的に、走行する自動車１の周囲に注意することが求められる。しかしながら、ドライバなどの乗員は、特に自動運転などにおいては、自動車１の進行方向以外へわき見をしたり、居眠りをしたり、突然の発作を生じたり、する可能性がある。乗員監視装置１１は、これらの事態の発生を監視して、それに対応する制御をたとえば走行支援装置１３といった制御システム１０に実行させる。
乗員監視装置１１は、入出力部３１、タイマ３２、メモリ３３、ＣＰＵ３４、投光ＬＥＤ３５、車内カメラ３６、および、これらが接続されるシステムバス３７、を有する。
なお、制御システム１０の他の装置１２～１６も、乗員監視装置１１と同様に、入出力部、タイマ、メモリ、ＣＰＵ、および、これらが接続されるシステムバス、を有してよい。

車内カメラ３６は、図１および図２に示すように、ダッシュボード５の左右方向中央部分において、後側を撮像するように設けられる。車内カメラ３６は、撮像デバイスとして、車室３にいるドライバなどの乗員を含む撮像画像を撮像可能である。

投光ＬＥＤ３５は、車内カメラ３６により撮像するドライバなどの乗員へ、たとえば赤外線光を照射する。投光ＬＥＤ３５は、ダッシュボード５の左右方向中央部分において、車内カメラ３６と並べて設けられてよい。

入出力部３１は、車内ネットワーク１７に接続される。入出力部３１は、車内ネットワーク１７を通じて、制御システム１０の他の装置との間でデータを入出力する。

タイマ３２は、時刻、時間を計測する。

メモリ３３は、ＣＰＵ３４が実行するプログラム、および各種のデータを記録する。メモリ３３は、不揮発性メモリ、揮発性メモリ、またはこれらの組み合わせでよい。不揮発性メモリには、たとえば、ＥＥＰＲＯＭやＳＳＤなどのデータ保持機能を備える半導体メモリ、ハードディスクドライブ、がある。揮発性メモリには、たとえばＲＡＭなどの半導体メモリがある。

ＣＰＵ３４は、メモリ３３に記録されているプログラムを読み込んで実行する。これにより、ＣＰＵ３４は、乗員監視装置１１の制御部として機能する。
乗員監視装置１１の制御部としてのＣＰＵ３４は、車内カメラ３６の撮像および投光ＬＥＤ３５の投光を制御する。
ＣＰＵ３４は、車内カメラ３６により撮像された撮像画像などに基づいて、車室３にいるドライバなどの乗員を識別して監視する。
ＣＰＵ３４は、たとえば撮像画像に基づいてドライバがわき見または居眠りをしていると判定すると、ドライバへ向けて警報を発し、警報後においても状況が変化しない場合には自動車１を路肩に減速停止させる制御の実行を走行支援装置１３に指示する。

図４は、図３の乗員監視装置１１のＣＰＵ３４による、乗員監視制御のフローチャートである。
乗員監視装置１１のＣＰＵ３４は、図４の乗員監視制御を、繰り返し実行する。

ステップＳＴ１において、ＣＰＵ３４は、車内カメラ３６による新たな撮像がなされたか否かを判断する。撮像カメラは、周期的に車内を撮像する。車内カメラ３６により新たな撮像がなされていない場合、ＣＰＵ３４は、本処理を繰り返す。車内カメラ３６により新たな撮像がなされている場合、ＣＰＵ３４は、処理をステップＳＴ２へ進める。

ステップＳＴ２において、ＣＰＵ３４は、新たな撮像画像に基づいて、ドライバなどの乗員の乗車を判断する。ＣＰＵ３４は、たとえば過去の撮像画像と新たな撮像画像とを比較し、差分が生じている撮像部分についての顔パターン認識などにより、ドライバなどの乗員が乗車していることを判断してよい。ドライバなどの乗員が乗車していない場合、ＣＰＵ３４は、処理をステップＳＴ１へ戻す。ドライバなどの乗員が乗車すると、ＣＰＵ３４は、処理をステップＳＴ３へ進める。

ステップＳＴ３において、ＣＰＵ３４は、自動車１が走行中であるか否かを判断する。ＣＰＵ３４は、たとえば自動車１に設けられる不図示の速度センサ、加速度センサ、ＧＰＳ受信機の検出値に基づいて、自動車１が走行中であるか否かを判断してよい。自動車１が走行中でない場合、ＣＰＵ３４は、処理をステップＳＴ１へ戻す。自動車１が走行中である場合、ＣＰＵ３４は、処理をステップＳＴ４へ進める。

ステップＳＴ４において、ＣＰＵ３４は、新たな撮像画像に基づいて、ドライバのわき見を判定する。ＣＰＵ３４は、ドライバ以外の乗員についてもわき見を判定してよい。

ステップＳＴ５において、ＣＰＵ３４は、新たな撮像画像に基づいて、ドライバの居眠りを判定する。ＣＰＵ３４は、ドライバ以外の乗員についても居眠りを判定してよい。

ステップＳＴ６において、ＣＰＵ３４は、新たな撮像画像に基づいて、ドライバを含む乗員の緊急状態を判定する。ドライバを含む乗員は、自動車１の走行中に、心筋梗塞、脳溢血などを発症することがある。撮像画像が赤外線成分を含む場合、赤外線の画像成分には各乗員の血流の情報が含まれる。ＣＰＵ３４は、血流から判断可能な脈拍が正常値範囲内であるか否かを判断してよい。ＣＰＵ３４は、撮像画像におけるドライバが運転姿勢などについて判断することにより、緊急状態を判定してもよい。たとえばドライバの頭部が下がっている場合、ＣＰＵ３４は、その撮像画像に基づいて緊急状態を判定してよい。

ステップＳＴ７において、ＣＰＵ３４は、警報が必要であるか否かを判断する。ＣＰＵ３４は、たとえばドライバのわき見または居眠りが判定されている場合、ドライバを含む乗員の緊急状態が判定されている場合、警報が必要であると判断し、処理をステップＳＴ８へ進める。これらの緊急状態が判定されていない場合、ＣＰＵ３４は、ステップＳＴ８の処理を飛ばして、処理をステップＳＴ９へ進める。

ステップＳＴ８において、ＣＰＵ３４は、ドライバを含む乗員に対して、警報を出力する。ＣＰＵ３４は、たとえばＵＩ装置１２へ警報を出力する。ＵＩ装置１２は、表示デバイス２２および音出力デバイス２４に、警報を出力する。これにより、ドライバを含む乗員の注意が喚起される。ドライバを含む乗員は、ドライバについてはわき見や居眠りを止めさせて運転に適した状態に復帰させ得る。また、ドライバを含む乗員は、緊急状態にある他の乗員に気づいて、その介護などを実施し得る。

ステップＳＴ９において、ＣＰＵ３４は、緊急状態があるか否かを判断する。ステップＳＴ６において緊急状態が判定されている場合、ステップＳＴ８の警報後においてもドライバが運転に適した状態に復帰しない場合、ＣＰＵ３４は、緊急状態があると判断し、処理をステップＳＴ１０へ進める。これらの緊急状態がない場合、ＣＰＵ３４は、ステップＳＴ１０の処理を飛ばして、本制御を終了する。

ステップＳＴ１０において、ＣＰＵ３４は、緊急処理を実行する。ＣＰＵ３４は、たとえば運転支援装置に対して、緊急停止を指示する。運転支援装置は、自動車１を減速させて走行中の車線または路肩に停車させる自動運転制御を実行する。ＣＰＵ３４は、この他にもたとえば、不図示の無線装置に対して、緊急通報を指示する。自動車１の無線装置は、予め定められた無線通信により、たとえば基地局を通じて緊急対応機関のサーバ装置へ緊急通報を実行する。これにより、救急隊などは、即時的に自動車１がいる現場へ急行することができる。

ところで、撮像画像に基づいてドライバなどのわき見を判定する場合、ＣＰＵ３４は、基本的に、乗員の顔の向きに基づいてわき見を判定すればよい。しかしながら、乗員の本当の視線方向は、顔の向きと異なる可能性がある。たとえば乗員は、顔を自動車１の進行方向である正面へ向けながら、視線を左右方向へ向けることができる。
このため、ドライバといった乗員のわき見の判定についての確からしさを高めるためには、顔の向きである顔方向に加えて、たとえば視線方向についても併せて判定に用いることが望ましいと考えられる。しかしながら、乗員の視線は、撮像画像において必ずしも高い確からしさで判定できるように撮像されているとは限らない。たとえば乗員が車内カメラ３６とは逆の方向へ顔を向けてしまうと、撮像画像には眼球の像が含まれなくなる。このように眼球の像が含まれない撮像画像について、顔方向と眼球による視線方向とに基づいたわき見判定処理を実行してしまうと、わき見判定処理が正しく実行できなくなる。眼球による視線方向に基づくわき見判定を無理に実行してしまうと、撮像されていない眼球についての視線方向を誤って判定してしまうことになり、その結果として、わき見の判定を誤ってしまう可能性が高くなる。
このように自動車１では、ドライバといった乗員のわき見の判定についての確からしさを高めることが求められている。

図５は、本実施形態による図４のわき見判定についての詳細なフローチャートである。
乗員監視装置１１のＣＰＵ３４は、図４の乗員監視制御において、図５のわき見判定処理を繰り返し実行する。

ステップＳＴ２１において、ＣＰＵ３４は、撮像画像に含まれるドライバの顔の像に基づいて、顔方向（角度）を特定する。ドライバの顔が向いている方向が変化すると、撮像画像に含まれるドライバの顔の像も変化する。ＣＰＵ３４は、撮像画像に含まれるドライバの顔の像の状態を解析することにより、顔方向（角度）を特定してよい。ＣＰＵ３４は、たとえばドライバが自動車１の正面をまっすぐに向いている方向を基準として、顔方向の角度を特定してよい。

ステップＳＴ２２において、ＣＰＵ３４は、撮像画像に含まれるドライバの眼球の像に基づいて、視線顔方向（角度）を特定する。ドライバの顔方向や顔において眼鏡が向いている方向が変化すると、撮像画像に含まれるドライバの眼球の像も変化する。ＣＰＵ３４は、撮像画像に含まれるドライバの眼球の像の状態を解析することにより、視線方向（角度）を特定してよい。ＣＰＵ３４は、たとえばドライバが自動車１の正面をまっすぐに向いている方向を基準として、視線方向の角度を特定してよい。

ステップＳＴ２３において、ＣＰＵ３４は、シート４に着座した状態でドライバが顔を向ける可能性がある視認範囲を分割する複数のエリアの中から、撮像画像においてドライバの顔が向いている顔方向のエリアを判定する。シート４に着座した状態でドライバが顔を向ける可能性がある視認範囲は、基本的に、シート４より前側の範囲となる。視認範囲は、最低限として、自動車１の走行中にドライバが視線を向ける自動車１の進行方向の正面エリアと、正面エリアの周囲の周辺エリアとに分割されればよい。この場合、ＣＰＵ３４は、顔方向が正面エリアの範囲内であるか否かを判断することにより、ドライバの顔が向いている顔方向のエリアを判定できる。
なお、ＣＰＵ３４は、ステップＳＴ２３のエリア判定において、顔方向のエリアとともに、視線方向のエリアを判定してもよい。ＣＰＵ３４は、ステップＳＴ２３のエリア判定において、顔方向と視線方向とを組み合わせた方向のエリアを判定してもよい。

ステップＳＴ２４において、ＣＰＵ３４は、ドライバの顔が向いている顔方向エリアが、顔方向と視線方向との中の、顔方向のみで判定するエリアであるか否かを判断する。顔方向エリアが顔方向のみで判定するエリアでない場合、ＣＰＵ３４は、処理をステップＳＴ２５へ進める。顔方向エリアが顔方向のみで判定するエリアである場合、ＣＰＵ３４は、処理をステップＳＴ２６へ進める。

ステップＳＴ２５において、ＣＰＵ３４は、ドライバの顔が向いている顔方向エリアが、視線方向のみで判定するエリアであるか否かを判断する。顔方向エリアが視線方向のみで判定するエリアでない場合、ＣＰＵ３４は、処理をステップＳＴ２８へ進める。顔方向エリアが視線方向のみで判定するエリアである場合、ＣＰＵ３４は、処理をステップＳＴ２７へ進める。

ステップＳＴ２６において、ＣＰＵ３４は、ドライバの顔方向のみに基づいて、ドライバのわき見を判定する。その後、ＣＰＵ３４は、処理をステップＳＴ２９へ進める。

ステップＳＴ２７において、ＣＰＵ３４は、ドライバの視線方向のみに基づいて、ドライバのわき見を判定する。その後、ＣＰＵ３４は、処理をステップＳＴ２９へ進める。

ステップＳＴ２８において、ＣＰＵ３４は、ドライバの顔方向に基づいてドライバのわき見を判定するとともに、ドライバの視線方向に基づいてドライバのわき見を判定する。そして、双方の中のいずれか一方においてドライバのわき見が判定されている場合、ＣＰＵ３４は、ドライバにわき見があると判定する。双方のいずれにおいてもドライバのわき見が判定されていない場合、ＣＰＵ３４は、ドライバにわき見がないと判定する。その後、ＣＰＵ３４は、処理をステップＳＴ２９へ進める。
このステップＳＴ２４からステップＳＴ２８の処理により、ＣＰＵ３４は、判定したエリアごとの判定処理により、ドライバのわき見を判定することができる。
ＣＰＵ３４は、エリアごとの判定処理において、視認範囲を分割する複数のエリアのすべてにおいて一律の判定処理を実行するのではなく、判定したエリアについての視認範囲での位置に応じて異なる判定処理を実行することができる。

ステップＳＴ２９において、ＣＰＵ３４は、ドライバについてわき見があると判定されているか否かを判断する。ドライバのわき見がある場合、ＣＰＵ３４は、処理をステップＳＴ３０へ進める。ドライバのわき見がない場合、ＣＰＵ３４は、処理をステップＳＴ３１へ進める。

ステップＳＴ３０において、ＣＰＵ３４は、ドライバのわき見があることを示すわき見情報を、メモリ３３に記録する。

ステップＳＴ３１において、ＣＰＵ３４は、ドライバのわき見がないことを示す非わき見情報を、メモリ３３に記録する。

ＣＰＵ３４は、図４のステップＳＴ４において図５の処理を繰り返し実行する。これにより、メモリ３３には、繰り返し撮像される撮像画像に基づいて、ドライバのわき見の判定結果が蓄積して記録される。
また、ＣＰＵ３４は、メモリ３３に蓄積されているドライバのわき見の判定結果の履歴を用いて、図４のステップＳＴ７の警報の要否の判断と、ステップＳＴ９の緊急状態の判断を実行できる。
たとえば最新のドライバのわき見の判定結果が、ドライバのわき見があることを示すわき見情報である場合、ＣＰＵ３４は、ステップＳＴ７において警報要と判断し、ステップＳＴ８においてドライバを含む乗員に対して警報を出力することができる。
この他にもたとえば、最近の複数のドライバのわき見の判定結果が、ドライバのわき見があることを示すわき見情報であり続ける場合、ＣＰＵ３４は、ステップＳＴ９において緊急状態と判断し、ステップＳＴ１０において緊急処理を実行することができる。

次に、ステップＳＴ２３の判断で用いる複数のエリアについて説明する。上述した説明では、シート４に着座した状態でドライバが顔を向ける可能性がある視認範囲が、自動車１の走行中にドライバが視線を向ける自動車１の進行方向の正面エリアと、正面エリアの周囲の周辺エリアとの２つのエリアに分けられた状態を説明している。以下においては、現実的に利用可能な具体的な複数のエリアについて説明する。

図６は、ドライバの視認範囲を上下方向に分割する一例の複数のエリアの説明図である。
図６には、図２と同様の自動車１の模式的な縦断面図の上に、ドライバの視認範囲を上下方向または自動車１のピッチ方向において分割する複数のエリアが示されている。ここで、複数のエリアは、Ｕエリア、Ｆエリア、Ｂ１エリア、Ｂ２エリア、である。

Ｆエリアは、自動車１の運転操作をするドライバが運転中に自動車１の進行方向を確認する際に顔を向けて視認する正面エリアである。Ｆエリアは、自動車１のフロントガラス６と重なる範囲としてよい。

Ｕエリアは、Ｆエリアの上側の上エリアである。自動車１の運転操作をするドライバは、基本的に、自動車１のフロントガラス６より上側となるＵエリアへ、自動車１の運転操作中に顔を向けて視認する必要はない。

Ｂ１エリアは、Ｆエリアの下側の第一下エリアである。Ｂ１エリアは、ダッシュボード５と重なる範囲としてよい。自動車１の運転操作をするドライバは、運転中に自動車１の走行状態を確認するために一時的にダッシュボード５にあるメータや表示デバイス２２へ顔を向けて視認することがある。

Ｂ２エリアは、Ｂ１エリアの下側の第二下エリアである。Ｂ２エリアは、ダッシュボード５の下側の範囲としてよい。自動車１の運転操作をするドライバは、基本的に、自動車１のダッシュボード５より下側となるＢ２エリアへ、自動車１の運転操作中に顔を向けて視認する必要はない。

このようにシート４に着座した状態でドライバが顔を向ける可能性がある、シート４より前側の視認範囲は、上から順番に、Ｕエリア、Ｆエリア、Ｂ１エリア、およびＢ２エリアの４つのエリアに分割するとよい。

図７は、ドライバの視認範囲を左右方向に分割する一例の複数のエリアの説明図である。
図７には、図１と同様の自動車１の模式的な平面図の上に、ドライバの視認範囲を左右方向または自動車１のヨー方向において分割する複数のエリアが示されている。ここで、複数のエリアは、ＦＲエリア、ＦＦエリア、ＦＣエリア、ＦＳエリア、ＦＬエリア、である。

ＦＦエリアは、自動車１の運転操作をするドライバが運転中に自動車１の進行方向を確認する際に顔を向けて視認する正面エリアである。ＦＦエリアは、自動車１のフロントガラス６についてのステアリングホイール７側の略右半分となる範囲でよい。

ＦＲエリアは、ＦＦエリアの右側の右端エリアである。自動車１の運転操作をするドライバは、基本的に、自動車１の右側のドアミラー９において後方確認をしたり、自動車１の右側を確認したりする場合において一時的に顔や視線を向ける。

ＦＣエリアは、ＦＦエリアの左側の中央エリアである。ＦＣエリアは、自動車１のフロントガラス６についての中央部分となる範囲でよい。自動車１の運転操作をするドライバは、ダッシュボード５やルームミラー８を確認する際に、自動車１の中央部分へ一時的に顔や視線を向ける。

ＦＳエリアは、ＦＣエリアの左側の左エリアである。ＦＳエリアは、自動車１のフロントガラス６についての略左半分となる範囲でよい。自動車１の運転操作をするドライバは、自動車１の左前側を確認する場合に、自動車１の左側へ一時的に顔や視線を向ける。

ＦＬエリアは、ＦＳエリアの左側の左端エリアである。自動車１の運転操作をするドライバは、基本的に、自動車１の左側のドアミラー９において後方確認をしたり、自動車１の左側を確認したりする場合において一時的に顔や視線を向ける。

このようにシート４に着座した状態でドライバが顔を向ける可能性がある、シート４より前側の視認範囲は、右から順番に、ＦＲエリア、ＦＦエリア、ＦＣエリア、ＦＳエリア、ＦＬエリア、の５つのエリアに分割するとよい。

図８は、図６および図７による複数のエリアを組み合わせ方の一例の説明図である。

図８では、図６において上下方向において上から二番目のＦエリアが、図７と同様に、ＦＲエリア４２、ＦＦエリア４３、ＦＣエリア４４、ＦＳエリア４５、ＦＬエリア４６、の５つのエリアに分割されている。
その結果、図８には、Ｕエリア４１、ＦＲエリア４２、ＦＦエリア４３、ＦＣエリア４４、ＦＳエリア４５、ＦＬエリア４６、Ｂ１エリア４７、Ｂ２エリア４８、の８つのエリアが示されている。
フロントガラス６には、ＦＦエリア４３、ＦＣエリア４４、ＦＳエリア４５、の３つのエリアが重なっている。ＦＦエリア４３の右側にあるＦＲエリア４２は、右側のドアミラー９と重なっている。ＦＳエリア４５の左側にあるＦＬエリア４６は、左側のドアミラー９と重なっている。
ＦＲエリア４２、ＦＦエリア４３、ＦＣエリア４４、ＦＳエリア４５、ＦＬエリア４６、の上側にはＵエリア４１が設けられ、下側にはＢ１エリア４７が設けられる。Ｂ１エリア４７の下側には、Ｂ２エリア４８が設けられる。
このように図８の視認範囲は、自動車１のピッチ方向または上下方向において複数のエリアに分割され、かつ、自動車１のヨー方向または左右方向において複数のエリアに分割されている。

ここで、図８のＵエリア４１は、ドライバの顔方向および視線方向の中の顔方向のみにより、わき見を判定するエリアとされる。
ＦＲエリア４２は、ドライバの顔方向のみにより、わき見を判定するエリアとされる。
ＦＦエリア４３は、ドライバの顔方向および視線方向の双方により、わき見を判定するエリアとされる。
ＦＣエリア４４は、ドライバの顔方向のみにより、わき見を判定するエリアとされる。
ＦＳエリア４５は、ドライバの顔方向および視線方向の双方により、わき見を判定するエリアとされる。
ＦＬエリア４６は、ドライバの顔方向のみにより、わき見を判定するエリアとされる。
Ｂ１エリア４７は、ドライバの視線方向のみにより、わき見を判定するエリアとされる。
Ｂ２エリア４８は、ドライバの顔方向のみにより、わき見を判定するエリアとされる。

このようにシート４に着座した状態でドライバが顔を向ける可能性がある視認範囲は、複数のエリア４１～４８に分けられる。
ＣＰＵ３４は、図５のステップＳＴ２３において、図６、図７、または図８の複数のエリア４１～４８の中から、ドライバの顔方向が向いている顔方向エリアを判定する。
また、ＣＰＵ３４は、ステップＳＴ２４からステップＳＴ２５において、ドライバの顔方向が含まれているとして判定した顔方向エリアが、顔方向のみによりわき見を判定するエリアであるのか、視線方向のみによりわき見を判定するエリアであるのか、顔方向および視線方向の双方によりわき見を判定するエリアであるのか、を判断する。

そして、顔方向を含むとして判定した顔方向エリアがＵエリア４１である場合、ＣＰＵ３４は、ドライバの顔方向のみにより、ドライバのわき見を判定する。
図６に示すように、自動車１の運転操作をするドライバは、運転中において基本的に自動車１のフロントガラス６からダッシュボード５までの範囲内で顔および視線を向けている。この運転中において視認する上下視認エリアは、ドライバがわき見をしていない非わき見角度範囲となる。非わき見角度範囲の上側または下側へドライバの顔または視線が向いている場合、ドライバは基本的にわき見をしていることになる。
この場合、ＣＰＵ３４は、たとえば、ドライバの顔方向が、非わき見角度範囲に含まれるか否かを判断して、ドライバの顔方向のみによりわき見を判定してよい。
ドライバの顔方向が非わき見角度範囲に含まれている場合、ＣＰＵ３４は、ドライバはわき見をしていないと判定してよい。
ドライバの顔方向が非わき見角度範囲に含まれていない場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。

顔方向を含むとして判定した顔方向エリアがＢ１エリア４７である場合、ＣＰＵ３４は、ドライバの視線方向のみにより、ドライバのわき見を判定する。
この場合、ＣＰＵ３４は、たとえば、ドライバの視線方向が、非わき見角度範囲に含まれるか否かを判断して、ドライバの視線方向のみによりわき見を判定してよい。
ドライバの視線方向が非わき見角度範囲に含まれていない場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。
ドライバの視線方向が非わき見角度範囲に含まれている場合、ＣＰＵ３４は、ドライバはわき見をしていないと判定してよい。
なお、ドライバの視線方向が非わき見角度範囲に含まれていても、タイマ３２により計測可能な所定期間において連続してダッシュボード５の方向へ視線が向いている場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。ＣＰＵ３４は、たとえば３回以上連続してダッシュボード５の方向へ視線が向いている場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。
顔方向を用いずに視線方向のみを用いてドライバのわき見を判定するＢ１エリア４７は、視認範囲を自動車１のピッチ方向または上下方向において分割する複数のエリアの少なくとも１つとして設けられている。

顔方向を含むとして判定した顔方向エリアがＢ２エリア４８である場合、ＣＰＵ３４は、ドライバの顔方向のみにより、ドライバのわき見を判定する。
この場合、ＣＰＵ３４は、たとえば、ドライバの顔方向が、非わき見角度範囲に含まれるか否かを判断して、ドライバの顔方向のみによりわき見を判定してよい。
ドライバの顔方向が非わき見角度範囲に含まれていない場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。
ドライバの顔方向が非わき見角度範囲に含まれている場合、ＣＰＵ３４は、ドライバはわき見をしていないと判定してよい。

図９は、図６のＦエリアにおいて左右方向に並ぶ複数のエリアごとのわき見判定処理の説明図である。
図９Ａは、顔方向エリアがＦＲエリア４２と判定される場合に用いられるわき見判定処理の説明図である。
図９Ｂは、顔方向エリアがＦＦエリア４３と判定される場合に用いられるわき見判定処理の説明図である。
図９Ｃは、顔方向エリアがＦＣエリア４４と判定される場合に用いられるわき見判定処理の説明図である。
図９Ｄは、顔方向エリアがＦＳエリア４５と判定される場合に用いられるわき見判定処理の説明図である。
図９Ｅは、顔方向エリアがＦＬエリア４６と判定される場合に用いられるわき見判定処理の説明図である。

顔方向を含むとして判定した顔方向エリアがＦＲエリア４２である場合、ＣＰＵ３４は、ドライバの顔方向のみにより、ドライバのわき見を判定する。
この場合、ＣＰＵ３４は、図９Ａに示す顔方向についての非わき見角度範囲ＲＦと、視線方向についての非わき見角度範囲ＲＥと、の中の、実線で示す非わき見角度範囲ＲＦのみに基づいて、ドライバのわき見を判定する。
ＣＰＵ３４は、たとえばドライバの顔方向が、図９Ａの非わき見角度範囲ＲＦに含まれるか否かを判断して、わき見を判定してよい。
ドライバの顔方向が図９Ａの非わき見角度範囲ＲＦに含まれていない場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。
ドライバの顔方向が図９Ａの非わき見角度範囲ＲＦに含まれている場合、ＣＰＵ３４は、ドライバはわき見をしていないと判定してよい。
視線方向を用いずに顔方向のみを用いてドライバのわき見を判定するＦＲエリア４２は、視認範囲を自動車１のヨー方向または左右方向において分割する複数のエリア４２～４６の少なくとも１つとして設けられている。

顔方向を含むとして判定した顔方向エリアがＦＦエリア４３である場合、ＣＰＵ３４は、ドライバの顔方向および視線方向の双方により、ドライバのわき見を判定する。
この場合、ＣＰＵ３４は、図９Ｂに示す顔方向についての非わき見角度範囲ＲＦと、視線方向についての非わき見角度範囲ＲＥと、の各々を用いて、ドライバのわき見を判定する。
ＣＰＵ３４は、たとえばドライバの顔方向が、図９Ｂの非わき見角度範囲ＲＦに含まれるか否かを判断するとともに、ドライバの視線方向が、図９Ｂの非わき見角度範囲ＲＥに含まれるか否かを判断して、わき見を判定してよい。
ドライバの顔方向が図９Ｂの非わき見角度範囲ＲＦに含まれ、かつ、視線方向が図９Ｂの非わき見角度範囲ＲＥに含まれている場合、ＣＰＵ３４は、ドライバはわき見をしていないと判定してよい。
それ以外の場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。

顔方向を含むとして判定した顔方向エリアがＦＣエリア４４である場合、ＣＰＵ３４は、ドライバの顔方向のみにより、ドライバのわき見を判定する。
この場合、ＣＰＵ３４は、図９Ｃに示す顔方向についての非わき見角度範囲ＲＦと、視線方向についての非わき見角度範囲ＲＥと、の中の、実線で示す非わき見角度範囲ＲＦのみに基づいて、ドライバのわき見を判定する。
ＣＰＵ３４は、たとえばドライバの顔方向が、図９Ｃの非わき見角度範囲ＲＦに含まれるか否かを判断して、わき見を判定してよい。
ドライバの顔方向が図９Ｃの非わき見角度範囲ＲＦに含まれていない場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。
ドライバの顔方向が図９Ｃの非わき見角度範囲ＲＦに含まれている場合、ＣＰＵ３４は、ドライバはわき見をしていないと判定してよい。
視線方向を用いずに顔方向のみを用いてドライバのわき見を判定するＦＣエリア４４は、視認範囲を自動車１のヨー方向または左右方向において分割する複数のエリア４２～４６の少なくとも１つとして設けられている。

顔方向を含むとして判定した顔方向エリアがＦＳエリア４５である場合、ＣＰＵ３４は、ドライバの顔方向および視線方向の双方により、ドライバのわき見を判定する。
この場合、ＣＰＵ３４は、図９Ｄに示す顔方向についての非わき見角度範囲ＲＦと、視線方向についての非わき見角度範囲ＲＥと、の各々を用いて、ドライバのわき見を判定する。
図９Ｄに示す顔方向についての非わき見角度範囲ＲＦは、図９Ａから図９Ｃに示す顔方向についての非わき見角度範囲ＲＦと比べて、左向きに設定される。
図９Ｄに示す視線方向についての非わき見角度範囲ＲＥは、図９Ａから図９Ｃに示す視線方向についての非わき見角度範囲ＲＥと比べて、左向きに設定される。
ＣＰＵ３４は、たとえばドライバの顔方向が、図９Ｄの非わき見角度範囲ＲＦに含まれるか否かを判断するとともに、ドライバの視線方向が、図９Ｄの非わき見角度範囲ＲＥに含まれるか否かを判断して、わき見を判定してよい。
ドライバの顔方向が図９Ｄの非わき見角度範囲ＲＦに含まれ、かつ、視線方向が図９Ｄの非わき見角度範囲ＲＥに含まれている場合、ＣＰＵ３４は、ドライバはわき見をしていないと判定してよい。
それ以外の場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。

顔方向を含むとして判定した顔方向エリアがＦＬエリア４６である場合、ＣＰＵ３４は、ドライバの顔方向のみにより、ドライバのわき見を判定する。
この場合、ＣＰＵ３４は、図９Ｅに示す顔方向についての非わき見角度範囲ＲＦと、視線方向についての非わき見角度範囲ＲＥと、の中の、実線で示す非わき見角度範囲ＲＦのみに基づいて、ドライバのわき見を判定する。
ＣＰＵ３４は、たとえばドライバの顔方向が、図９Ｅの非わき見角度範囲ＲＦに含まれるか否かを判断して、わき見を判定してよい。
ドライバの顔方向が図９Ｅの非わき見角度範囲ＲＦに含まれていない場合、ＣＰＵ３４は、ドライバはわき見をしていると判定してよい。
ドライバの顔方向が図９Ｅの非わき見角度範囲ＲＦに含まれている場合、ＣＰＵ３４は、ドライバはわき見をしていないと判定してよい。
視線方向を用いずに顔方向のみを用いてドライバのわき見を判定するＦＬエリア４６は、視認範囲を自動車１のヨー方向または左右方向において分割する複数のエリア４２～４６の少なくとも１つとして設けられている。

このようにＣＰＵ３４は、判定部として、視認範囲を分割する複数のエリア４１～４８の一部（４３，４５）では、特定した顔方向と視線方向との双方を用いて、ドライバのわき見を判定する。また、ＣＰＵ３４は、視認範囲を分割する複数のエリア４１～４８の残りの一部（４７）では、特定した顔方向と視線方向との中の顔方向を用いずに視線方向のみを用いて、ドライバのわき見を判定する。また、ＣＰＵ３４は、視認範囲を分割する複数のエリア４１～４８の残部（４１，４２，４４，４６，４８）では、特定した顔方向と視線方向との中の視線方向を用いずに顔方向のみを用いて、ドライバのわき見を判定する。

以上のように、本実施形態では、自動車１のドライバが向く可能性がある視認範囲について、複数のエリア４１～４８が分割して設定されている。そして、自動車１のドライバを含む撮像画像を撮像可能な撮像デバイスの撮像画像に基づいてドライバのわき見を判定する判定部としてのＣＰＵ３４は、ドライバが向く可能性がある視認範囲を分割する複数のエリア４１～４８の中から、撮像画像においてドライバが向いている顔向きエリアを判定し、判定したエリアごとの判定処理により、ドライバのわき見を判定する。これにより、ドライバのわき見は、各エリアとドライバとの相対位置関係に応じて、エリアごとに設定されている判定処理により判定することが可能になる。ドライバのわき見は、ドライバが向く可能性がある視認範囲の全体において一律の判定処理により判定する必要が無くなる。
これに対し、ドライバのたとえば顔や眼球の撮像状態は、ドライバが向いている方向に応じて変化する。このため、仮にたとえばＣＰＵ３４が、ドライバが向く可能性がある視認範囲の全体において一律のわき見の判定処理により判定する場合、ドライバが向いている方向についてのわき見の判定の確からしさは、ドライバが向いている方向によっては低下してしまう可能性がある。たとえば、わき見の判定処理が、顔の向いている顔方向と眼球の向いている視線方向との双方を用いた一律の判定処理であり、撮像画像において眼球がその視線方向を判別することができない状態で撮像されている場合、ＣＰＵ３４は、眼球の向いている視線方向が撮像画像において不確かにしか特定できないことに起因して、わき見の判定を誤まってしまう可能性が生じ得る。
本実施形態では、ドライバが向く可能性がある視認範囲を複数のエリア４１～４８に分割して、そのエリアごとに異なる判定処理を実行可能であるため、このようなわき見の判定誤りの可能性を低減することが可能になる。これにより、本実施形態では、ドライバのわき見の判定を誤り難くなる。本実施形態では、ドライバのわき見の判定についての確からしさを高めることが可能になる。

以上の実施形態は、本発明に好適な実施形態の例であるが、本発明は、これに限定されるものではなく、発明の要旨を逸脱しない範囲において種々の変形または変更が可能である。

たとえば上述した実施形態では、自動車１の制御システム１０において、乗員監視装置１１のＣＰＵ３４が、図４から図５のすべて制御を実行している。
自動車１の制御システム１０では、他の装置１２～１６もＣＰＵを有する。制御システム１０を構成する複数のＣＰＵは、図４から図５の制御についての一部を実行してよい。制御システム１０に設けられる複数のＣＰＵは、図４から図５の制御を分散により共働して実行してよい。

上述した実施形態では、乗員監視装置１１のＣＰＵ３４は、視認範囲を分割する図８の複数のエリア４１～４８について、顔向きエリアを判定している。
この他にもたとえば、ＣＰＵ３４は、視認範囲を分割する図６の複数のエリアについて、または、視認範囲を分割する図７の複数のエリアについて、顔向きエリアを判定してよい。
また、ＣＰＵ３４は、視認範囲を分割する図６の複数のエリアについて、または、視認範囲を分割する図７の複数のエリアについて、顔向きエリアを判定してよい。
また、ＣＰＵ３４は、正面エリアと、その周囲の周辺エリアとの２つのエリアについて、顔向きエリアを判定してよい。

上述した実施形態では、乗員監視装置１１のＣＰＵ３４は、自動車１にいるドライバについてわき見を判定している。
この他にたとえば、乗員監視装置１１のＣＰＵ３４は、自動車１にいるドライバ以外の他の乗員についてもわき見を判定してよい。

１…自動車（車両）、２…車体、３…車室、４…シート、５…ダッシュボード、６…フロントガラス、７…ステアリングホイール、８…ルームミラー、９…ドアミラー、１０…制御システム（わき見監視装置）、１１…乗員監視装置、１２…ＵＩ装置、１３…走行支援装置、１４…駆動装置、１５…制動装置、１６…操舵装置、１７…車内ネットワーク、２１…操作デバイス、２２…表示デバイス、２３…音入力デバイス、２４…音出力デバイス、３１…入出力部、３２…タイマ、３３…メモリ、３４…ＣＰＵ（判定部）、３５…投光ＬＥＤ、３６…車内カメラ（撮像デバイス）、３７…システムバス、４１…Ｕエリア、４２…ＦＲエリア、４３…ＦＦエリア、４４…ＦＣエリア、４５…ＦＳエリア、４６…ＦＬエリア、４７…Ｂ１エリア、４８…Ｂ２エリア

Claims (8)

1. 車両の乗員を含む撮像画像を撮像可能な撮像デバイスと、
   前記撮像画像に基づいて乗員のわき見を判定する判定部と、
   を有し、
   前記判定部は、
   乗員が向く可能性がある視認範囲を分割する複数のエリアの中から、前記撮像画像において乗員が向いているエリアを判定し、
   判定した前記エリアごとの判定処理により、乗員のわき見を判定する、
   車両のわき見監視装置。
   
2. 前記判定部は、
   乗員の顔が向いている顔方向を、前記撮像画像から特定し、
   乗員が向く可能性がある視認範囲を分割する複数のエリアの中から、特定した顔方向が向いているエリアを判定する、
   請求項１記載の、車両のわき見監視装置。
   
3. 前記視認範囲は、少なくとも、前記車両の進行方向の正面エリアと、前記正面エリアの周囲の周辺エリアとに分割される、
   請求項１または２記載の、車両のわき見監視装置。
   
4. 前記視認範囲は、少なくとも前記車両のピッチ方向または上下方向において複数の前記エリアに分割され、または、少なくとも前記車両のヨー方向または左右方向において複数の前記エリアに分割される、
   請求項１から３のいずれか一項記載の、車両のわき見監視装置。
   
5. 前記判定部は、
   前記撮像画像に基づいて、乗員の顔が向いている顔方向とともに眼球が向いている視線方向を特定し、
   前記エリアごとの判定処理では、判定した前記エリアについての前記視認範囲での位置に応じて異なる判定処理を実行する、
   請求項１から４のいずれか一項記載の、車両のわき見監視装置。
   
6. 前記判定部は、
   前記視認範囲を分割する複数の前記エリアの一部では、特定した前記顔方向と前記視線方向との双方を用いて、乗員のわき見を判定し、
   前記視認範囲を分割する複数の前記エリアの残りの一部では、特定した前記顔方向と前記視線方向との中の前記顔方向を用いずに前記視線方向のみを用いて、乗員のわき見を判定し、
   前記視認範囲を分割する複数の前記エリアの残部では、特定した前記顔方向と前記視線方向との中の前記視線方向を用いずに前記顔方向のみを用いて、乗員のわき見を判定する、
   請求項５記載の、車両のわき見監視装置。
   
7. 前記視線方向を用いずに前記顔方向のみを用いて乗員のわき見を判定する前記エリアは、前記視認範囲を前記車両のヨー方向または左右方向において分割する複数の前記エリアの少なくとも１つとして設けられる、
   請求項５または６記載の、車両のわき見監視装置。
   
8. 前記顔方向を用いずに前記視線方向のみを用いて乗員のわき見を判定する前記エリアは、前記視認範囲を前記車両のピッチ方向または上下方向において分割する複数の前記エリアの少なくとも１つとして設けられる、
   請求項５から７のいずれか一項記載の、車両のわき見監視装置。
   
   
   

Images