JP2024050167A - ヘッドアップディスプレイ装置および映像データの処理方法 - Google Patents

Abstract

【課題】様々な表示仕様に柔軟に対応することが可能なヘッドアップディスプレイ装置および映像データの処理方法を提供する。また、持続可能な開発目標の「３．すべての人に健康と福祉を」に貢献する。【解決手段】映像を表示し、表示した映像の映像光を出射する映像表示部と、出射された映像光を表示領域に投射することで、投射された映像光を虚像として視認させる映像光投射部と、表示内容を決定し、映像データを準備し、当該データに基づく映像を映像表示部に表示させる制御部と、を備える。制御部は、表示内容を決定する前の仮決定した表示内容の映像データの準備に要する準備時間が所定の処理周期よりも長い場合、仮決定した表示内容を変更する。【選択図】図１６

Description

本発明は、ヘッドアップディスプレイ装置および映像データの処理方法に関し、例えば、ＡＲ（Augmented Reality）を利用したヘッドアップディスプレイ装置の技術に関する。

特許文献１には、撮像データに基づきＡＲ表示対象となる対象物を抽出し、対象物のＡＲ画像データを生成し、当該ＡＲ画像データのフレームレートを対象物の重要度に基づき設定する表示システムが示される。例えば、全体のフレームレートを６０ｆｐｓとして、３個のＡＲ画像データを時分割で表示する場合、３個のＡＲ画像データのフレームレートは、重要度に応じて、順に３０ｆｐｓ、２０ｆｐｓ、１０ｆｐｓに設定される。これにより、重要度が高いＡＲ画像データほど、ちらつきを抑制することができる。

特開２０１９－６１６４号公報

ヘッドアップディスプレイ装置は、ＡＤＡＳ（Advanced Driver Assistance Systems）等から取得した情報に基づいて様々な映像データを準備し、当該映像データに基づく映像光を表示領域に投射することで虚像として視認させる。この際に、映像データの準備に要する準備時間は、映像の種類、個数や、虚像距離の遠近に応じた映像のサイズや、２Ｄ／３Ｄといった表示形式や、グラフィックス効果の有無等の違いにより変化する。なお、明細書では、ヘッドアップディスプレイ装置を、ＨＵＤ装置とも呼ぶ。

ここで、ＨＵＤ装置では、通常、最大フレームレート等の処理性能は、主にハードウェアの仕様に基づいて固定的に定められる。一方、例えば、ＨＵＤ装置のハードウェア自体を変更することなく、ソフトウェアの更新によって、ＨＵＤ装置の表示仕様を変更したいといった要望が生じることがある。この際に、求められるＨＵＤ装置の表示仕様は、処理負荷の増大を伴うものになることが多い。その結果、ハードウェアの処理性能が不足し、例えば、ＡＲ表示の際にコマ落ちが生じる等、求められる表示仕様を満たせなくなるおそれがあった。

本発明は、このようなことに鑑みてなされたものであり、その目的の一つは、ハードウェアの処理性能の範囲内において、求められる表示仕様をできるだけ満足するとともに、表示仕様に柔軟に対応することが可能なヘッドアップディスプレイ装置および映像データの処理方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴については、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

代表的なヘッドアップディスプレイ装置は、映像を表示し、表示した映像の映像光を出射する映像表示部と、出射された映像光を表示領域に投射することで、投射された映像光を虚像として視認させる映像光投射部と、取得された乗り物に関する情報に基づいて表示内容を決定し、決定した表示内容に基づく映像データを準備し、準備した映像データに基づく映像を映像表示部に表示させる制御部と、を備える。制御部は、表示内容を決定する前の仮決定した表示内容の映像データの準備に要する準備時間が所定の処理周期よりも長い場合、仮決定した表示内容を変更する。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、ヘッドアップディスプレイ装置において、表示仕様に柔軟に対応することが可能になる。

実施の形態１によるヘッドアップディスプレイ装置を搭載した車両の構成例を示す概略図である。 図１におけるＨＵＤ装置の主要部の構成例を示す概略図である。 図１におけるＨＵＤ装置の、図２Ａとは異なる主要部の構成例を示す概略図である。 図２Ａおよび図２Ｂに示されるＨＵＤ装置において、制御を担う制御系の主要部の構成例を示すブロック図である。 図２Ａおよび図２Ｂに示されるＨＵＤ装置において、制御を担う制御系の図３Ａとは異なる主要部の構成例を示すブロック図である。 図３Ａおよび図３Ｂにおいて、制御ユニットに関わる箇所の構成例を示すブロック図である。 図１に示されるＨＵＤ装置の表示内容の一例を示す概略図である。 図３Ａに示されるＨＵＤ装置において、映像を表示する際の処理手順の一例を示すフロー図である。 図６に示されるフローを用いて映像を表示する際の問題点の一例を模式的に示すタイミングチャートである。 コマ落ちが生じていない場合での表示内容の変化の様子を示す模式図である。 コマ落ちが生じた場合での表示内容の変化の様子を示す模式図である。 図３Ａに示される制御部が有する内部状態の一例を示す図である。 図３Ａに示される制御部による、準備時間の監視結果の一例を示す図である。 図９に示される通常状態における、ＨＵＤ装置の表示内容の一例を示す概略図である。 図９に示される抑制移行状態における、ＨＵＤ装置の表示内容の一例を示す概略図である。 図９に示される抑制状態における、ＨＵＤ装置の表示内容の一例を示す概略図である。 図３Ａに示される制御部の処理内容の一例を示すフロー図である。 図３Ａおよび図３Ｂに示されるＨＵＤ装置において、フレームバッファに書き込まれる映像データと、映像表示部に表示される表示内容との関係の一例を示す模式図である。 図１３Ａとは異なる関係の一例を示す模式図である。 図６において、映像データの準備時間に影響する項目の一例を示す図である。 実施の形態２によるＨＵＤ装置において、映像を表示する際の処理手順の一例を示すフロー図である。 図１５における表示内容の調整処理の詳細な処理内容の一例を示すフロー図である。 図１６における準備時間の予測方法（ステップＳ４１２）の具体例を示す図である。 図１７Ａとは異なる具体例を示す図である。 図１６における表示内容の変更方法（ステップＳ４１４）の一例を説明する図である。 図１８において、表示内容の変更を行った結果として得られるＨＵＤ装置の表示内容の一例を示す概略図である。 図１５および図１６に示されるフローを用いて映像を表示する際のタイミングチャートである。 実施の形態３によるＨＵＤ装置において、制御部の主要な処理内容の一例を示す模式図である。 図２１Ａの補足図である。 図２１Ａとは異なる一例を示す模式図である。 図２２Ａの補足図である。 実施の形態３によるＨＵＤ装置において、制御部が記憶している表示設定テーブルの構成例を示す図である。 実施の形態３によるＨＵＤ装置において、制御部の処理内容の一例を示すフロー図である。 図２４Ａとは異なる処理内容の一例を示すフロー図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態１）
＜ＨＵＤ装置の概要＞
図１は、実施の形態１によるヘッドアップディスプレイ装置を搭載した車両の構成例を示す概略図である。図１に示されるヘッドアップディスプレイ（ＨＵＤ）装置１は、乗り物の一つである車両２に搭載される。車両２は、代表的には、自動車であるが、必ずしもこれに限定されず、鉄道車両等であってもよい。また、乗り物は、車両に限らず、航空機等であってもよい。また、車両２には、例えば、ＥＣＵ（Electronic Control Unit）と呼ばれる制御ユニット２１が搭載される。

制御ユニット２１は、例えば、車両２の各部に設置された各種センサや、加えて、ナビゲーション装置等から車両情報４を取得する。各種センサは、例えば、車両２で生じた各種イベントを検知し、また、走行状況に関する各種パラメータ値を検知する。ＨＵＤ装置１は、制御ユニット２１によって取得された車両情報４を、例えばＣＡＮ（Controller Area Network）通信等を用いて取得する。

車両情報４には、例えば、車両２の速度情報やギア情報、ハンドル操舵角情報、ランプ点灯情報、外光情報、距離情報、赤外線情報、エンジンＯＮ／ＯＦＦ情報、車内外のカメラ映像情報、加速度ジャイロ情報、ＧＰＳ（Global Positioning System）情報、ナビゲーション情報、車車間通信情報、および路車間通信情報等が含まれる。ＧＰＳ情報の中には、現在時刻等の情報も含まれる。また、車両情報４には、各種警告情報も含まれる。ＨＵＤ装置１は、このような車両情報４に基づいて、ウィンドシールド３などの表示領域に映像光を投射する。これにより、ＨＵＤ装置１は、運転者等の利用者に、表示領域に投射された映像光を虚像として、詳細には車両２の前方の風景に重畳された虚像として視認させる。

図２Ａは、図１におけるＨＵＤ装置の主要部の構成例を示す概略図である。図２Ａに示されるＨＵＤ装置１は、例えば、筐体１２内に収容された映像表示部１１、ミラーＭ１，Ｍ２、およびミラー駆動部１４等を備える。映像表示部１１は、例えば、ＬＣＤ（Liquid Crystal Display）等の表示パネルや、プロジェクタ等であり、入力された映像データに基づいて映像を表示し、表示した映像の映像光を出射する。

ミラーＭ２は、映像表示部１１からの映像光を、ミラーＭ１に向けて反射する。ミラーＭ２は、省スペースで光路長を長く確保するために効果を発揮するものである。ＨＵＤ筐体内のスペースと、必要な光路長の値によっては、ミラーＭ２を配置しなくてもよいし、複数配置してもよい。ミラーＭ１は、映像光投射部として機能する。映像光投射部であるミラーＭ１は、映像表示部１１から出射され、ミラーＭ２によって反射された映像光を、ダッシュボード１０に設けた開口部７を介してウィンドシールド３の表示領域５に投射する。これにより、映像光投射部は、投射された映像光を、虚像として利用者６に視認させる。

詳細には、ミラーＭ１は、例えば、凹面鏡（拡大鏡）であり、ミラーＭ２で反射された映像光を反射および拡大し、開口部７を介して表示領域５に投射する。表示領域５に投射された映像光は、表示領域５で反射され、利用者６の眼に入射する。その結果、利用者６は、表示領域５に投射された映像光を、透明のウィンドシールド３の先に存在する虚像９として、車外の風景（道路や建物、人など）に重畳される形で視認する。虚像９が表す情報の中には、例えば、道路標識や、自車の現速度や、風景上の物体に付加される各種情報、すなわちＡＲ情報等、様々なものが含まれる。

また、ミラーＭ１，Ｍ２は、例えば、自由曲面ミラーや光軸非対称の形状を有するミラー等であってよい。ここで、ミラーＭ２は、設置角度が固定される。一方、ミラーＭ１には、ミラー駆動部１４が設置される。ミラー駆動部１４は、ミラーＭ１の設置角度を可変調整する。詳細には、ミラー駆動部１４は、例えば、モータを含み、モータの回転動作によってミラーＭ１を回転させる。

ミラーＭ１の設置角度を可変調整することで、ウィンドシールド３上の表示領域５の位置、すなわち、利用者６が視認する虚像の上下方向の位置を調整できる。さらに、ミラーＭ１の設置角度を可変調整することで、映像表示部１１を太陽光から保護することが可能になる。具体的には、太陽光は、映像光の光路を逆方向に進んで映像表示部１１に入射し得る。当該太陽光の入射によって、映像表示部１１の破損が生じる可能性が高くなった場合には、太陽光が映像表示部１１に到達しないように、ミラーＭ１の設置角度を変更すればよい。

図２Ｂは、図１におけるＨＵＤ装置の、図２Ａとは異なる主要部の構成例を示す概略図である。図２Ｂに示されるＨＵＤ装置１は、図２Ａに示した構成と異なり、筐体１２内に、ミラーＭ２の代わりにレンズＬＳが設けられる。映像表示部１１からの映像光は、レンズＬＳを介してミラーＭ１に入射する。ミラーＭ１は、図２Ａの場合と同様に、入射した映像光を、開口部７を介して表示領域５に投射する。ミラーＭ１には、図２Ａの場合と同様に、ミラー駆動部が設置されてもよい。図２Ｂに示される構成は、例えば、ワンボックスカーやトラック等のように、ウィンドシールド３が垂直に近い角度で設置される場合に適用され得る。

図３Ａは、図２Ａおよび図２Ｂに示されるＨＵＤ装置において、制御を担う制御系の主要部の構成例を示すブロック図である。図３Ａに示されるＨＵＤ装置１は、互いにバス１３で接続されるミラー駆動部１４、表示駆動部１５、通信部１６、メモリ１７、フレームバッファ１８および制御部２０を備える。

通信部１６は、車両情報を受信および送信するものであり、例えば、通信インタフェース回路等によって実現され、情報取得部として機能する。通信部１６は、制御ユニット２１から、ＣＡＮ通信等を用いて乗り物に関する情報を取得または受信し、受信した乗り物に関する情報を制御部２０に送信する。制御部２０は、通信部１６からの情報によりミラー駆動部１４と表示駆動部１５とを制御する。ミラー駆動部１４は、例えば、制御部２０からの命令に応じて、図２Ａで述べたように、ミラーＭ１の設置角度を調整する。ミラー駆動部１４は、図２Ａで述べたようなモータに加えて、当該モータを駆動するモータドライバ回路等によって実現され得る。

フレームバッファ１８は、例えば、揮発性メモリによって構成され、映像データを記憶する。表示駆動部１５は、フレームバッファ１８が記憶している映像データを、バス１３を介して読み出し、当該映像データに基づいて映像表示部１１を駆動する。映像表示部１１は、例えば、光源と、表示パネルとを備えた液晶ディスプレイ等である。表示パネルは、光源から照射されたバックライトを、画素毎に映像データに基づいて変調することで映像を表示する。この場合、表示駆動部１５は、ＬＣＤドライバ回路等によって実現され得る。

メモリ１７は、例えば、揮発性メモリおよび不揮発性メモリの組み合わせで構成され、制御部２０で用いられるプログラムやデータ等を記憶する。制御部２０は、例えば、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）等のプロセッサによって実現され、メモリ１７が記憶しているプログラムを実行することで、ＨＵＤ装置１全体を制御する。その一つとして、制御部２０は、通信部１６、すなわち情報取得部によって取得された乗り物に関する情報に基づいて、映像データの作成を含めて映像データを準備し、準備した映像データに基づく映像を映像表示部１１に表示させる。

なお、図３Ａに示される通信部１６、メモリ１７、フレームバッファ１８および制御部２０は、マイクロコントローラ等に搭載され得る。ただし、このような実装形態に限らず、例えば、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）等を適宜組み合わせた実装形態であってもよい。

図３Ｂは、図２Ａおよび図２Ｂに示されるＨＵＤ装置において、制御を担う制御系の図３Ａとは異なる主要部の構成例を示すブロック図である。図３Ｂに示されるＨＵＤ装置１は、図３Ａに示した構成例と異なり、メモリ１７および制御部２０が設けられない構成となっている。この場合、制御ユニット２１は、図３Ａに示した制御部２０に代わって映像データを作成し、作成した映像データを、通信処理部１６ａを介してフレームバッファ１８に書き込む。

なお、図３Ｂに示した構成例の場合、図３Ａで述べた制御部２０は、通信処理部１６ａとして機能することになってもよい。または、制御ユニット２１と通信処理部１６ａにそれぞれ一部機能を分担することになってもよい。図３Ｂの構成例では、ミラー駆動部１４、表示駆動部１５、通信処理部１６ａが設けられる。通信処理部１６ａは、図３Ａの通信部１６と異なり、制御ユニット２１から、ＣＡＮ通信等を用いて乗り物に関する情報を受信し、受信した情報を処理し、処理した結果により、ミラー駆動部１４と表示駆動部１５の動作を調整する。

図４は、図３Ａおよび図３Ｂにおいて、制御ユニットに関わる箇所の構成例を示すブロック図である。制御ユニット２１は、図１で述べたように車両情報４を取得する。車両情報４は、図４に示されるように、制御ユニット２１に接続される各種センサ等の情報取得デバイスによって生成される。図４には、当該情報取得デバイスの一例が示される。

図４において、例えば、車速センサ１０１は、図１の車両２の速度を検知し、検知結果となる速度情報を生成する。シフトポジションセンサ１０２は、現在のギアを検知し、検知結果となるギア情報を生成する。ハンドル操舵角センサ１０３は、現在のハンドル操舵角を検知し、検知結果となるハンドル操舵角情報を生成する。ヘッドライトセンサ１０４は、ヘッドライトのＯＮ／ＯＦＦを検知し、検知結果となるランプ点灯情報を生成する。照度センサ１０５および色度センサ１０６は、外光を検知し、検知結果となる外光情報を生成する。

測距センサ１０７は、車両２と外部の物体との間の距離を検知し、検知結果となる距離情報を生成する。赤外線センサ１０８は、車両２の近距離における物体の有無や距離等を検知し、検知結果となる赤外線情報を生成する。エンジン始動センサ１０９は、エンジンのＯＮ／ＯＦＦを検知し、検知結果となるＯＮ／ＯＦＦ情報を生成する。加速度センサ１１０およびジャイロセンサ１１１は、車両２の加速度および角速度をそれぞれ検知し、検知結果として、車両２の姿勢や挙動を表す加速度ジャイロ情報を生成する。温度センサ１１２は、車内外の温度を検知し、検知結果となる温度情報を生成する。

路車間通信用無線受信機１１３は、車両２と、道路、標識、信号機等との間の路車間通信によって路車間通信情報を生成する。車車間通信用無線受信機１１４は、車両２と周辺の他の車両との間の車車間通信によって車車間通信情報を生成する。車内用カメラ１１５および車外用カメラ１１６は、それぞれ、車内および車外を撮影することで車内のカメラ映像情報および車外のカメラ映像情報を生成する。車内用カメラ１１５は、例えば、図２Ａ等に示した利用者６の姿勢や、眼の位置、動き等を撮影するＤＭＳ（Driver Monitoring System）用のカメラ等である。この場合、撮像された映像を解析することで、利用者６の疲労状況や視線の位置等が把握できる。

一方、車外用カメラ１１６は、例えば、車両２の前方や後方といった周囲の状況を撮影する。この場合、撮像された映像を解析することで、周辺に存在する他の車両や人などの障害物の有無、建物や地形、雨や積雪、凍結、凹凸等といった路面状況、および道路標識等を把握することが可能になる。また、車外用カメラ１１６には、例えば、走行中の状況を映像で記録するドライブレコーダ等も含まれ得る。

ＧＰＳ受信機１１７は、ＧＰＳ信号を受信することで得られるＧＰＳ情報を生成する。例えば、ＧＰＳ受信機１１７によって、現在時刻を取得することが可能である。ＶＩＣＳ（Vehicle Information and Communication System、登録商標）受信機１１８は、ＶＩＣＳ信号を受信することで得られるＶＩＣＳ情報を生成する。ＧＰＳ受信機１１７やＶＩＣＳ受信機１１８は、ナビゲーション装置の一部として設けられてもよい。なお、図４に示される各種情報取得デバイスに関しては、適宜、削除することや、他の種類のデバイスを追加することや、他の種類のデバイスに置き換えることが可能である。

＜ＨＵＤ装置の表示について＞
図５は、図１に示されるＨＵＤ装置の表示内容の一例を示す概略図である。当該表示内容は、ＡＲ表示の一例を示すものであり、図２Ａ等に示した虚像９の一例を示すものである。図５に示される例では、５個の映像ＶＤａ～ＶＤｅが表示されている。明細書では、複数の映像ＶＤａ～ＶＤｅを総称して映像ＶＤ、または画像ＶＤ、または映像オブジェクトＶＤと呼ぶ。

映像ＶＤａは、風景の一つであり、ＡＲの対象物である物体ＯＢ、ここでは人に重畳するように表示される。映像ＶＤａは、図４に示した各種情報取得デバイスによって物体ＯＢを検知済みであることを意味する。すなわち、ＨＵＤ装置１は、制御ユニット２１から物体ＯＢの検知結果を表す情報を取得する。また、映像ＶＤａは、物体ＯＢへの注意喚起を利用者６、例えば運転者に促すための警告情報を表す。

映像ＶＤｂは、風景の一つである道路上に表示され、車両２の進行方向を表す。映像ＶＤｃは、ナビゲーション情報を表す。映像ＶＤｄは、例えば、路車間通信情報の一つである道路標識を表す。映像ＶＤｅは、車両２の速度情報を表す。なお、映像ＶＤａ，ＶＤｂは、３Ｄグラフィックスであり、映像ＶＤｃ～ＶＤｅは、２Ｄグラフィックスである。

図６は、図３Ａに示されるＨＵＤ装置において、映像を表示する際の処理手順の一例を示すフロー図である。図６において、まず、通信部１６、すなわち情報取得部は、制御ユニット２１から乗り物に関する情報を取得する（ステップＳ１１）。続いて、制御部２０は、ステップＳ１２１～Ｓ１２４を含む映像データの準備処理を行う（ステップＳ１２）。例えば、プロセッサは、メモリ１７内の映像処理プログラムを実行することで、ステップＳ１２１～Ｓ１２３の処理を実行する。

ステップＳ１２１において、制御部２０は、ステップＳ１１で取得した乗り物に関する情報、例えば、図１に示した車両情報４に基づいて、表示内容を決定する。具体的には、制御部２０は、表示に対応している車両情報４を選定すると共に、当該選定した車両情報４を表す映像ＶＤを、どの位置にどのようなサイズおよびレイアウトで表示するか等を決定する。図５に示される例では、制御部２０は、表示内容として、５個の映像ＶＤａ～ＶＤｅを表示することを決定する。ステップＳ１２２において、制御部２０は、ステップＳ１２１で決定した表示内容に基づいて、映像ＶＤ毎の映像データを作成する。

ステップＳ１２３において、制御部２０は、ステップＳ１２２で作成した複数の映像データを、それぞれ、表示すべき位置に対応するフレームバッファ１８内の記憶領域に書き込む。ステップＳ１２４において、制御部２０は、フレームバッファ１８内の映像データ全体に対して、例えば、ウィンドシールド３の曲率等に応じた歪補正を行う。なお、歪補正に関しては、例えば、プロセッサが、メモリ１７内の歪補正プログラムを実行することで実現されるか、または、専用のハードウェアによって実現されてもよい。

このような映像データの準備処理（ステップＳ１２）を終えたのち、映像の表示処理が行われる（ステップＳ１３）。ステップＳ１３において、表示駆動部１５は、フレームバッファ１８が記憶している映像データを読み出し、当該映像データに基づいて映像表示部１１を駆動することで、映像表示部１１に映像ＶＤを表示させる。なお、図６に示した処理手順は、フレームレートに基づいて定められる処理周期に同期して実行される。例えば、フレームレートが６０ｆｐｓの場合、処理周期は、１６．６ｍｓである。また、映像ＶＤを表示する際の処理手順は、特に、図６に示したものに限らず、一般的に知られている様々な手順に置き換え可能である。

図７は、図６に示されるフローを用いて映像を表示する際の問題点の一例を模式的に示すタイミングチャートである。図７には、１番目～５番目の処理周期または制御周期Ｔｃ［１］～Ｔｃ［５］で実行される動作が示される。明細書では、処理周期または制御周期Ｔｃ［１］～Ｔｃ［５］を総称して処理周期または制御周期Ｔｃと呼ぶ。制御周期Ｔｃは、例えば、１６．６ｍｓである。また、図７には、図６におけるステップＳ１１，Ｓ１２の処理と、ステップＳ１３の処理とをパイプラインで実行する場合の動作が示される。

図７において、１番目の制御周期Ｔｃ［１］では、乗り物に関する情報が取得され（ステップＳ１１）、当該情報に基づいて映像データが準備される（ステップＳ１２）。当該ステップＳ１１，Ｓ１２の処理に要する映像データの準備時間Ｔｐ［１］は、制御周期Ｔｃ［１］よりも短くなっている。これは、例えばＡＲの対象物、ひいては表示する映像ＶＤの数が少なく、準備時間Ｔｐ［１］が制御周期Ｔｃ［１］内に収まるケースである。同様に、２番目の制御周期Ｔｃ［２］でも、乗り物に関する情報が取得され（ステップＳ１１）、当該情報に基づいて映像データが準備される（ステップＳ１２）。また、これと並行して、２番目の制御周期Ｔｃ［２］では、１番目の制御周期Ｔｃ［１］で準備された映像データに基づいて、映像ＶＤの表示処理が行われる（ステップＳ１３）。

ここで、２番目の制御周期Ｔｃ［２］において、ステップＳ１１，Ｓ１２の処理に要する映像データの準備時間Ｔｐ［２］は、制御周期Ｔｃ［２］よりも長くなっている。準備時間Ｔｐ［２］は、例えば、ＡＲの対象物、ひいては表示する映像ＶＤが増加すること等により、長期化し得る。このため、当該映像データは、３番目の制御周期Ｔｃ［３］での表示処理に反映されずに、４番目の制御周期Ｔｃ［４］での表示処理に反映されることになる。その結果、３番目の制御周期Ｔｃ［３］において、コマ落ちが生じることになる。

また、４番目の制御周期Ｔｃ［４］において、ステップＳ１１，Ｓ１２の処理に要する映像データの準備時間Ｔｐ［３］は、制御周期Ｔｃ［４］よりも短くなっている。このため、当該映像データは、５番目の制御周期Ｔｃ［５］での表示処理に反映される。ただし、方式によっては、コマ落ちが生じたことにより、準備時間Ｔｐ［３］で準備される映像データは、本来、３番目の制御周期Ｔｃ［３］で準備されるべき映像データとなる場合がある。なお、明細書では、複数の準備時間Ｔｐ［１］～Ｔｐ［３］を総称して準備時間Ｔｐと呼ぶ。

図８Ａは、コマ落ちが生じていない場合での表示内容の変化の様子を示す模式図である。図８Ｂは、コマ落ちが生じた場合での表示内容の変化の様子を示す模式図である。例えば、図８Ａおよび図８Ｂに示されるように、物体ＯＢ、ここでは人が、時刻ｔ１から時刻ｔ２にかけて移動した場合を想定する。コマ落ちが生じていない場合、図８Ａに示されるように、時刻ｔ１での物体ＯＢ（ｔ１）には、その位置に映像ＶＤａ（ｔ１）が重畳して表示され、時刻ｔ２での物体ＯＢ（ｔ２）には、その位置に映像ＶＤａ（ｔ２）が重畳して表示される。

このように、コマ落ちが生じない場合には、ＡＲの対象物に追従するリアルタイム性が高い映像ＶＤを表示することができる。一方、コマ落ちが生じた場合、特に、連続する制御周期Ｔｃで連続してコマ落ちが生じた場合、図８Ｂに示されるように、時刻ｔ２での物体ＯＢ（ｔ２）には、その位置から物体ＯＢ（ｔ１）側にズレた位置に映像ＶＤａ（ｔ２）が表示される。この場合、映像ＶＤａ（ｔ２）は、物体ＯＢ（ｔ２）に完全には重畳されない。このように、コマ落ちが生じた場合には、ＡＲの対象物に追従しないリアルタイム性が低い映像ＶＤを表示されることになり得る。

＜制御部の概略動作＞
そこで、制御部２０は、リアルタイム性が高い映像ＶＤを表示できるようにするため、概略的には、所定の処理周期または制御周期Ｔｃ内に映像データの準備を完了するように、映像データの準備に必要な処理負荷を軽減する制御を行う。つまり、制御部２０は、通信部１６によって受信された乗り物に関する情報に基づいて映像データを準備し、映像データの準備条件が所定の処理周期に所定条件を満たさない場合、準備する映像データの一部内容を変更して準備する。より詳細には、制御部２０は、映像データの準備に要する準備時間Ｔｐを監視し、準備時間Ｔｐが予め定めた条件を満たした場合に、処理負荷を軽減する制御を開始する。また、所定の処理周期または制御周期Ｔｃは、フレームレートに基づいて定められるものである。

準備時間Ｔｐは、図７で述べたような動作方式を前提とすると、図６に示したステップＳ１１，Ｓ１２の処理に要する時間である。一方、例えば、ステップＳ１１の処理と、ステップＳ１２の処理とをパイプラインで実行するような動作方式を前提とすると、準備時間Ｔｐは、ステップＳ１２の処理に要する時間であってよい。ただし、リアルタイム性を高めるためには、図７で述べたような動作方式を用いる方が望ましい。

制御部２０は、準備時間Ｔｐを逐次監視する。例えば、車両の時間と連動し、または、タイマ等を用いて準備時間を監視することができる。図７で述べたような動作方式を前提とすると、図３Ａに示すように、制御部２０は、通信部１６を用いて乗り物に関する情報の取得を開始してから、作成した映像データをフレームバッファ１８に書き終えるまでに要する準備時間Ｔｐを、タイマ等を用いて監視する。図３Ｂに示した構成を用いる場合、図３Ａの場合と異なり、通信処理部１６ａは、制御ユニット２１からの情報を取得して、取得した情報を処理し、処理した結果をフレームバッファ１８に書き終えるまでに要する準備時間Ｔｐを、タイマ等を用いて監視する。

図９は、図３Ａに示される制御部が有する内部状態の一例を示す図である。図１０は、図３Ａに示される制御部による、準備時間の監視結果の一例を示す図である。制御部２０は、図９に示されるように、内部状態として、通常状態ＳＴ０と、復帰移行状態ＳＴ１と、抑制移行状態ＳＴ２と、抑制状態ＳＴ３とを有する。言い換えれば、制御部２０は、動作モードとして、通常モードＳＴ０と、復帰移行モードＳＴ１と、抑制移行モードＳＴ２と、抑制モードＳＴ３とを有する。４つの状態を有するのは一例であり、別の例では、制御部２０は、通常状態ＳＴ０と、抑制状態ＳＴ３の２つの状態を有してもよい。

制御部２０は、通常状態ＳＴ０では、通信部１６を用いて取得した情報に基づいて、通常通りに映像データを準備し、それに基づく映像ＶＤを映像表示部１１に表示させる。また、制御部２０は、通常状態ＳＴ０において、（Ａ）監視結果となる準備時間Ｔｐが制御周期Ｔｃよりも長かった場合、または、（Ｂ）準備時間Ｔｐが複数回連続して第１の閾値時間Ｔｔｈ１よりも長かった場合に、抑制移行状態ＳＴ２に遷移する。連続回数は、例えば、２回以上１０回以下の値に定められる。

具体例として、図１０では、監視時刻ｔｍ４で得られた準備時間Ｔｐ４は、制御周期Ｔｃよりも長くなっている。また、連続する監視時刻ｔｍ２，ｔｍ３で得られた準備時間Ｔｐ２，Ｔｐ３は、共に、制御周期Ｔｃよりも短いが、第１の閾値時間Ｔｔｈ１よりも長くなっている。第１の閾値時間Ｔｔｈ１は、制御周期Ｔｃである１６．６ｍｓよりも短い時間であり、例えば、１５．０ｍｓ等である。

制御部２０は、通常状態ＳＴ０において、（Ａ）準備時間Ｔｐ４のような監視結果が得られた場合、または、（Ｂ）準備時間Ｔｐ２，Ｔｐ３のような監視結果が複数回連続して、例えば２連続で得られた場合に、抑制移行状態ＳＴ２に遷移する。条件（Ａ）は、コマ落ちを迅速に解消するためのものである。一方、条件（Ｂ）は、近い将来に、準備時間Ｔｐが制御周期Ｔｃよりも長くなる状況、ひいてはコマ落ちが生じる状況を、事前に予防するためのものである。

制御部２０は、抑制移行状態ＳＴ２において、処理負荷を軽減する制御を開始したのち、予め定めた抑制移行期間内で、処理負荷の軽減量を制御周期Ｔｃ毎に段階的に増やしていく。抑制移行期間は、例えば、５秒等に定められる。詳細は後述するが、制御部２０は、例えば、一部の映像データを作成しない、または、一部の映像データを簡略化すること等で、準備する映像データのデータ量を削減し、処理負荷を軽減する。この場合、仮に、映像データのデータ量が急減に削減されると、表示内容も急減に変化するため、利用者６の視点で好ましくない。そこで、制御部２０は、削減するデータ量を段階的に増やしていく。そして、制御部２０は、抑制移行期間、例えば５秒を経たのち、抑制状態ＳＴ３に遷移する。

制御部２０は、抑制状態ＳＴ３において、軽減後の処理負荷で映像データを準備する。また、制御部２０は、抑制状態ＳＴ３において、準備時間Ｔｐが第２の閾値時間Ｔｔｈ２よりも短かった状態が予め定めた閾値継続期間ＴｔｈＤ以上継続した場合に、復帰移行状態ＳＴ１に遷移する。第２の閾値時間Ｔｔｈ２は、制御周期Ｔｃよりも短い時間であり、例えば、第１の閾値時間Ｔｔｈ１と同じ時間、または、第１の閾値時間Ｔｔｈ１よりも短い時間に定められる。閾値継続期間ＴｔｈＤは、制御周期Ｔｃの複数倍以上の期間であり、例えば、５秒等に定められる。

具体例として、図１０では、第２の閾値時間Ｔｔｈ２は、第１の閾値時間Ｔｔｈ１よりも短い時間に定められる。監視時刻ｔｍ５，ｔｍ６で得られた準備時間Ｔｐ５，Ｔｐ６は、共に、第２の閾値時間Ｔｔｈ２よりも短くなっている。制御部２０は、準備時間Ｔｐ５，Ｔｐ６のような監視結果が閾値継続期間ＴｔｈＤ以上継続して得られた場合に、復帰移行状態ＳＴ１に遷移する。

このように、“準備時間Ｔｐ＜第２の閾値時間Ｔｔｈ２”の状態が安定的に生じている場合、通常状態ＳＴ０に復帰しても、前述した条件（Ａ）および条件（Ｂ）に該当しなくなることが見込まれる。なお、制御部２０は、場合によっては、所定の期間を経ることで処理負荷が自ずと軽減されることを見込んで、このような条件判定を行うことがなく、単に、５秒等の時間を経て、復帰移行状態ＳＴ１に遷移してもよい。

制御部２０は、復帰移行状態ＳＴ１において、予め定めた復帰移行期間内で、処理負荷の軽減量を制御周期Ｔｃ毎に段階的に減らしていく。復帰移行期間は、例えば、５秒等に定められる。そして、制御部２０は、当該復帰移行期間、例えば５秒を経たのち、通常状態ＳＴ０に遷移する。復帰移行状態ＳＴ１を設けることで、抑制移行状態ＳＴ２の場合と同様に、利用者６の視点で好ましくない状況を回避することができる。

＜処理負荷の軽減方法＞
図１１Ａは、図９に示される通常状態における、ＨＵＤ装置の表示内容の一例を示す概略図である。通常状態ＳＴ０では、例えば、図１１Ａに示されるように、７個の映像ＶＤａ１～ＶＤａ３，ＶＤｂ～ＶＤｅが表示される。映像ＶＤａ１，ＶＤａ２は、それぞれ、物体ＯＢ１，ＯＢ２、ここでは人に重畳するように表示される。映像ＶＤａ３は、物体ＯＢ３、ここでは車両に重畳するように表示される。映像ＶＤｂ～ＶＤｅは、図５の場合と同様に、それぞれ、ナビゲーション情報、進行方向、道路標識、速度情報を表す。

図１１Ｂは、図９に示される抑制移行状態における、ＨＵＤ装置の表示内容の一例を示す概略図である。抑制移行状態ＳＴ２では、図１１Ａに示した表示内容を基準として、図１１Ｂでの符号２０１，２０３で示されるように、図１１Ａでの２個の映像ＶＤａ２，ＶＤｄが削除されている。すなわち、物体ＯＢ１よりも遠い物体ＯＢ２に重畳される映像ＶＤａ２と、道路標識を表す映像ＶＤｄとが削除されている。また、図１１Ｂでの符号２０２で示されるように、図１１Ａでの映像ＶＤａ３を無着色にすること等で、映像ＶＤａ３が簡略化されている。

さらに、図１１Ｂでは、抑制移行状態ＳＴ２、言い換えれば抑制移行期間であることを利用者６に通知するための映像ＶＤｍ１、例えばマークが表示されている。制御部２０は、抑制移行状態ＳＴ２では、当該映像ＶＤｍ１の映像データを、テンプレートとして、フレームバッファ１８内の固定の記憶領域に書き込む。このようなマークを表示することで、利用者６は、故障による表示内容の変化ではなく、表示抑制機能が作動したことによる表示内容の変化であることを認識することができる。

図１１Ｂに示した表示を行う場合、制御部２０は、図６に示したステップＳ１２１において、映像ＶＤａ２，ＶＤｄを非表示に定め、映像ＶＤａ３に簡略化表示を適用することで、ステップＳ１２で準備する映像データのデータ量を削減する。これによって、制御部２０は、映像データの準備に必要な処理負荷を軽減する。すなわち、制御部２０は、ステップＳ１２２での処理に要する時間や、ステップＳ１２３での処理に要する時間を短縮する。また、制御部２０は、このようなデータ量の削減を段階的に進めていく。

図１１Ｃは、図９に示される抑制状態における、ＨＵＤ装置の表示内容の一例を示す概略図である。抑制状態ＳＴ３では、図１１Ｂに示した表示内容を基準として、図１１Ｃでの符号３０１，３０２で示されるように、さらに、図１１Ｂでの２個の映像ＶＤａ１，ＶＤｂが簡略化されている。すなわち、２個の映像ＶＤａ１，ＶＤｂにおいて、無着色やサイズの縮小といった簡略化が行われている。さらに、図１１Ｃでは、抑制状態ＳＴ３、言い換えれば抑制期間であることを利用者６に通知するための映像ＶＤｍ２、例えばマークが表示されている。

具体的な処理の一例として、制御部２０は、車両情報４の種別と優先度との対応関係等を定めた抑制テーブルを、メモリ１７に予め記憶しておく。制御部２０は、例えば、抑制移行状態ＳＴ２において、当該抑制テーブルに基づいて、優先度が低い順に車両情報４を選択すると共に、当該選択数を段階的に増やしていく。そして、制御部２０は、選択した車両情報４を表す映像ＶＤを非表示に定める、または、予め定められた方法で簡略化する。

ここで、抑制テーブルにおける優先度は、例えば、次のような基準で定められる。まず、安全運転への寄与度が高い車両情報４ほど、優先度を高くする。また、車両情報４が警告を表す場合で、警告の対象物が人と車両の場合には、人の方の優先度を高くする。ただし、この際には、自車と対象物との距離に応じて優先度に重み付けを持たせてもよい。例えば、人との距離が遠く、車両との距離が極端に近い場合は車両を優先してもよい。また、自車から遠ざかって行く人よりも近づいてくる人の優先度を高くしてもよい。

また、図１１Ｂおよび図１１Ｃに示した進行方向を表す映像ＶＤｂに関し、例えば、ナビゲーション情報に基づいて、直線が続く場合には優先度は低くし、右左折のタイミングが近い場合には優先度を高くしてもよい。また、映像ＶＤｂに関し、過去の走行履歴に基づいて、利用頻度が高い道を走行している場合には優先度を低くし、過去に利用したことがない道を走行している場合には優先度を高くしてもよい。さらに、図１１Ａおよび図１１Ｂに示した道路標識、すなわち制限速度を表す映像ＶＤｄに関し、自車の走行速度との差分に基づいて、優先度を変えてもよい。

なお、制御部２０は、映像ＶＤを完全に削除せずに、例えば、映像ＶＤを複数の制御周期Ｔｃ毎に１回表示すること等で、処理負荷を軽減してもよい。さらに、制御部２０は、このような映像データのデータ量を削減する方法に限らず、例えば、図６におけるステップＳ１２４での歪補正の処理を簡略化する、ひいては精度を落とすことで、処理負荷を軽減してもよい。

＜制御部の詳細動作＞
図１２は、図３Ａに示される制御部の処理内容の一例を示すフロー図である。制御部２０は、例えば、図２Ａに示したミラーＭ１の設置角度の調整等が完了し、映像を投射できる環境が整った時点で図１２に示されるフローを実行する。図１２において、制御部２０は、タイマ等を用いて準備時間Ｔｐの監視を開始する（ステップＳ２０）。続いて、制御部２０は、開始トリガが生じるのを待つ（ステップＳ２１）。開始トリガは、制御周期Ｔｃ毎に生成される。

ステップＳ２１で開始トリガが生じると、制御部２０は、通信部１６、すなわち情報取得部を用いて、乗り物に関する情報を取得する（ステップＳ２２）。次いで、制御部２０は、図９で述べた現在の内部状態を確認する（ステップＳ２３）。そして、制御部２０は、図６でのステップＳ１２で述べたような、映像データの準備処理を行う（ステップＳ２４）。この際に、制御部２０は、通常状態ＳＴ０を除く内部状態である場合には、図９、図１１Ｂおよび図１１Ｃで述べたように、映像データの準備に必要な処理負荷を軽減する制御を行う。

制御部２０は、ステップＳ２４における映像データの準備処理を完了すると、準備完了信号を生成する（ステップＳ２５）。制御部２０は、例えば、準備完了信号を生成した後の開始トリガに応じて、表示駆動部１５に表示開始命令を出力する。表示駆動部１５は、表示開始命令に応じて、図６におけるステップＳ１３および図７で述べたような、映像ＶＤの表示処理を行う。また、制御部２０は、映像データの準備処理を完了した段階で、ステップＳ２１に伴う監視結果である準備時間Ｔｐを評価する（ステップＳ２６）。

そして、制御部２０は、監視結果である準備時間Ｔｐに基づいて、図９で述べた状態遷移が必要か否かを判定する（ステップＳ２７）。状態遷移が必要な場合（ステップＳ２７：Ｙｅｓ）、制御部２０は、遷移先を決定し（ステップＳ２９）、定めた遷移先へ状態遷移し、併せて内部状態を更新する（ステップＳ３０）。一方、状態遷移が不要な場合（ステップＳ２７：Ｎｏ）、制御部２０は、ＨＵＤ表示の終了要求が生じるまで、ステップＳ２１に戻って次の開始トリガを待ち、同様の処理を繰り返す（ステップＳ２８）。

＜実施の形態１の主要な効果＞
以上、実施の形態１の方式では、制御周期Ｔｃ内に映像データの準備を完了するように、映像データの準備に必要な処理負荷を軽減する制御を行うで、コマ落ち等の発生を抑制し、最低限の表示品質を確保することが可能になる。詳細には、コマ落ち等が生じないようにＨＵＤ装置１を設計した場合であっても、表示仕様の変更を伴うソフトウェアのアップデート等によって、処理負荷が増大し、コマ落ち等が生じる可能性がある。実施の形態１の方式を用いると、このような場合であっても、コマ落ち等の発生を抑制することができる。その結果、ハードウェアの処理性能の範囲内において、求められる表示仕様をできるだけ満足するとともに、表示仕様に柔軟に対応することが可能になる。

（実施の形態２）
実施の形態１の方式は、映像データまたは画像データの準備に要した準備時間Ｔｐを実際に監視することで、制御周期Ｔｃ、言い換えれば処理周期内に映像データまたは画像データの準備を完了するように、処理負荷を軽減する方式であった。実施の形態２では、当該準備時間Ｔｐを予測することで、制御周期Ｔｃ、言い換えれば処理周期内に映像データまたは画像データの準備を完了するように、処理負荷を軽減する方式について説明する。以下は映像データを用いて説明する。

＜映像データの準備処理について＞
図１３Ａは、図３Ａおよび図３Ｂに示されるＨＵＤ装置において、フレームバッファに書き込まれる映像データと、映像表示部に表示される表示内容との関係の一例を示す模式図である。図１３Ｂは、図１３Ａとは異なる関係の一例を示す模式図である。例えば、図６で述べたように、映像データの準備処理（ステップＳ１２）では、フレームバッファ１８に、決定した表示内容に基づく映像データが書き込まれる（ステップＳ１２２，Ｓ１２３）。

図１３Ａにおいて、６個の映像ＶＤａ１～ＶＤａ３，ＶＤｂ，ＶＤｃ，ＶＤｅは、表示すべき位置に対応するフレームバッファ１８内の記憶領域に、それぞれ映像データとして書き込まれている。図５で述べたように、映像ＶＤａ１～ＶＤａ３は、検知した物体に重畳される警告映像である。映像ＶＤｂは、車両の進行方向を表し、映像ＶＤｃは、ナビゲーション情報を表し、映像ＶＤｅは、車両の速度情報を表す。また、例えば、映像ＶＤａ１～ＶＤａ３，ＶＤｂは、３Ｄグラフィックスであり、映像ＶＤｃ，ＶＤｅは、２Ｄグラフィックスである。

ここで、図１３Ａに示される例では、フレームバッファ１８のサイズと、映像表示部１１のサイズとが等しくなっている。この場合、映像表示部１１には、フレームバッファ１８に書き込まれる各映像ＶＤ、言い換えれば各映像オブジェクトＶＤの全てがそのままの位置に表示される。一方、図１３Ｂに示される例では、フレームバッファ１８のサイズは、映像表示部１１のサイズよりも大きくなっている。この場合、映像表示部１１には、フレームバッファ１８に書き込まれる各映像ＶＤの一部が表示される。

図１３Ｂでは、例えば、ピッチング補正によって表示が上下に動いた場合にも対応するため、フレームバッファ１８における、映像表示部１１の表示領域外の領域にも、映像ＶＤが配置されている。この場合、準備処理に必要とされる処理負荷の大きさは、映像表示部１１の表示領域外の領域を含めて、フレームバッファ１８全体に、どれだけの映像ＶＤを配置したかによって定められる。

図１４は、図６において、映像データの準備時間に影響する項目の一例を示す図である。準備時間に影響する項目として、映像ＶＤの数と、映像ＶＤ毎の表示形式とが挙げられる。映像ＶＤの数に関しては、数が多いほど処理負荷が大きくなり、ひいては、準備時間Ｔｐは長くなる。映像ＶＤ毎の表示形式には、項目として、例えば、サイズ、表示位置、デザイン種別、歪補正等が含まれる。

サイズに関しては、サイズが大きいほど準備時間Ｔｐは長くなる。表示位置に関しては、通常、表示位置が手前になる、言い換えれば近くなるほどサイズが大きくなるため、準備時間Ｔｐは長くなる。デザイン種別には、例えば、２Ｄ／３Ｄグラフィックスといった種別や、グラデーションの有／無といった種別等が含まれる。例えば、ポリゴン数が多い３Ｄグラフィックスを用い、かつグラデーション有りを用いる場合のように、複雑なデザインを用いる場合ほど、準備時間Ｔｐは長くなる。また、歪補正に伴う準備時間Ｔｐは、図６でも述べたように、ハードウェアで歪補正を行う場合には短くなり、ソフトウェアで歪補正を行う場合には長くなる。

図１５は、実施の形態２によるＨＵＤ装置において、映像を表示する際の処理手順の一例を示すフロー図である。実施の形態２によるＨＵＤ装置１は、前述した図３Ａまたは図３Ｂに示した構成で実現される。図１５には、図６の場合と同様のフローが示される。すなわち、図６の場合と同様に、制御部２０は、通信部１６、すなわち情報取得部によって取得された乗り物に関する情報に基づいて表示内容を決定し、決定した表示内容に基づく映像データを準備し、準備した映像データに基づく映像を映像表示部１１に表示させる。

ただし、図１５では、図６の場合と異なり、制御部２０は、表示内容を適宜調整したのちに表示内容を決定する。このため、図１５では、図６の場合とは、映像データの準備処理（ステップＳ１２Ａ）の内容が若干異なっている。すなわち、図１５に示されるステップＳ１２Ａでは、制御部２０は、まず、表示内容の調整処理（ステップＳ４１Ａ）を行うことで表示内容を決定し、続いて、調整後の表示内容に基づいて映像データを作成する（ステップＳ４２Ａ）。その後、制御部２０は、図６の場合と同様に、作成した映像データをフレームバッファ１８に書き込み（ステップＳ１２３Ａ）、ハードウェア処理またはソフトウェア処理を用いて歪補正を行う（ステップＳ１２４Ａ）。

図１６は、図１５における表示内容の調整処理（ステップＳ４１Ａ）の詳細な処理内容の一例を示すフロー図である。詳細は後述するが、制御部２０は、前提として、表示内容、例えば表示内容の違いと、映像データの準備に要する予測時間との関係を定めた予測時間情報を予めメモリ１７等に記憶している。この前提で、制御部２０は、まず、図１５におけるステップＳ１１で取得した乗り物に関する情報に基づいて、表示内容を決定する前に、表示内容を仮決定する（ステップＳ４１１）。続いて、制御部２０は、仮決定した表示内容、仮表示内容とも呼ぶ、に基づく映像データの準備に要する準備時間Ｔｐを、予測時間情報に基づいて予測する（ステップＳ４１２）。

次いで、制御部２０は、ステップＳ４１２で予測した準備時間Ｔｐが所定の制御周期Ｔｃ、言い換えれば処理周期よりも短いか否かを判定する（ステップＳ４１３）。準備時間Ｔｐが制御周期Ｔｃよりも長い場合（ステップＳ４１３：Ｎｏの場合）、制御部２０は、仮決定した表示内容を変更したのち、ステップＳ４１２に戻って同様の処理を繰り返す（ステップＳ４１４）。これにより、制御部２０は、準備時間Ｔｐが制御周期Ｔｃよりも短くなるように、仮決定した表示内容、すなわち仮表示内容を変更する。一方、準備時間Ｔｐが制御周期Ｔｃよりも短い場合（ステップＳ４１３：Ｙｅｓの場合）、制御部２０は、仮決定している表示内容、すなわち現在の仮表示内容を最終的な表示内容として決定する（ステップＳ４１５）。

＜準備時間の予測方法＞
図１７Ａは、図１６における準備時間の予測方法（ステップＳ４１２）の具体例を示す図である。図１７Ｂは、図１７Ａとは異なる具体例を示す図である。図１７Ａおよび図１７Ｂに示されるように、制御部２０は、表示内容の違いと、映像データの準備に要する予測時間との関係を定めた予測時間情報４００を予め記憶している。具体的には、予測時間情報４００は、基本時間、この例では０．８［ｍｓｅｃ］と、図１４に示した映像毎の表示形式に含まれる各項目に応じた係数とを含んでいる。

すなわち、予測時間情報４００は、サイズ係数Ｃ１と、表示位置係数Ｃ２と、デザイン種別係数Ｃ３とを含んでいる。デザイン種別係数Ｃ３には、ポリゴン数係数Ｃ３１と、グラデーション係数Ｃ３２とが含まれる。サイズ係数Ｃ１は、映像ＶＤのサイズに比例する係数である。サイズ係数Ｃ１は、例えば、図１３Ａに示した警告を表す映像ＶＤａ１、進行方向を表す映像ＶＤｂ、ナビゲーション情報を表す映像ＶＤｃといったような映像ＶＤの種類毎に固定的に定められる。

表示位置係数Ｃ２は、映像ＶＤの表示位置が近くなるほど大きくなるように定められる。この例では、表示位置は、近い、中間、遠いの３段階に区別され、表示位置係数Ｃ２は、表示位置が近い場合には１．５に、中間の場合には１．０に、近い場合には０．５に定められる。ポリゴン数係数Ｃ３１は、映像ＶＤを描画する際のポリゴン数が多いほど大きくなるように定められる。この例では、ポリゴン数は、基準値以上、基準値未満、すなわち、多い、標準の２段階に区別され、ポリゴン数係数Ｃ３１は、ポリゴン数が多い場合には１．２に、標準の場合には１．０に定められる。

グラデーション係数Ｃ３２は、グラデーションの有無に応じた係数である。この例では、グラデーション係数Ｃ３２は、グラデーションが有りの場合には１．１に、無しの場合には１．０に定められる。なお、基本時間や、各係数の値は、図１５に示したステップＳ４２Ａでの映像データの作成処理、言い換えれば描画処理に要する時間や、ステップＳ１２３Ａでのフレームバッファ１８への書き込み処理に要する時間や、ステップＳ１２４Ａでの歪補正に要する時間を全て勘案して定められる。具体的な定め方としては、例えば、シミュレーションに基づく方法や、実測値に基づく方法等が挙げられる。

制御部２０は、このような予測時間情報４００を用いて、基本時間に各係数を乗算することで、準備時間Ｔｐを予測する。具体的には、制御部２０は、映像ＶＤ毎に、映像データの準備に要する予測時間Ｔｒを、“基本時間×Ｃ１×Ｃ２×Ｃ３１×Ｃ３２”によって算出する。なお、予測時間Ｔｒの算出方法は、これに限定されず、場合によっては、“基本時間×Ｃ１×Ｃ２×Ｃ３１”によって算出しても構わない。また、予測時間Ｔｒに影響する別のパラメータがある場合には、そのパラメータを考慮して予測時間Ｔｒを算出してもよい。

さらに、予測時間Ｔｒを算出する際には、基本時間と係数から都度算出するのではなく、例えば、どの映像を、どのサイズで、どの位置に、どのようなデザインで表示すると、準備にどれだけの時間を要するかを表す情報を、予測時間情報として予め記憶しておいてもよい。この場合、準備に要する時間を映像ＶＤ毎に記憶しておく必要があるが、予測時間Ｔｒを都度算出しなくて済む。制御部２０は、以上のような方法によって算出した映像ＶＤ毎の予測時間Ｔｒを合計することで、準備時間Ｔｐを予測する。

具体例として、図１６に示したステップＳ４１１において、図１７Ａに示されるような３個の映像ＶＤ１～ＶＤ３を表示するように表示内容が仮決定された場合を想定する。映像ＶＤ１は、サイズ係数Ｃ１が５であり、近い表示位置に、３Ｄグラフィックスかつグラデーション有りを用いて表示されるものとなっている。映像ＶＤ２は、サイズ係数Ｃ１が２であり、中間の表示位置に、２Ｄグラフィックスを用いて表示されるものとなっている。映像ＶＤ３は、サイズ係数Ｃ１が１０であり、遠い表示位置に、２Ｄグラフィックスかつグラデーション有りを用いて表示されるものとなっている。

この場合、制御部２０は、映像ＶＤ１の映像データの準備に要する予測時間Ｔｒを、７．９［ｍｓｅｃ］＝０．８×Ｃ１（＝５）×Ｃ２（＝１．５）×Ｃ３１（＝１．２）×Ｃ３２（＝１．１）と算出する。同様にして、制御部２０は、映像ＶＤ２の映像データの準備に要する予測時間Ｔｒを１．６［ｍｓｅｃ］と算出し、映像ＶＤ３の映像データの準備に要する予測時間Ｔｒを４．４［ｍｓｅｃ］と算出する。

そして、制御部２０は、算出した映像ＶＤ１～ＶＤ３毎の予測時間Ｔｒを合計することで、準備時間Ｔｐを１３．９［ｍｓｅｃ］＝７．９＋１．６＋４．４と予測する。例えば、制御周期Ｔｃが１６．６ｍｓの場合、予測される準備時間Ｔｐは、制御周期Ｔｃよりも短くなる。このため、制御部２０は、図１６に示したステップＳ４１５において、そのままの表示形式を有する３個の映像ＶＤ１～ＶＤ３を、表示内容として決定する。

また、別の具体例として、図１７Ｂに示されるように、図１７Ａに示した３個の映像ＶＤ１～ＶＤ３に加えて２個の映像ＶＤ４，ＶＤ５を表示するように表示内容が仮決定された場合を想定する。映像ＶＤ４は、サイズ係数Ｃ１が８であり、中間の表示位置に、２Ｄグラフィックスを用いて表示されるものとなっている。映像ＶＤ５は、サイズ係数Ｃ１が２であり、近い表示位置に、３Ｄグラフィックスを用いて表示されるものとなっている。

この場合、制御部２０は、映像ＶＤ４の映像データの準備に要する予測時間Ｔｒを、６．４［ｍｓｅｃ］＝０．８×Ｃ１（＝８）×Ｃ２（＝１．０）×Ｃ３１（＝１．０）×Ｃ３２（＝１．０）と算出する。同様にして、制御部２０は、映像ＶＤ５の映像データの準備に要する予測時間Ｔｒを２．９［ｍｓｅｃ］と算出する。そして、制御部２０は、算出した映像ＶＤ１～ＶＤ５毎の予測時間Ｔｒを合計することで、準備時間Ｔｐを２３．２［ｍｓｅｃ］と予測する。予測される準備時間Ｔｐは、制御周期Ｔｃよりも長くなる。このため、制御部２０は、図１６に示したステップＳ４１４において、表示内容、すなわち仮決定した表示内容を変更する。

＜表示内容の変更方法＞
図１８は、図１６における表示内容の変更方法（ステップＳ４１４）の一例を説明する図である。制御部２０は、準備時間Ｔｐが制御周期Ｔｃよりも短くなるように、映像ＶＤの数を変更するか、または、映像ＶＤ毎の表示形式、すなわち、サイズ、表示位置、デザイン種別の中の少なくとも一つを変更する。この際に、制御部２０は、例えば、図１８に示されるように、変更対象となる項目毎の優先度を定めた優先度情報４１０を、予めメモリ１７等に記憶している。そして、制御部２０は、準備時間Ｔｐが制御周期Ｔｃよりも短くなるまで、当該優先度情報４１０に基づいて変更対象とする項目を増やしながら、表示内容を変更する。

図１８に示される優先度情報４１０では、映像ＶＤの数は、映像ＶＤ毎の表示形式よりも低い優先度に設定されている。映像ＶＤ毎の表示形式を変更する際の優先度は、図１８に示される例では、高い方から順に、デザイン種別、サイズ、表示位置、歪補正となっている。制御部２０は、優先度情報４１０に基づいて、まず、各映像ＶＤのデザイン種別を変更する。具体的には、制御部２０は、例えば、３Ｄグラフィックスを２Ｄグラフィックスに変更し、グラデーション有りをグラデーション無しに変更する。

これにより、図１６において、再度予測した準備時間Ｔｐが制御周期Ｔｃよりも短くなった場合（ステップＳ４１２，Ｓ４１３）、制御部２０は、変更後の映像ＶＤを用いて、表示内容を決定する（ステップＳ４１５）。一方、再度予測した準備時間Ｔｐが依然として制御周期Ｔｃよりも長かった場合（ステップＳ４１２，Ｓ４１３）、制御部２０は、各映像ＶＤのデザイン種別に加えて、各映像ＶＤのサイズを小さくする。具体的には、制御部２０は、例えば、予め映像ＶＤの種類毎にサイズの下限値を定めておき、下限値に到達するまで、各映像ＶＤのサイズを順に小さくしていく。

具体例として、図１７Ｂにおいて、映像ＶＤ３に対するサイズの下限値、詳細には、サイズ係数Ｃ１の下限値が８に設定されている場合を想定する。この場合、制御部２０は、まず、映像ＶＤ３のサイズを、サイズ係数Ｃ１が９となる大きさに変更し、それでもＴｐ＞Ｔｃであった場合、サイズ係数Ｃ１が８となる大きさに変更する。なお、この際には、映像ＶＤの種類に応じて、サイズ係数Ｃ１の変更が許可されない、すなわち下限値が設定されない映像ＶＤも設定され得る。

以降同様にして、制御部２０は、優先度情報４１０に基づいて、Ｔｐ＜Ｔｃとなるまで、変更対象の項目に、表示位置と、歪補正とを順に加えていく。制御部２０は、表示位置を変更する際には、表示位置を奥に移動させることでサイズを小さくする。この際には、映像ＶＤの種類に応じて、表示位置の変更が許可されない映像ＶＤも設定され得る。また、制御部２０は、歪補正の項目を変更する際には、例えば、予め定められた簡略化された歪補正を適用したり、あるいは、歪補正自体を行わないようにする。

このようにして映像ＶＤ毎の表示形式を変更しても、依然としてＴｐ＞Ｔｃであった場合、制御部２０は、最終手段として、映像ＶＤの数を減らす。この際に、制御部２０は、どの映像ＶＤから順に削減するかを、例えば、図１１Ｃで述べた抑制テーブル等に基づいて定める。抑制テーブルでは、前述したように、安全運転への寄与が大きい車両情報４、言い換えれば映像ＶＤの種類ほど、削除対象とならないように優先度が設定される。

図１９は、図１８において、表示内容の変更を行った結果として得られるＨＵＤ装置の表示内容の一例を示す概略図である。図１９における上段には、変更前の表示内容として、図１１Ａの場合と同様の表示内容が示される。すなわち、ここでは、７個の映像ＶＤａ１～ＶＤａ３，ＶＤｂ～ＶＤｅが表示される。映像ＶＤａ１，ＶＤａ２は、それぞれ、物体ＯＢ１，ＯＢ２、ここでは人に重畳するように表示される。映像ＶＤａ３は、物体ＯＢ３、ここでは車両に重畳するように表示される。映像ＶＤｂ，ＶＤｃ，ＶＤｄ，ＶＤｅは、それぞれ、進行方向、ナビゲーション情報、道路標識、速度情報を表す。映像ＶＤａ１～ＶＤａ３には、３Ｄグラフィックス、かつ、グラデーション有りが用いられるものとする。

図１９における下段には、変更後の表示内容が示される。変更後の表示内容では、変更前の表示内容と比較して、映像ＶＤａ１～ＶＤａ３がそれぞれ映像ＶＤａ１ｘ～ＶＤａ３ｘに置き換わっている。映像ＶＤａ１ｘ～ＶＤａ３ｘには、２Ｄグラフィックス、かつ、グラデーション無しが用いられる。さらに、映像ＶＤａ１ｘ～ＶＤａ３ｘのサイズは、映像ＶＤａ１～ＶＤａ３と比較して、若干小さくなっている。

さらに、図１９に示される例では、映像ＶＤａ１ｘ～ＶＤａ３ｘを用いた場合であっても、準備時間Ｔｐが依然として制御周期Ｔｃよりも長かったため、符号４０５の箇所に示されるように、速度情報を表す映像ＶＤｄが削除されている。すなわち、この例では、速度情報を表す映像ＶＤｄは、他の映像ＶＤに比べて、安全運転への寄与が小さいものと仮定して、映像ＶＤｄが削除されている。このような変更方法を用いることで、安全運転の観点で、変更前の表示内容を可能な限り維持しつつ、運転者等の利用者に、大きな違和感を抱かせないように、表示内容を変更することが可能になる。

図２０は、図１５および図１６に示されるフローを用いて映像を表示する際のタイミングチャートである。図２０には、図７の場合と同様に、１番目～４番目の処理周期または制御周期Ｔｃ［１］～Ｔｃ［４］で実行される動作が示される。制御周期Ｔｃは、例えば、１６．６ｍｓである。図２０に示されるように、仮に表示内容を変更しない場合、例えば、制御周期Ｔｃ［２］での準備時間Ｔｐ［２ａ］は、制御周期Ｔｃ［２］よりも長くなり得る。この場合、図７で述べたように、コマ落ちが生じることになる。

一方、表示内容を変更すると、例えば、制御周期Ｔｃ［２］での準備時間Ｔｐ［２ｂ］を、制御周期Ｔｃ［２］よりも短くすることができる。その結果、コマ落ちを防止することが可能になる。なお、準備時間Ｔｐには、図１５および図１６に示した表示内容の調整処理（ステップＳ４１Ａ）に要する時間も含まれる。このため、当該ステップＳ４１Ａに要する時間は、準備時間Ｔｐ内のオーバヘッド時間となるが、通常、ステップＳ４２，Ｓ１２３，Ｓ１２４に要する時間と比較して十分に小さく、無視できるレベルと考えられる。

また、前述した実施の形態１の方式では、実際に発生した準備時間Ｔｐを監視し、その監視結果に基づいて制御を行う、言うなればフィードバック制御を行う関係上、図２０に示した準備時間Ｔｐ［２ａ］のような状況が瞬間的に生じる可能性がある。一方、実施の形態２の方式では、準備時間Ｔｐを予測して制御を行う、言うなればフィードフォワード制御を行うため、理想的には、図２０に示した準備時間Ｔｐ［２ａ］のような状況は生じない。

＜実施の形態２の主要な効果＞
以上、実施の形態２の方式を用いることでも、実施の形態１で述べた各種効果と同様の効果が得られる。すなわち、コマ落ち等の発生を抑制または防止し、最低限の表示品質を確保することができる。そして、ハードウェアの処理性能の範囲内において、求められる表示仕様をできるだけ満足するとともに、表示仕様に柔軟に対応することが可能になる。さらに、準備時間Ｔｐを予測することにより、実施の形態１の方式と比較して、表示内容を過剰に変更する、または抑制する事態が生じ難いため、表示品質をより高めることが可能になる。

なお、実施の形態１の方式は、例えば、初期製品等にように表示仕様に多くの変動要素があり、図１７Ａおよび図１７Ｂに示したような予測時間情報４００を作成し難いような場合に特に有益となる。一方、実施の形態２の方式は、例えば、ある程度成熟した製品等にように、表示仕様における変動要素が少ない場合に特に有益となる。また、実施の形態２の方式では、予測時間情報４００を作成する必要があるため、変動が大きい表示仕様に対応する際の柔軟性、または汎用性の観点では、実施の形態１の方式がより有益となり得る。

（実施の形態３）
＜制御部の詳細＞
図２１Ａは、実施の形態３によるＨＵＤ装置において、制御部の主要な処理内容の一例を示す模式図であり、図２１Ｂは、図２１Ａの補足図である。図２２Ａは、図２１Ａとは異なる一例を示す模式図であり、図２２Ｂは、図２２Ａの補足図である。実施の形態３によるＨＵＤ装置１は、前述した図３Ａまたは図３Ｂに示した構成で実現される。制御部２０は、図２１Ａでの映像ＶＤａ３ａおよび図２２Ａでの映像ＶＤａ３ｂに示されるように、物体ＯＢ３、ここでは車両に警告映像を重畳させる。

この際に、制御部２０は、警告映像である映像ＶＤａ３ａ，ＶＤａ３ｂの色または形状を、物体ＯＢ３との距離に応じて定める。図２１Ａおよび図２１Ｂの例では、ＨＵＤ装置１を搭載した自車４２０と、自車４２０の前方に存在する物体ＯＢ３との距離は、５０ｍとなっている。この場合、制御部２０は、映像ＶＤａ３ａの色を、例えば緑色に定める。一方、図２２Ａおよび図２２Ｂの例では、自車４２０と物体ＯＢ３との距離は、１０ｍとなっている。この場合、制御部２０は、映像ＶＤａ３ｂの色を、例えば赤色に定める。

図２３は、実施の形態３によるＨＵＤ装置において、制御部が記憶している表示設定テーブルの構成例を示す図である。制御部２０は、例えば図２３に示されるような表示設定テーブル４１５を、予めメモリ１７等に記憶している。表示設定テーブル４１５は、前方の物体ＯＢ３との距離と、警告映像の色または形状、ここでは色との対応関係を定める。この例では、警告映像の色は、物体ＯＢ３との距離が１２ｍ未満の場合には赤色に、３２ｍ以上の場合には緑色に、１７ｍ～２７ｍの範囲の場合には黄色にそれぞれ定められる。また、合間の距離となる１２ｍ～１７ｍの範囲や２７ｍ～３２ｍの範囲での色は、適宜、中間色に定められる。

表示設定テーブル４１５は、例えば、物体ＯＢ３との距離が近くなるほど、利用者、例えば運転者の注意をより喚起するような色または形状となるように設定される。これにより、安全運転に寄与することが可能となる。ただし、色または形状の捉え方は、利用者の主観に依存する。このため、利用者による初期設定によって、表示設定テーブル４１５における色または形状を複数の選択肢の中から任意に選択できるように構成されてもよい。さらに、表示設定テーブル４１５において、距離の範囲を任意に設定できるように構成されてもよい。

図２４Ａは、実施の形態３によるＨＵＤ装置において、制御部の処理内容の一例を示すフロー図である。図２４Ａにおいて、制御部２０は、実施の形態２における図１６で述べたステップＳ４１１～Ｓ４１５の処理を実行する。また、当該処理に先立って、通信部１６、すなわち情報取得部は、図１５に示したステップＳ１１において、乗り物に関する情報の一つとして、自車４２０と、自車４２０の前方に存在する物体ＯＢ３との距離を取得する。

制御部２０は、図２４Ａに示したステップＳ４１１～Ｓ４１５の処理によって、準備時間Ｔｐが制御周期Ｔｃ、言い換えれば処理周期よりも短くなるように、表示内容を決定する。その後、制御部２０は、ステップＳ４１５で決定した表示内容の中に、物体ＯＢ３に重畳される警告映像が含まれるか否かを判定する（ステップＳ４１６Ａ）。決定した表示内容の中に警告映像が含まれる場合（ステップＳ４１６Ａ：Ｙｅｓの場合）、制御部２０は、通信部１６で取得した物体ＯＢ３との距離情報を参照し（ステップＳ４１７）、表示設定テーブル４１５に基づいて警告映像の色または形状を更新する（ステップＳ４１８Ａ）。なお、警告映像が複数含まれる場合には、警告映像毎に当該更新処理が行われる。

このように、図２４Ａに示されるフローでは、制御部２０は、決定した表示内容の中に警告映像が含まれる場合には、準備時間Ｔｐを再度予測することなく、すなわちステップＳ４１２等の処理を経ることなく、警告映像の色または形状を更新する（ステップＳ４１８Ａ）。このため、距離毎の警告映像の色または形状は、警告映像の色または形状を更新した場合であっても、準備時間Ｔｐが更新前と同等となるように、予め定められることが望ましい。

図２４Ｂは、図２４Ａとは異なる処理内容の一例を示すフロー図である。図２４Ｂに示されるフローでは、図２４Ａに示したフローと異なり、図１６で述べたステップＳ４１１～Ｓ４１５の処理の後ではなく、ステップＳ４１１～Ｓ４１５の処理の中に、図２４Ａで述べたステップＳ４１６Ａ，Ｓ４１７，Ｓ４１８Ａと同様の処理が組み込まれている。

図２４Ｂにおいて、制御部２０は、表示内容を仮決定したのち（ステップＳ４１１）、仮決定した表示内容の中に、物体ＯＢ３に重畳される警告映像が含まれるか否かを判定する（ステップＳ４１６Ｂ）。仮決定した表示内容の中に警告映像が含まれる場合（ステップＳ４１６Ｂ：Ｙｅｓの場合）、制御部２０は、物体ＯＢ３との距離情報を参照し（ステップＳ４１７）、表示設定テーブル４１５に基づいて警告映像の色または形状を決定する（ステップＳ４１８Ｂ）。

そして、その後に、制御部２０は、仮決定した表示内容に基づく映像データの準備に要する準備時間Ｔｐを予測する（ステップＳ４１２）。なお、仮決定した表示内容の中に警告映像が含まれない場合（ステップＳ４１６Ｂ：Ｎｏの場合）、制御部２０は、そのままステップＳ４１２へ移行する。ステップＳ４１２の後、制御部２０は、図１６の場合と同様に、ステップＳ４１３～Ｓ４１５の処理によって、準備時間Ｔｐが制御周期Ｔｃよりも短くなるように、仮決定した表示内容を変更する。

ただし、図１６の場合と異なり、制御部２０は、仮決定した表示内容を変更したのち、ステップＳ４１６Ｂへ移行する（ステップＳ４１４）。これにより、ステップＳ４１４の処理によって警告映像の色または形状が変更されたとしても、それを、ステップＳ４１７，Ｓ４１８Ｂの処理によって正しく戻した上で、準備時間Ｔｐを予測することができる（ステップＳ４１２）。

図２４Ｂに示したフローを用いると、警告映像における色または形状の変更を反映させた上で準備時間Ｔｐを予測できるため、図２４Ａに示したフローを用いる場合と比較して、予測精度を高められる場合がある。ただし、図２４Ｂに示したフローを用いると、ステップＳ４１４からステップＳ４１６Ｂへのループが生じる度に、ステップＳ４１６Ｂ，Ｓ４１７，Ｓ４１８Ｂの処理を行う必要があるため、処理のオーバヘッドが増大し得る。したがって、この観点では、図２４Ａに示したフローを用いることが有益となる。

また、例えば、図２４ＡにおけるステップＳ４１６Ａ，Ｓ４１７，Ｓ４１８Ａで述べたような表示設定テーブル４１５に基づく処理は、実施の形態２の方式に限らず、実施の形態１の方式に適用されてもよい。この場合、制御部２０は、例えば、図６に示したステップＳ１２１において内部状態を踏まえて表示内容を決定する際に、その最終段階で、ステップＳ４１６Ａ，Ｓ４１７，Ｓ４１８Ａで述べたような処理を実行すればよい。

＜実施の形態３の主要な効果＞
以上、実施の形態３の方式を用いると、実施の形態１および実施の形態２で述べた各種効果に加えて、警告映像の色または形状を物体との距離に応じて変更することで、より安全運転に寄与することが可能になる。

また、各実施の形態の方式を用いると、利用者６は、行き先や速度などのナビゲーション情報の他に、対向車や歩行者を検知した際のアラート情報など、走行に必要な各種情報をウィンドシールド３越しの映像として視認でき、表示仕様が変わっても、最低限の表示品質が確保された映像を視認できる。これにより、利用者６の視点移動を軽減して安全運転の支援に寄与するＨＵＤ装置１を提供できる。その結果、交通事故を防止することが可能となる。さらに、国連の提唱する持続可能な開発目標（ＳＤＧｓ：Sustainable Development Goals）の「３．すべての人に健康と福祉を」に貢献することが可能になる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、前述した実施の形態は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

１…ヘッドアップディスプレイ（ＨＵＤ）装置、２…車両、４…車両情報、５…表示領域、６…利用者、１１…映像表示部、１６…通信部（情報取得部）、２０…制御部、４００…予測時間情報、４１０…優先度情報、４１５…表示設定テーブル、Ｃ１～Ｃ３，Ｃ３１，Ｃ３２…係数、Ｍ１…ミラー（映像光投射部）、ＳＴ０…通常状態、ＳＴ１…復帰移行状態、ＳＴ２…抑制移行状態、ＳＴ３…抑制状態、Ｔｃ…制御周期、Ｔｐ…準備時間、Ｔｒ…予測時間、Ｔｔｈ１…第１の閾値時間、Ｔｔｈ２…第２の閾値時間、ＴｔｈＤ…閾値継続期間、ＶＤ…映像

Claims (16)

1. 乗り物に搭載されるヘッドアップディスプレイ装置であって、
   前記乗り物に関する情報を取得する情報取得部と、
   映像を表示し、表示した映像の映像光を出射する映像表示部と、
   前記映像表示部から出射された前記映像光を表示領域に投射することで、投射された前記映像光を虚像として視認させる映像光投射部と、
   前記情報取得部によって取得された前記乗り物に関する情報に基づいて表示内容を決定し、決定した前記表示内容に基づく映像データを準備し、準備した前記映像データに基づく映像を前記映像表示部に表示させる制御部と、
   を備え、
   前記制御部は、前記表示内容を決定する前の仮決定した表示内容の前記映像データの準備に要する準備時間が所定の処理周期よりも長い場合、前記仮決定した表示内容を変更する、
   ヘッドアップディスプレイ装置。
2. 請求項１に記載のヘッドアップディスプレイ装置において、
   前記制御部は、前記表示内容を決定する前に、前記仮決定した表示内容に基づく前記映像データの準備に要する準備時間を、前記表示内容と前記映像データの準備に要する予測時間との関係を定めた予測時間情報に基づいて予測し、前記準備時間が前記処理周期よりも長い場合、前記処理周期よりも短くなるように前記仮決定した表示内容を変更する、
   ヘッドアップディスプレイ装置。
3. 請求項２に記載のヘッドアップディスプレイ装置において、
   前記仮決定した表示内容を変更する際の項目は、映像の数、または、映像毎の表示形式を含み、
   前記映像毎の表示形式を変更する際の項目は、サイズ、表示位置、デザイン種別の中の少なくとも一つを含む、
   ヘッドアップディスプレイ装置。
4. 請求項３に記載のヘッドアップディスプレイ装置において、
   前記制御部は、前記項目毎の優先度を定めた優先度情報を予め記憶し、前記準備時間が前記処理周期よりも短くなるまで、前記優先度情報に基づいて変更対象とする前記項目を増やしながら、前記仮決定した表示内容を変更する、
   ヘッドアップディスプレイ装置。
5. 請求項４に記載のヘッドアップディスプレイ装置において、
   前記仮決定した表示内容を変更する際の前記項目は、前記映像の数と前記映像毎の表示形式とを含み、
   前記優先度情報において、前記映像の数は、前記映像毎の表示形式よりも低い優先度に設定されている、
   ヘッドアップディスプレイ装置。
6. 請求項３に記載のヘッドアップディスプレイ装置において、
   前記予測時間情報は、基本時間と、前記映像毎の表示形式に含まれる前記項目に応じた係数とを含み、
   前記制御部は、前記基本時間に前記係数を乗算することで、前記準備時間を予測する、
   ヘッドアップディスプレイ装置。
7. 請求項１に記載のヘッドアップディスプレイ装置において、
   前記情報取得部は、前記ヘッドアップディスプレイ装置を搭載した前記乗り物と、前記乗り物の前方に存在する物体との距離を取得し、
   前記制御部は、前記物体に警告映像を重畳させる場合、前記警告映像の色または形状を前記物体との距離に応じて定める、
   ヘッドアップディスプレイ装置。
8. 請求項７に記載のヘッドアップディスプレイ装置において、
   前記制御部は、前記準備時間が前記処理周期よりも短くなるように、前記表示内容を決定したのち、決定した前記表示内容の中に前記警告映像が含まれる場合には、前記準備時間を再度予測することなく前記警告映像の色または形状を更新する、
   ヘッドアップディスプレイ装置。
9. 乗り物に搭載されるヘッドアップディスプレイ装置への映像データの処理方法であって、
   前記乗り物に関する情報を取得し、
   取得された前記乗り物に関する情報に基づいて表示内容を決定し、決定した前記表示内容に基づく映像データを準備し、準備した前記映像データに基づく映像を前記ヘッドアップディスプレイ装置の映像表示部に表示させ、
   前記表示内容を決定する前の仮決定した表示内容の前記映像データの準備に要する準備時間が所定の処理周期よりも長い場合、前記仮決定した表示内容を変更する、
   映像データの処理方法。
10. 請求項９に記載の映像データの処理方法において、
    前記表示内容を決定する前に、前記仮決定した表示内容に基づく前記映像データの準備に要する準備時間を、前記表示内容と前記映像データの準備に要する予測時間との関係を定めた予測時間情報に基づいて予測し、前記準備時間が所定の処理周期よりも長い場合、前記処理周期よりも短くなるように前記仮決定した表示内容を変更する、
    映像データの処理方法。
11. 請求項１０に記載の映像データの処理方法において、
    前記仮決定した表示内容を変更する際の項目は、映像の数、または、映像毎の表示形式を含み、
    前記映像毎の表示形式を変更する際の項目は、サイズ、表示位置、デザイン種別の中の少なくとも一つを含む、
    映像データの処理方法。
12. 請求項１１に記載の映像データの処理方法において、
    前記項目毎の優先度を定めた優先度情報を予め記憶し、前記準備時間が前記処理周期よりも短くなるまで、前記優先度情報に基づいて変更対象とする前記項目を増やしながら、前記仮決定した表示内容を変更する、
    映像データの処理方法。
13. 請求項１２に記載の映像データの処理方法において、
    前記仮決定した表示内容を変更する際の前記項目は、前記映像の数と前記映像毎の表示形式とを含み、
    前記優先度情報において、前記映像の数は、前記映像毎の表示形式よりも低い優先度に設定されている、
    映像データの処理方法。
14. 請求項１１に記載の映像データの処理方法において、
    前記予測時間情報は、基本時間と、前記映像毎の表示形式に含まれる前記項目に応じた係数とを含み、
    前記基本時間に前記係数を乗算することで、前記準備時間を予測する、
    映像データの処理方法。
15. 請求項９に記載の映像データの処理方法において、
    前記ヘッドアップディスプレイ装置を搭載した前記乗り物と、前記乗り物の前方に存在する物体との距離を取得し、
    前記物体に警告映像を重畳させる場合、前記警告映像の色または形状を前記物体との距離に応じて定める、
    映像データの処理方法。
16. 請求項１５に記載の映像データの処理方法において、
    前記準備時間が前記処理周期よりも短くなるように、前記表示内容を決定したのち、決定した前記表示内容の中に前記警告映像が含まれる場合には、前記準備時間を再度予測することなく前記警告映像の色または形状を更新する、
    映像データの処理方法。

Images