特許 7250784 ボリュームデータの密度座標ハッシュ化

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-03-24

(45)【発行日】2023-04-03

(54)【発明の名称】ボリュームデータの密度座標ハッシュ化

(51)【国際特許分類】

   G06T 15/08 20110101AFI20230327BHJP

【ＦＩ】

G06T15/08

【請求項の数】 20

(21)【出願番号】P 2020522337

(86)(22)【出願日】2018-10-16

(65)【公表番号】

(43)【公表日】2020-12-17

(86)【国際出願番号】 US2018056164

(87)【国際公開番号】W WO2019079358

(87)【国際公開日】2019-04-25

【審査請求日】2021-10-04

(31)【優先権主張番号】62/573,089

(32)【優先日】2017-10-16

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】520132791

【氏名又は名称】モビディウス リミテッド

(74)【代理人】

【識別番号】110000877

【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所

(72)【発明者】

【氏名】モロニー、デイヴィッド マクダラ

(72)【発明者】

【氏名】ビレン、ジョナサン デイヴィッド

(72)【発明者】

【氏名】バックリー、レオニー

(72)【発明者】

【氏名】バウグ、ギャリー ガーフィールド バーリントン

(72)【発明者】

【氏名】コールフィールド、サム

(72)【発明者】

【氏名】パッラ、アレッサンドロ

(72)【発明者】

【氏名】グプタ、アナンヤ

【審査官】岡本 俊威

(56)【参考文献】

【文献】特表２００６－５２０９４８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｔ １５／０８

(57)【特許請求の範囲】

【請求項1】

ボリュームを表すボリュームデータを生成する手順であって、前記ボリュームは一組のボクセルを含み、前記ボクセルの少なくとも１つは、三次元（３Ｄ）ジオメトリで占有され、前記ボリュームデータは、前記一組のボクセルの各々について、それぞれの前記ボクセルが占有されているかを特定する、手順と、
ハッシュ化アルゴリズムに応じて、前記ボリュームデータのインデックス値を生成する手順であって、前記一組のボクセル内の前記ボクセルの特定のサブセットを表す、前記ボリュームデータの特定の部分の前記インデックス値は、前記ボクセルの特定のサブセットに関連付けられた、ｘ座標、ｙ座標およびｚ座標の値の組み合わせに基づいて生成され、前記ボリュームに対応する辺長値に基づいて、前記特定の部分の前記インデックス値がさらに生成される、手順と、
前記ボリュームデータの前記特定の部分を、ハッシュテーブルのエントリ内に記憶する手順であって、前記エントリは、前記特定の部分の前記インデックス値に基づくアドレスを有する、手順と、
をプロセッサに実行させる、
プログラム。

【請求項2】

前記ｘ座標、前記ｙ座標および前記ｚ座標の前記値の前記組み合わせは、前記ｘ座標、前記ｙ座標および前記ｚ座標の前記値の加重和を含み、前記ｘ座標、前記ｙ座標および前記ｚ座標の１または複数が、前記辺長値に基づいて重み付けされる、請求項１に記載のプログラム。

【請求項3】

前記インデックス値は、式ｉｎｄｅｘ＝（ＩＤ_ｚ×（ＳＬ^２）＋ＩＤ_ｙ×（ＳＬ）＋ＩＤ_ｘ）に応じて生成され、式中、ＩＤ_ｚは前記ｚ座標の前記値であり、ＩＤ_ｙは前記ｙ座標の前記値であり、ＩＤ_ｘは前記ｘ座標の前記値であり、ＳＬは前記辺長値である、請求項２に記載のプログラム。

【請求項4】

前記ボリュームの前記ｘ座標、前記ｙ座標および前記ｚ座標の各々の内部の、占有ボリュームの相対密度に基づいて、前記辺長値を使用して前記ｘ座標、前記ｙ座標および前記ｚ座標に適用される重みを決定する手順をさらに前記プロセッサに実行させる、請求項２に記載のプログラム。

【請求項5】

前記ボリュームは、一組のボクセルブロックに論理的に細分化され、前記ボクセルブロックの各々は、それぞれのボクセルサブセットのサブボリュームを含み、前記特定のサブセットボクセルは、前記一組のボクセルブロックの特定の１つを含む、請求項１から４のいずれか一項に記載のプログラム。

【請求項6】

前記ハッシュテーブル内の各エントリは、前記一組のボクセルブロックのそれぞれにおける各ボクセルを記述するためのボリュームデータを含むようなサイズである、請求項５に記載のプログラム。

【請求項7】

各ボクセルブロックは、複数のボクセルを含み、前記ハッシュテーブル内の各エントリは、前記対応するボクセルが占有されているかを特定するために、前記ボクセルブロックにおけるボクセル毎に少なくとも１つのビットを含む、請求項６に記載のプログラム。

【請求項8】

前記ハッシュテーブル内の各エントリは、前記対応するボクセルブロックにおけるボクセル毎に２ビットを含むようなサイズである、請求項７に記載のプログラム。

【請求項9】

前記エントリの前記アドレスを計算する手順であって、前記ハッシュテーブル内のエントリのアドレスは、前記インデックス値の剰余に基づいて計算される、手順をさらに前記プロセッサに実行させる、請求項１から８のいずれか一項に記載のプログラム。

【請求項10】

前記ハッシュテーブル内の前記エントリで衝突があるかを検出する手順と、
衝突が検出された場合、前記ハッシュテーブルに関連付けられた衝突管理方式を使用する手順と、
をさらに前記プロセッサに実行させる、
請求項１から９のいずれか一項に記載のプログラム。

【請求項11】

前記ハッシュ化アルゴリズムは密度座標（ＤＥＣＯ）ハッシュ化アルゴリズムである、請求項１から１０のいずれか一項に記載のプログラム。

【請求項12】

ボリューム内の特定のボクセルを特定する手順と、
コンピュータメモリ内に記憶されたハッシュテーブルにアクセスする手順と、
前記特定のボクセルに関連付けられた、前記ボリューム内のｘ座標、ｙ座標およびｚ座標を決定する手順と、
ハッシュ化アルゴリズムに応じて、かつ、前記ｘ座標、前記ｙ座標および前記ｚ座標に基づいて、前記特定のボクセルに関連付けられたインデックス値を決定する手順であって、前記インデックス値は、前記ボリュームに対応する辺長値に基づく、前記ｘ座標、前記ｙ座標および前記ｚ座標の加重値の総和を通じて、前記ハッシュ化アルゴリズムに応じて決定される、手順と、
前記インデックス値に基づいてハッシュテーブル内の特定のエントリを特定する手順であって、前記特定のエントリはボリュームデータを含み、前記ボリュームデータは、前記ボリュームの特定の部分におけるボクセルの特定のサブセットについて、前記ボクセルのサブセットにおけるボクセルが占有されているかを特定し、前記ボクセルのサブセットは、前記特定のボクセルを含む、手順と、
前記特定のエントリから、前記特定のボクセルが占有されているかを判定する手順と、
をプロセッサに実行させる、
プログラム。

【請求項13】

前記特定のボクセルが占有されているかの判定に基づいて、前記ボリューム内でのナビゲーション動作を決定する手順をさらにプロセッサに実行させる、請求項１２に記載のプログラム。

【請求項14】

前記インデックス値は、式ｉｎｄｅｘ＝（ＩＤ_ｚ×（ＳＬ^２）＋ＩＤ_ｙ×（ＳＬ）＋ＩＤ_ｘ）に応じて決定され、式中、ＩＤ_ｚは前記ｚ座標の値であり、ＩＤ_ｙは前記ｙ座標の値であり、ＩＤ_ｘは前記ｘ座標の値であり、ＳＬは前記辺長値である、請求項１２または１３に記載のプログラム。

【請求項15】

前記特定のボクセルに関連付けられた前記ｘ座標、前記ｙ座標および前記ｚ座標は、前記ボリューム内のボクセルのブロックの座標を含み、前記ボクセルのブロックは、前記ボクセルのサブセットを含む、請求項１２から１４のいずれか一項に記載のプログラム。

【請求項16】

前記ボリュームは、複数のボクセルのブロックを含み、前記辺長値は、前記ボリューム内のボクセルのブロックの数の立方根に等しい、請求項１５に記載のプログラム。

【請求項17】

ボリューム内の特定のボクセルを特定する段階と、
コンピュータメモリ内に記憶されたハッシュテーブルにアクセスする段階と、
前記特定のボクセルに関連付けられた、前記ボリューム内のｘ座標、ｙ座標およびｚ座標を決定する段階と、
ハッシュ化アルゴリズムに応じて、前記特定のボクセルに関連付けられたインデックス値を決定する段階であって、前記ハッシュ化アルゴリズムに応じて前記インデックス値を決定する段階は、前記ボリュームの寸法に対応する辺長値に基づく、前記ｘ座標、前記ｙ座標および前記ｚ座標の加重値を合計する段階を有する、段階と、
前記インデックス値に基づいてハッシュテーブル内の特定のエントリを特定する段階であって、前記特定のエントリはボリュームデータを含み、前記ボリュームデータは、前記特定のボクセルについて、前記特定のボクセルが占有されているかを特定する、段階と、
前記特定のボクセルが占有されているかに基づいて、前記ボリューム内の、デバイスの自律ナビゲーションの経路を決定する段階と、
を備える方法。

【請求項18】

データ処理装置と、
ハッシュテーブルを有するメモリと、
ボリュームの少なくとも一部分の内部のジオメトリを特定するためにボリュームデータを生成するセンサと、
ボリューム処理ロジックと、
を備えるシステムであって、
前記ボリューム処理ロジックは、
前記ボリュームの特定のサブボリュームに、前記ボリュームデータの特定の部分が対応すると判定する手順と、
前記ボリューム内の、前記特定のサブボリュームのｘ座標、ｙ座標およびｚ座標を決定する手順であって、前記特定のサブボリュームは、一組の１または複数のボクセルを含む、手順と、
ハッシュ化アルゴリズムに基づいて、前記ボリュームデータの前記特定の部分のインデックス値を決定する手順であって、前記インデックス値は、前記特定のサブボリュームの前記ｘ座標、前記ｙ座標および前記ｚ座標の加重値の総和から決定され、前記ｘ座標、前記ｙ座標および前記ｚ座標の値の１または複数が、辺長変数に基づいて重み付けされる、手順と、
前記インデックス値から、前記ハッシュテーブル内のアドレスを決定する手順と、
前記アドレスに衝突が存在するかを判定する手順と、
前記アドレスに衝突がないと判定されたことに基づいて、前記ボリュームデータの前記特定の部分を、前記アドレスに関連付けられた前記ハッシュテーブルのエントリに書き込まれるようにする手順と、
を実行可能である、
システム。

【請求項19】

前記ボリューム処理ロジックはさらに、
前記ボリューム内の特定のボクセルを特定する手順と、
前記ボリュームのサブボリュームが前記特定のボクセルを含むと判定する手順と、
前記特定のボクセルの前記サブボリュームのｘ座標、ｙ座標およびｚ座標を特定する手順と、
前記特定のボクセルの前記サブボリュームの前記ｘ座標、前記ｙ座標および前記ｚ座標から、かつ、前記ハッシュ化アルゴリズムに基づいて、前記特定のボクセルに関連付けられたインデックス値を計算する手順と、
前記特定のボクセルに関連付けられたボリュームデータにアクセスするために、前記特定のボクセルに関連付けられた前記インデックス値に対応する、前記ハッシュテーブル内のエントリにアクセスする手順であって、前記特定のボクセルに関連付けられた前記ボリュームデータは、前記特定のボクセルがジオメトリで占有されているかを特定する、手順と、
前記特定のボクセルがジオメトリで占有されているかに基づいて、前記ボリューム内での自律移動をトリガする手順と、
を実行可能である、
請求項１８に記載のシステム。

【請求項20】

ドローン、ロボットまたは自律走行車両の１つを備える、請求項１８または１９に記載のシステム。

【発明の詳細な説明】

【関連出願】

【0001】

本願は、２０１７年１０月１６日に出願され、その全体が参照により本明細書に組み込まれる米国仮特許出願第６２／５７３，０８９号の利益を主張する。

【技術分野】

【0002】

本開示は概してコンピュータシステムの分野に関し、より具体的にはコンピュータビジョンアプリケーションで使用されるハッシュテーブルに関する。

【背景技術】

【0003】

ＭａｇｉｃＬｅａｐ（商標）、Ｍｉｃｏｒｓｏｆｔ（商標）、ＨｏｌｏＬｅｎｓ（商標）、Ｏｃｕｌｕｓ（商標）、Ｒｉｆｔ（商標）による拡張現実（ＡＲ）、仮想現実（ＶＲ）および複合現実（ＭＲ）製品、さらにＶａｌｖｅ（商標）およびＨＴＣ（商標）等によるその他ＶＲシステムの出現により、コンピュータビジョンとグラフィックス両者の世界は、急速に統合が進んでいる。そのようなシステムにおける現行の手法として、並行動作する、個別のグラフィックスプロセッシングユニット（ＧＰＵ）およびコンピュータビジョンサブシステムが使用されている。これらの並行システムは、プロセッサ、および／またはプログラマブルハードウェアアクセラレータアレイ上で動作するソフトウェアにおいて実装されるコンピュータビジョンパイプラインと並行に、既存のＧＰＵから組み立て可能である。

【図面の簡単な説明】

【0004】

本開示の主題の様々な目的、特徴、および利点が、以下の図に関連して考慮した場合、以下の開示の主題の詳細の説明を参照することで、完全に理解可能である。図中、同様の符号は、同様の要素を示す。添付の図面は概略的であって、実寸どおりに描かれることは意図されていない。見やすさのため、全ての図の全ての構成要素に符号を付けてはいない。また、本開示の主題を当業者が理解するのに必ずしも必要でない図示の部分において、開示の主題の各実施形態の全ての構成要素が図示されてはいない。

【0005】

【図1】従来の拡張または複合現実レンダリングシステムを示す。

【0006】

【図2】いくつかの実施形態に係るボクセル型拡張または複合現実レンダリングシステムを示す。

【0007】

【図3】いくつかの実施形態に係る、デンスまたはスパースなボリューム表現間の違いを示す。

【0008】

【図4】いくつかの実施形態に係る、シーンの合成図を示す。

【0009】

【図5】いくつかの実施形態に係る、例示的な要素ツリー構造における、詳細度を示す。

【0010】

【図6】いくつかの実施形態に係る、本出願のデータ構造およびボクセルデータを利用可能なアプリケーションを示す。

【0011】

【図7】いくつかの実施形態に係る、３Ｄ数字の認識に使用される例示的ネットワークを示す。

【0012】

【図8】いくつかの実施形態に係る、同一のデータ構造に対して、非自明的詳細度を利用して実行される複数の分類を示す。

【0013】

【図9】いくつかの実施形態に係る、２Ｄ畳み込みニューラルネットワークによる動作省略を示す。

【0014】

【図10】いくつかの実施形態に係る、例示的テスト画像の分析からの実験結果を示す。

【0015】

【図11】いくつかの実施形態に係る、動作を省略するためのハードウェアを示す。

【0016】

【図12】いくつかの実施形態に係る、動作を省略するためのハードウェアの向上を示す。

【0017】

【図13】いくつかの実施形態に係るハードウェアを示す。

【0018】

【図14】ハッシュテーブルと関連したロジックとを採用した例示的システムを示す。

【0019】

【図15】いくつかの実施形態に係る、例示的ハッシュ化アルゴリズムの態様を示す。

【0020】

【図16A】例示的ハッシュ化アルゴリズムの性能を示すグラフである。

【図16B】例示的ハッシュ化アルゴリズムの性能を示すグラフである。

【図16C】例示的ハッシュ化アルゴリズムの性能を示すグラフである。

【0021】

【図17】いくつかの実施形態に係る、ハッシュテーブル内に、ボリュームデータを挿入するための例示的技術を示す。

【0022】

【図18】いくつかの実施形態に係る、ハッシュテーブルからボリュームデータにアクセスする例示的技術を示す。

【0023】

【図19】いくつかの実施形態に係る、例示的マルチスロットベクトルプロセッサを示す。

【0024】

【図20】いくつかの実施形態に係る、例示的ボリュームアクセラレーションハードウェアを示す。

【0025】

【図21】いくつかの実施形態に係る、ボクセルキューブの構成を示す。

【0026】

【図22】いくつかの実施形態に係る、２レベルスパースボクセルツリーを示す。

【0027】

【図23】いくつかの実施形態に係る、２レベルスパースボクセルツリーを示す。

【0028】

【図24】いくつかの実施形態に係る、例示的ボクセルデータの記憶を示す。

【0029】

【図25】いくつかの実施形態に係る、例示的ボリュームデータへのボクセル挿入を示す。

【0030】

【図26】いくつかの実施形態に係る、例示的３Ｄボリュームオブジェクトの投影を示す。

【0031】

【図27】例示的ボリュームデータ構造を伴う例示的動作を示す。

【0032】

【図28】いくつかの実施形態に係る、簡潔なマップを生成するための投影の使用を示す。

【0033】

【図29】いくつかの実施形態に係る、内蔵デバイスからの例示的ボリューム３Ｄおよび／または２Ｄ測定値の例示的蓄積を示す。

【0034】

【図30】いくつかの実施形態に係る、２Ｄの２×２ビットマップ上での、２Ｄ経路探索の例示的向上を示す。

【0035】

【図31】いくつかの実施形態に係る、例示的ボリュームデータ構造を使用した、衝突検出の例示的向上を示す。

【0036】

【図32】少なくともいくつかの実施形態に係るデバイスを有する例示的ネットワークの簡潔なブロック図である。

【0037】

【図33】少なくともいくつかの実施形態に係る、例示的なフォグまたはクラウドコンピューティングシステムの簡潔なブロック図である。

【0038】

【図34】少なくともいくつかの実施形態に係る、例示的デバイスを含むシステムの簡潔なブロック図である。

【0039】

【図35】少なくともいくつかの実施形態に係る、例示的処理デバイスのブロック図を示す。

【0040】

【図36】少なくともいくつかの実施形態に係る、例示的プロセッサのブロック図を示す。

【0041】

【図37】少なくともいくつかの実施形態に係る、例示的コンピューティングシステムのブロック図を示す。

【発明を実施するための形態】

【0042】

以下の説明において、開示の主題を完全に理解できるように等、開示の主題のシステムおよび方法、並びに当該システムおよび方法が動作し得る環境について数多くの具体的詳細が記載される。ただし、当業者には、開示の主題はそのような具体的な詳細がなくても実施できることは明らかであろう。開示の主題の複雑化を避けるため、従来技術により公知であるそのような特徴については詳細に説明しない。さらに、下記の実施形態は例示的であって、開示の主題の範囲内に含まれる、その他システムおよび方法が存在することが考えられる。

【0043】

多様な技術が、三次元空間およびジオメトリのボリュームを表すデータモデルを使用し得る、拡張現実、仮想現実、複合現実、自律デバイス、およびロボットに基づいて発生し、それら組み込んでいる。そのような３Ｄまたはボリュームデータを使用した様々な現実および仮想環境の表現は伝統的に、膨大のデータセットを伴うものであり、それはいくつかのコンピューティングシステムにとっては、所望のとおりに処理するのが困難であった。さらに、ドローン、ウェアラブルデバイス、仮想現実システム等のデバイスの小型化が進むと、当該デバイスのメモリおよび処理資源も制限され得る。一例として、ＡＲ／ＶＲ／ＭＲアプリケーションは、対応ハードウェアを使用して生成されたグラフィック表現に対して、高フレームレートを要し得る。しかし、いくつかのアプリケーションでは、そのようなハードウェアのＧＰＵおよびコンピュータビジョンサブシステムは、所望の結果を得るため（例えば、真に迫る結果を得られるようなフレームレートによる真に迫るグラフィックシーンの生成、過度のレイテンシによるユーザの動揺病の防止、その他例示的目的が挙げられる、１３０ｆｐｓ（７ミリ秒）等の高レートにて、データ（例えば、３Ｄデータ）を処理する必要があり得る。さらなるアプリケーションも同様に、処理、メモリ、電力、対応するアプリケーション要件、その他例示的問題に関する制限下で、大きなボリュームを記述したデータを十分に処理することに挑み得る。

【0044】

いくつかの実装において、コンピューティングシステムに、フォーマットに応じて定義されたスパースな（ｓｐａｒｓｅ）ボリュームデータを生成、および／または使用するためのロジックが設けられてもよい。例えば、各種システムおよびアプリケーションにおいて、コンピュータビジョンと３Ｄレンダリングとを統合するため、定義されたボリュームデータ構造が提供され得る。オブジェクトのボリューム表現は、例えばステレオカメラまたは深度計測カメラ等の光学センサを使用して取得されてもよい。オブジェクトのボリューム表現は、多数のボクセルを含み得る。オブジェクトの目標解像度を実現するため、対応するボリューム表現を繰り返し細分化可能とする、改良ボリュームデータ構造が定義され得る。細分化時、ボクセルの内の１または複数に含まれ得る、ボリューム表現内の空き空間を、ボリューム表現（および対応する動作）から省略することができる。空き空間は、ボリューム表現において、オブジェクトのジオメトリ特徴を含まない領域であり得る。

【0045】

したがって、改良ボリュームデータ構造においては、対応するボリューム内の個別のボクセルは、（なんらかのジオメトリが対応するボリューム空間内に存在することによる）「占有」または（対応するボリュームが空き空間から成ることを表す）「空」とタグ付けされ得る。当該タグはさらに、その対応するサブボリュームの内の１または複数も占有（例えば、親またはより高位のボクセルが占有とタグ付けされた場合）、またはそのサブボリュームの全てが空き空間（即ち、親またはより高位のボクセルが空とタグ付けされた場合）と指定していると解されてよい。いくつかの実装において、ボクセルを空とタグ付けすることは、そのボクセル、および／または対応するサブボリュームボクセルを、対応するボリューム表現を生成するために利用される動作から効果的に除去可能とし得る。ボリュームデータ構造は、スパース累乗細分化ツリー（ｓｐａｒｓｅ ｓｅｘａｑｕａｔｅｒｎａｒｙ ｔｒｅｅ；ＳＳＴ）フォーマット等に応じた、スパースツリー構造に応じたものであってもよい。さらに、スパースボリュームデータ構造に対するこのような手法によると、オブジェクトのボリューム表現の伝統的記憶方式と比較して、ストレージ空間が大幅に低減され得る。さらに、ボリュームデータを圧縮することで、同表現の送信可能性を向上、および同表現のより高速処理が可能となり得る。その他例示的な効果もあり得る。

【0046】

ボリュームデータ構造は、ハードウェアアクセラレーションにより、３Ｄレンダラへの急速更新を可能にし、個別のコンピュータビジョンおよびグラフィックスシステムで生じ得る遅延をなくすることができる。このような遅延は、ＡＲ、ＶＲ、ＭＲおよびその他アプリケーションにおいて使用される場合に、ユーザの運動酔いやその他さらなる問題につながり得るレイテンシを伴い得る。アクセラレーションがなされたデータ構造において、ボクセルに対してジオメトリ特徴で占有されているかが高速検証可能であることにより、リアルタイムで更新可能な、低レイテンシＡＲ、ＶＲ、ＭＲ、またはその他システムが構築可能となる。

【0047】

いくつかの実施形態において、ボリュームデータ構造の機能としてさらに、フレーム間警告が提供でき得る。例えば、ＡＲ、ＶＲ、ＭＲ、およびその他アプリケーションにおいて、画像シーン内の実または合成オブジェクトにユーザが衝突しそうな場合、またはドローンまたはロボットのコンピュータビジョンアプリケーションにおいて、当該デバイスが撮像シーン内の実または合成オブジェクトに衝突しそうな場合に、ボリュームデータ構造により実現される処理スピードであれば、起きうる衝突に対して警告を出せる。

【0048】

本開示の実施形態は、ロボティクス、拡張および複合現実用のヘッドマウントディスプレイ、さらに電話およびタブレット等のアプリケーションにおけるボリュームデータの記憶および処理に関し得る。本開示の実施形態は、一群のボクセル内の各ボリューム要素（例えばボクセル）と、任意でボクセルのジオメトリに関する物理量とを、単一のビットで表す。対応する赤緑青（ＲＧＢ）またはその他配色表現形式、透明度、面取りされたシグナリング距離ファンクション（ｔｒｕｎｃａｔｅｄ ｓｉｇｎｅｄ ｄｉｓｔａｎｃｅ ｆｕｎｃｔｉｏｎ（ＴＳＤＦ））情報等の６４ボクセルの群に関するさらなるパラメータが、ボクセルに関連付けられ、さらに関連付けられた任意の６４ビットデータ構造に（例えば、各ボクセルを２つまたはそれより多くのビットで表現するために用いられるように）記憶されてもよい。このような表現方式により、最小のメモリ要件が実現され得る。さらに、ボクセルを単一のビットで示すことで、ボリューム表現からの要素の論理的または数学的結合のための計算の多くが簡略化されるという性能が実現可能となる。ボリューム表現からの要素の結合の例としては、ボリュームの平面の論理和を取ることで、３Ｄボリュームデータの２Ｄ投影を生成することと、２．５Ｄマニホールドにおける占有ボクセルの数を数えて、表面積を計算すること、その他が挙げられる。比較用として、排他的論理和ロジックを使用して６４ビットサブボリューム（例えば、４^３サブボリューム）を比較してもよく、ボリュームを反転させてもよい。その論理和を取ることで、オブジェクトを合成してハイブリッドオブジェクトを生成できる。その他例もあり得る。

【0049】

図１は、従来の拡張または複合現実システムを示す。これは、並行グラフィックスレンダリングおよびコンピュータビジョンサブシステムから成り、レンダリングされたグラフィックスにオクルージョンや影を生じ得る、急速な頭部の動きによる変化や環境の変化に対応するように、ポストレンダリング接続装置が設けられる。一例示的実装において、システムは、バス１０１を介した相互接続、オンチップネットワークオンチップ、またはその他相互接続により、グラフィックスパイプライン、コンピュータビジョンパイプライン、およびポストレンダリング補正装置の実行を制御するためのホストメモリ１２４に補助されるホストプロセッサ１００を備えてもよい。この相互接続は、適切なソフトウェアを動作させるホストプロセッサ１００に、グラフィックスプロセッシングユニット（ＧＰＵ）１０６、関連するグラフィックスメモリ１１１、コンピュータビジョンパイプライン１１６、および関連するコンピュータビジョンメモリ１２４の実行を制御可能とする。一例において、ＧＰＵ１０６を使用し、（例えば、三角形リスト１０５上で動作する）ＯｐｅｎＧＬグラフィックスシェーダー１０７を介したグラフィックスのレンダリングが、コンピュータビジョンパイプラインよりも低速で行われ得る。そのため、ＧＰＵ１０６によるグラフィクスのレンダリング後に生じ得た頭部姿勢の、およびオクルージョンを生じるシーンジオメトリの変化に対応するように、ワープエンジン１０８およびディスプレイ／オクルージョンプロセッサ１０９を介して、ポストレンダリング補正を実行してもよい。頭部姿勢１１９およびオクルージョンを生じるジオメトリ１１３のあらゆる変化に対応するため、ＧＰＵ１０６の出力は、適切なグラフィックス出力を生成するために、頭部姿勢パイプライン１２０およびオクルージョンパイプライン１２３のそれぞれからの適切な制御信号１２１および１２３とともに使用可能となるようにタイムスタンプされる。その他例もあり得る。

【0050】

ＧＰＵ１０６と並列に、複数のセンサおよびカメラ（例えば、深度およびビジョン処理１１７のためのアクティブおよびパッシブステレオカメラを含む）がコンピュータビジョンパイプライン１１６に接続されてもよい。コンピュータビジョンパイプライン１１６は、各々がより低位の処理の複数の段階を含み得る少なくとも３つの段階の１または複数を含み得る。一例において、コンピュータビジョンパイプライン１１６における段階は、画像信号処理（ＩＳＰ）パイプライン１１８、頭部姿勢パイプライン１２０、およびオクルージョンパイプライン１２２であり得る。ＩＳＰパイプライン１１８は、入力カメラセンサ１１７の出力を取得し、それを後続の頭部姿勢およびオクルージョン処理で使用できるように調整してもよい。頭部姿勢パイプライン１２０は、対応する出力グラフィックスフレームがＧＰＵ１０６によりレンダリングされてからの頭部姿勢の変化を計算するため、ＩＳＰパイプライン１１８の出力を取得し、それをヘッドセット１１０内の慣性測定ユニット（ＩＭＵ）の出力１１９と共に使用してもよい。頭部姿勢パイプライン（ＨＰＰ）１２０の出力１２１を、ユーザが指定したメッシュと共にワープエンジン１０８に適用して、ＧＰＵ出力１０２を、更新された頭部姿勢位置１１９に一致するように変形してよいオクルージョンパイプライン１２２は、頭部姿勢パイプライン１２１の出力を取得し、視野に入り、対応する影１１４をシーンジオメトリにもたらすであろう、手１１３（またはその他例示的オブジェクト）等の、視野内の新たなオブジェクトを探してもよい。オクルージョンパイプライン１２２の出力１２３は、ディスプレイおよびオクルージョンプロセッサ１０９により、ワープエンジン１０８の出力１０３の上に、適切に視野を重ねるために使用されてもよい。ディスプレイおよびオクルージョンプロセッサ１０９は、計算された頭部姿勢１１９を使用して、合成影１１４用に影マスクを生成する。そしてディスプレイおよびオクルージョンプロセッサ１０９は手１１３の、オクルージョンを生じるジオメトリを、影マスク上に合成し、グラフィックの影１１４をワープエンジン１０８の出力１０３上に生成し、拡張／複合現実ヘッドセット１１０上に表示される最終出力フレーム１０４を生成してもよい。その他例示的使用ケースおよび特徴もあり得る。

【0051】

図２は、本開示のいくつかの実施形態に係るボクセル系拡張または複合現実レンダリングシステムを示す。図２に示す装置は、ホストＣＰＵ２００および関連するホストメモリ２０１上に構成されるホストシステムを含んでもよい。当該システムは、バス２０４、オンチップネットワーク、またはその他通信機構を介して、一体型コンピュータビジョンおよびグラフィックスパイプライン２２３と、ヘッドマウント拡張または複合現実ディスプレイ２１１に表示される最終的シーンにおいてレンダリングされる現実および合成ボクセルを含む、関連する一体型コンピュータビジョンおよびグラフィックスメモリ２１３と通信してよい。ＡＲ／ＭＲディスプレイ２１１はさらに、複数のアクティブおよびパッシブ画像センサ２１４、および頭部姿勢２２２の向きの変化を測定するために使用される慣性測定ユニット（ＩＭＵ）２１２を含んでもよい。

【0052】

複合型レンダリングパイプラインにおいて、合成ジオメトリは、合成ボクセルジオメトリ２０２を生成するためにＯｐｅｎＧＬ ＪｉＴ（Ｊｕｓｔ－ｉｎ－Ｔｉｍｅ）トランスレータ２０５により処理される三角形リスト２０４から生成開始されてもよい。合成ボクセルジオメトリは、例えば、三角形リストから、三角形の主平面を選択することで生成され得る。その後、選択された平面内の各三角形の（例えばＸ方向およびＺ方向における）２Ｄラスタ化が実行されてもよい。第３の座標（例えば、Ｙ）が、三角形全体で補間される属性として生成されてもよい。ラスタ化された三角形の各ピクセルが、対応するボクセルの定義となり得る。この処理は、ＣＰＵまたはＧＰＵの何れかにより実行され得る。ＧＰＵにより実行される場合、ＧＰＵがピクセルを描いたボクセルを生成するように、各ラスタ化三角形は、ＧＰＵから読み戻されてもよい。その他例示的実装もあり得る。例えば、リストの２Ｄバッファを使用して合成ボクセルを生成してもよい。ここで、リストの各エントリは、該当するピクセルでレンダリングされるポリゴンの深度情報を記憶する。例えば、正投影視点（例えば、上から下）を使用して、モデルがレンダリング可能である。例えば、例示的バッファに設けられたそれぞれの（ｘ，ｙ）は、対応するボクセルボリューム（例えば、（ｘ，ｙ，０）から（ｘ，ｙ，４０９５））における（ｘ，ｙ）の行を表してもよい。そして、各リスト内の情報を使用して、３Ｄ走査線としての情報から、各行がレンダリングされてもよい。

【0053】

図２の例の説明を続ける。いくつかの形態では、同時位置特定およびマッピング（ＳＬＡＭ）パイプライン２１７を使用して構築された、測定ジオメトリボクセル２２７に、合成ボクセルジオメトリ２０２が組み合わされてもよい。ＳＬＡＭパイプラインは、アクティブセンサおよび／またはパッシブ画像センサ２１４（例えば、２１４．１および２１４．２）を使用してもよい。これらはまず画像信号処理（ＩＳＰ）パイプライン２１５を使用して、出力２２５を生成するように処理される。出力２２５は、深度パイプライン２１６により、深度画像２２６に変換され得る。アクティブまたはパッシブ画像センサ２１４（２１４．１および２１４．２）は、アクティブまたはパッシブステレオセンサ、構造化光センサ、タイムオブフライトセンサを含み得る。その他例もあり得る。例えば、深度パイプライン２１６は、構造化光またはタイムオブフライトセンサ２１４．１あるいはパッシブステレオセンサ２１４．２からの深度データを交互に処理することの何れかを処理してもよい。一例示的実装において、ステレオセンサ２１４．２は、一組のパッシブステレオセンサを含み得る。その他例示的実装もあり得る。

【0054】

深度パイプライン２１５により生成された深度画像は、測定ジオメトリボクセル２２７の、ボクセル化モデルを生成するように、ＳＬＡＭアルゴリズム（例えば、Ｋｉｎｅｃｔ Ｆｕｓｉｏｎ）を使用するデンス（ｄｅｎｓｅ）ＳＬＡＭパイプライン２１７により処理されてもよい。ディスプレイプロセッサ２１０を介して、ディスプレイデバイス（例えば、ＶＲまたはＡＲアプリケーションにおける、ヘッドマウントディスプレイ２１１）に出力されるシーンの２Ｄレンダリングを生成するため、測定ジオメトリボクセル２２７（例えば、実ボクセルジオメトリ）を合成ボクセルジオメトリ２０２に合成し得る、レイトレーシングアクセラレータ２０６が設けられてもよい。そのような実装において、完全なシーンモデルは、測定ジオメトリボクセル２２７からの実ボクセルおよび合成ジオメトリ２０２から構築され得る。この結果、２Ｄレンダリングされたジオメトリのワーピング（例えば、図１に示す）が不要となる。このような実装は、現実の測定されたジオメトリを正しく位置合わせするため、頭部姿勢トラッキングセンサと対応するロジックに組み合わされてもよい。例えば、例示的頭部姿勢パイプライン２２１は、ヘッドマウントディスプレイ２１２内に搭載されたＩＭＵ２１２からの頭部姿勢測定値２３２を処理してもよく、ディスプレイプロセッサ２１０を介したレンダリングの際に、頭部姿勢測定パイプラインの出力２３１が考慮されてもよい。

【0055】

いくつかの例において、一体型レンダリングパイプラインは、オーディオリバーブモデルをレンダリングし、現実世界、仮想、または複合現実シーンの物理的性質をモデリングするためにも、測定ジオメトリボクセル２２７（例えば、実ボクセルモデル）および合成ジオメトリ２０２（例えば、合成ボクセルモデル）を使用してもよい。一例として、物理的性質パイプライン２１８は、測定ジオメトリボクセル２２７および合成ジオメトリ２０２ボクセルジオメトリを取得し、ボクセルデータ構造内に組み込まれた音響反射係数を使用して、出力サンプル２３０を計算するため、レイキャスティングアクセラレータ２０６を使用して、ヘッドマウントディスプレイ（ＨＭＤ）２１１の左右のイヤホンに対する出力音響サンプルを計算してよい。同様に、２０２および２２７から成る一体型ボクセルモデルはさらに、ＡＲ／ＭＲ複合シーンにおける合成オブジェクトの物理的性質更新決定にも使用されてよい。物理的性質パイプライン２１８は、入力として合成シーンジオメトリを取得し、レンダリング用の合成ジオメトリ２０２に対する更新２２８の計算前に、レイキャスティングアクセラレータ２０６を使用して衝突を計算する。これは物理的性質モデルの以降の繰り返しの基準ともなる。

【0056】

いくつかの実装において、図２に示すシステム等のシステムに、ＩＳＰパイプライン２１５からの出力からのＲＧＢ動画／静止画入力、およびＳＬＡＭパイプライン２１７の出力からのボリュームシーンデータ、その他例の何れかを処理可能な畳み込みニューラルネットワーク（ＣＮＮ）を実現、および／または利用するための１または複数ハードウェアアクセラレータが追加で設けられてもよい。ニューラルネットワーク分類器は、出力分類２３７を生成するため、ハードウェア（ＨＷ）畳み込みニューラルネットワーク（ＣＮＮ）アクセラレータ２０７を使用して専用に、またはプロセッサとＨＷ ＣＮＮアクセラレータ２０７との組み合わせの何れかで動作可能である。ＨＷ ＣＮＮアクセラレータ２０７が、ボリューム表現に対する予測を行う機能を有すれば、測定ジオメトリボクセル２２７における各群のボクセルが特定のオブジェクトクラスに属するとラベル付け可能となり得る。その他使用例もあり得る。

【0057】

ボクセルのラベル付け（例えば、ＣＮＮと補助用ハードウェアアクセラレーション）により、システムが、当該ボクセルが属するオブジェクトが、既知のオブジェクトに対応すると認識でき得る。また、ソースボクセルが測定ジオメトリボクセル２２７から除去でき、オブジェクトに対応するバウンディングボックスおよび／またはオブジェクトの原点、オブジェクトの姿勢、オブジェクトの記述子についての情報に置き換え可能となる。その他例示的情報もあり得る。これは、シーン内のオブジェクトと相互作用する、ロボット、ドローン、またはその他コンピューティングシステムによる入力として、またはオーディオシステムがシーンにおけるオブジェクトの吸音係数を調べ、そのシーンの音響的モデルに反映するために使用可能な、シーンについての意味的に極めてより有意な記述に帰結し得る。その他例示的使用例もあり得る。

【0058】

図２において示され、説明された例示的システムのパイプラインを実現するために、１または複数プロセッサデバイスおよびハードウェアアクセラレータが設けられてもよい。いくつかの実装において、複合レンダリングパイプラインのハードウェアおよびソフトウェア要素の全てが、ＤＲＡＭコントローラ２０９に対するアクセスを共有してもよく、これにより、データが共有ＤＤＲメモリデバイス２０８に記憶可能となる。その他例示的実装もあり得る。

【0059】

図３は、いくつかの実施形態に係る、デンスおよびスパースなボリューム表現間の違いを示す。図３の例に示すように、現実世界または合成オブジェクト３００（例えば、うさぎの像）が、ボクセルにより、３０２に示すようにデンス、または３０４に示すようにスパースの何れかで記述可能である。３０２のようなデンスな表現の利点として、ボリューム内の全てのボクセルに対して均一のスピードでアクセスできることが挙げられる。一方、欠点として、必要になり得るストレージ量が挙げられる。例えば、５１２^３要素のボリューム（例えば、Ｋｉｎｅｃｔセンサを使用して走査されるボリュームについて、１ｃｍ解像度で５ｍに対応する）のようなデンスな表現の場合、各ボクセルについて、４バイトの面取りされたシグナリング距離ファンクション（ｔｒｕｎｃａｔｅｄ ｓｉｇｎｅｄ ｄｉｓｔａｎｃｅ ｆｕｎｃｔｉｏｎ（ＴＳＤＦ））を有する比較的小さなボリュームを記憶するのに、５１２ＭＢｙｔｅが必要となり得る。一方で、スパースな表現としてのオクトツリー表現３０４の場合、現実世界シーンにおける実際のジオメトリが存在するボクセルのみが記憶され得る。そのため、同じボリュームを記憶するのに必要なデータ量が低減される。

【0060】

図４を参照すると、いくつかの実施形態に係る、例示的なシーンの合成図が示される。特に、図４は、合成および現実世界ボクセルデータをそれぞれ示す、等しいバウンディングボックス４００および４０２内に、合成ボクセル４０１および現実世界の測定されたボクセル４０３を表現するように、どのようにシーン４０４の合成図が維持、表示、または並行データ構造を使用したさらなる処理が施されるかを示す。図５は、いくつかの実施形態に係る、均一な４^３要素のツリー構造における、詳細度を示す。図５の例に示すように、いくつかの実装において、オクトツリー表現を使用して、ボリュームにおける各ボクセルを記述するのに、最小で１ビットが利用され得る。しかし、オクトツリー型技術では、オクトツリー内の特定のボクセルにアクセスするのに利用される、間接的メモリアクセスの数が欠点となり得る。スパースなボクセルオクトツリーの場合、同一のジオメトリが、複数の詳細度で非明示的に表され得る。これにより、レイキャスティング、ゲーム物理、ＣＮＮ、その他技術の動作において、シーンの空部分のさらなる計算が省略可能となるという利点がある。したがって、必要なストレージだけでなく、消費電力および計算負荷の全体的低減が図られる。その他例示的利点もあり得る。

【0061】

１つの実装において、改良ボクセル記述子（本明細書において、「ボリュームデータ構造」とも称する）を設けて、ボクセル毎に１ビットというメモリ要件の５０１に示すように、ボリューム情報を４^３（または６４ビット）符号なし整数として構成してもよい。この例において、ボクセル毎１ビットでは、面取りされたシグナリング距離ファンクション（ｔｒｕｎｃａｔｅｄ ｓｉｇｎｅｄ ｄｉｓｔａｎｃｅ ｆｕｎｃｔｉｏｎ ｖａｌｕｅ）値の記憶には不十分である（６４ビットを用いるＳＬＡＭｂｅｎｃｈ／ＫＦｕｓｉｏｎにおけるＴＳＤＦとの比較）。本例において、ボクセル記述子内に、追加の（例えば、６４ビット）フィールド５００が含まれてもよい。本例は、６４ビットフィールド５００におけるＴＳＤＦが１６ビットである一方、ボクセル記述子５０１において２ビット分の若干の解像度がｘ、ｙおよびｚに非明示的に追加されるようにさらに拡張されてもよい。これにより、ＳＬＡＭｂｅｎｃｈ／ＫＦｕｓｉｏｎまたはその他例において使用されるような、解像度が大幅に高いＴＳＤＦに等しい、６４ビットフィールド５００におけるボクセルＴＳＤＦと、ボクセル位置５０１との組み合わせが実現される。例えば、６４ビットフィールド５００（ボクセル 記述子）におけるこの追加データは、各１バイトのサブサンプリングされたＲＧＢ色情報（例えば、パッシブＲＧＢセンサを介したシーンから）、８ビットの透明度値アルファ、さらに２つの１バイト予備フィールドＲ１およびＲ２の記憶に使用されてもよい。予備フィールドＲ１およびＲ２は、アプリケーション特有のものであり、例えばオーディオアプリケーションの場合は音響反射率、物理的アプリケーションの場合は剛性、そしてオブジェクト材料種類の記憶に使用可能である。その他例もあり得る。

【0062】

図５に示すように、ボクセル記述子５０１は、各々が１６ボクセル５０２を含む、４つの２Ｄ平面に論理的にグループ分けできる。これら２Ｄ平面（またはボクセル平面）は、図５に表すように、４の累乗で段階的に分解されることに基づくオクトツリー式構造の各レベルを記述し得る。この例示的形態において、対応するシステム実装で使用される６４ビットバスインフラストラクチャとの相性の良さから、６４ビットボクセル記述子が選択される（ただし、その他システム形態では、ボクセル記述子のサイズとフォーマットは異なっていてもよく、バスまたはシステム内のその他インフラストラクチャに応じたサイズとなってもよい）。いくつかの形態において、ボクセル記述子は、ボクセル取得するために用いられるメモリアクセスの数を低減するようなサイズに設定されてもよい。例えば、２^３個の要素上で動作する伝統的なオクトツリーに対して、オクトツリーにおける任意のレベルにおけるボクセルにアクセスするのに必要なメモリアクセスの数を半分に減らすように、６４ビットボクセル記述子を使用してもよい。その他例示的考察および形態もあり得る。

【0063】

一例において、オクトツリーは４^３ルートボリューム５０３から始まるように記述されてもよく、下位層５０４、５０５、および５０６におけるジオメトリの存在を示すコードの各非ゼロエントリが、例示的な２５６^３ボリュームで示される。この具体例において、オクトツリーの最下層にアクセスするのに４度のメモリアクセスが用いられ得る。そのようなオーバーヘッドが高すぎる場合、５０７で示すように、６４^３等のより大きなボリュームとして、オクトツリーの最高位を符号化するように、別の手法を採ってもよい。この場合、各非ゼロエントリ５０７は、下位の２５６^３ボリューム５０８における、下位の４^３オクトツリーの存在を示し得る。この代替的構成の結果として、５０３、５０４、および５０５で示す代替的構成と比較して、２５６^３ボリューム５０８の任意のボクセルへのアクセスに必要なメモリアクセス数は２回のみとなる。後者の手法は、オクトツリー構造のホストデバイスの内蔵メモリ量が大きい場合に有効である。外部メモリ内では、ボクセルオクトツリー５０８の下位かつ低頻度アクセス部分のみ可能にする。この手法は、ストレージの観点でコスト高になり得る。例えば、オンチップメモリに一体的で大きな（例えば、６４^３）ボリュームが記憶されるような場合である。しかし、トレードオフにより、より高速（例えば倍速）のメモリアクセス、および電力消費の大幅な低減が可能となり得る。その他例示的な利点もあり得る。

【0064】

図６を参照すると、いくつかの実施形態に係る、本開示のデータ構造およびボクセルデータを利用し得る、例示的アプリケーションを示すブロック図が示されている。図５に示すような一例において、例示的なボクセル記述子５００を通じて追加的な情報が提供され得る。このボクセル記述子は、利用される全体的なメモリをボクセル毎２ビットにまで増加し得るが、一方で幅広いアプリケーションを可能にし得る。即ち、図６に表すようなボクセルデータの利用が可能となり得る。例えば、デンスなＳＬＡＭシステム６０１（例えばＳＬＡＭｂｅｎｃｈ）を使用して生成されるような共有ボリューム表現６０２が、グラフィックレイキャスティングまたはレイトレーシング６０３を使用したシーンのレンダリングにおいて、そしてオーディオレイキャスティング６０４において使用可能である。その他実装もあり得る。さらなる別の例において、ボリューム表現６０２は畳み込みニューラルネットワーク（ＣＮＮ）予測６０５においても使用でき、クラウドインフラストラクチャ６０７によりバックアップできる。いくつかの例において、クラウドインフラストラクチャ６０７は、予測によりアクセス可能な木、１つの家具、またはその他オブジェクト（例えば６０６）等のオブジェクトの詳細なボリューム記述子を含み得る。オブジェクトの予測またはその他方法による特定に基づき、対応する詳細な記述子がデバイスに返されてもよい。これにより、ボリューム表現６０２のボクセルを、姿勢情報と、オブジェクトの特性を含む記述子を有するバウンディングボックス表現で置換可能となる。その他例示的特徴もあり得る。

【0065】

さらに別の実施形態において、ボリューム表現６０２の３Ｄ－２Ｄ投影を利用して、例示的な環境６０８の２Ｄマップを構築するように、上述したボクセルモデルを、追加的、または代替的にいくつかのシステムで使用してもよい。これら２Ｄマップも、クラウドインフラストラクチャおよび／またはその他ネットワーク型資源６０７を通じて、通信中の機械を介して共有可能である。そしてクラウドソーシング技術を使用して、より高品質なマップを構築するように蓄積され得る（例えば、同じクラウドインフラストラクチャを使用する）。これらマップは、機械およびデバイス接続されたクラウドインフラストラクチャ６０７により共有できる。さらに異なる例において、２Ｄマップは、区分的簡略化６０９（例えば、車両またはロボットの固定された幅及び高さを前提とする）に先立つ、投影に利用される超低帯域アプリケーション用に改良してもよい。したがって簡略化された経路は、経路の区分的直線部位毎に、単一のＸ、Ｙ座標組を有してもよい。これにより、車両６０９からクラウドインフラストラクチャ６０７への通信経路を構築するのに必要な帯域量が低減される。経路は同じクラウドインフラストラクチャ６０７内に蓄積されることで、クラウドソーシング技術を利用して、より高品質なマップが構築される。これらマップは、機械およびデバイスに接続されたクラウドインフラストラクチャ６０７により共有できる。

【0066】

これら異なる複数のアプリケーションを可能にするため、いくつかの形態において、共有ソフトウェアライブラリを通じて等により、共通機能が提供されてもよい。この機能は、いくつかの実施形態において、ハードウェアアクセラレータまたはプロセッサ命令セットアーキテクチャ（ＩＳＡ）拡張を使用して、向上可能である。その他例もあり得る。例えば、このような機能は、記述子へのボクセルの挿入、ボクセルの削除、またはボクセル６１０の検索を含んでもよい。いくつかの実装において、さらに衝突検出機能６２０、およびボリュームからのポイント／ボクセル削除６３０にも対応し得る。その他例もあり得る。上述のとおり、システムに、対応するボリューム表現６０２（３Ｄボリューム）から迅速にＸ方向、Ｙ方向およびＺ方向の２Ｄ投影６４０（例えば、経路または衝突判定の基準となり得る）を生成する機能が設けられてもよい。いくつかの場合において、ヒストグラムピラミッド６５０を使用して、ボリューム表現６０２から三角形リストを生成可能であることも有利であり得る。さらにシステムは、ボリューム空間６０２の２Ｄおよび３Ｄ表現における自由経路６６０の高速決定用の機能が設けられてもよい。当該機能は、様々なアプリケーションで有利となり得る。ボリュームにおけるボクセルの数を検討の上算出する、ボリューム表現６０２のマスク付き領域での１ビットの数を計算するポピュレーションカウンタを使用してオブジェクトの表面を決定する等の機能がさらに設けられてもよい。その他例もあり得る。

【0067】

図７の簡潔なブロック図を参照すると、少なくともいくつかの実施形態に係る、３Ｄ数字認識機能を備えたシステムを含む例示的ネットワークが示されている。例えば、図６に示すアプリケーションの１つとして、ボリュームＣＮＮアプリケーション６０５が挙げられる。これを図７でより詳細に説明する。ここで、Ｍｉｘｅｄ Ｎａｔｉｏｎａｌ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｓｔａｎｄａｒｄｓａｎｄ Ｔｅｃｈｎｏｌｏｇｙ（ＭＮＩＳＴ）データセット等のデータセットから生成された３Ｄ数字７００を認識するのに例示的ネットワークが使用される。当該データセット内の数字は、訓練前にＸ方向、Ｙ方向およびＺ方向での適切な回転および並進を数字に適用することにより、ＣＮＮ型畳み込みネットワーク分類器７１０の訓練に使用されてもよい。内蔵するデバイスにおける予測に使用される場合、訓練済みネットワーク７１０は、仮に数字がＸ方向、Ｙ方向およびＺ方向７２０に回転および並進していたとしても、シーンにおける３Ｄ数字を高精度で分類するのに使用可能である。その他例もあり得る。いくつかの実装において、図２に示すＨＷ ＣＮＮアクセラレータ２０７により、ＣＮＮ分類器の動作を向上できる。ニューラルネットワークの第１層はボリューム表現６０２内のボクセルを使用して乗算を行なうが、ゼロをかけると必ずゼロになる、そしてデータ値Ａに１（ボクセル）をかけるとＡに等しくなることから、これら演算動作をスキップできる。

【0068】

図８は、同一のデータ構造に対して、複数の非自明的詳細度を利用して実行される複数の分類を示す。ボリューム表現６０２を使用したＣＮＮ分類のさらなる向上は以下のとおりであり得る。即ち、オクトツリー表現は、図５に示すオクトツリー構造において非明示的に複数の詳細度を含む。そして、図８に示すように、単一の分類器８３０を使用、または複数の分類器を並列に使用して、同一のデータ構造に対して、非明示的な詳細度８００、８１０、および８２０により複数の分類を実現できる。伝統的なシステムにおいては、このような並行分類は、分類間の移行で必要な画像サイズ変更により、低速となり得る。本明細書に記載のボクセル構造を適用する実装では、同一のオクトツリーが、複数の詳細度で同一の情報を含み得るので、このようなサイズ変更が前に行われ得る。実際、従来のＣＮＮネットワークで必要になるような、サイズ変更を伴う訓練データセットではなく、ボリュームモデルに基づく単一の訓練データセットで、全ての詳細度を網羅可能である。

【0069】

図９に示す例を参照すると、動作省略の例がいくつかの実施形態に係る２ＤのＣＮＮにより示される。動作省略は３ＤのボリュームＣＮＮで利用でき、さらに図９に示すように２ＤのＣＮＮにも利用できる。例えば、図９において、第１層では、入力９１０の予期される「形状」を記述するようにビットマップマスク９００が使用され、入力ビデオストリーム９２０に適用され得る。一例において、動作省略は、３ＤのボリュームＣＮＮだけではなく、２ＤのボリュームＣＮＮにも使用可能である。例えば、図９の２ＤのＣＮＮにおいて、入力９１０の予期される「形状」を記述するように、ＣＮＮの第１層にビットマップマスク９００が適用されてもよく、入力ビデオストリーム８２０等のＣＮＮの入力データに適用されてもよい。一例として、図９では、ＣＮＮネットワークの訓練または予測のため、歩行者の画像にビットマップマスクを適用する効果が示されている。ここで９０１は歩行者９０１の元画像を表し、９０３は対応するビットマップマスク適用バージョンを表す。同様に、９０２は歩行者を含まない画像を示し、９０４は対応するビットマップマスク付きバージョンを示す。検出器により予期される、予期される２Ｄまたは３Ｄジオメトリの知識を通じて、同じ方法が、ＣＮＮ訓練または予測に必要な動作の数を低減するため、あらゆる２Ｄまたは３Ｄオブジェクトに適用できる。９１１は、３Ｄボリュームビットマップの例を示す。９２０は、実際のシーンにおける予測のための、２Ｄビットマップの使用を示す。

【0070】

図９の例示的実装において、オブジェクト９１０の特定のクラスについて、一連の訓練画像の平均を取ることで実ビットマップが生成されながら、概念的ビットマップが（９００で）示される。図示の例では、二次元で示されているが、提案されたボクセル毎１ビットのボリュームデータフォーマットにおいて、同様なビットマップマスクが３Ｄオブジェクトに対しても生成可能である。実際、さらなるボクセル／ピクセル毎に追加のビットを使用することで、２Ｄまたは３Ｄオブジェクトの予期される色範囲またはその他特徴を指定するように、方法を拡張するという可能性もあり得る。

【0071】

図１０は、いくつかの実施形態に係る、１０，０００個のＣＩＦＡＲ－１０テスト画像の分析を伴う例示的実験の結果を示す表である。いくつかの実装において、図１０に示すＬｅＮｅｔ１０００等のＣＮＮネットワークで頻繁に生じる、正規化線形ユニット（ＲｅＬＵ）による１Ｄ、２Ｄ、および３ＤのＣＮＮにおける中間計算を省略するように、動作省略が利用可能である。図１０に示すように、１０，０００ＣＩＦＡＲ－１０テスト画像を使用した実験において、ＲｅＬＵユニットにより生成されたデータ依存ゼロのパーセンテージは、８５％に昇り得る。これは、ゼロに該当する場合、ゼロを認識して、それに応じて対応するデータを取得せず、対応する乗算を実行しないシステムが設けられる得ることを示唆する。この例において、８５％は、Ｍｏｄｉｆｉｅｄ Ｎａｔｉｏｎａｌ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｓｔａｎｄａｒｄｓ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙデータベース（ＭＮＩＳＴ）テストデータセットから生成されたＲｅＬＵによる動的ゼロのパーセンテージを表す。これらゼロに対応する、対応する動作省略は、電力消費およびメモリ帯域要件の低減を実現し得る。その他例示的利点もあり得る。

【0072】

重要でない動作は、ビットマップに基づいて省略され得る。例えば、当該ビットマップの使用は、参照により本明細に全体が組み込まれる、名称「データ圧縮用回路およびそれを利用するプロセッサ」の米国特許第８，７１３，０８０号に記載および図示の実施形態の原理に応じてもよい。いくつかの形態では、同じく参照により本明細に全体が組み込まれる、名称「演算処理を実行するためのハードウェア」の米国特許第９，１０４，６３３号に記載および図示のシステム、回路、およびその他形態等、当該ビットマップを使用可能なハードウェアが提供されてもよい。

【0073】

図１１は、いくつかの実施形態に係る、ビットマップに基づいて、重要ではない動作を省略する機能を提供するため、システムに組み込まれ得るハードウェアを示す。この例において、繰り返し畳み込み層を含む、多層ニューラルネットワークが提供される。このハードウェアは、１または複数のプロセッサ、１または複数のマイクロプロセッサ、１または複数の回路、１または複数のコンピュータ等を備えてもよい。この具体例では、ニューラルネットワークは、最初の畳み込み処理第層１１００と、それに続くプーリング処理１１１０と、最後の正規化線形ユニット（ＲｅＬＵ）の機能１１２０等の活性化関数処理が含まれる。ＲｅＬＵ出力ベクトル１１３１を提供するＲｅＬＵユニット１１２０の出力は、ＲｅＬＵ出力ベクトル１１３１を受け取る後続の畳み込み処理層１１８０（例えば、遅延１１３２を伴い得る）に接続され得る。一例示的実装において、ＲｅＬＵユニット１１２０の後続の畳み込みユニット１１８０への接続と並行して、ＲｅＬＵビットマップ１１３０も生成されてもよい。ＲｅＬＵビットマップ１１３０は、ＲｅＬＵ出力ベクトル１１３１においてどの要素がゼロであるか、ゼロでないかを示す。

【0074】

一実装において、イネーブルされたハードウェアに対して、ニューラルネットワークの計算に伴う動作を省略する機会を通知するために、ビットマップ（例えば、１１３０）が生成されるか、またはそれ以外の方法で提供されてもよい。例えば、ビットマップスケジューラ１１６０がＲｅＬＵビットマップ１１３０内のビットを解釈し得る。ビットマップスケジューラ１１６０は、後続の畳み込みユニット１１８０における乗算器に、ＲｅＬＵビットマップ１１３０における対応する２値ゼロが存在するＲｅＬＵ出力ベクトル１１３１のゼロエントリをスキップするように指示する。ゼロをかけると必ず出力がゼロとなるためである。並行して、ＲｅＬＵビットマップ１１３０内のゼロに対応するデータ／重みについての、アドレス生成器１１４０からのメモリ取得もスキップされてもよい。後続の畳み込みユニット１１８０によりスキップされるような重みを取得することに価値はほぼ認められないためである。重みがＤＤＲコントローラ１１５０を介して、取り付けられたＤＤＲ ＤＲＡＭストレージデバイス１１７０から取得される場合、レイテンシが高すぎて、オンチップ帯域および関連する消費電力の多少の低減しか実現できない可能性がある。一方、重みがオンチップＲＡＭ１１８０ストレージから取得される場合、特に、ＲＡＭ／ＤＤＲ取得遅延１１３２に対応する遅延が、特に後続の畳み込みユニット１１８０の入力で加えられた場合、重み取得動作の全体を回避／スキップ可能となり得る。

【0075】

図１２を参照すると、いくつかの実施形態に係る、重要でない動作を省略する（または動作省略を実行する）回路またはその他ロジックによる、例示的ハードウェアに対する向上を示すように提供された、簡潔なブロック図が示されている。図１２の例に示すように、直前の最大プーリングユニット１２１０または畳み込みユニット１２００からのＲｅＬＵユニット１２２０入力の符号を予測するように追加的ハードウェアロジックが提供されてもよい。最大プーリングユニット１２１０に符号予測およびＲｅＬＵビットマップ生成を加えることで、アドレス生成器１２４０を通じて、外部ＤＤＲコントローラ１２５０およびＤＤＲストレージ１２７０または内部ＲＡＭストレージ１２７１を通じて生じ得る遅延をカバーするように、タイミング的により早くＲｅＬＵビットマップ情報の予測が可能となり得る。遅延が十分に低い場合、アドレス生成器１２４０においてＲｅＬＵビットマップが解釈され得、ＲｅＬＵビットマップのゼロに関連したメモリ取得が完全にスキップできる。メモリからの取得の結果が使用され得ないと判定できるからである。この図１１の方式に対する変形は、追加の省電力が実現できる。ＤＤＲアクセスパス（例えば、１２４０から１２５０から１２７０）またはＲＡＭアクセスパス（例えば、１２４０から１２７１）を通じた遅延が、遅延タグ１２３２が発生しないほど十分に低い場合、さらに後続の畳み込みユニット１２８０の入力での遅延タグ（例えば、１１３２、１２３２）が除去可能となり得る。その他例示的特徴および機能もあり得る。

【0076】

図１３は、いくつかの実施形態に係る、例示的ハードウェアを示す、別の簡潔なブロック図である。例えば、ＣＮＮ ＲｅＬＵ層は、負の入力に対応する多数のゼロ出力を生成可能である。実際、負のＲｅＬＵ入力は、直前の層（例えば、図１３の例におけるプーリング層）に対する符号入力を確認することで予測的に判定できる。浮動小数点および整数は、最上位ビット（ＭＳＢ）に関して、明示的に符号付け可能である。したがって、図１３に示すように、畳み込み層で乗算される、入力のベクトル全体への単純なビット処理排他的論理和（ＸＯＲ）動作により、どの乗算によりゼロ出力を生じるか予測可能である。その結果である符号予測ＲｅＬＵビットマップベクトルは、省略される乗算のサブセットおよび関連するメモリからの係数読み込みの決定の基準として使用可能である。これは上述の別の例にて説明されたように実現される。

【0077】

直前のプーリングまたは畳み込み段階（即ち、対応するＲｅＬＵ段階の前の段階）に戻されるＲｅＬＵビットマップ生成の実現は、電力消費増に帰結し得る。例えば、ＲｅＬＵ活性化ロジックにより最終的にゼロに設定される負の出力を生成するような場合に、乗算器を停止するように符号予測ロジックが提供されてもよい。この例として、乗算器１３１４の入力１３０１および１３０２の、２つの符号ビット１３１０および１３１５が、ＸＯＲゲートにより論理的に合成されて、ＰｒｅＲｅＬＵビットマップビット１３０３を形成することが示される。この同じ信号を使用して、続く畳み込み段階１３９０での乗算用の入力前に、さもなくばＲｅＬＵロジックによりゼロに設定され得る負の出力を生成することで無用に電力を消耗してしまうような乗算器１３１４の動作を停止することができる。その他例もあり得る。

【0078】

なお、１３００、１３０１、１３０２、および１３０３（Ａで示す）は、図１３でＢが付されたものの上位視点を示す。この例において、ブロック１３０２への入力は、２つの浮動小数点オペランドを含み得る。入力１３０１は、明示的符号ビット１３１０と、複数のビットを含む仮数１３１１と、同じく複数のビットを含む指数１３１２とを含み得る。同様に、入力１３０２も同じような符号１３１５、仮数１３１７、および指数１３１６を含み得る。いくつかの実装において、仮数および指数は精度が異なり得る。結果１３０３の符号は、１３０１および１３０２の符号、または１３１０および１３１５のそれぞれにのみ依存するためである。事実、１３０１および１３０２のいずれも、符号付番号であり、最上位ビット（ＭＳＢ）が効果的に明示的なまたは非明示的な符号ビットである限り（例えば、これら番号が１または２の補数であるような場合等）、浮動小数点数である必要はなく、任意の整数であるか、または固定点形式であってよい。

【0079】

図１３の例の説明を続ける。２つの符号入力１３１０および１３１５が、ＸＯＲ（本明細書において、これ以外にもＥｘＯＲまたはＥＸＯＲと称する場合もある）ゲートを用いて合成されてもよい。これによりビットマップビット１３０３が生成され、これはその後、後続の畳み込みブロック（例えば、１３９０）において省略され得る下流乗算を特定するハードウェアを使用して処理されてもよい。同じＸＯＲ出力１３０３を使用してさらに、２つの入力数１３１３（例えば、１３０１に対応する）および１３１８（例えば、１３０２に対応する）の符号が逆で、ＲｅＬＵブロック１３１９によりゼロに設定され、後続の畳み込み段階１３９０に入力されるＲＥＬＵ出力ベクトル１３１９１におけるゼロ値に帰結する負の出力１３０４が生成される場合に、乗算器１３１４を停止してもよい。したがって、いくつかの実装において、これに並行して、畳み込みユニット１３９０上で動作する（および／または省略される）乗算をスケジューリングし得るビットマップスケジューラ１３６０に対して、ＰｒｅＲｅＬＵビットマップ１３２０が送信されてもよい。例えば、ビットマップ１３２０におけるすべてのゼロについて、畳み込みユニット１３９０における対応する畳み込み動作がスキップされてもよい。これと並行に、ビットマップ１３２０が、畳み込みユニット１３９０で使用される重みの取得を制御する例示的なアドレス生成器１３３０により消費されてもよい。ビットマップ１３２０における１に対応するアドレスのリストが、アドレス生成器１３３０内でコンパイルされてもよい。これにより、ＤＤＲコントローラ１３５０を介したＤＤＲストレージ１３７０への経路を制御するか、またはチップＲＡＭ１３８０への経路を制御する。いずれの場合でも、ＰｒｅＲｅＬＵビットマップ１３２０における１に対応する重みが取得されて、畳み込みブロック１３９０に対して提示されてもよい（例えば、重み入力１３７１に対するクロック周期に関するある程度のレイテンシ後）。この際、ゼロに対応する重みの取得は省略され得る。その他例もあり得る。

【0080】

上述のように、いくつかの形態において、遅延（例えば、１３６１）が、ビットマップスケジューラ１３６０と、畳み込みユニット１３９０との間に介在してもよい。これにより、アドレス生成器１３３０、ＤＤＲコントローラ１３５０およびＤＤＲ１３５０を介した、またはアドレス生成器１３３０および内部ＲＡＭ１３８０を介した遅延とのバランスを取る。この遅延により、ビットマップスケジューラにより駆動される畳み込みが、畳み込みユニット１３９０における畳み込み計算に対する、対応する重みに応じて、適切に時間設定され得る。実際、タイミングに関して、ＲｅＬＵブロック１３１９の出力よりも早くＲｅＬＵビットマップを生成することで、追加の時間が稼ぐことができる。これを使用して、アドレス生成器１３３０により生成される前に、メモリ（例えば、ＲＡＭ１３８０またはＤＤＲ１３７０）からの読み取りを止め得る。したがって、いくつかの読み取り（例えば、ゼロに対応する）が不要となり得る。メモリ読み取りは、チップ上の論理的動作よりも遥かに高く成り得るため、そのようなメモリ取得を省略することは、大幅な省電力に帰結し得る。その他例示的利点もあり得る。

【0081】

いくつかの実装において、クロック周期に関して、ＤＲＡＭアクセス時間に対する十分に時間が稼ぎきれない場合、ブロック指向の技術を利用して、事前にＤＤＲから符号ビット群（例えば１３０１）を読み込んでもよい。これら符号ビット群は、入力画像または中間畳み込み層１３０２からの符号のブロックと共に使用されてよい。これにより、一組の（複数の）ＸＯＲゲート１３００を使用して、ＰｒｅＲｅＬＵビットマップのブロックが生成される（例えば、２Ｄまたは３Ｄアレイ／行列間の２Ｄまたは３Ｄ畳み込みにおける符号ビットの差分を計算する。その他例もあり得る）。そのような実装において、各重みの符号を記憶するのに、ＤＤＲまたはオンチップＲＡＭにおける追加の１ビットストレージが提供されてもよいが、この場合は、多数のレイテンシ周期がカバーされ、ＲｅＬＵ段階からゼロで乗算される、ＤＤＲまたはＲＡＭからの重みを読み込むことが完全になくなり得る。いくつかの実装において、符号が個別に指数および仮数から指定され得るように記憶されることで、ＤＤＲまたはオンチップＲＡＭにおける重み毎の１ビットのストレージの追加が避けられ得る。これ以外の例示的考察および形態もあり得る。

【0082】

一例において、最大限のデータ転送速度を実現するように、自然なバーストアクセスを有し得る、ＤＤＲアクセスを利用して、システムをさらに向上してもよい。この場合、ＤＤＲ重みアクセスはバーストよりも大幅に短くなり得るため、それを個別にスキップすることによる省電力は実現不能となり得る。したがって、いくつかの例において、特定のバーストトランザクションに対応する全てのビットマップビットがゼロである場合にバーストは省略されてもよい。しかしこれは低頻度であり得る。したがって、得られる省電力および帯域効果は限定的となり得る。さらに別の実装では、ビットマップバーストにおけるＮビット超がゼロである場合、バーストが完全にスキップされるように、バーストにおけるビットマップビットの数に対して、レジスタプログラマブル閾値が設定されてよい。これは、ＣＮＮ分類の全体的精度を若干下げる効果があり得るが、省電力の観点から許容され得る。

【0083】

いくつかの実装において、上述の例では、それら例において使用されるボリュームデータの少なくとも一部のストレージおよびアクセスのために、ハッシュテーブルが利用され得る。ハッシュテーブルは、例えば上述の低レイテンシ、低電力、および資源限定的実施形態にて使用され得る。伝統的なハッシュ化方法で３Ｄボリュームデータを記憶する場合、アドレス指定衝突を最低限にとどめるため、十分に分散されたハッシュアドレスの実現を図るため、大きな素数が利用される。伝統的な実装では、元来２Ｄデータアプリケーションでの使用を意図したハッシュ化技術を利用し、キーバリューのランダム化を通じてハッシュアドレスを生成するように作用する大きな素数を利用する。しかし、これら伝統的な実装の一部には、このような大きな素数の利用について根拠がない。いくつかの実装において、３Ｄデータは、ほぼ全ての座標が固有と見做され得るため、本質的に分散性が高い。したがって、大きな素数の使用を省略するような、３Ｄデータアプリケーションに対する代替のハッシュ化技術を適用した実装があり得る。実際、伝統的な実装における、３Ｄデータのハッシュ化用の素数の使用は、経験的見地に基づくものではなく、主に慣習的に行われてきたものであり得る。

【0084】

改良されたシステムにおいては、大きな素数の使用を避け、３Ｄデータ固有の配列を利用したアドレス指定方式が実施され得る。このような実装は、３Ｄボリュームデータのより効率的な記憶、検出、および削除を誇るシステムを実現し得る。その他例示的利点もあり得る。例えば、そのよう改良３Ｄアドレス指定方式の場合さらに、大きな素数を使用した伝統的なハッシュ化技術と比較して、アドレス指定の衝突発生が大幅に低減され得る。

【0085】

いくつかのコンピューティングシステムでは、ハッシュ化アルゴリズムと、それらアルゴリズムを実行する対応するロジック（即ち、専用および／または汎用ハードウェア回路、ファームウェア、および／またはソフトウェア内で実装される）が、特定のアドレス指定空間に対して、任意のサイズのデータをマッピングするのに使用されてよい。そのようなハッシュ化技術は、３Ｄボリュームデータ等の、３Ｄ空間を定義するデータの記憶、検索、および削除に使用され得る。本明細書において説明されるＶＯＬＡフォーマットに応じて実現される３Ｄデータ等の、そのような３Ｄボリュームデータ。さらに、ハッシュ化技術は、本明細書に記載のアプリケーションに関連した、３Ｄデータの記憶、検索、および利用に関して使用されてよい。伝統的なアプリケーションにおいて、伝統的なハッシュ化アルゴリズム使用の共通目的は、データに対して互いに異なるマッピングアドレスを実現することである。しかし、実際に非ランダムデータから完全にランダムなデータを生成するハッシュ機能を定義することは理論上不可能とされる。このような固有のアドレスを実現する困難さを強調する例示的現象として、「誕生日のパラドクス」が挙げられる。即ち、サイズ３６５のテーブルに対して、２３個のキーをマッピングするようにランダム関数が選択された場合、２つのキーが同じ位置にマッピングされない可能性は、わずか０．４９２７である。

【0086】

ハッシュ化（または「空間的ハッシュ化」）において、アドレス計算は一般的に、キーバリューのランダム化スクランブリングで実現され、多くの技術において、このスクランブリングは大きな素数を使用して実現する。この文脈において、ハッシュ化とは、２Ｄまたは３Ｄ領域空間におけるオブジェクトまたはポイントが、１Ｄデータテーブル（または「ハッシュテーブル」）に投影され、領域空間内のオブジェクトに対する超高速クエリを可能にする技術である（例えば、位置クエリ、近接検出クエリ等）。３Ｄデータに対するハッシュ化を考慮する場合、データ完全性を維持するのに、十分に分散されたアドレスが望ましくなり得る。３Ｄボリュームデータは、本質的に、十分に分散されたボクセルアドレスを有し得る。例えば、例示的３Ｄボリュームデータにおいて、各ビットｉは一意であり得、各ボクセル_ｉの（ｘ，ｙ，ｚ）座標は一意であり得る。一例示的実装において、システムにおいて実装されるアルゴリズムは、例示的３Ｄボリュームデータにおける一意のボクセル位置を利用して、アドレス指定衝突を最小限にとどめるアドレス指定方式を実現し得る。この文脈において、アドレス指定衝突（またはハッシュ衝突、または単純に「衝突」）の参考状況として、ハッシュ化方式で使用されたハッシュ関数が、複数のキーに対して、ハッシュテーブル内で同じインデックスを生成することが挙げられる。

【0087】

いくつかの実装において、複数の異なるハッシュ関数がシステム内でイネーブルされ、ハッシュ関数の特定の１つが、アプリケーションに基づいて選択されてもよい。一部のアプリケーションは、データ完全性の維持（例えば、ハッシュ化衝突の数を最小限にする）に特化し、一方でその他は実行速度（例えばデータ検索速度）に特化する。その他例もあり得る。さらに、容易にデータ挿入および除去を可能にする技術を提供することが考えられる。これは、ダイナミックデータを考慮した場合に極めて重要となる。その他例もあり得る。いくつかの例において、十分に望ましい性能実現を促すため、アルゴリズムから生成されたハッシュ値が一様に分布するように、ハッシュアルゴリズムが選択されるべきである。実際、理想的なソリューションは、単一のクエリでハッシュテーブルのデータ検索を可能とするような完全ハッシュ化関数を提供することであり得る。そのようなソリューションは、アドレス指定衝突を伴わないハッシュを提供するものである。単純に、これは十分に大きなハッシュテーブルを提供することで実現可能である。しかし、これは常に実現可能ではない。ボリュームデータは、モバイルプラットフォーム上を始めとする、メモリが限られた状況で使用されることが多いのである。その他制限的なシステムもあり得る。

【0088】

３Ｄデータのハッシュ化で素数を使用する伝統的なハッシュ化方式の例として、除算的（ｄｉｖｉｓｉｏｎ）ハッシュ化技術、乗算的（ｍｕｌｔｉｐｌｉｃａｔｉｖｅ）ハッシュ化技術、排他的論理和または（ＸＯＲ）ハッシュ化方式、モートン順序ハッシュ化方式が挙げられる。その他例もあり得る。いくつかの実装において、複数の異なるハッシュ化方式のいずれか１つを実施するロジックを含むシステムが設けられてもよい。いくつかの例において、有効なハッシュ関数は、アプリケーションに依存し得る。いくつかの文脈において、ハッシュ関数の有効性は、妥当なデータフットプリントを維持しながら、アドレス指定衝突によりハッシュテーブルに記憶されないボクセルの数を最小限に抑える等、データ完全性に基づいて、測定または検討され得る。その他例もあり得る。さらに、特に軽量システムまたは資源限定的システムにおいて、データフットプリントのサイズ管理に関して、使用されるハッシュテーブルのサイズが重要となり得る。当該システムとしては、資源限定的なドローン、ロボット、自律走行乗用車または貨物車両、または３Ｄ空間内で自律移動可能なその他デバイスが挙げられる。テーブルが大きいほど、そのテーブルへのデータ挿入の場合に、アドレス指定衝突が生じにくいとも考えられるが、ハッシュアドレスがハッシュテーブルサイズの剰余である場合、ハッシュテーブルサイズの選択はバイアスを伴い得る。したがって、ハッシュテーブルサイズを選択する場合、必ずしも大きいほどよいとは限らない。より効率的なハッシュアルゴリズムにより、資源限定的アーキテクチャにおいてより使いやすい、より小さなハッシュテーブルが使用可能となり得る。

【0089】

いくつかの実装において、ハッシュテーブルは、当該ハッシュテーブルの各エントリに、複数の要素の情報（例えば、特定の仮想または物理的３Ｄ空間における複数のボクセルについて、占有されているか否か、またはその他情報）を記憶可能とする特定のハッシュ化アルゴリズムに関連して使用されてもよい。例えば、複数の要素を記憶するハッシュテーブルエントリを使用する利点の１つとして、適切なエントリを発見するために用いられる外部検索の数の低減が挙げられる。ハッシュテーブルエントリサイズは、ボクセル（およびその他識別データ）の数および、各ボクセルまたはその他要素についての情報の記憶に使用されるビットの数に基づいて設計され得る。例えば、本開示で説明されるスパースツリーボリュームデータ構造と、そのボリュームデータ構造に記載の複数のボクセルを表すデータを含むように利用される対応するハッシュテーブルエントリサイズが考えられ得る。一例として、連続した４^３ボクセルブロックのボクセル毎２ビット表現を含むように、単一のハッシュテーブルエントリに対して、１２８ビットが割り当てられ得る。しかし、一部の３Ｄデータは、ボクセルが広く分布しながら、本質的にスパースであり得るため（例えば、Ｄｕｂｌｉｎ Ｃｉｔｙ Ｄａｔａｓｅｔは、平均で９８．７４％スパースである）、ハッシュテーブルの単一のエントリ内のデータが表すボクセルの数は限定され得る。より控えめなボクセルの数（例えば６４ボクセル）を表すことが、外れ値の形式で存在するノイズの効果を最小限に抑えながら、効率的であり得る。例えば、エントリ毎６４ボクセルの例において、ボクセル毎２ビットの手法では、ノイズに割り当てられるのはせいぜい１２８ビットとなる。しかし、ハッシュエントリが大きくなるほど、ノイズの大きいボクセルにより多くのメモリが割り当てられる可能性があり得る。

【0090】

図１４を参照にすると、３Ｄ空間を分析する機械１４０５を含む例示的環境を示す簡潔なブロック１４００が示されている。いくつかの実装において、機械は、ＳＬＡＭプロセス、レイキャスティング、衝突検出、２Ｄまたは３Ｄルートプランニング、およびその他本明細書に記載の例のような、アプリケーションまたは動作の１または複数において、３Ｄ空間を記述したボリュームデータを利用するため、ハードウェアおよび／または回路内に実装された、機械により実行可能なロジックを備えてもよい。ボリュームデータは、本明細書に記載のような、スパースツリー表現として実現され得る。いくつかの例において、メモリ使用量増（例えば、ハッシュテーブルは、デンスなアレイよりもメモリ使用量が少ない）とのトレードオフにより、ボリュームデータのより高速処理を実現するように、ハッシュテーブルが追加的、または代替的に利用されてもよい。いくつかの例において、ハッシュテーブルは多層スパースツリー型構造と共に使用されてもよい。ここで、ハッシュテーブルは、特定の解像度で、占有ボクセルを早急に特定するように使用される。そしてスパースツリー表現を使用して、ボクセルが占有されているかを高解像度で判定し、呼び出された場合、より詳細な分析を実行するものである。その他例もあり得る。実際、機械１４０５は、スパースツリーボリュームデータ構造で表されたボリュームデータを扱い、処理するように構成された、本明細書に記載のハードウェアおよびロジックを備えてもよい。

【0091】

図１４に示す具体例において、機械１４０５は、３Ｄシーンを記述したボリュームデータを処理し、シーン内に存在する地形に基づいて、シーン内で自律移動するために（例えば、シーン内での位置の変化、および／または機械の１または複数の要素（例えば、センサ、カメラ、ポインタ、アクチュエータ、ツール等）の向き（例えば、目標）の変化）その情報を利用可能な自律的または半自律的な機械として実現されてもよい。これにより、機械はオブジェクト（例えば、１４１０ａからｃ）を検出して、検出したオブジェクトに基づいて、自律的にシーン内でナビゲートまたは相互作用してもよい。いくつかの実装において、機械１４０５は、自律走行車両（人、または荷物を運ぶ）、陸空ベースまたは海上ベースのドローン、ロボットとして実施されてもよい。その他例もあり得る。

【0092】

一例示的実装において、機械１４０５は１または複数の中央処理ユニット（ＣＰＵ）、グラフィック処理ユニット（ＧＰＵ）、テンソル処理ユニット、またはその他行列演算プロセッサ、ハードウェアアクセラレータ（例えば、ボリューム処理アクセラレータ、機械学習アクセラレータ）、およびその他汎用および専用プロセスハードウェア等のデータプロセッサ１４１５を使用して、さらに１または複数メモリ要素（例えば、１４２０）を使用して実現されるコンピューティングシステム１４０６を含んでもよい。ボリューム処理ロジック１４２５、アクチュエータ１４３０、およびハッシュ化ロジック１４３５等のハードウェア回路、ファームウェア、またはソフトウェア内に実装されたさらなる論理ブロックが設けられてもよい。いくつかの実装において、機械１４０５はさらに３Ｄ空間を測定する、１または複数センサ（例えば、１４４０）を備えてもよい（例えば、ｌｉｄａｒ、タイムオブフライトセンサ、ｒｅａｌｓｅｎｓｅ ｓｅｎｓｏｒｓ等）。当該センサ１４４０は、ボリュームのマップを展開するため、３Ｄ環境を記述したボリュームデータの生成に使用され得る。さらに、センサ１４４０を使用して検出された、局地観察ジオメトリと、予期される、または以前に観察されたボリュームを占有するジオメトリを記述した参照データとの比較に使用される。機械で生成、および／または使用されるボリュームデータは、１または複数のハッシュテーブル１４５０の少なくとも一部に保持されてもよい。上述のように、いくつかの実装において、ハッシュテーブルエントリにおけるボリュームデータは、ＶＯＬＡフォーマットのスパースツリーボリュームデータ（例えば、データ１４５５）等の、本明細書に記載のようなスパースツリーボリュームデータと通じたもののような、高解像度ボリュームデータにより補足されてもよい。

【0093】

図１４の例の説明を続ける。一例において、ボリューム処理ロジック１４２５は、１または複数の異なるボリューム処理動作、または３Ｄ畳み込み、レイキャスティング、ＳＬＡＭ、衝突検出、自律ナビゲーション等に関連したタスク等のタスクを実行するロジックが設けられてもよい。一例において、本明細書において説明されるボリュームアクセラレーションユニット（ＶＸＵ）等のボリュームアクセラレーションユニットを使用して、ボリューム処理ロジック１４２５の少なくとも一部分を実施してもよい。ボリューム処理ロジックは、ハッシュテーブルエントリ、ＶＯＬＡデータ１４５５の一方または両方で実施されるボリュームデータを入力として取得してもよい。その他例もあり得る。いくつかの例において、ボリュームデータにより生成された結果は、機械１４０５の１または複数アクチュエータ１４３０をトリガして、１または複数モータ、エンジン、またはその他ドライブ、および／または１または複数の操縦機構を起動して、機械自体、または機械の特定のツールが、ボリューム内でその設計に応じて移動するようにしてもよい。例えば、ボリューム処理ロジックは、１または複数のアクチュエータに入力を提供して、ドローンまたは自律走行車両が、ボリュームデータの処理を通じて、当該機械が認識したボリュームにおいて自律ナビゲートするようにしてもよい。

【0094】

資源限定的システムまたは高速応答時間を要するアプリケーション等のいくつかの例において、システムは高解像度ボリュームデータをまず処理するのではなく、その代わりにより早くクエリおよびアクセスを可能にする、より低解像度のボリュームデータを利用してもよい。例えば、各種ボリュームアプリケーションは、３Ｄ空間における１または複数ボクセルが空であるか、または３Ｄジオメトリ（例えば、物理的または仮想的のいずれか）で占有されているかを検出することを伴い得る。そのような場合、ボリューム処理ロジック１４２５は、ハッシュ化ロジック１４３５と動作して、ハッシュテーブル１４５０のエントリ内に保持されたボリュームデータを問い合わせ、処理のためにボリュームデータにアクセスしてもよい。さらに、ハッシュ化ロジック１４３５を使用して、新しいハッシュテーブルエントリを、システムのセンサ１４４０により生成されたボリュームデータおよび、レーダ、超音波等の、任意のその他空間的３Ｄデータと共に挿入してもよい。その他例もあり得る。いくつかの実装において、より詳細に後述するような、密度座標（ｄｅｎｓｉｔｙ ｃｏｏｒｄｉｎａｔｅ；ＤＥＣＯ）式ハッシュ化アルゴリズムを実現するように、ハードウェア、ファームウェア、および／またはソフトウェアにより、ハッシュ化ロジック１４３５が実現されてもよい。

【0095】

ハッシュテーブル（例えば、１４５０）は、ボクセル毎１または複数ビットを使用して、ボクセルを表すデータを含むように実現されてもよい。一例において、ボクセル毎に１つのビットを利用して、ボクセルが占有されているかを表してもよく、ボクセル毎に別のビットが、テーブルエントリ識別子でアドレス指定衝突検出を可能とするように利用されてもよい。いくつかの実装において、エントリ内に記憶されたボリュームデータは、少なくとも部分的にＶＯＬＡまたはその他スパースツリーデータ構造フォーマットにフォーマットおよび／または整理されてもよい。別の例では、各ボクセルに対する追加的情報を示すか、または衝突検出および回避を可能とするように、さらなるビットが利用されてもよい。例えば、追加的なビットは、ボクセル毎に割り当てられてもよい。これにより、色、素材、または種類等のボクセル特徴が特定される。ただし、そのような情報を足すことは、機械のハッシュテーブルの使用に関しては蛇足であり得、アプリケーションによっては過剰にメモリ負荷がかかり得る。一例において、ボリューム内に、６４ボクセルのサブセットまたはブロックの表現を含むテーブルエントリ内の各ボクセルに、２ビットが割り当てられる場合、単一のエントリに対するメモリ要件は、１２８ビット（０．０１６ｋＢ）となる。これにより、ハッシュテーブルメモリの各ｋＢは、６２．５バケットまたはエントリを含むことが可能となるため、４０００バケットまたはエントリ等の６４ｋＢの実現が促される。

【0096】

いくつかの実装において、１または複数センサにより取得されたボリュームデータに記述されたボリューム情報への高速アクセスを可能とするために、改良ハッシュ化アルゴリズムが利用されてもよい。例えば、３Ｄボリュームデータの固有の構造的態様を利用するため、コンピューティングデバイスのハードウェアおよび／またはソフトウェア内に密度座標（ＤＥＣＯ）ハッシュ化アルゴリズムが提供および実装されてもよい。例えば、例示的ＤＥＣＯハッシュ化アルゴリズムは、多くの３Ｄボリュームデータにより占有されるデンス／スパースがどれくらいかを利用してもよく、どのようにボリューム内の全てのボクセルのそれぞれの座標値の高い一意性を利用してもよい。例えば、占有されたボクセルを表すことのみを通じて、多くの３Ｄデータのスパースな性質が利用され得る。これにより、貴重なメモリが他の目的のために使用可能となる。一例において、ボリュームにおいて、１または複数のボクセルを表すボリュームデータが、ハッシュテーブルにおけるエントリに記憶されてよく、エントリのアドレスが、例示的なＤＥＣＯハッシュ化アルゴリズムを通じて求められたインデックスから生成されてよい。一例において、ＤＥＣＯハッシュ化アルゴリズムは、ボクセルに関連付けられた座標の値（即ち、ボクセルに関連付けられたボリュームにおけるｘ座標、ｙ座標およびｚ座標）を効果的に集約できる。ここで、座標値は、辺長（ＳＬ）変数を使用して重み付けされ、加重値を合計してインデックスが生成される。構成座標値がどのように重み付けされるかは、ボリュームの１または複数の軸に沿ったボリューム内の３Ｄジオメトリの、観察された、または予想された密度またはばらつきに基づいてもよい。例えば、ボリューム内の３Ｄジオメトリが、ボリュームのｘまたはｙ寸法内でよりデンスであるかまたは多様であり、ｚ寸法ではよりスパースであると観察され得る。重み付けは、観察されたまたは予想されたボリュームの密度に基づいて、ハッシュ化関数における衝突を最小限にとどめるように選択されてよい。

【0097】

具体例として、ＤＥＣＯハッシュ化アルゴリズムは次の式に応じて実施されてもよい。ｉｎｄｅｘ＝（ＩＤ_ｚ×（ＳＬ^２）＋ＩＤ_ｙ×（ＳＬ）＋ＩＤ_ｘ）式中ＩＤ_ｘ、ＩＤ_ｙ、およびＩＤ_ｚは、対象ボクセルに関連付けられたｘ座標値、ｙ座標値、ｚ座標値であり、ＳＬは辺長変数である。辺長変数ＳＬは潜在的に、任意の値であり得、得られるハッシュテーブルにおける衝突を最小限にするように選択されてもよい。いくつかの実装において、ＳＬ値は、対象ボリュームの辺の長さ（例えば、ボクセル、またはボクセルブロック内）に対応するように選択されてもよい。ハッシュテーブルアドレスは、例えば以下の例示的式に応じてモジュロ演算を利用して、計算されたインデックス値から生成され得る。ｈａｓｈ＿ａｄｄｒ＝ｉｎｄｅｘ％Ｎ式中、Ｎはハッシュテーブルにおけるインデックス付けされるエントリ／アドレスの数を示す。その他例示的実装もあり得る。

【0098】

上述の例示的ハッシュ化式において、ｚ座標値ＩＤ_ｚとの乗算前に辺長変数（ＳＬ）を二乗することにより、ｚ座標値が最も強く重み付けされてもよい。これは、３Ｄボリューム内の占有空間が、ボリュームのｚ座標においてよりデンスさまたは多様さの一方または両方が低いという仮定に基づいて行われ得る。このような重み付けは、ハッシュテーブルに対して、対応するボリュームデータについて決定されたハッシュアドレスの衝突の可能性を低減するように作用し得る。別の実装において、占有空間または３Ｄジオメトリがｚ座標面でよりデンスで、ｘまたはｙ座標のいずにおいてデンスさがより低い場合、ｚ座標値の重み付けがより弱く（例えば、ＳＬ^２ではなくＳＬ^０をかける）、その他座標値（ｘおよびｙ）の重み付けがより強くてもよい。その他例もあり得る。実際、ボリューム内の密度特徴の過去の観測または予測が特定されてもよい。この情報は、適切にそれぞれの座標値を重み付けするための、ＤＥＣＯハッシュ化式の動的選択に使用されてもよい。さらに、ＳＬ値は、対象ボリュームに対して決定された仮定に基づいて動的に決定されてもよい。これにより、ＤＥＣＯハッシュアルゴリズムを使用して決定されたハッシュアドレスの衝突の数の制限に関する最適化を促進する。その他例示的考察、および実装もあり得る。

【0099】

本明細書に記載のとおり、単一なハッシュテーブルエントリが、ボリューム内の複数のボクセルを同時に記述するボリュームデータを有することが有利となり得る。例えば、図１５の例の示すように、ハッシュテーブルエントリは、４^３ボクセルブロックにより定義されるサブボリューム内の６４ボクセルの組またはブロックに対して、ボリュームデータをエントリ内に収容可能にし得る。この例において、単一の特定の対象ボクセルの座標を使用したハッシュを実行するのではなく、アルゴリズムは座標値ｘ、ｙおよびｚとして、ジオメトリ内の当該ボクセルブロックの相対座標を取得してよい。例えば、図１５に示す例において、３Ｄ空間内の各ボクセル（例えば１５０５）が、４×４×４ボクセルブロック（例えば、１５１０）を表す６４ボクセルの組（または「ブロック」）に論理的にグループ化されてもよい。特定のボクセルを特定する場合、当該のボクセルの座標が、図１５に表すようなボリューム１５１５に対して定義された４×４×４ブロックの内の対応するものにマッピングされ得る。例えば、あるボクセル（例えば、１５０５）が占有されており、ハッシュテーブルに追加要と判定された場合、まずそれが４×４×４ブロック（例えば、１５１０）の内のいずれに属するかが判定される。６４^３ボクセルボリューム５１５または環境の例では、１６^３×４^３ブロックが存在することになる。例えば、ブロックの識別子または座標値が、ブロックのサイズに対して離散化された、ブロックの角ノード（例えば、ボクセル１５２０）の座標として取得されてもよい。例えば、４^３ブロックを使用する場合、ボクセルブロック識別子は４に対して離散化される。６４^３ボクセルボリューム１５１５による例において（図１５に示す例のように）、これらブロックの座標（識別子（ＩＤ）座標と称する）の範囲は、（ｘ；ｙ；ｚ）＝（０；０；０）から（ｘ；ｙ；ｚ）＝（６３／４；６３／４；６３／４）＝（１５；１５；１５）となる。

【0100】

上述のとおり、ＤＥＣＯハッシュ化で使用される際、辺長（ＳＬ）変数は、アルゴリズムの最適化を図り、ハッシュ化の際に最小の衝突数またはパーセンテージを実現するように調整および選択され得る。例えば、ボクセルのブロックについての情報が単一のハッシュテーブルエントリに記憶される実装においては、対象ボリューム全体の、辺におけるボクセルブロックの数に対応する辺長を選択することで、衝突のパーセンテージが最小となり得る。一例において、３２ｋＢのハッシュテーブルサイズ（２０４０テーブルエントリ）を利用して、スタンフォードうさぎのボリュームを記述した情報が記憶され得る。ボリュームは、うさぎが４^３ボクセルブロックの１６^３ボリューム内に嵌る解像度であるとされる。ＳＬ値を変えながらＤＥＣＯハッシュ化アルゴリズムをテストすることで、この例では、ＳＬ値１６で最小の衝突パーセンテージ（例えば、０．７９％）が得られることがわかる。より一般的には、最適なＳＬ値は、対象ボリューム内のボクセルブロックの数の立方根に対応し得る。この理由は以下のとおりである。例えば、６４^３ボクセルの環境では、最大で１６^３×４^３ボクセルブロックが存在する。したがって、ＳＬ値を１６とした場合、現在のブロックのインデックスを計算（即ち、上述のようなＤＥＣＯハッシュ化式を使用）する際に、衝突は起こらないのである。ただし、ハッシュテーブルアドレスの計算時には衝突は生じ得る。

【0101】

ＤＥＣＯハッシュ化実装の場合、占有ボクセルが所属する４^３ブロックの座標が判定されると、別の４^３ブロックに対するそのインデックスが決定される（いくつかの例においては、個別の対象ボクセルの座標の値から直接求められ得る（例えば、最下位ビットの１または複数をボクセルの座標の２値表現から除去することで、２値表現を切り捨てて、対応する４^３ボクセルブロックの座標を特定する）。例えば、図１５の例では、各個別のボクセルは、３２ビット値を用いて表されてもよく、所与のブロック内の各ボクセルは、同じ３０最上位ビットを共有する個別の複数のボクセル座標値を有してもよい。したがって、これら共有３０共通ビットは、ボリューム内のブロックの座標値となり得る（そして、最下位ビットの残りの２つが、ブロック内の各個別ボクセルを一意に特定してもよい）。その他例もあり得る。

【0102】

上述の例の説明を続ける。対象の特定のボクセルを含むブロックに対してブロック座標が決定された場合、これらブロック座標値は、ＩＤ_ｘ、ＩＤ_ｙ、およびＩＤ_ｚ（例えば、上述の例による）の値として提供されてもよい。さらに、図１５に示すように、辺長値は、４^３ボクセルブロックで表される対象ボリュームの長さに基づいてもよい（例えば、辺毎に１６ボクセルブロックで、４^３ボクセルブロックの１６^３の集合となる）。その他例もあり得る。実際、選択されたボクセルブロック（例えば、２^３、３^３、８^３ボクセルブロック等）のサイズ、ハッシュテーブルのサイズとそれを構成するエントリ、対象ボリュームのサイズおよび寸法に基づいて、同様の原理を適用してもよい。その他考察もあり得る。

【0103】

ＤＥＣＯハッシュ化関数を使用して、ハッシュテーブルアドレスを判定するための（例えば、モジュロ演算を使用する）インデックスが求められ得る。これにより、対応するボクセルブロックに対するボリュームデータを含むハッシュテーブル内の（既に測定されている場合）、特定のエントリを特定する。したがって、エントリのボリュームデータは、当該ブロック内の各ボクセルそれぞれの占有状態を記述し得る。このボリュームデータ列は、機械により読み取られ（またはそこに書き込まれ）、そのボリュームデータ列内の、特定されたボクセルブロック内の特定のボクセル占有（および潜在的にその他の）情報（および当該ブロック内のその他のボクセルの各々の同様の情報）が特定される。

【0104】

ＤＥＣＯハッシュ化アルゴリズムは、大きい素数を使用するハッシュ化アルゴリズムを含む３Ｄデータ（即ち、３Ｄボリュームを表し、記述したデータ）に対する伝統的なハッシュ化アルゴリズムに対して複数の利点を実現し得る。例えば、いくつかの形態において、ＤＥＣＯハッシュ化を使用したハッシュテーブル内の挿入は、伝統的な手法よりも簡潔となり得る。即ち、ボクセルが占有されていると判定され（例えば、ハッシュ関数を実行する機械上のセンサを通じて、または遠隔機械上のセンサからデータを受信する機械を通じて等）、そのためハッシュテーブル内に挿入されるべきと判定されると、当該ボクセルが属する４^３ブロックのハッシュアドレスが計算される。これは、選択されたハッシュ化関数に応じて計算されてもよい。衝突が生じない場合、ハッシュエントリ内の当該ボクセルに対応するビットが、１に設定される。衝突が生じる場合は、ボクセルは設定できない。そこで、ハッシュテーブルに関連して設けられた衝突管理方式を利用して、衝突を処理してもよい（例えば、挿入されるデータを次の利用可能な一連のエントリに記憶することを通じて、「逆方向性（ｄｅｇｅｎｅｒａｔｉｖｅ）アドレス」を使用することを通じて（例えば、エントリ２７４８で衝突が生じる場合、エントリ２７４に、ボクセルが配置される。エントリ２７４に収まらない場合はエントリ２７に配置される等。その他例示的方式もあり得る）。削除に関して、ボクセルがハッシュテーブルから削除されると判定された場合、再度、ボクセルが属する４^３ノードのハッシュアドレスが計算される。衝突が起きず、ビットが設定済みである場合、ハッシュアドレスにおけるボクセルに対応するビットは単純に未設定である。衝突が起きず、ビットが設定済みでないか、またはハッシュアドレスが空である場合、未設定のボクセルの削除が図られている。これが特定されると、さらなる計算は行われない。

【0105】

ＤＥＣＯハッシュ化は、衝突が大幅に低減されることから、伝統的な３Ｄハッシュ化アルゴリズムよりも有利であり得る。例えば、図１６Ａから１６Ｃのグラフ１６００ａからｃは、例示的なＤＥＣＯハッシュ化アルゴリズムを使用して観察された衝突性能を、ＸＯＲハッシュ化アルゴリズム等の伝統的なハッシュ化アルゴリズム、モートン順序素数無しハッシュ化アルゴリズム、および伝統的なモートン順序ハッシュ化アルゴリズムの性能と比較したものを示す。これらの例において、対象ハッシュ化アルゴリズムの各々が、同様のサイズのハッシュテーブルを利用する。図１６Ａは、スタフォードうさぎデータセットで構成されるデータセットの結果を示し、各アルゴリズムを使用した場合の衝突のパーセンテージを表す。同様に、図１６Ｂは、Ｄｕｂｌｉｎ Ｃｉｔｙ Ｄａｔａｓｅｔ Ｌｉｆｆｅｙ Ｔｉｌｅで定義されたボリュームにおいて、ハッシュ化アルゴリズムの各々を使用して観察された衝突のパーセンテージの比較を示す。最後に、図１６Ｃは、完全なＤｕｂｌｉｎ Ｃｉｔｙ Ｄａｔａｓｅｔ（例えば、アイルランドのダブリン市の＃Ｄマップを表す）の全体において観察された、ハッシュ化アルゴリズムによる衝突のパーセンテージ比較を表す。図示のように、ＤＥＣＯハッシュ化アルゴリズムは、信頼された伝統的な３Ｄハッシュ化アルゴリズムよりも有効性を示している。

【0106】

適切なハッシュ化アルゴリズムに加えて、ハッシュテーブルサイズもアドレス指定衝突の数に影響し得る。即ち、わずかにのみ変化する数の剰余を取る場合、対応するアドレス結果は大きく変化し得るためである。一方で、ハッシュテーブルサイズは、資源利用と、性能最適化の間のトレードオフを表し得る。例えば、特定のデータセットに対してハッシュテーブルサイズを変えた影響を、競合するハッシュ化アルゴリズム間で調べてもよい。一例において、１．２ＭＢと小さいハッシュテーブルを使用して、特定のデータセットに対してＤＥＣＯハッシュ化を行うと、衝突率は１％未満であると確認され得る。しかし、別の、伝統的ハッシュ化アルゴリズム（例えば、ＸＯＲハッシュ化）を用いて同じ結果を得るには、ハッシュテーブルをかなり大きくする必要があり得る（例えば、４ＭＢを超えるサイズを有する）。このような結果は、ハッシュ化３Ｄボリュームデータに対するＤＥＣＯハッシュ化の、ＸＯＲハッシュ化に対する優位性を際立たせる。

【0107】

伝統的な３Ｄハッシュ化手法に対する、ＤＥＣＯハッシュ化のさらなる例示的利点として、ＤＥＣＯハッシュ化を使用して埋められたハッシュテーブルに記憶されたボクセルの分布は、伝統的なハッシュ化手法を使用して実現可能なものよりも、かなりコンパクトとなり得ることが挙げられる。モートン順序素数無しハッシュ化等の一部の伝統的なハッシュ化手法も、ハッシュテーブル内にボクセルをコンパクトに記憶するものである。しかしそのような伝統的手法は、占有されたハッシュエントリと、空のものとの間に大きな差分を伴いがちである。いくつかの例において、ＤＥＣＯハッシュ化を使用して実現された有利なコンパクトさを通じて、結果として得られたハッシュテーブルは、ハッシュテーブルの一部領域で極めてコンパクトとなり、その他領域で極めてスパースとなり得る。したがって、そのような状況が検出された場合、システムは動的に、テーブルのよりスパースに占有された領域を、ボクセルがよりデンスにコンパクト化され得る二次的ハッシュテーブル等、その他用途に再割り当てしてもよい。このような手法により、主ハッシュテーブルに対して使用されていたメモリが他の目的に使用可能になる。これは、内蔵型、モバイル、および同様にメモリが制限されたデバイスには魅力的であろう。

【0108】

図１７を参照すると、上述のように、１または複数ボクセルを記述したボリュームデータを、ＤＥＣＯハッシュ化アルゴリズムを使用してハッシュテーブルに入力する例示的技術を示すフローチャート１７００が示されている。ボリュームの少なくとも一部分を記述し、ボリューム内に存在するジオメトリを特定するボリュームデータが受信され得る１７０５（例えばセンサから）。例えば、ボリュームデータは、ボリューム内の特定のボクセルが、ジオメトリで占有されているか否かを示し得る。ボリューム内のｘ座標、ｙ座標およびｚ座標で表現される、特定のボクセルに関連付けられた座標が判定され得る１７１０。いくつかの例において、この座標は、ボクセルブロックの座標であってもよく（即ち、座標が、特定のボクセルの特定の座標であるのではなく）、特定のボクセルがこのボクセルブロック内に含まれてもよい。ｘ座標、ｙ座標およびｚ座標の値を入力とするＤＥＣＯハッシュ化アルゴリズムを使用して、特定のボクセルに対するインデックスが決定され得る１７１５。ハッシュ化アルゴリズムは、ｘ座標、ｙ座標およびｚ座標の加重値を合計して、インデックスを生成し得る。ここで、ｘ座標、ｙ座標およびｚ座標は、変数値（例えば、辺長変数値）を０乗、１乗または２乗に重み付けすることで、重み付けされる。座標（および特定のボクセルのボリュームデータ）に関連付けられるハッシュテーブル内のエントリを特定するため、インデックス値からハッシュテーブルアドレスが決定されてもよい１７２０（例えば、モジュロ演算を使用する）。ボリュームデータをエントリにボリュームデータに書き込むまたは挿入する前に、別のボクセルのボリュームデータにより、当該エントリが書き込まれて埋められていることで衝突の可能性があるか判定されてもよい１７２５。衝突がある場合、それでも特定のボクセルを記述したボリュームデータを（例えば、ハッシュテーブルの代替的エントリに）記憶するため、衝突管理方式が採用されてもよい。衝突がない場合、ボリュームデータと、それが表す情報に高速クエリおよびアクセスを可能とするように、ボリュームデータをハッシュテーブル内に記憶するため、エントリ内にボリュームデータを挿入してもよい１７３０。いくつかの実装において、ボリュームデータは、ＶＯＬＡ型フォーマットに応じたものであってよい（例えば、特定の解像度で、４^３ボクセルの群またはブロックが占有されているかを記述する）。

【0109】

図１８の例を参照すると、３Ｄ空間（またはボリューム）内の特定のボクセルに対応するボリュームデータに対するクエリおよびアクセスを実行するための例示的技術を示す、別のフローチャート１８００が示されている。例えば、特定のボクセルを特定して（例えば、ボリューム動作またはアプリケーション（例えば、自律ナビゲーション、経路探索、レイキャスティング等）に関連して）、特定のボクセルのそれぞれの座標（即ち、ｘ座標、ｙ座標およびｚ座標）を判定してもよい１８１０。別の例のように、これら座標は、特定のボクセルそのものの座標ではなく、特定のボクセルのボクセルブロックの座標であってもよい（ただし、上述のように、ボクセルブロックの座標は含まれるボクセルの特定の座標から直接判定可能である）。本明細書に記載のとおり、ｘ座標、ｙ座標およびｚ座標の加重値（例えば、辺長変数またはその他重み付け変数を用いて重み付けされる）から総和を計算することで、ＤＥＣＯハッシュ化アルゴリズムを使用して、ｘ座標、ｙ座標およびｚ座標の値からインデックスを決定してもよい１８１５。さらに、決定されたインデックス値からハッシュテーブルアドレスが求められてもよい１８２０（例えば、インデックス値の剰余を通じて）。アドレスが決定されると、ハッシュテーブル内の決定されたアドレスに対応するエントリから、ボリュームデータが読み出されてもよい。いくつかの例において、エントリが空だと判定され得る。その場合、特定のボクセルに対するボリュームデータが収集されて、ハッシュテーブルが埋められる。別の例では、決定されたアドレスに対応するエントリが、別のボクセルブロックのボリュームデータで埋められている場合に、ハッシュテーブルに衝突が生じていると判定され得る。その他例示的問題もあり得る。しかし、無衝突動作において、ハッシュテーブルエントリ内のボリュームデータが読み出され１８２５、特定のボクセルがジオメトリで占有されているか否かを判定されるように処理されてもよい１８３０（例えば、特定のボクセルにマッピングされたボリュームデータにおける特定のビットから）。このような判定（１８３０における）は、さらなる動作をトリガするために用いられ得る（例えば、経路探索、衝突回避、マルチレベルＶＯＬＡ構造へのアクセスによるより高解像度のボクセルボリューム分析。その他例示的用途もあり得る）。実際、本開示は、コンピューティングシステムにおけるＶＯＬＡデータの使用の多数の例を包含する。なお、ハッシュテーブルからアクセスされるボリュームデータも（ＤＥＣＯハッシュ化を使用して生成されたもの等）も、同様に本明細書に記載のアプリケーションおよび例で利用されてもよい。実際、以下の図および説明は、ＤＥＣＯハッシュ化を使用して構築されたハッシュテーブルからアクセスされるボリュームデータを利用し得る、使用ケース及びハードウェアのさらなる例を提供する。

【0110】

図１９は、いくつかの実施形態に係る、例示的なマルチスロットベクトルプロセッサ（例えば、超長命令語（ＶＬＩＷ）ベクトルプロセッサ）を表す簡潔なブロック図である。この例において、ベクトルプロセッサは複数の（例えば、９個の）機能的ユニット（例えば、１９０３から１９１１）を含み得る。これは、ベクトルレジスタファイル（ＶＲＦ）１９０１および汎用レジスタファイル（ＧＲＦ）１９０２によりバックアップされたマルチポートメモリシステム１９００により提供され得る。プロセッサは、命令をデコードし、機能的ユニット１９０３から１９１１を制御する制御信号を生成する、命令デコーダ（ＩＤＥＣ）１９１２を含む。機能的ユニット１９０３から１９１１は、前提実行ユニット（ｐｒｅｄｉｃａｔｅｄ ｅｘｅｃｕｔｉｏｎ ｕｎｉｔ；ＰＥＵ）１９０３、分岐および繰り返しユニット（ｂｒａｎｃｈ ａｎｄ ｒｅｐｅａｔ ｕｎｉｔ；ＢＲＵ）１９０４、ロード記憶ポートユニット（例えば、ｌｏａｄ ｓｔｏｒｅ ｐｏｒｔ ｕｎｉｔ（ＬＳＵ０）１９０５およびＬＳＵ１ １９０６）、ベクトル演算ユニット（ｖｅｃｔｏｒ ａｒｉｔｈｍｅｔｉｃ ｕｎｉｔ；ＶＡＵ）１９０７、スカラー演算ユニット（ｓｃａｌａｒ ａｒｉｔｈｍｅｔｉｃ ｕｎｉｔ；ＳＡＵ）１９１０、比較および移動ユニット（ｃｏｍｐａｒｅ ａｎｄ ｍｏｖｅ ｕｎｉｔ；ＣＭＵ）１９０８、整数演算ユニット（ｉｎｔｅｇｅｒ ａｒｉｔｈｍｅｔｉｃ ｕｎｉｔ；ＩＡＵ）１９１１、ボリュームアクセラレーションユニット（ｖｏｌｕｍｅｔｒｉｃ ａｃｃｅｌｅｒａｔｉｏｎ ｕｎｉｔ；ＶＸＵ）１９０９である。この特定の形態において、ＶＸＵ１９０９は、記憶／検索の両動作、論理動作、および演算動作を含む、ボリュームデータに対する動作を向上してよい。図１９の例では、ＶＸＵ回路１９０９は単一コンポーネントとして示されているが、ＶＸＵ（および他の機能的ユニット１９０３から１９１１の）の機能は、複数の回路に分散されてもよいことが理解されよう。さらに、いくつかの実装において、ＶＸＵ１９０９の機能は、いくつかの実装において、プロセッサのその他機能的ユニット（例えば、１９０３から１９０８、１９１０、１９１１）の１または複数の内部に分散されてもよい。その他例示的実装もあり得る。

【0111】

図２０は、いくつかの実施形態に係るＶＸＵ２０００の例示的実装を示す簡潔なブロック図である。例えば、ＶＸＵ２０００は、ベクトルレジスタファイル１９０１または汎用レジスタファイル１９０２の何れかからの入力を受信する、６４ビット入力ポート２００１を少なくとも１つ提供してもよい。この入力は、レジスタファイル２００３、アドレス生成器２００４、ポイントアドレス指定ロジック２００５、ポイント挿入ロジック２００６、ポイント削除ロジック２００７、Ｘ次元３Ｄ－２Ｄ投影ロジック２００８、Ｙ次元３Ｄー２Ｄ投影ロジック２００９、Ｘ次元３Ｄ－２Ｄ投影ロジック２０１０、２Ｄヒストグラムピラミッド生成器２０１１、３Ｄヒストピラミッド生成器２０１２、ポピュレーションカウンタ２０１３、２Ｄ経路探索ロジック２０１４、３Ｄ経路探索ロジック２０１５、および６４ビット符号なし整数ボリュームビットマップ上で動作する考えられる追加的機能的ユニットを含む複数の機能的ユニットに接続されてもよい。ブロック２００２からの出力は、ベクトルレジスタファイルＶＲＦ１９０１または汎用レジスタファイルＧＲＦ１９０２の何れかのレジスタファイルに書き戻されてもよい。

【0112】

図２１の例を参照すると、４^３ボクセルキューブ２１００の構成が表されている。第２のボクセルキューブ２１０１も表されている。この例において、ボクセルキューブは、６４ビット整数２１０２としてのデータ内に定義され得る。ここで、キューブ内の各単一ボクセルは、６４ビット整数内の単一の対応するビットで表される。例えば、アドレス｛ｘ，ｙ，ｚ｝＝｛３，０，３｝におけるボクセル２０１２は、「１」に設定されてもよい。これは、ボクセルキューブ２１０１が表すボリューム空間内の当該座標に、ジオメトリが存在することを示す。さらに、この例において、その他全てのボクセル（ボクセル２１０２以外）は、「空」の空間に対応し、それら座標には物理的ジオメトリが不在であることを示すように「０」に設定されてよい。その他例もあり得る。図２２を参照すると、いくつかの実施形態に係る、２レベルスパースボクセルツリー２２００の例が示されている。この例において、ボリューム内には、「占有」ボクセル（例えば、位置｛１５，０，１５｝に存在）が１つだけ含まれている。この場合、ツリー２２０１の上位レベル０は、単一のボクセルエントリ｛３，０，３｝を含む。このボクセルは、要素｛３，０，３｝における単一のボクセルを含む次のレベルのツリー２２０２を指す。スパースボクセルツリーのレベル０に対応するデータ構造内のエントリは、１つのボクセルが占有と設定された６４ビット整数２２０３である。このように設定されたボクセルは、６４ビット整数のアレイが、さらに２２０３に設定されたボクセルボリュームに対応するツリーのレベル１に割り当てられることを意味する。レベル１サブアレイ２２０４では、ボクセルの１つのみが占有に設定され、その他全てのボクセルが空と設定される。この例において、ツリーは２レベルツリーであり、レベル１はツリーの最下層を表す。即ち、階層がそこで終わることを表す。

【0113】

図２３は、いくつかの実施形態に係る、２レベルスパースボクセルツリー２３００を示す。これは、特定のボリュームの、位置｛１５，０，３｝および｛１５，０，１５｝において、占有ボクセルを含む。この場合、ツリー２３０１の上位レベル０（特定のボリュームを６４個の上位レベル０ボクセルに細分化したものである）は、２つのボクセルエントリ｛３０，０｝および｛３，０，３｝を含み、対応するデータ２３０４が、２つのボクセルが設定されている（または占有されている）ことを示す。スパースボクセルツリー（ＳＶＴ）の次のレベルは、それぞれ１つずつレベル０で設定された各ボクセルに対応した２つのサブキューブ２３０２および２３０３を含む、６４ビット整数アレイとして設けられる。レベル１サブアレイ２３０５において、２つのボクセルｖ１５およびｖ６３が占有と設定され、その他ボクセルは全て空、そしてツリーに設定される。ツリーの次のレベルの６４エントリが、常にツリーにおける上位層における各設定されたボクセルに対応して割り当てられるという点で、このフォーマットは柔軟である。この柔軟性により、上位層における対応するボクセルが設定されている限り、動的に変化するシーンジオメトリが、柔軟に既存のボリュームデータ構造に挿入可能である（即ち、ランダム等、固定の順序ではない）。そうでない場合、ポインタのテーブルが維持され、より厳しいメモリ要件となるか、または未知のジオメトリを挿入するために、ツリーが少なくとも部分的に再構築される必要が生じる。

【0114】

図２４は、いくつかの実施形態に係る、図２３からのボクセルを記憶する代替的な技術を示す。この例において、全体的なボリューム２４００は、図２３のように、グローバル座標｛１５，０，３｝および｛１５，０，１５｝に記憶された２つのボクセルを含む。この手法では、レベル０の下のレベル１における全てのサブキューブを表すように６４エントリを割り当てるのではなく、レベル１内の要素において、実際にジオメトリを含むもののみが、６４ビットレベル１記録に対応すると割り当てられる（例えば、対応するレベル０ボクセルが占有されたものか否かを示すことによる）。これにより、この例において、レベル１は６４ビットエントリを６４個（即ち、占有または空に関わらず、レベル１の６４ボクセルの各々について）ではなく、２個のみ有する。したがって、この例において、２４０４で示す第１のレベル０は、図２３の２３０４と等しいが、次のレベル２４０５は、図２３の対応２３０５と比較して、メモリ要件が１／６２である。いくつかの実装において、新しいジオメトリが、レベル１で空間が割り当てられていないレベル０に挿入される場合、ツリーをコピーおよび再構成する必要がある。

【0115】

図２４の例では、サブボリュームは、現層の上位層における占有ボクセルを数えることで、求められる。これにより、システムはボクセルデータのどこで１つ上の層が終わり、どこで次の下の層が始まるか判定し得る。例えば、層－０ボクセルが３つ占有されている場合、システムは、ボクセルデータにおいて、３つの対応する層－１エントリが続き、（これら３つの後の）次のエントリが層－２の第１のエントリに対応し、以下同様であると想定できる。このような、最適な圧縮は、シーンの特定の部分が経時変化しない、またはアプリケーションにおいてボリュームデータの遠隔送信が必要である場合において極めて有効であり得る。例えば、宇宙探査機が冥王星の表面を走査する場合が考えられる。この場合、各ビットの送信にコストも時間もかかる。

【0116】

図２５は、いくつかの実施形態に係る、対応するボリューム内のジオメトリへの変化を反映するように、６４ビット整数ボリュームデータ構造エントリとして表される４^３キューブにどのようにボクセルが挿入され得るかを示す。一例において、各ボクセルキューブは、２５００で示すように、６４ビット整数内の４つの論理的１６ビット平面として構成され得る。各平面は、０から３のＺ値に対応する。各平面内で、各ｙ値が４つの論理的４ビット変位０から３を符号化し、最後に各４ビットｙ平面内において、各ビットがｘの取り得る４つの値０から３を符号化する。その他例示的構成もあり得る。したがって、この例において、４^３ボリュームにボクセルは以下のとおりに挿入される。まず１ビットが、ｘ値０から３でシフトされ得る。そしてその値が、０／４／８／１２ビットでシフトされて、ｙ値が符号化される。最後に、ｚ値が０／１６／３２／４８ビットシフトで示され得る。これは、２５０１のＣコード表現で示される。最後に、各６４ビット整数が、各々が別個に書き込まれた最大６４ボクセルの組み合わせであり得るため、新しいビットマップは、スパースボクセルツリーから読み出された古い６４ビット値と論理的に組み合わされる必要がある。これは、２５０２に示すように、新旧ビットマップ値の論理和を取ることで実現される。

【0117】

図２６を参照すると、図示の表現は、いくつかの実施形態において、どのように６４ビット整数２６００に記憶された３Ｄボリュームオブジェクトが論理和により投影できるかを示す。Ｘ方向に投影されることで、２Ｄパターン２６０１が生成される。Ｙ方向に投影されることで、２Ｄ出力２６０２が生成される。最後にＺ方向に投影されることで、パターン２６０３が生成される。図２７は、いくつかの実施形態において、どのように入力６４ビット整数からのビットの論理和を論理的に取って、Ｘ、ＹおよびＺの出力投影を生成するかを示す。この例において、テーブル２７０１では、ｘ投影出力ベクトル２７０２を生成するために、入力ベクトル２７００からのどの要素インデックスの論理和を取るかが行方向に示される。テーブル２７０３では、ｙ投影出力ベクトル２７０４を生成するために、入力ベクトル２７００からのどの要素インデックスの論理和を取るかが行方向に示される。最後に、２７０５では、ｚ投影出力ベクトル２７０６を生成するために、入力ベクトル２７００からのどの要素インデックスの論理和を取るかが行方向に示される。

【0118】

Ｘ投影は、入力データ２７００からのビット０、１、２、３の論理和を論理的に取って、Ｘ投影２７０１のビット０が生成される。例えば、２７０１におけるビット１は、２７００からのビット４、５、６、および７の論理和を取ることで生成され、以下同である。同様に、Ｙ投影２７０４におけるビット０は、２７００のビット０、４、８、および１２の論理和を取ることで生成される。２７０４におけるビット１は、２７００のビット１、５、９、および１３の論理和を取ること等で生成される。最後に、Ｚ投影２７０６におけるビット０は、２７００のビット０、１６、３２、および４８の論理和を取ることで生成される。２７０６におけるビット１は、２７００のビット１、１７、３３、および４９の論理和を取ることで生成され、以下同である。

【0119】

図２８は、いくつかの実施形態において、どのように投影を使用して、簡略化されたマップが生成できるかを示す。このシナリオでは、ボクセルボリューム２８０２から、２８１０で示される高さｈと、２８０１で示される幅ｗの車両２８００が走行する、コンパクトな２Ｄ経路マップを生成することが目標であり得る。ここで、Ｙ投影ロジックを使用して、ボクセルボリューム２８０２から初期の、元となる２Ｄマップ２８０３を生成してもよい。いくつかの実装において、特定の寸法を有する、特定の車両（例えば自動車（または自律走行車）ドローン等）が、経路の幅２８０１および高さ制限２８１０を通過できるかを確認するため処理されてもよい。これは、経路が通過可能であることを保証するために実行され得、Ｚ投影で幅制限２８０１を確認して、Ｙ投影は、車両の高さ２８１０に対する計算を制限するために、マスクされてもよい。追加の後処理（例えばソフトウェアにおける）により、通過可能で、幅および高さ制限を満たす経路の場合、車両が移動可能な適切な経路を完全再構築するため、経路に沿った点Ａ２８０４、Ｂ２８０５、Ｃ２８０６、Ｄ２８０７、Ｅ２８０８、およびＦ２８０９のみにおける、ＸおよびＺ座標のみを記憶するか、またはネットワークを通じて送信してもよいことがわかる。経路が、このように小区域に分解可能であることで、当該経路の小直線的区域毎に１バイトまたは２バイトのみを使うことで、経路を完全に記述できる。これは、当該経路データの高速送信および処理（例えば、自律走行車両による）に寄与し得る。その他例もあり得る。

【0120】

図２９は、いくつかの実施形態において、どのように内蔵デバイスからの、ボリューム３Ｄまたは単純な２Ｄの何れかの測定値が蓄積され得るかを示す。これは、高精度測定のために、ＬＩＤＡＲまたはその他高価な手段を使用する代わりに、数学的手段で、高品質クラウドソースマップを生成するものである。提案のシステムでは、複数の内蔵デバイス２９００、２９０１等に、中央サーバ２９１０に送信され得る測定値を取得可能な各種センサが備えられてもよい。サーバ上で動作するソフトウェアは、全ての測定値２９０２を収集して、非線形ソルバー２９０３により、得られた行列に対する数値解法を実施し、高精度マップを生成する。これは、その後内蔵デバイスに戻すように再配信され得る。実際、データ蓄積には、衛星２９２０からの高精度調査データ、空中ＬＩＤＡＲ調査２９２１、地上ＬＩＤＡＲ測定値２９２２も含まれ得る。これにより、得られるマップではこれら高忠実度データセットが利用可能で、精度向上が図られる。いくつかの実装において、マップおよび／または記録される測定値は、本明細書において説明されるような形式の、スパースボクセルデータ構造内に生成、またはそれに変換されるか、それを利用して他方法で表現され得る。その他例示的実装もあり得る。

【0121】

図３０は、いくつかの実施形態において、２Ｄの２×２ビットマップ上の２Ｄ経路探索がどのように向上できるかを示す図である。この動作の原理として、ｘもしくはｙまたはｘおよびｙで連続して並ぶセルの値が全て１に設定されている場合にのみ、同一のグリッドセルのマップ上のポイント間に接続性が存在する。したがって、それらセルから描かれたビットの論理ＡＮＤをインスタンス化することで、グリッド内のビットマップに有効経路が存在するかテストされる。さらに、Ｎ×Ｎグリッドを通じた各有効経路に対して、異なるＡＮＤゲートがインスタンス化されてもよい。いくつかの例において、この手法は、組み合わせによる複雑さを伴い得る。即ち、８×８の２Ｄグリッドで有効な経路が２^６４－１含まれ得るのである。したがって、いくつかの改良実装において、グリッドが、２×２または４×４のタイルに絞られる。これらは、接続性について、階層的にテスト可能である。２×２ビットマップ３０００は、ｂ０、ｂ１、ｂ２、およびｂ３とラベル付けされた４ビットを含む。この４ビットは、００００から１１１１の値を取り得、ラベル３００１から３０１７が対応する。これらビットパターンの各々は、３０２１から３０３０でラベル付けされた２×２グリッドの面間の接続性の変化レベルを表現する。例えば、２×２グリッド３０００にビットマップ１０１０（３０１２）、１０１１（３０１３）、１１１０（３０１６）または１１１１（３０１７）が含まれる場合、３０００におけるｘ０およびｙ０の縦の接続性を示すインスタンス３０２１またはｖ０が存在する。テーブル３０１８の列１に示される、３０００の２－入力論理ＡＮＤまたはｂ０およびｂ３は、接続性マップにおけるｖ０を生成する。これは、より高位のハードウェアまたはソフトウェアにより、２×２サブグリッドに細分化されたグローバルグリッドを通じたグローバル接続性判定に使用され得る。グローバルマップがｘまたはｙ軸の何れかで、グリッド点の数が奇数になる場合、最上位グリッドを、次の偶数グリッド点にまで拡大する必要がある（例えば、グローバルグリッドのｘおよび／またはｙ軸に、ゼロの列を１つ追加する必要がある）。図３０は、例示的な７×７グリッド３０５０を示す。これはさらに、ゼロで満たされた追加の列３０３２および行３０３４を追加することで、８×８まで拡大される様子を示す。他の技術（例えば、深さ優先探索、幅優先探索もしくはダイクストラアルゴリズム法またはその他グラフ式手法）よりも高速経路探索を実現するため、本例では、漸進的にＮ×Ｎマップ３０５０を２×２マップまでサブサンプリングしてもよい。例えばこの例において、セルＷ３０４０は、３０５０におけるセルＡ、Ｂ、Ｃ、およびＤの内容の論理和を取ることで埋められる。以下同様である。そして、３０４０内の２×２セル内のビットの論理和を取ることで、３０４２におけるセルが埋められる。経路探索に関して、アルゴリズムは、グリッド３０４２の最小２×２表現から開始して、各ビットをテストする。接続性についてのテストは、２×２グリッド３０４２内の１ビットに対応する、３０４０（４つの２×２グリッドを含む）内の４×４グリッドの一部のみに実行すればよい。ゼロビットが、３０４０内の対応する２×２グリッドセルが存在しないことを意味することが分かっているためである。この手法はさらに、３０２０における８×８グリッドの探索にも使用可能である。例えば、３０４０内のセルＷがゼロを含む場合、３０２０におけるＡＢＣＤ等に経路がないことがわかるのである。この手法では、それがＡ×、Ｄｉｊｋｓｔｒａ、ＤＦＳ、ＢＦＳまたはその変形であるかどうかを問わず使用されるグラフ探索アルゴリズムから分岐を除去する。これに加え、２×２構成３０１８によるハードウェア基本経路探索を用いることにより、さらに関連した演算が制限され得る。実際、４×４基本ハードウェア要素が、３０４０および３０４２と同じ配列の、５つの２×２ハードウェアブロックを使用して構成可能である。この場合、実行する必要にあるグラフ探索量がさらに制限される。さらに、８×８ハードウェア型サーチエンジンが、３０４２、３０４０、および３０００と同じ構成の、２１個の２×２ＨＷブロック（３０１８）により構築可能である。そして任意のＮ×Ｎ構成について、以下同となり得る。

【0122】

図３１は、いくつかの実施形態に係る、提案されたボリュームデータ構造を使用して、どのように衝突検出が向上できるかを示す、簡潔なブロック図である。ジオメトリの３ＤのＮ×Ｎ×Ｎマップは、最低詳細度（ＬｏＤ）の２×２×２ボリューム３１０２、次に高い４×４×４ボリューム３１０１、８×８×８ボリューム３１００等、Ｎ×Ｎ×Ｎまでを含むピラミッドにサブサンプリングされてもよい。ＧＰＳ等の測位手段または３Ｄマップからのリローカライゼーションのいずれかにより、ドローン、車両、またはロボット３１０５の位置が３Ｄ空間において分かっている場合、関連する２×２×２サブボリュームの四半部においてジオメトリが存在するか否かについてのテストに迅速に使用可能である。具体的には、ドローン／ロボットのｘ、ｙおよびｚ位置を適切にスケーリングし（該当する回数、２で割る）、ジオメトリが存在するかについて問い合わせる３１０２ことで実行される（例えば、対応するビットマップのビットが、衝突の可能性を示す１であるか確認する）。衝突の可能性がある場合（例えば、「１」が見つかった場合）、ボリューム３１０１、３１００等に対するさらなる確認を実行して、ドローン／ロボットが移動可能か否かを定めてもよい。しかし、３１０２におけるボクセルが空（例えば「０」）である場合、ロボット／ドローンは同空間を解釈して、マップの大部分に亘って自由に移動するように、方向制御を操作する。

【0123】

本明細書において説明および図示されたシステムおよびソリューションの一部は、複数の要素を含むまたはそれに関連付けられるものとして説明されているが、明確に図示された、または説明された全ての要素が、本開示の各代替的な実装において利用されなくてもよい。さらに、本明細書において説明される要素の１または複数が、システム外に存在してもよい。別の例では、所定の要素が、その他の説明される要素および図示の実装において説明されないその他の要素の１または複数の内に、またはその一部分として含まれてもよい。さらに、所定の要素は、その他構成部材と組み合わされてよく、また本明細書において説明される目的に対して、代替的または追加的な目的に使用されてよい。

【0124】

さらに、上述の例は、非限定的で、所定の原理および特徴を示すことのみを目的としたものであることが理解されたい。したがって、本明細書において説明される概念の潜在的実施形態を必ずしも限定または制限するものではない。例えば、様々な異なる実施形態が、本明細書において説明される特徴および構成要素の様々な組み合わせを利用して実現できる。これは、本明細書において説明される構成要素の様々な実装を通じて実現される組み合わせを含む。その他実装、特徴、および詳細が、本明細書の内容から理解されよう。

【0125】

図３２から３７は、本明細書に開示された実施形態に従って使用され得る例示的なコンピュータアーキテクチャのブロック図である。実際、本明細書において説明されたコンピューティングデバイス、プロセッサ、ならびにシステムのその他のロジックおよび回路は、機能の全てまたは一部分を内蔵してよく、ソフトウェアおよび／またはハードウェア回路をサポートして当該機能を実装する。さらに、プロセッサおよびコンピューティングシステムについて公知の他のコンピュータアーキテクチャ設計が、本明細書に示された例を越えて使用されてもよい。一般に、本明細書に開示された実施形態に適したコンピュータアーキテクチャとしては、図３２から３７に示された構成が挙げられるが、これらに限定されない。

【0126】

図３２は、リンクを介してそれぞれのゲートウェイに結合されたそれぞれのモノのインターネット（ＩｏＴ）ネットワークのための例示的ドメイントポロジを示す。モノのインターネット（ＩｏＴ）は、多数のコンピューティングデバイスが、互いに相互接続され、またインターネットと相互接続されて、ネットワークの非常に下位レベルにおいて機能およびデータ収集を提供する概念である。本明細書で使用される場合、ＩｏＴデバイスは、他のＩｏＴデバイスおよびインターネット等のより広域のネットワークと通信している、とりわけ検知または制御等の機能を実行する半自律デバイスを含み得る。このようなＩｏＴデバイスには、ロジックおよびメモリが設けられ、上述のようなハッシュテーブルを実施し、使用してよい。

【0127】

多くの場合、ＩｏＴデバイスは、メモリ、サイズ、または機能が制限されているため、少数の大型デバイスと同程度のコストで多くの台数をデプロイできる。しかしながら、ＩｏＴデバイスは、スマートフォン、ラップトップ、タブレットもしくはＰＣまたは他のより大型デバイスであってもよい。さらに、ＩｏＴデバイスは、スマートフォンまたは他のコンピューティングデバイス上のアプリケーション等の仮想デバイスであってもよい。ＩｏＴデバイスは、データストレージ、プロセス制御等のために、ＩｏＴデバイスを他のＩｏＴデバイスおよびクラウドアプリケーションに結合するために使用されるＩｏＴゲートウェイを含み得る。

【0128】

ＩｏＴデバイスのネットワークとしては、配水システム、配電システム、パイプライン制御システム、プラント制御システム、光スイッチ、サーモスタット、ロック、カメラ、警報、モーションセンサ等の商業用デバイスおよび家庭用デバイスを挙げることができる。ＩｏＴデバイスは、例えば、システムを制御したりデータにアクセスしたりするために、リモートコンピュータ、サーバ、および他のシステム等を介してアクセス可能であり得る。

【0129】

インターネットや同様のネットワークの将来の発展は、非常に多数のＩｏＴデバイスを対象にし得る。したがって、本明細書で説明する技術において、将来のネットワーキングのための複数のイノベーションは、これらの層が、制約を受けずに拡大し、接続されたリソースを発見してアクセスできるようにし、接続されたリソースを隠蔽して区画化する機能をサポートするという必要性に対処する。任意の数のネットワークプロトコルおよび通信規格を使用することができ、各プロトコルおよび規格は特定の目的に対処するように設計されている。さらに、プロトコルは、位置、時間、または空間に関係なく動作する人間がアクセス可能なサービスをサポートするファブリックの一部である。これらのイノベーションには、サービス提供、ならびにハードウェアおよびソフトウェア等の関連するインフラストラクチャ、セキュリティ強化、サービスレベルおよびサービス提供契約で指定されているサービス品質（ＱｏＳ）条件に基づくサービスの提供が含まれる。理解されるように、図３２および図３３に示されるようなＩｏＴデバイスおよびネットワークの使用は、有線技術と無線技術との組み合わせを含む、異種ネットワークの接続における複数の新たな課題を提示する。

【0130】

図３２は、バックボーンリンク３２０２を介してそれぞれのゲートウェイ３２５４に接続したＩｏＴネットワーク３２５６、３２５８、３２６０、３２６２とともに、ＩｏＴデバイス３２０４を含む複数のモノのインターネット（ＩｏＴ）ネットワークで使用され得るドメイントポロジの簡略図を特に提供する。例えば、複数のＩｏＴデバイス３２０４は、ゲートウェイ３２５４と通信し、ゲートウェイ３２５４を介して互いに通信してよい。図面を簡単にするために、すべてのＩｏＴデバイス３２０４、または通信リンク（例えば、リンク３２１６、３２２２、３２２８、または３２３２）に符号が付けられているわけではない。バックボーンリンク３２０２は、光ネットワークを含む任意の数の有線技術または無線技術を含むことができ、ローカルエリアネットワーク（ＬＡＮ）の一部であってもよいし、広域ネットワーク（ＷＡＮ）の一部であってもよいし、インターネットの一部であってもよい。さらに、そのような通信リンクは、各種デバイスの相互接続を促進するＭＵＸｉｎｇ／ｄｅＭＵＸｉｎｇコンポーネントの使用を含む、ＩｏＴデバイス３２０４およびゲートウェイ３２５４の両者間の光学信号路を促進する。

【0131】

ネットワークトポロジは、Ｂｌｕｅｔｏｏｔｈ（登録商標）ｌｏｗ ｅｎｅｒｇｙ（ＢＬＥ）リンク３２２２を使用するネットワーク３２５６が設けられたメッシュネットワーク等、任意の数の種類のＩｏＴネットワークを含んでもよい。存在し得る他のＩｏＴネットワークとしては、ＩＥＥＥ８０２．１１（Ｗｉ－Ｆｉ（登録商標））リンク３２２８を介してＩｏＴデバイス３２０４と通信するために使用されるＷＬＡＮネットワーク３２５８、ＬＴＥ／ＬＴＥ－Ａ（４Ｇ）または５Ｇセルラーネットワークを介してＩｏＴデバイス３２０４と通信するために使用されるセルラーネットワーク３２６０、および例えば、ＬｏＲａ ａｌｌｉａｎｃｅによって公表されたＬｏＲａＷａｎ規格に準拠したＬＰＷＡネットワーク、またはインターネット技術特別調査委員会（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ））によって公表された規格に準拠したＬｏｗ Ｐｏｗｅｒ Ｗｉｄｅ－Ａｒｅａネットワーク（ＬＰＷＡＮ）ネットワークによるＩＰｖ６等のＬＰＷＡネットワーク３２６２が挙げられる。さらに、それぞれのＩｏＴネットワークは、ＬＴＥセルラーリンク、ＬＰＷＡリンク、またはＺｉｇｂｅｅ（登録商標）等のＩＥＥＥ８０２．１５．４規格に基づくリンク等の任意の数の通信リンクを使用して、外部ネットワークプロバイダ（例えば、ティア２またはティア３プロバイダ）と通信してよい。それぞれのＩｏＴネットワークは、各種ネットワークプロトコルおよびＣｏＡＰ（Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）等のインターネットアプリケーションプロトコルの使用により動作してよい。それぞれのＩｏＴネットワークは、リンクされたデバイスとネットワークのクラスタツリーを形成するリンクのチェーンを提供するコーディネータデバイスと統合されていてもよい。

【0132】

これらのＩｏＴネットワークの各々が、本明細書において説明されたもの等の新たな技術的特徴を生む機会を提供し得る。改良された技術およびネットワークにより、フォグデバイスまたはシステムとしてのＩｏＴネットワークの使用を含む、デバイスおよびネットワークの指数関数的成長が可能になり得る。そのような改良された技術の使用が広がるにつれて、ＩｏＴネットワークは、直接的な人間の介入を必要とすることのない、自己管理、機能の発展、および協調に向けて開発され得る。改良された技術により、ＩｏＴネットワークが集中型制御システムなしで機能できるようになり得る。本明細書で説明される改良された技術を使用して、現在の能力を大きく超えて、ネットワークを管理および運用する機能を自動化、強化し得る。

【0133】

一例では、バックボーンリンク３２０２を介する等、ＩｏＴデバイス３２０４間の通信は、認証、認可、および課金（ＡＡＡ）のための非集中型システムによって保護されてもよい。非集中型ＡＡＡシステムでは、分散型支払い、クレジット、監査、認可、および認証システムを相互接続された異種インフラストラクチャにわたって実装することができる。これにより、システムおよびネットワークは自律的運用に移行できる。この種の自律的運用では、機械は、人的資源を縮小し、他の機械ネットワークとパートナーシップを交渉することができる。これにより、概説され計画されたサービスレベル契約に対する相互目的とバランスのとれたサービス提供との実現が可能になるだけでなく、計量、測定、ならびにトレーサビリティおよび追跡可能性を提供するソリューションを実現できる。新たなサプライチェーン構造および方法の創出は、人間の関与なしに、多数のサービスを創出し、価値を取り出し、そして縮小することを可能にし得る。

【0134】

このようなＩｏＴネットワークは、音、光、電子トラフィック、顔およびパターンの認識、匂い、ならびに振動等のセンシング技術をＩｏＴデバイス間の自律的な組織に統合することによって、さらに強化され得る。感覚システムの統合は、契約上のサービス目的に対するサービス提供の体系的かつ自律的な通信および調整、オーケストレーションおよびサービスの質（ＱｏＳ）ベースのスウォーミングならびにリソースの融合を可能にし得る。ネットワークベースのリソース処理の個別の例としては、以下のものが挙げられる。

【0135】

メッシュネットワーク３２５６は、インラインでデータから情報への変換を実行するシステムによって強化することができる。例えば、マルチリンクネットワークを含む自己形成型の処理リソースのチェーンは、生データから情報への変換を効率的に分散させることができる。これにより、アセットとリソースとを区別する機能、および関連する管理の各々を提供することができる。さらに、データの完全性、品質、保証を改善し、データの信頼性のメトリックを提供するために、インフラストラクチャおよびリソースベースの信頼およびサービスインデックスの適切な成分を挿入することができる。

【0136】

ＷＬＡＮネットワーク３２５８は、例えば、規格の変換を実行して複数の規格に対応する接続を提供するシステムを使用し、異なるプロトコルを使用するＩｏＴデバイス３２０４が通信することを可能にし得る。さらなるシステムは、可視であるインターネットリソースおよび隠蔽されたインターネットリソースを含む複数の規格に対応するインフラストラクチャにわたってシームレスな相互接続を提供することができる。

【0137】

セルラーネットワーク３２６０における通信は、例えば、データをオフロードする、よりリモートのデバイスに通信を拡張する、またはその両方を行うシステムによって強化することができる。ＬＰＷＡネットワーク３２６２は、非インターネットプロトコル（ＩＰ）からＩＰへの相互接続、アドレス指定、および経路指定を実行するシステムを含み得る。さらに、各ＩｏＴデバイス３２０４は、当該デバイスでの広域通信に適した送受信機を備えてもよい。さらに、各ＩｏＴデバイス３２０４は、追加のプロトコルおよび周波数を使用した通信用の他の送受信機を備えてもよい。この点は、図３４および図３５に示されたＩｏＴ処理デバイスの通信環境およびハードウェアに関してさらに説明される。

【0138】

さらに、ＩｏＴデバイスのクラスタは、ｓ他のＩｏＴデバイスならびにクラウドネットワークと通信するように装備されてもよい。これは、ＩｏＴデバイスがデバイス間にアドホックネットワークを形成することを可能にし、それらが単一のデバイスとして機能することを可能にし、この単一のデバイスはフォグデバイスと呼ばれ得る。この構成は、図３３に関連して以下でさらに説明する。

【0139】

図３３は、クラウドコンピューティングネットワークのエッジでフォグデバイスとして動作するＩｏＴデバイス（デバイス３３０２）のメッシュネットワークと通信しているクラウドコンピューティングネットワークを示す。ＩｏＴデバイスのメッシュネットワークは、クラウド３３００のエッジで動作するフォグ３３２０と呼ばれ得る。図面を簡単にするために、すべてのＩｏＴデバイス３３０２に符号が付けられているわけではない。

【0140】

フォグ３３２０は、複数のＩｏＴデバイス３３０２が、例えば、無線リンク３３２２によって互いに通信している大規模に相互接続されたネットワークと考えられる。一例として、この相互接続ネットワークは、オープンコネクティビティファウンデーション（商標）（ＯＣＦ）によって発行された相互接続仕様を使用して促進されてもよい。この規格により、デバイスが互いを見つけ、相互接続のための通信を確立することを可能にする。例えば、とりわけ、ｏｐｔｉｍｉｚｅｄ ｌｉｎｋ ｓｔａｔｅ ｒｏｕｔｉｎｇ （ＯＬＳＲ）プロトコル、ｂｅｔｔｅｒ ａｐｐｒｏａｃｈ ｔｏ ｍｏｂｉｌｅ ａｄ－ｈｏｃ ｎｅｔｗｏｒｋｉｎｇ （Ｂ．Ａ．Ｔ．Ｍ．Ａ．Ｎ．）ルーティングプロトコル、またはＯＭＡ Ｌｉｇｈｔｗｅｉｇｈｔ Ｍ２Ｍ（ＬＷＭ２Ｍ）プロトコルを含む、他の相互接続プロトコルも使用することができる。

【0141】

この例においては、ゲートウェイ３３０４、データアグリゲータ３３２６、およびセンサ３３２８という３種類のＩｏＴデバイス３３０２が示されているが、ＩｏＴデバイス３３０２および機能の任意の組み合わせを使用してよい。ゲートウェイ３３０４は、クラウド３３００とフォグ３３２０との間の通信を提供するエッジデバイスであってもよく、さらに、動きデータ、流れデータ、温度データ等のセンサ３３２８から取得されたデータに対するバックエンドプロセス機能を提供してよい。データアグリゲータ３３２６は、任意の数のセンサ３３２８からデータを収集し、分析用にバックエンド処理機能を実施してよい。結果、生データ、またはその両方が、ゲートウェイ３３０４を通じてクラウド３３００に伝達されてもよい。センサ３３２８は、例えば、データの収集およびデータの処理の両方が可能なフルＩｏＴデバイス３３０２であってもよい。いくつかの例において、センサ３３２８は、例えば、データを収集するが、そのデータをデータアグリゲータ３３２６またはゲートウェイ３３０４に処理させる等、機能面で限定されていてもよい。

【0142】

任意のＩｏＴデバイス３３０２からの通信は、任意のＩｏＴデバイス３３０２間でゲートウェイ３３０４に到達するための便利な経路（例えば、最も便利な経路）に沿って伝えられ得る。これらのネットワークでは、複数の相互接続により十分な冗長性が提供され、複数のＩｏＴデバイス３３０２が失われても通信を維持できる。さらに、メッシュネットワークを使用することにより、非常に低電力な、またはインフラストラクチャから離れて位置しているＩｏＴデバイス３３０２の使用を可能にし得る。この別のＩｏＴデバイス３３０２に接続する範囲は、ゲートウェイ３３０４に接続する範囲よりもずっと小さい。

【0143】

これらのＩｏＴデバイス３３０２から提供されるフォグ３３２０は、サーバ３３０６等のクラウド３３００内のデバイスに、例えば、フォグデバイス等の、クラウド３３００のエッジに位置する単一のデバイスとして提供されてもよい。この例において、ｔｈｅ ａｌｅｒｔｓ ｃｏｍｉｎｇ ｆｒｏｍ ｔｈｅ フォグデバイスからの警告が、フォグ３３２０内で特定のＩｏＴデバイス３３０２からの発信であると識別されることなく送信され得る。このように、フォグ３３２０は、とりわけ、データ分析、データ集約、機械学習等の処理またはデータ集約型のタスクを実施するためのコンピューティングリソースおよびストレージリソースを提供する分散型プラットフォームと考えられる。

【0144】

いくつかの例において、ＩｏＴデバイス３３０２は、命令型プログラミングのスタイルを使用して、例えば各ＩｏＴデバイス３３０２が特定の機能および通信相手を有している状態で、構成され得る。しかしながら、フォグデバイスを形成するＩｏＴデバイス３３０２は、宣言型プログラミングのスタイルで構成され、ＩｏＴデバイス３３０２が、条件、クエリ、およびデバイス障害に応じて必要なリソースを決定するように、それらの動作および通信を再構成することを可能にし得る。一例として、ＩｏＴデバイス３３０２によって監視されている機器のサブセットの動作に関するクエリがサーバ３３０６に位置するユーザから送られた場合、フォグ３３２０デバイスは、特定のセンサ３３２８等のＩｏＴデバイス３３０２を、当該クエリに回答させるように選択し得る。これらのセンサ３３２８からのデータは、クエリに回答するために、フォグ３３２０デバイスによってサーバ３３０６へと送信される前に、センサ３３２８、データアグリゲータ３３２６、またはゲートウェイ３３０４の任意の組み合わせによって集約および分析されてもよい。この例において、フォグ３３２０内のＩｏＴデバイス３３０２は、流量センサまたは温度センサからのデータの追加等、クエリに基づいて使用されるセンサ３３２８を選択してよい。さらに、一部のＩｏＴデバイス３３０２が動作していない場合、フォグ３３２０デバイス内の他のＩｏＴデバイス３３０２が、利用可能であれば類似のデータを提供してよい。

【0145】

別の例では、上述の動作および機能は、電子処理システムの例示的形態のＩｏＴデバイス機械によって実施されてよく、その中では、例示的実施形態による、本明細書に記載の方法のいずれか１つを電子処理システムに実施させるように命令のセットまたはシーケンスが実行されてよい。この機械はＩｏＴデバイスまたはＩｏＴゲートウェイであってよく、これには、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、携帯情報端末（ＰＤＡ）、携帯電話もしくはスマートフォン、または当該機械が取るべき動作を規定する（シーケンシャルまたは別の）命令を実行可能な任意の機械の態様によって実施される機械を含む。さらに、上述の例では１つの機械のみが図示され説明されているが、当該機械は、本明細書に記載の方法のいずれか１または複数を実施するための一組の（または複数組の）命令を個別にまたは協働して実行する任意の機械の集合を含む形態を取り得る。さらに、プロセッサベースのシステムに対する上記例や同様の例は、本明細書に記載の方法のいずれか１または複数を実施するための命令を個別にまたは協働して実行するためにプロセッサ（例えば、コンピュータ）によって制御または動作される任意の一組の１または複数の機械を含む形態を取り得る。いくつかの実装において、１または複数のデバイスは、本明細書において説明される機能を実装し、タスクを実施するよう協働的に動作してよい。いくつかの例において、１または複数ホストデバイスは、データを供給し、命令を提供し、結果を集約し、またはその他の方法で促進する複数のデバイスによって提供された共同作業および機能を促進してよい。機能は、１つのデバイスによって実行された場合、そのデバイスに局所的な機能と考えられるが、１つの機械として動作している複数のデバイスの実装では、機能は集合的にこれらデバイスに局所的なものと考えられ、このデバイスの集合が、他の例示的実装の中でも、他の、リモート機械（１つのデバイスまたは集合デバイスとして実行）によって提供された結果を提供または消費し得る。

【0146】

例えば、図３４は、複数のモノのインターネット（ＩｏＴ）デバイスと通信しているクラウドコンピューティングネットワークまたはクラウド３４００の図を示している。クラウド３４００は、インターネットを表してよく、またはローカルエリアットワーク（ＬＡＮ）もしくは企業専用のネットワーク等の広域ネットワーク（ＷＡＮ）であってよい。ＩｏＴデバイスは、様々な組み合わせでグループ化された任意の数の異なる種類のデバイスを含んでよい。例えば、交通管制グループ３４０６は、街路沿いに ＩｏＴデバイスを含むことができる。これらのＩｏＴデバイスとしては、信号、交通流モニタ、カメラ、気象センサ等を挙げることができる。交通管制グループ３４０６、または他のサブグループは、有線リンクまたは無線リンク３４０８（ＬＰＷＡリンク等）、または光学リンク等を介して、クラウド３４００と通信することができる。さらに、有線または無線サブネットワーク３４１２は、ローカルエリアネットワーク、無線ローカルエリアネットワーク等を介して、ＩｏＴデバイスが互いに通信できるようにし得る。ＩｏＴデバイスは、クラウド３４００等のリモートロケーションと通信するために、ゲートウェイ３４１０または３４２８等の他のデバイスを使用してよく、ＩｏＴデバイスは、クラウド３４００またはゲートウェイ３４１０との通信を促進するために、１または複数サーバ３４３０を使用してもよい。例えば、１または複数サーバ３４３０は、ローカルエリアネットワークの中のローカルエッジクラウドまたはフォグ実装をサポートするために、中間ネットワークノードとして動作し得る。さらに、図示されたゲートウェイ３４２８は、クラウド３４００内のリソースの割り当ておよび使用が制約されている、または動的な各種ＩｏＴデバイス３４１４、３４２０、３４２４等と共に、クラウド－ゲートウェイ－多エッジデバイス構成において動作し得る。

【0147】

ＩｏＴデバイスの他のグループとしては、とりわけ、リモートの気象観測所３４１４、ローカル情報端末３４１６、警報システム３４１８、現金自動預払機３４２０、警報パネル３４２２、または緊急車両３４２４もしくは他の車両３４２６等の移動車両を挙げることができる。これらのＩｏＴデバイスの各々が、他のＩｏＴデバイスと、サーバ３４０４と、別のＩｏＴフォグデバイスもしくはシステム（ここでは図示しないが、図３３に示す）と、またはそれらの組み合わせと、通信することができる。ＩｏＴデバイスのグループは、各種居住、商業、工業環境（私的または公的環境の両方を含む）でデプロイされ得る。

【0148】

図３４からわかるように、多数のＩｏＴデバイスがクラウド３４００を介して通信することができる。これにより、異なるＩｏＴデバイスが自律的に他のデバイスに情報を要求または提供できるようになり得る。例えば、ＩｏＴデバイスのグループ（交通管制グループ３４０６）は、人間の介入なしに予測を提供することができる一群のリモートの気象観測所３４１４のグループからの現在の天気予報を要求することができる。さらに、現金自動預払機３４２０が、現在強盗に入られている最中であることを緊急車両３４２４に警告することもできる。緊急車両３４２４が現金自動預払機３４２０に向かって進む際に、緊急車両３４２４は交通管制グループ３４０６にアクセスして、例えば、緊急車両３４２４が交差点まで妨げられることなくアクセスするのに十分な時間、交差点において交差する交通を遮断するために信号灯を赤にすることによる、現場までの通行の認可を要求することができる。

【0149】

リモートの気象観測所３４１４または交通管制グループ３４０６等のＩｏＴデバイスのクラスタは、他のＩｏＴデバイスおよびクラウド３４００と通信するように装備されてもよい。これは、ＩｏＴデバイスがデバイス間にアドホックネットワークを形成することを可能にし、それらが単一のデバイスとして機能することを可能にし、この単一のデバイスはフォグデバイスまたはシステム （例えば、図３３を参照して上述したように）と呼ばれ得る。

【0150】

図３５は、本明細書において説明される技術を実装するための、ＩｏＴデバイス３５５０に存在し得るコンポーネントの一例のブロック図である。ＩｏＴデバイス３５５０は、この例に示す、または上述の開示で言及したコンポーネントの任意の組み合わせを備え得る。コンポーネントは、ＩＣ、その一部分、個別の電子デバイス、もしくは他のモジュール、ロジック、ハードウェア、ソフトウェア、ファームウェア、またはＩｏＴデバイス３５５０に適合されたそれらの組み合わせとして、あるいはより大きなシステムのシャーシ内に他の方法で組み込まれるコンポーネントとして実装され得る。図３５のブロック図は、ＩｏＴデバイス３５５０のコンポーネントの上位レベルの図を示すことを意図している。しかしながら、示されているコンポーネントのうちの一部は省略されてもよく、追加のコンポーネントが存在してもよく、示されているコンポーネントの異なる構成が他の実装形態において生じてもよい。

【0151】

ＩｏＴデバイス３５５０は、プロセッサ３５５２を備えることができ、プロセッサ３５５２は、マイクロプロセッサ、マルチコアプロセッサ、マルチスレッドプロセッサ、超低電圧プロセッサ、組み込みプロセッサ、または他の既知の処理要素とすることができる。プロセッサ３５５２は、ＩｎｔｅｌのＥｄｉｓｏｎ（商標）もしくはＧａｌｉｌｅｏ（商標）ＳｏＣボード等の、プロセッサ３５５２および他のコンポーネントが単一の集積回路または単一のパッケージに形成されるシステムオンチップ（ＳｏＣ）の一部であってもよい。一例として、プロセッサ３５５２は、Ｑｕａｒｋ（商標）、Ａｔｏｍ（商標）、ｉ３、ｉ５、ｉ７、もしくはＭＣＵクラスのプロセッサ等のＩｎｔｅｌ（登録商標）アーキテクチャコア（商標）ベースのプロセッサ、またはカリフォルニア州サンタクララのＩｎｔｅｌ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎから入手可能な、別のそのようなプロセッサを含み得る。しかしながら、カリフォルニア州サニーベールのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ、Ｉｎｃ．（ＡＭＤ）、カリフォルニア州サニーベールのＭＩＰＳ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．のＭＩＰＳベースの設計、ＡＲＭ Ｈｏｌｄｉｎｇｓ，Ｌｔｄ．からライセンス供与されたＡＲＭベースの設計、もしくはその顧客、またはそれらのライセンシーもしくは採用者から入手可能なもの等、他の任意の数のプロセッサが使用されてもよい。プロセッサは、Ａｐｐｌｅ（登録商標）Ｉｎｃ．製のＡ５～Ａ１０プロセッサ、Ｑｕａｌｃｏｍｍ（登録商標）Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．製のＳｎａｐｄｒａｇｏｎ（商標）プロセッサ、またはＴｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ，Ｉｎｃ．製のＯＭＡＰ（商標）プロセッサ等のユニットを含むことができる。

【0152】

プロセッサ３５５２は、相互接続部３５５６（例えば、バス）を介してシステムメモリ３５５４と通信することができる。所与の量のシステムメモリを提供するために、任意の数のメモリデバイスを使用することができる。例として、メモリは、ＤＤＲまたはモバイルＤＤＲ規格（例えば、ＬＰＤＤＲ、ＬＰＤＤＲ２、ＬＰＤＤＲ３またはＬＰＤＤＲ４）等の、Ｊｏｉｎｔ Ｅｌｅｃｔｒｏｎ Ｄｅｖｉｃｅｓ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｕｎｃｉｌ（ＪＥＤＥＣ）の設計に従うランダムアクセスメモリ（ＲＡＭ）であり得る。様々な実装において、個々のメモリデバイスは、シングルダイパッケージ（ＳＤＰ）、デュアルダイパッケージ（ＤＤＰ）、またはクワッドダイパッケージ（Ｑ１７Ｐ）等の任意の数の異なるパッケージタイプであってもよい。これらのデバイスは、いくつかの例において、薄型化の解決策を提供するために、マザーボード上に直接はんだ付けされる場合もある一方で、他の実施形態では、所与のコネクタによりマザーボードに順に結合される１または複数のメモリモジュールとして構成される。他の種類のメモリモジュール、例えば、ｍｉｃｒｏＤＩＭＭまたはＭｉｎｉＤＩＭＭを含むがこれらに限定されない、異なる種類のデュアルインラインメモリモジュール（ＤＩＭＭ）等、任意の数の他のメモリ実装を使用することができる。

【0153】

データ、アプリケーション、オペレーティングシステム等の情報の永続的ストレージを提供するために、ストレージ３５５８も相互接続部３５５６を介してプロセッサ３５５２に結合されてもよい。ストレージ３５５８の一例として、ソリッドステートドライブ（ＳＳＤＤ）を介して実装されてもよい。ストレージ３５５８に使用することができる他のデバイスとしては、ＳＤカード、マイクロＳＤカード、ｘＤピクチャカード等のフラッシュメモリカード、およびＵＳＢフラッシュドライブが挙げられる。低電力実装では、ストレージ３５５８は、プロセッサ３５５２に関連するオンダイメモリまたはレジスタであり得る。しかしながら、いくつかの例において、ストレージ３５５８は、マイクロハードディスクドライブ（ＨＤＤ）を使用して実装され得る。さらに、ストレージ３５５８には、説明された技術に加えて、またはその代わりに、とりわけ、抵抗変化メモリ、相変化メモリ、ホログラフィックメモリ、または化学メモリ等の任意の数の新しい技術を使用することができる。

【0154】

コンポーネントは、相互接続部３５５６を介して通信することができる。相互接続部３５５６は、業界標準アーキテクチャ（ＩＳＡ）、拡張ＩＳＡ（ＥＩＳＡ）、周辺機器相互接続（ＰＣＩ）、拡張周辺機器相互接続（ＰＣＩｘ）、ＰＣＩエクスプレス（ＰＣＩｅ）、または他の任意の数の技術を含む、任意の数の技術を含み得る。相互接続部３５５６は、例えばＳｏＣベースのシステムで使用される、専用バスであってもよい。とりわけ、Ｉ２Ｃインターフェース、ＳＰＩインターフェース、ポイントツーポイントインターフェース、および電力バス等、他のバスシステムが含まれてもよい。

【0155】

相互接続部３５５６は、他のメッシュデバイス３５６４と通信するために、プロセッサ３５５２をメッシュ送受信機３５６２に結合することができる。メッシュ送受信機３５６２は、とりわけ、ＩＥＥＥ ８０２．１５．４規格下の、Ｂｌｕｅｔｏｏｔｈ（登録商標）Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐによって規定されるＢｌｕｅｔｏｏｔｈ（登録商標）ｌｏｗ ｅｎｅｒｇｙ（ＢＬＥ）規格を使用する、またはＺｉｇＢｅｅ（登録商標）規格を使用する、２．４ギガヘルツ（ＧＨｚ）伝送等の任意の数の周波数およびプロトコルを使用することができる。特定の無線通信プロトコル用に構成された任意の数の無線機をメッシュデバイス３５６４への接続に使用することができる。例えば、ＷＬＡＮユニットは、米国電気電子技術者協会（ＩＥＥＥ）８０２．１１規格に従ってＷｉ－Ｆｉ（商標）通信を実装するために使用され得る。さらに、例えばセルラーまたは他の無線広域プロトコルによる、無線広域通信は、ＷＷＡＮユニットを介して行われ得る。

【0156】

メッシュ送受信機３５６２は、異なる距離範囲で通信するために複数の規格または無線機を使用して通信することができる。例えば、ＩｏＴデバイス３５５０は、電力を節約するために、ＢＬＥに基づくローカル送受信機または別の低電力無線機を使用して、近接したデバイスと、例えば約１０メートル以内で通信することができる。より遠い、例えば約５０メートル以内のメッシュデバイス３５６４は、ＺｉｇＢｅｅまたは他の中間電力無線機を介して到達することができる。双方の通信技法が、異なる電力レベルで単一の無線機を介して行われてもよいし、例えばＢＬＥを使用するローカル送受信機およびＺｉｇＢｅｅを使用する別個のメッシュ送受信機等の別個の送受信機を介して行われてもよい。

【0157】

無線ネットワーク送受信機３５６６が、ローカルエリアネットワークプロトコルまたは広域ネットワークプロトコルを介して、クラウド３５００内のデバイスまたはサービスと通信するために備えられてよい。無線ネットワーク送受信機３５６６は、とりわけ、ＩＥＥＥ ８０２．１５．４、またはＩＥＥＥ ８０２．１５．４ｇ規格に従うＬＰＷＡ送受信機であり得る。ＩｏＴデバイス３５５０は、ＳｅｍｔｅｃｈおよびＬｏＲａ Ａｌｌｉａｎｃｅによって開発されたＬｏＲａＷＡＮ（商標）（Ｌｏｎｇ Ｒａｎｇｅ Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を使用して広域にわたって通信することができる。本明細書で説明される技法はこれらの技術に限定されず、Ｓｉｇｆｏｘ等の長距離低帯域幅通信を実装する任意の数の他のクラウド送受信機、および他の技術と共に使用され得る。さらに、ＩＥＥＥ ８０２．１５．４ｅ仕様において説明されているタイムスロットチャネルホッピング等の他の通信技法を使用することもできる。

【0158】

本明細書で説明するように、メッシュ送受信機３５６２および無線ネットワーク送受信機３５６６に関して言及したシステムに加えて、任意の数の他の無線通信およびプロトコルを使用することができる。例えば、無線送受信機３５６２および３５６６は、ＬＴＥ、または高速通信を実施するためにスペクトラム拡散（ＳＰＡ／ＳＡＳ）通信を使用する他のセルラー送受信機を含むことができる。さらに、中速通信用およびネットワーク通信の提供用のＷｉ－Ｆｉ（登録商標）ネットワーク等、任意の数の他のプロトコルを使用することができる。

【0159】

無線送受信機３５６２および３５６６は、任意の数の３ＧＰＰ（第３世代パートナーシッププロジェクト）仕様、特に、とりわけ、ロングタームエボリューション（ＬＴＥ）、ロングタームエボリューション－アドバンスト（ＬＴＥ－Ａ）、またはロングタームエボリューション－アドバンストプロ（ＬＴＥ－Ａ Ｐｒｏ）と互換性のある無線機を含むことができる。他の任意の数の固定、モバイル、または衛星通信技術および規格と互換性のある無線機を選択することができることに留意されたい。これらは、例えば、任意のセルラー方式広域無線通信技術を含むことができ、当該技術は、例えば、第５世代（５Ｇ）通信システム、汎欧州デジタル移動電話方式（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）（ＧＳＭ（登録商標））無線通信技術、汎用パケット無線サービス（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）（ＧＰＲＳ）無線通信技術、または進化型高速拡張データレート（Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅｓ ｆｏｒ ＧＳＭ（登録商標） Ｅｖｏｌｕｔｉｏｎ）（ＥＤＧＥ）無線通信技術、ＵＭＴＳ（ユニバーサル移動体通信システム）通信技術を含み得、さらに上記の規格について、無線ネットワーク送受信機３５６６用に任意の数の衛星アップリンク技術を使用することができ、とりわけ、例えば、ｒａｄｉｏｓ ｃｏｍｐｌｉａｎｔ ｗｉｔｈ ｓｔａｎｄａｒｄｓ ｉｓｓｕｅｄ ｂｙ ｔｈｅ ＩＴＵ（国際電気通信連合）またはＥＴＳＩ（欧州電気通信規格協会）によって発行された規格に準拠した無線機を含む。よって、本明細書で提供される例は、既存のものとまだ策定されていないものとの両方の、他の様々な通信技術に適用可能であると理解されたい。

【0160】

ネットワークインターフェースコントローラ（ＮＩＣ）３５６８は、クラウド３５００またはメッシュデバイス３５６４等の他のデバイスへの有線通信を提供するために備えられてよい。有線通信は、イーサネット（登録商標）接続を提供してもよいし、とりわけ、コントローラエリアネットワーク（ＣＡＮ）、ローカル相互接続ネットワーク（ＬＩＮ）、ＤｅｖｉｃｅＮｅｔ、ＣｏｎｔｒｏｌＮｅｔ、Ｄａｔａ Ｈｉｇｈｗａｙ＋、ＰＲＯＦＩＢＵＳ、またはＰＲＯＦＩＮＥＴ等の他の種類のネットワークに基づいてもよい。第２のネットワークへの接続を可能にするために追加のＮＩＣ３５６８、例えばイーサネット（登録商標）を介してクラウドに通信を提供するＮＩＣ３５６８、および他の種類のネットワークを介して他のデバイスに通信を提供する第２のＮＩＣ３５６８が含まれてもよい。

【0161】

相互接続部３５５６は、プロセッサ３５５２を、外部デバイスまたはサブシステムに接続するために使用される外部インターフェース３５７０に結合することができる。外部デバイスとしては、加速度計、液位センサ、流量センサ、光学センサ、カメラセンサ、温度センサ、全地球測位システム（ＧＰＳ）センサ、圧力センサ、気圧センサ等のセンサ３５７２を挙げることができる。外部インターフェース３５７０はさらに、ＩｏＴデバイス３５５０を、電源スイッチ、バルブアクチュエータ、可聴音生成器、視覚的警告デバイス等のアクチュエータ３５７４に接続するために使用されてもよい。

【0162】

一部の任意の例では、様々な入出力（Ｉ／Ｏ）デバイスが、ＩｏＴデバイス３５５０内に存在してもよいし、ＩｏＴデバイス３５５０に接続されてもよい。例えば、ディスプレイまたはその他の出力デバイス３５８４が、センサの読み取り値またはアクチュエータの位置等の情報を示すために含まれてもよい。タッチスクリーンまたはキーパッド等の入力デバイス３５８６が入力を受け入れるために含まれてもよい。出力デバイス３５８４は、バイナリ状態表示器（例えば、ＬＥＤ）およびマルチキャラクタ視覚的出力等の単純な視覚的出力、またはＩｏＴデバイス３５５０の動作から生成または作成された文字、グラフィックス、マルチメディアオブジェクト等の出力を伴うディスプレイスクリーン（例えば、ＬＣＤスクリーン）等のより複雑な出力を含む、任意の数の聴覚的または視覚的表示装置の形態を含み得る。

【0163】

バッテリ３５７６は、ＩｏＴデバイス３５５０に電力を供給し得るが、ＩｏＴデバイス３５５０が固定位置に取り付けられる例では、送配電網に結合された電源を有し得る。バッテリ３５７６は、リチウムイオン電池、または亜鉛空気電池、アルミニウム空気電池、リチウム空気電池等の金属空気電池等とすることができる。

【0164】

バッテリモニタ／充電器３５７８は、バッテリ３５７６の充電状態（ＳｏＣｈ）を追跡するためにＩｏＴデバイス３５５０に備えられ得る。バッテリモニタ／充電器３５７８は、バッテリ３５７６の他のパラメータを監視して、バッテリ３５７６の劣化状態（ｓｔａｔｅ ｏｆ ｈｅａｌｔｈ）（ＳｏＨ）および作動状態（ＳｏＦ）等の障害予測を提供するために使用され得る。バッテリモニタ／充電器３５７８は、Ｌｉｎｅａｒ Ｔｅｃｈｎｏｌｏｇｉｅｓ製のＬＴＣ４０２０もしくはＬＴＣ２９９０、アリゾナ州フェニックスのＯＮ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ製のＡＤＴ７４８８Ａ、またはテキサス州ダラスのＴｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ製のＵＣＤ９０ｘｘｘファミリのＩＣ等のバッテリモニタ集積回路を含むことができる。バッテリモニタ／充電器３５７８は、バッテリ３５７６に関する情報を、相互接続部３５５６を介してプロセッサ３５５２に通信することができる。バッテリモニタ／充電器３５７８はまた、プロセッサ３５５２がバッテリ３５７６の電圧またはバッテリ３５７６からの電流を直接監視できるようにするアナログ－デジタル（ＡＤＣ）変換器を含み得る。バッテリパラメータは、送信周波数、メッシュネットワーク動作、センシング周波数等、ＩｏＴデバイス３５５０が実行することができる動作を決定するために使用され得る。

【0165】

電力ブロック３５８０、または送配電網に結合された他の電源が、バッテリ３５７６を充電するためにバッテリモニタ／充電器３５７８と結合されてもよい。いくつかの例において、電力ブロック３５８０は、例えばＩｏＴデバイス３５５０内のループアンテナを介して、無線で電力を取得するために無線給電レシーバと置き換えられ得る。とりわけ、カリフォルニア州ミルピタスのＬｉｎｅａｒ Ｔｅｃｈｎｏｌｏｇｉｅｓ製のＬＴＣ４０２０チップ等の無線バッテリ充電回路をバッテリモニタ／充電器３５７８に含めることができる。選択される具体的な充電回路は、バッテリ３５７６のサイズ、従って必要とされる電流に依存する。充電は、とりわけ、Ａｉｒｆｕｅｌ Ａｌｌｉａｎｃｅによって公表されたＡｉｒｆｕｅｌ規格、Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒ Ｃｏｎｓｏｒｔｉｕｍによって公表されたＱｉ無線充電規格、またはＡｌｌｉａｎｃｅ ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒによって公表されたＲｅｚｅｎｃｅ充電規格を使用して実行することができる。

【0166】

ストレージ３５５８は、本明細書で説明される技術を実装するためのソフトウェア、ファームウェアまたはハードウェアコマンドの形態の命令３５８２を含み得る。このような命令３５８２がメモリ３５５４およびストレージ３５５８においてコードブロックとして示されているが、コードブロックのうちのいずれも、例えば特定用途向け集積回路（ＡＳＩＣ）に組み込まれる等、ハードワイヤード回路で置き換えられ得ることが理解されよう。

【0167】

一例において、メモリ３５５４、ストレージ３５５８、またはプロセッサ３５５２を介して提供される命令３５８２は、プロセッサ３５５２に対して、ＩｏＴデバイス３５５０内で電子的動作を実施するように指示するコードを含む非一時的機械可読媒体３５６０として実施されてよい。プロセッサ３５５２は、相互接続部３５５６を介して非一時的機械可読媒体３５６０にアクセスしてよい。例えば、非一時的機械可読媒体３５６０は、図３５のストレージ３５５８について説明されたデバイスとして実施されてよく、または光ディスク、フラッシュドライブ、または任意の数の他のハードウェアデバイス等の特定のストレージユニットを含んでよい。非一時的機械可読媒体３５６０は、プロセッサ３５５２に対して、例えば、上述の動作および機能のフローチャートおよびブロック図に関して説明されたような、特定のシーケンスまたは動作の流れを実施するように指示する命令を含んでよい。

【0168】

図３６は、実施形態によるプロセッサの例示である。プロセッサ３６００は、上述の実装に関連して用いられ得るハードウェアデバイスの種類の一例である。プロセッサ３６００は、任意の種類のプロセッサであってよく、マイクロプロセッサ、組み込みプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、マルチコアプロセッサ、シングルコアプロセッサ、またはコードを実行する他のデバイス等がある。図３６には１つのプロセッサ３６００だけが例示されているが、これに代えて、処理要素が、図３６に例示されたプロセッサ３６００を複数含んでよい。プロセッサ３６００はシングルスレッドコアであってよく、少なくとも１つの実施形態では、プロセッサ３６００は、コア毎に複数のハードウェアスレッドコンテキスト（または「論理プロセッサ」）を含むことができるという点で、マルチスレッドであってよい。

【0169】

図３６は、一実施形態による、プロセッサ３６００に結合されたメモリ３６０２も例示する。メモリ３６０２は、当業者に知られているか、またはそうでなければ当業者が利用可能な、幅広い種類のメモリ（メモリ階層の様々な層を含む）のうちいずれかであってよい。そのようなメモリ要素には、限定されないが、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）の論理ブロック、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭ）、および電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）が含まれてよい。

【0170】

プロセッサ３６００は、本明細書で詳述されるアルゴリズム、プロセス、または動作と関連した任意の種類の命令を実行することができる。一般に、プロセッサ３６００は要素または項目（例えば、データ）を、ある状態または物から別の状態または物に変換することができる。

【0171】

プロセッサ３６００により実行される１または複数の命令であり得るコード３６０４は、メモリ３６０２に記憶されてよく、あるいは、ソフトウェア、ハードウェア、ファームウェア、もしくはこれらの任意の好適な組み合わせに、または、必要に応じて特定のニーズに基づき、任意の他の内部もしくは外部のコンポーネント、デバイス、要素、もしくはオブジェクトに記憶されてよい。一例において、プロセッサ３６００は、コード３６０４により示される命令のプログラムシーケンスに従うことができる。各命令はフロントエンドロジック３６０６に入り、１または複数のデコーダ３６０８により処理される。デコーダはその出力として、あらかじめ定義されたフォーマットの固定幅マイクロオペレーション等のマイクロオペレーションを生成してよく、または他の命令、マイクロ命令、もしくは元のコード命令を反映する制御信号を生成してよい。フロントエンドロジック３６０６は、レジスタリネーミングロジック３６１０およびスケジューリングロジック３６１２も含んでよく、これらは一般に、リソースを割り当て、実行命令に対応する演算をキューに入れる。

【0172】

プロセッサ３６００は、一組の実行ユニット３６１６ａ、３６１６ｂ、３６１６ｎ等を有する実行ロジック３６１４も含み得る。いくつかの実施形態は、特定の機能または機能のセットに専用の複数の実行ユニットを含んでよい。他の実施形態では、１つの実行ユニットだけ、または特定の機能を実行することができる１つの実行ユニットを含んでよい。実行ロジック３６１４は、コード命令により指定された演算を実行する。

【0173】

コード命令により指定された演算の実行が完了した後、バックエンドロジック３６１８はコード３６０４の命令をリタイアすることができる。１つの実施形態において、プロセッサ３６００はアウトオブオーダ実行を可能にするが、命令のインオーダリタイアメントを必要とする。リタイアメントロジック３６２０は、様々な既知の形態（例えば、リオーダバッファ等）を取ってよい。このように、プロセッサ３６００は、コード３６０４の実行中に、少なくともデコーダ、レジスタリネーミングロジック３６１０により利用されるハードウェアレジスタおよびテーブル、並びに実行ロジック３６１４により修正される任意のレジスタ（不図示）によって生成される出力に関して変換される。

【0174】

図３６には示されていないが、処理要素が、プロセッサ３６００を搭載したチップ上に他の要素を含んでよい。例えば、処理要素が、プロセッサ３６００と共にメモリ制御ロジックを含んでよい。処理要素は、Ｉ／Ｏ制御ロジックを含んでよく、および／または、メモリ制御ロジックと統合されたＩ／Ｏ制御ロジックを含んでよい。処理要素は、１または複数のキャッシュを含んでもよい。いくつかの実施形態において、不揮発性メモリ（フラッシュメモリまたはヒューズ等）も、プロセッサ３６００を搭載したチップ上に含まれてよい。

【0175】

図３７は、実施形態による、ポイントツーポイント（ＰｔＰ）構成で配置されたコンピューティングシステム３７００を示す。特に、図３７は、プロセッサ、メモリ、および入力／出力デバイスが複数のポイントツーポイントインターフェースで相互接続されたシステムを示す。一般的に、本明細書において説明されるコンピューティングシステムの１または複数が、コンピューティングシステム３７００と同一または同様に構成されてよい。

【0176】

プロセッサ３７７０および３７８０は各々、メモリ要素３７３２および３７３４と通信するために、集積メモリコントローラロジック（ＭＣ）３７７２および３７８２を含んでもよい。別の実施形態では、メモリコントローラロジック３７７２および３７８２は、プロセッサ３７７０および３７８０とは分かれている個別のロジックであってよい。メモリ要素３７３２および／または３７３４は、プロセッサ３７７０および３７８０が本明細書に概説された動作および機能を実行するために使用する各種データを記憶してよい。

【0177】

プロセッサ３７７０および３７８０は、他の図に関連して説明したような、任意の種類のプロセッサであってよい。プロセッサ３７７０および３７８０は、ポイントツーポイントインターフェース回路３７７８および３７８８をそれぞれ使用して、ポイントツーポイント（ＰｔＰ）インターフェース３７５０を介してデータを交換してよい。プロセッサ３７７０および３７８０は各々、ポイントツーポイントインターフェース回路３７７６、３７８６、３７９４、および３７９８を使用して、個々のポイントツーポイントインターフェース３７５２および３７５４を介して、チップセット３７９０とデータを交換してよい。チップセット３７９０は、ＰｔＰインターフェース回路であり得るインターフェース回路３７９２を使用して、高性能グラフィックスインターフェース３７３９を介して、高性能グラフィックス回路３７３８とデータを交換してもよい。別の実施形態では、図３７に図示された任意のまたは全てのＰｔＰリンクは、ＰｔＰリンクというよりもマルチドロップパスとして実施され得る。

【0178】

チップセット３７９０は、インターフェース回路３７９６を介して、バス３７２０と通信状態にあってよい。バス３７２０は、バスブリッジ３７１８およびＩ／Ｏデバイス３７１６等、バス３７２０によって通信する１または複数デバイスを有してよい。バス３７１０を介して、バスブリッジ３７１８は、ユーザインターフェース３７１２（キーボード、マウス、タッチスクリーン、またはその他の入力デバイス等）、通信デバイス３７２６（モデム、ネットワークインターフェースデバイス、またはコンピュータネットワーク３７６０を通じて通信し得るその他の種類の通信デバイス等）、オーディオＩ／Ｏデバイス３７１４、および／またはデータストレージデバイス３７２８等の、他のデバイスと通信状態にあってよい。データストレージデバイス３７２８は、プロセッサ３７７０および／または３７８０によって実行され得るコード３７３０を記憶してよい。別の実施形態では、バスアーキテクチャの任意の部分は、１または複数ＰｔＰリンクで実装され得る。

【0179】

図３７に示すコンピュータシステムは、本明細書に記載の各種実施形態を実装するために利用し得るコンピューティングシステムの実施形態を概略的に図示したものである。図３７に示すシステムの各種コンポーネントは、システムオンチップ（ＳｏＣ）アーキテクチャ、または本明細書に提示された例および実施の機能および特徴を実現可能な任意の他の適切な構成と組み合わされてよいことが理解されよう。

【0180】

さらなる例では、機械可読媒体は、機械により実行するための命令を記憶、符号化、もしくは記録することができ、機械に本開示の方法のいずれか１または複数を実施させ、またはそのような命令によって利用される、もしくはこれに関連付けられるデータ構造を記憶、符号化、もしくは記録することができる任意の有形の媒体も含む。したがって、「機械可読媒体」は、固体メモリ、光学および磁気メディアを含んでよいが、これらに限定されない。機械可読媒体の特定の例としては、半導体メモリデバイス（例えば、電気的プログラマブルリードオンリメモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ））、フラッシュメモリデバイス、内部ハードディスクおよびリムーバブルディスク等の磁気ディスク、光磁気ディスク、ＣＤ－ＲＯＭおよびＤＶＤ－ＲＯＭディスクを含むがこれらに限定されない不揮発性メモリが挙げられる。機械可読媒体によって実施される命令はさらに、複数の転送プロトコルのいずれか１つ（例えば、ＨＴＴＰ）を利用するネットワークインターフェースデバイスを介して、伝送媒体を使用する通信ネットワークを通じて送信または受信され得る。

【0181】

本明細書において説明される機能的ユニットまたは能力は、これらの実装の独立性を特に強調するために、コンポーネントまたはモジュールとして言及または符号で示され得ることを理解されたい。そのようなコンポーネントは、任意の数のソフトウェアまたはハードウェアの形態によって実施されてよい。例えば、コンポーネントまたはモジュールは、カスタムの超大規模集積（ＶＬＳＩ）回路もしくはゲートアレイ、またはロジックチップ、トランジスタ、もしくはその他の個別のコンポーネント等の既成の半導体装置を備えるハードウェア回路として実装されてよい。コンポーネントまたはモジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイス等のプログラマブルハードウェアデバイスに実装されてもよい。コンポーネントまたはモジュールは、各種プロセッサによって実行されるためのソフトウェアに実装されてもよい。例えば、実行可能コードの識別されたコンポーネントまたはモジュールは、例えば、オブジェクト、プロシージャ、または機能として組織され得る、コンピュータ命令の１または複数の物理的または論理的ブロックを含んでよい。ただし、識別されたコンポーネントまたはモジュールの実行ファイルは、物理的に同じ場所に配置される必要はなく、異なる場所に記憶された異なる命令を含んでよく、これらの命令は、論理的に統合された場合、コンポーネントまたはモジュールを含み、当該コンポーネントまたはモジュールの上述の目的を実現し得る。

【0182】

実際、実行可能コードのコンポーネントまたはモジュールは、１つの命令または多数の命令であってよく、異なるプログラムにおける複数の異なるコードセグメントに分散され、複数のメモリデバイスまたは処理システムにまたがっていてもよい。特に、上述のプロセスの一部の態様（コードの再書き込みおよびコードの分析等）は、コードがデプロイされている場所（例えば、センサまたはロボットに埋め込まれたコンピュータ）とは異なる処理システム（例えば、データセンター内のコンピュータ）上で実施されてよい。同様に、演算データは、本明細書ではコンポーネントまたはモジュール内で識別および例示され、任意の適切な形態で実施され、任意の適切な種類のデータ構造内に組織され得る。演算データは、１つのデータセットとして収集されても、または、異なるストレージデバイスを含む異なる場所に分散されてもよく、少なくとも部分的にシステムまたはネットワーク上の単なる電子信号として存在してもよい。コンポーネントまたはモジュールは、上述の機能を実施可能なエージェントを含み、パッシブまたはアクティブであってよい。

【0183】

ここで説明されている方法、システム、およびデバイス実施形態の追加の例として、以下の非限定的な構成が挙げられる。以下の非限定的な例の各々は、独立して成立してもよいし、以下に示す他の例のいずれか１または複数または本開示全体のいずれかとの任意の並び替えまたは組み合わせで組み合わせてもよい。

【0184】

本開示は、特定の実施および一般的に関連付けられた方法という点で説明されているが、これらの実施および方法の変更および並び替えも当業者には自明であろう。例えば、本明細書ににおいて説明された動作は、説明されたものとは異なる順序で実施でき、それによっても所望の結果を実現できる。一例として、添付の図面に示されたプロセスは、所望の結果を実現するために必ずしも図示された特定の順序または順番を要するものではない。ある実施においては、同時処理や並行処理が有利となり得る。さらに、他のユーザインターフェースレイアウトおよび機能にも対応できる。その他の変形も、以下の特許請求の範囲内に包含される。

【0185】

本明細書は多くの特定の実施の詳細を含んでいるが、これらは任意の発明の範囲や請求される内容を限定するものと解釈されるものではなく、特定の発明の特定の実施形態に固有の特徴の記載として解釈されるべきである。個別の実施形態の文脈で本明細書において説明されたある特徴を、１つの実施形態との組み合わせで実施することもできる。逆に、１つの実施形態の文脈で説明された各種特徴を、複数の実施形態において別々に、または任意の適切な下位組み合わせで実施することもできる。さらに、特徴はある組み合わせで動作するものとして上述され、そのように元々請求され得るが、請求された組み合わせにおける１または複数の特徴は、いくつかの例においてはその組み合わせから除外され、請求された組み合わせを下位組み合わせまたは下位組み合わせの変形に適用し得る。

【0186】

同様に、図面において動作は特定の順序で示されているが、この動作が図示された特定の順序または順序を要するものとして理解されるべきではなく、または、所望の結果を実現するために図示された全ての動作が実施されると理解されるべきではない。ある状況では、同時処理や並行処理が有利となり得る。さらに、上述の実施形態の各種システムコンポーネントの区分は、全ての実施形態においてそのように区分される必要があると理解されるべきではなく、説明されたプログラムコンポーネントおよびシステムが、全体として１つのソフトウェア製品に統合されるか、または複数のソフトウェア製品にパッケージされることができると理解すべきである。

【0187】

以下の例が本明細書による実施形態に関連する。例１は、命令を記憶する、非一時的な機械によりアクセス可能な記憶媒体であって、命令は、機械上で実行された場合、機械に三次元（３Ｄ）ボリュームを表すボリュームデータを生成する手順であって、ボリュームは一組のボクセルを含み、ボクセルの少なくとも１つは、３Ｄジオメトリで占有され、ボリュームデータは、一組のボクセルの各々について、ボクセルそれぞれが占有されているかを特定する、手順と、ハッシュ化アルゴリズムに応じて、ボリュームデータに対するインデックス値を生成する手順であって、一組のボクセル内のボクセルの特定のサブセットを表す、ボリュームデータの特定の部分に対するインデックス値は、ボクセルの特定のサブセットに関連した、ｘ座標、ｙ座標およびｚ座標の値の組み合わせに基づいて生成され、ボリュームに対応する辺長値に基づいて、特定の部分に対するインデックス値がさらに生成される、手順と、ボリュームデータの特定の部分を、ハッシュテーブルのエントリ内に記憶する手順であって、エントリは、特定の部分に対するインデックス値に基づくアドレスを有する、手順と、を実行させる、記憶媒体である。

【0188】

例２は、例１の主題を含み、ｘ座標、ｙ座標およびｚ座標の値の組み合わせは、ｘ座標、ｙ座標およびｚ座標の値の加重和を含み、ｘ座標、ｙ座標およびｚ座標の内の１または複数が、辺長値に基づいて重み付けされる。

【0189】

例３は、例２の主題を含み、インデックス値は、式ｉｎｄｅｘ＝（ＩＤ_ｚ×（ＳＬ^２）＋ＩＤ_ｙ×（ＳＬ）＋ＩＤ_ｘ）、に応じて生成され、式中、ＩＤ_ｚはｚ座標の値であり、ＩＤ_ｙはｙ座標の値であり、ＩＤ_ｘはｘ座標の値であり、ＳＬは辺長値である。

【0190】

例４は、例２または３のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、ボリュームのｘ座標、ｙ座標およびｚ座標の各々の内部の、占有ボリュームの相対密度に基づいて、辺長値を使用してｘ座標、ｙ座標およびｚ座標に適用される重みを決定する手順を実行させる。

【0191】

例５は、例１から４のいずれか１つの主題を含み、ボリュームは、一組のボクセルブロックに論理的に細分化され、ボクセルブロックはそれぞれ、各ボクセルサブセットの、サブボリュームを含み、特定のサブセットボクセルは、一組のボクセルブロックの内の特定の１つを含む。

【0192】

例６は、例５の主題を含み、ハッシュテーブル内の各エントリは、一組のボクセルブロックのそれぞれにおける各ボクセルを記述したボリュームデータを含むようなサイズである。

【0193】

例７は、例６の主題を含み、各ボクセルブロックは、複数のボクセルを含み、ハッシュテーブルエントリは各々、対応するボクセルが占有されているかと特定するために、ボクセルブロックにおけるボクセル毎に少なくとも１つのビットを含む。

【0194】

例８は、例７の主題を含み、各ハッシュテーブルエントリは、対応するボクセルブロックにおいて、ボクセル毎に２ビットを含むようなサイズである。

【0195】

例９は、例１から８のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、エントリのアドレスを計算し、ハッシュテーブル内のエントリのアドレスは、インデックス値の剰余に基づいて計算される手順を実行させる。

【0196】

例１０は、例１から９のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、ハッシュテーブル内のエントリで衝突があるかを検出する手順と、
衝突が検出された場合、ハッシュテーブルに関連付けられた衝突管理方式を利用する手順と、を実行させる。

【0197】

例１１は、例１から１０のいずれか１つの主題を含み、ハッシュ化アルゴリズムは大きな素数を使用しない。

【0198】

例１２は、命令を記憶する、非一時的な機械によりアクセス可能な記憶媒体であって、命令は、機械上で実行された場合、機械にボリューム内の特定のボクセルを特定する手順と、コンピュータメモリ内に記憶されたハッシュテーブルにアクセスする手順と、特定のボクセルに関連付けられた、ボリューム内のｘ座標、ｙ座標およびｚ座標を決定する手順と、ハッシュ化アルゴリズムに応じて、そしてｘ座標、ｙ座標およびｚ座標に基づいて、特定のボクセルに関連付けられたインデックス値を決定する手順であって、インデックス値は、ボリュームに対応する辺長値に基づく、ｘ座標、ｙ座標およびｚ座標の加重値の総和を通じて、ハッシュ化アルゴリズムに応じて決定される、手順と、インデックス値に基づいてハッシュテーブル内の特定のエントリを特定する手順であって、特定のエントリはボリュームデータを含み、ボリュームデータは、ボリュームの特定の部分におけるボクセルの特定のサブセットに対して、ボクセルのサブセットにおけるボクセルが３Ｄジオメトリによって占有されているかを特定し、ボクセルのサブセットは、特定のボクセルを含む、手順と、特定のエントリから、特定のボクセルが３Ｄジオメトリによって占有されているかを判定する手順と、を実行させる、記憶媒体である。

【0199】

例１３は、例１２の主題を含み、命令は実行された場合、さらに機械に、特定のボクセルが占有されているかの判定に基づいて、ボリューム内で、ナビゲーション動作を決定する手順を実行させる。

【0200】

例１４は、例１２または１３のいずれか１つの主題を含み、インデックス値は、式ｉｎｄｅｘ＝（ＩＤ_ｚ×（ＳＬ^２）＋ＩＤ_ｙ×（ＳＬ）＋ＩＤ_ｘ）、に応じて決定され、式中、ＩＤ_ｚはｚ座標の値であり、ＩＤ_ｙはｙ座標の値であり、ＩＤ_ｘはｘ座標の値であり、ＳＬは辺長値である。

【0201】

例１５は、例１２から１４のいずれか１つの主題を含み、特定のボクセルに関連付けられたｘ座標、ｙ座標およびｚ座標は、ボリューム内のボクセルのブロックの座標を含み、ボクセルのブロックは、ボクセルのサブセットを含む。

【0202】

例１６は、例１５の主題を含み、ボリュームは、複数のボクセルのブロックを含み、辺長値は、ボリューム内のボクセルのブロックの数の立方根に等しい。

【0203】

例１７は、例１５または１６のいずれか１つの主題を含み、ハッシュテーブル内の各エントリは、一組のボクセルブロックのそれぞれにおける各ボクセルを記述したボリュームデータを含むようなサイズである。

【0204】

例１８は、例１７の主題を含み、各ボクセルブロックは、複数のボクセルを含み、ハッシュテーブルエントリは各々、対応するボクセルが占有されているかと特定するために、ボクセルブロックにおけるボクセル毎に少なくとも１つのビットを含む。

【0205】

例１９は、例１８の主題を含み、各ハッシュテーブルエントリは、対応するボクセルブロックにおいて、ボクセル毎に２ビットを含むようなサイズである。

【0206】

例２０は、例１２から１９のいずれか１つのの主題を含み、命令は実行された場合、さらに機械に、特定のエントリのアドレスを計算し、ハッシュテーブル内のエントリのアドレスは、インデックス値の剰余に基づいて計算される手順を実行させる。

【0207】

例２１は、例１２から２０のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、ハッシュテーブル内の特定のエントリで衝突があるかを検出する手順と、衝突が検出された場合、ハッシュテーブルに関連付けられた衝突管理方式を利用する手順と、を実行させる。

【0208】

例２２は、例１２から２１のいずれか１つの主題を含み、ハッシュ化アルゴリズムは大きな素数を使用しない。

【0209】

例２３は、例１２から２２のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、特定のボクセルが占有されているかに基づいて、ボリューム内で、デバイスの自律ナビゲーション経路を決定する手順を実行させる。

【0210】

例２４は、方法であって、三次元（３Ｄ）ボリュームを表すボリュームデータを生成する段階であって、ボリュームは一組のボクセルを含み、ボクセルの少なくとも１つは、３Ｄジオメトリで占有され、ボリュームデータは、一組のボクセルの各々について、それぞれのボクセルが占有されているかを特定するものである、段階と、ハッシュ化アルゴリズムに応じて、ボリュームデータに対するインデックス値を生成する段階であって、一組のボクセル内のボクセルの特定のサブセットを表す、ボリュームデータの特定の部分に対するインデックス値は、ボクセルの特定のサブセットに関連した、ｘ座標、ｙ座標およびｚ座標の値の組み合わせに基づいて生成され、ボリュームに対応する辺長値に基づいて、特定の部分に対するインデックス値がさらに生成される、段階と、ボリュームデータの特定の部分を、ハッシュテーブルのエントリ内に記憶する段階であって、エントリは、特定の部分に対するインデックス値に基づくアドレスを有する、段階と、を備える、方法である。

【0211】

例２５は、例２４の主題を含み、ｘ座標、ｙ座標およびｚ座標の値の組み合わせは、ｘ座標、ｙ座標およびｚ座標の値の加重和を含み、ｘ座標、ｙ座標およびｚ座標の内の１または複数が、辺長値に基づいて重み付けされる。

【0212】

例２６は、例２５の主題を含み、インデックス値は、式ｉｎｄｅｘ＝（ＩＤ_ｚ×（ＳＬ^２）＋ＩＤ_ｙ×（ＳＬ）＋ＩＤ_ｘ）、に応じて生成され、式中、ＩＤ_ｚはｚ座標の値であり、ＩＤ_ｙはｙ座標の値であり、ＩＤ_ｘはｘ座標の値であり、ＳＬは辺長値である。

【0213】

例２７は、例２５または２６のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、ボリュームのｘ座標、ｙ座標およびｚ座標の各々の内の、占有ボリュームの相対密度に基づいて、辺長値を使用してｘ座標、ｙ座標およびｚ座標に適用される重みを決定する段階を実行させる。

【0214】

例２８は、例２４から２７のいずれか１つの主題を含み、ボリュームは、一組のボクセルブロックに論理的に細分化され、ボクセルブロックはそれぞれ、各ボクセルサブセットの、サブボリュームを含み、特定のサブセットボクセルは、一組のボクセルブロックの特定の１つを含む。

【0215】

例２９は、例２８の主題を含み、ハッシュテーブル内の各エントリは、一組のボクセルブロックのそれぞれにおける各ボクセルを記述したボリュームデータを含むようなサイズである。

【0216】

例３０は、例２９の主題を含み、各ボクセルブロックは、複数のボクセルを含み、ハッシュテーブルエントリは各々、対応するボクセルが占有されているかと特定するために、ボクセルブロックにおけるボクセル毎に少なくとも１つのビットを含む。

【0217】

例３１は、例３０の主題を含み、各ハッシュテーブルエントリは、対応するボクセルブロックにおいて、ボクセル毎に２ビットを含むようなサイズである。

【0218】

例３２は、例２４から３１のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、エントリのアドレスを計算し、ハッシュテーブル内のエントリのアドレスは、インデックス値の剰余に基づいて計算される段階を実行させる。

【0219】

例３３は、例２４から３２のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、ハッシュテーブル内のエントリで衝突があるかを検出する段階と、衝突が検出された場合、ハッシュテーブルに関連付けられた衝突管理方式を利用する段階と、を実行させる。

【0220】

例３４は、例２４から３３のいずれか１つの主題を含み、ハッシュ化アルゴリズムは大きな素数を使用しない。

【0221】

例３５は、方法であって、ボリューム内の特定のボクセルを特定する段階と、コンピュータメモリ内に記憶されたハッシュテーブルにアクセスする段階と、特定のボクセルに関連付けられた、ボリューム内のｘ座標、ｙ座標およびｚ座標を決定する段階と、ハッシュ化アルゴリズムに応じて、特定のボクセルに関連付けられたインデックス値を決定する段階であって、ハッシュ化アルゴリズムに応じてインデックス値を決定することは、ボリュームの寸法に対応する辺長値に基づく、ｘ座標、ｙ座標およびｚ座標の加重値を合計する段階を備える、段階と、インデックス値に基づいてハッシュテーブル内の特定のエントリを特定する段階であって、特定のエントリはボリュームデータを含み、ボリュームデータは、特定のボクセルに対して、特定のボクセルが３Ｄジオメトリで占有されているかを特定する、段階と、を備える方法である。

【0222】

例３６は、例３５の主題を含み、命令は実行された場合、さらに機械に、特定のボクセルが占有されているかの判定に基づいて、ボリューム内で、ナビゲーション動作を決定する段階を実行させる。

【0223】

例３７は、例３５または３６のいずれか１つの主題を含み、インデックス値は、式ｉｎｄｅｘ＝（ＩＤ_ｚ×（ＳＬ^２）＋ＩＤ_ｙ×（ＳＬ）＋ＩＤ_ｘ）、に応じて決定され、式中、ＩＤ_ｚはｚ座標の値であり、ＩＤ_ｙはｙ座標の値であり、ＩＤ_ｘはｘ座標の値であり、ＳＬは辺長値である。

【0224】

例３８は、例３５から３７のいずれか１つの主題を含み、特定のボクセルに関連付けられたｘ座標、ｙ座標およびｚ座標は、ボリューム内のボクセルのブロックの座標を含み、ボクセルのブロックは、ボクセルのサブセットを含む。

【0225】

例３９は、例３８の主題を含み、ボリュームは、複数のボクセルのブロックを含み、辺長値は、ボリューム内のボクセルのブロックの数の立方根に等しい。

【0226】

例４０は、例３８から３９のいずれか１つの主題を含み、ハッシュテーブル内の各エントリは、一組のボクセルブロックのそれぞれにおける各ボクセルを記述したボリュームデータを含むようなサイズである。

【0227】

例４１は、例４０の主題を含み、各ボクセルブロックは、複数のボクセルを含み、ハッシュテーブルエントリは各々、対応するボクセルが占有されているかと特定するために、ボクセルブロックにおけるボクセル毎に少なくとも１つのビットを含む。

【0228】

例４２は、例４１の主題を含み、各ハッシュテーブルエントリは、対応するボクセルブロックにおいて、ボクセル毎に２ビットを含むようなサイズである。

【0229】

例４３は、例３５から４２のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、特定のエントリのアドレスを計算し、ハッシュテーブル内のエントリのアドレスは、インデックス値の剰余に基づいて計算される段階を実行させる。

【0230】

例４４は、例３５から４３のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、ハッシュテーブル内の特定のエントリで衝突があるかを検出する段階と、衝突が検出された場合、ハッシュテーブルに関連付けられた衝突管理方式を利用する段階と、を実行させる。

【0231】

例４５は、例３５から４４のいずれか１つの主題を含み、ハッシュ化アルゴリズムは大きな素数を使用しない。

【0232】

例４６は、例３５から４５のいずれか１つの主題を含み、命令は実行された場合、さらに機械に、特定のボクセルが占有されているかに基づいて、ボリューム内で、デバイスの自律ナビゲーション経路を決定する段階を実行させる。

【0233】

例４７は、データ処理装置と、ハッシュテーブルを有するメモリと、ボリュームの少なくとも一部分内のジオメトリを特定するボリュームデータを生成するセンサと、ボリューム処理ロジックと、を備えるシステムである。ボリューム処理ロジックは、ボリュームの特定のサブボリュームに、ボリュームデータの特定の部分が対応すると判定する手順と、ボリューム内で、特定のサブボリュームのｘ座標、ｙ座標およびｚ座標を決定する手順であって、特定のサブボリュームは、一組の１または複数のボクセルを含む、手順と、ハッシュ化アルゴリズムに基づいて、ボリュームデータの特定の部分に対するインデックス値を決定する手順であって、インデックス値は、特定のサブボリュームのｘ座標、ｙ座標およびｚ座標の加重値の総和から決定され、ｘ座標、ｙ座標およびｚ座標の値の１または複数が、辺長変数に基づいて重み付けされる、手順と、インデックス値から、ハッシュテーブル内のアドレスを決定する手順と、アドレスに衝突が存在するかを判定する手順と、アドレスに衝突がないと判定されたことに基づいて、ボリュームデータの特定の部分を、アドレスに関連付けられたハッシュテーブルのエントリに書き込まれるようにする手順と、を実行可能である。

【0234】

例４８は、例４７の主題を含み、ボリューム処理ロジックはさらに、ボリューム内の特定のボクセルを特定する手順と、ボリュームのサブボリュームが、特定のボクセルを含むと判定することと、特定のボクセルの、サブボリュームに対するｘ座標、ｙ座標およびｚ座標を特定することと、特定のボクセルの、サブボリュームのｘ座標、ｙ座標およびｚ座標から、そしてハッシュ化アルゴリズムに基づいて、特定のボクセルに関連付けられたインデックス値を計算する手順と、特定のボクセルに関連付けられたボリュームデータにアクセスするため、特定のボクセルに関連付けられたインデックスに対応する、ハッシュテーブル内のエントリにアクセスする手順であって、特定のボクセルに関連付けられたボリュームデータは、特定のボクセルがジオメトリで占有されているかを特定する、手順と、特定のボクセルがジオメトリで占有されているかに基づいて、ボリューム内での自律移動をトリガする手順と、を実行可能である。

【0235】

例４９は、例４７または４８のいずれか１つの主題を含み、ドローン、ロボット、および自律走行車両の１つを含む。

【0236】

例５０は、例４７から４９のいずれか１つの主題を含み、インデックス値は、式ｉｎｄｅｘ＝（ＩＤ_ｚ×（ＳＬ^２）＋ＩＤ_ｙ×（ＳＬ）＋ＩＤ_ｘ）、に応じて決定され、式中、ＩＤ_ｚはｚ座標の値であり、ＩＤ_ｙはｙ座標の値であり、ＩＤ_ｘはｘ座標の値であり、ＳＬは辺長値である。

【0237】

主題の具体的実施形態を説明した。以下の請求項の範囲内にその他実施形態も含まれる。場合によっては、請求項に記載の動作は、実行順序を変更してもよく、それでも所望の結果が得られる。さらに、所望の結果を得るのに、添付の図面に記載の処理は、必ずしも図示の特定の順序または順番である必要はない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16A】

【図16B】

【図16C】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図 】

【図 】

【図28】

【図29】

【図30】

【図 】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】