IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 石黒 稜人の特許一覧

<>
  • 特開-交差点形状表現アルゴリズム 図1
  • 特開-交差点形状表現アルゴリズム 図2
  • 特開-交差点形状表現アルゴリズム 図3
  • 特開-交差点形状表現アルゴリズム 図4
  • 特開-交差点形状表現アルゴリズム 図5
  • 特開-交差点形状表現アルゴリズム 図6
  • 特開-交差点形状表現アルゴリズム 図7
  • 特開-交差点形状表現アルゴリズム 図8
  • 特開-交差点形状表現アルゴリズム 図9
  • 特開-交差点形状表現アルゴリズム 図10
  • 特開-交差点形状表現アルゴリズム 図11
  • 特開-交差点形状表現アルゴリズム 図12
  • 特開-交差点形状表現アルゴリズム 図13
  • 特開-交差点形状表現アルゴリズム 図14
  • 特開-交差点形状表現アルゴリズム 図15
  • 特開-交差点形状表現アルゴリズム 図16
  • 特開-交差点形状表現アルゴリズム 図17
  • 特開-交差点形状表現アルゴリズム 図18
  • 特開-交差点形状表現アルゴリズム 図19
  • 特開-交差点形状表現アルゴリズム 図20
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024096461
(43)【公開日】2024-07-12
(54)【発明の名称】交差点形状表現アルゴリズム
(51)【国際特許分類】
   G01C 21/32 20060101AFI20240705BHJP
【FI】
G01C21/32
【審査請求】未請求
【請求項の数】2
【出願形態】OL
【公開請求】
(21)【出願番号】P 2024078245
(22)【出願日】2024-05-13
(71)【出願人】
【識別番号】522043747
【氏名又は名称】石黒 稜人
(72)【発明者】
【氏名】石黒 稜人
(57)【要約】
【課題】自動運転車が交差点形状や交差点上のシンボルを適切に認識できるようにするための交差点表現アルゴリズムを提供する。
【解決手段】縦横高さ25cmの立方体を交差点の基準点(はしごの道路標示の終端のふみさん)から転がしていき、できあがる閉ループを交差点形状とし、その場でくるくると立方体が何回転かすることでシンボルの存在を表現するアルゴリズムを利用する。
【選択図】図1
【特許請求の範囲】
【請求項1】
1点から見た交差点の形状を保存するアルゴリズムであって、
前記保存とは、
1次元コードや、2次元のコードや、タグや、ハードディスクや、SSDや、ROMや、RAMといった、情報を保存できる媒体に情報を蓄えることを特徴とし、
前記交差点とは、
交差点とは、道路の交わる部分や、道路の行き止まり(袋小路)の先の部分や、横断歩道といった道路と歩道の交わる部分や、歩道を挟んで道路の交わる部分や、道路の合流地点や、道路の分岐地点や、急な曲がり角や、ビルの壁や、部屋の天井といった、道の接続部であることを特徴とし、
前記アルゴリズムとは、
交差点の1点に置かれた、一定サイズの立方体を、鉛直上側から突き刺すZ軸を中心とするその場での回転方向か、回転移動方向か、平行移動方向の中の、いずれか2方向で1ビットの情報を持つ、前記2方向の中から、好きな方向に、90度ずつ、立方体を回転移動または平行移動させていき、前記立方体が通過した部分でできた閉ループを、前記交差点の形状とすることと、
同じ方向に複数回、前記回転方向または回転移動方向または平行移動させることで同じ位置同じ姿勢に戻ることを利用して、横断歩道などの交差点に存在するオブジェクトの位置を表現することを特徴とする、交差点の形状を保存するアルゴリズム。
【請求項2】
前記平行移動方向のみで構成される1bitの場合、常に転がった方向を前といった、一方向と定義しなおし続けるという特徴を有する請求項1に記載の
交差点の形状を保存するアルゴリズム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は市街地の自動運転と自動バレー駐車に応用可能な交差点形状保存アルゴリズムに関する。
【背景技術】
【0002】
従来のはしごの道路標示の発明の説明を見ただけだと、説明不足で自動運転車が実現できない可能性が有る。
日本一多くに分岐している交差点は菅原橋交差点で、11叉路になっている。そのため、Uターンする道を含めて、道は11に分岐しているものとして考える。
世界一車線数の多い道路は8車線である。
日本一大きい交差点は箱堤交差点であり、とても大きい。
従来通りの、線の長さと角度と幅を利用した情報で交差点の形状を表現しようとすると、2000ビット程度必要となる。
QRコード(QRコードは(株)デンソーウェーブの登録商標です)のバージョン8の誤り訂正レベルHの保存できるバイナリの最大長は84byte(672bit)までである。
道路は一車線あたり約2.5m程度である。また、25cmずつサイズが変化する。
本発明で登場するRFIDは5m程度の通信距離が必要で、ユーザメモリ容量は1500bit程度を想定しています。動作温度は路面温度の範囲を想定しています。
【0003】
ーーーーーーーーーー
(重要)交差点とは、道路の交わる部分や、道路の行き止まり(袋小路)の先の部分や、横断歩道といった道路と歩道の交わる部分や、歩道を挟んで道路の交わる部分や、道路の合流地点や、道路の分岐地点や、急な曲がり角や、ビルの壁や、部屋の天井といった、道の接続部である。
ーーーーーーーーーー
常識的には違うが、本発明の中では、駐車場の駐車スペースが複数ある行き止まりは交差点である。また、横断歩道は交差点の一部である。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特願2022-195491
【特許文献2】特願2023-91455
【特許文献3】特願2023-91456
【特許文献4】特願2023-130625
【特許文献5】特願2023-151777
【特許文献6】特願2023-208096
【特許文献7】意願2023-025713
【特許文献8】意願2023-025714
【特許文献9】意願2023-026595
【特許文献10】特願2024-008905
【非特許文献】
【0005】
【非特許文献1】なし
【発明の概要】
【発明が解決しようとする課題】
【0006】
従来のはしごの道路標示を通常使用する上での問題点として、交差点の形状をどのように表現するかという問題がある。
自動運転車に交差点の形状を伝える場合に、道路の幅や高さや長さや曲率半径等を伝えていると膨大なデータになってしまう。小数を扱う場合、とてもデータの容量が大きくなる。そこで、圧縮以外の方法で、とにかくデータ容量の少ない交差点表現アルゴリズムを考える。さらに、歩道の場所やパーキングスポットの場所も表現したい。本発明では交差点上に存在するものをなるべく少ないデータで表現する。
ついでで本資料は以下の要点に絞って自動運転車を制作する場合に困る点と解決法を記載しています。波線で区切られた範囲がひと固まりです。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
・高速道路の急なカーブをほぼ100%安全に自動走行させる方法について
・はしごの具体的な利用方法について
・ルールを改正しないといけない部分
・どか雪対策について
・車両の下につけるセンサの汚れ防止装置
・アイスバーン対策について
・はしごの色について
・はしごの幅について
・はしごの終端のQRコードについて
・はしごの道路標示の整備費用はどこから捻出するのか
・はしごの分岐と交差点について
・交差点のQRコードについて
・目的地について
・横断歩道等のその他の道路標示について
・交差点前に設置するQRコードの内容について
・交差点形状を示すQRコードの方向補正について
・車線変更について
・工事について
・すれ違いについて
・道路のマンホールについて
・グレーチングについて
・信号の認識について
・高速の入り口について
・自動運転車だと周りから判別する方法
・高速から近くのパーキングエリアまでの運転について
・マルチコプターについて
・実証実験のおおよその流れの例について
・3次元のQRコードについて
・DNNの必要な場面
・QRコードではなくRFIDにて実装する場合について
・QRコードやRFID読み取り装置のONOFFについて
・自動倉庫との連携について
・総括
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
【0007】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・高速道路の急なカーブをほぼ100%安全に自動走行させる方法について
道路の中央に塗料の線を引いて、それをライントレースする方式の自動運転車にします。その方式の場合、ラインを既存の手動運転車と共存できるような線にする必要があります。
解決方法としては、「ふみさんが2色以上のはしごを道路の中央に引く」ことで、手動運転車の走行の邪魔にならずに、自動運転者でライントレースする事ができます。1色の場合、ゼブラゾーン(導流体)との区別が付きにくいため、ふみさんを2色としています。また、はしごのふみさんの間隔を制限速度とすることで、カーブといった部分での速度を自動で落とすことができます。
本資料の方式でライントレースを行う場合は、従来の画像処理のように道路の形状を認識する必要がなく、急なカーブでも事故になる可能性が低いです。
例として図1のようなはしごを道路に描きます。ふみさんとは図1の横棒のことです。また、穴の開いた橋やグレーチング等は、板とはしごのシートを貼ることで解決できます。また、ちょっとぐらいなら、途切れてもライントレースには大きな問題はありません。グレーチングについては後述します。
【0008】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・はしごの具体的な利用方法について
ーー読み取りについてーー
はしごの読み取りは車両の下側に取り付けたラインカメラで行います。従来の自動運転車は通常のカメラやライダー等で行いますが、本資料の方式であれば、ラインカメラでおこなうため、制御周期がとても短く、時速300km/hで走行しても線を読み取る性能が十分にあります。
現在は時速300km/hで追従走行する技術がありますが、カーブで前方車両を見失ったりするといった危険があります。そこで、走行自体はライントレースで行い、車間距離の維持だけ気にすれば、現在の技術で理論上は300km/hの安全な自動運転ができます。(カーブでは安全な速度に落とす)
ーー実施についてーー
はしごを道路上に記入し、縦棒の間を透明な塗料で上から塗ります。そして乾く前にガラスシードやアクリルシードといった透明な粒を撒いて、縦棒の間を透明な塗料で重ね塗りします。自衛隊等でも滑り止めとして利用されている方法であり、バイクではしごの上を通っても問題ないようにできます。また、難しいですが、はしごの道路標示の上だけを重ね塗りする方法もあります。
ーーはしごの保守についてーー
はしごの近くを車が通るとはしごの外側から削れていきます。削れるとはしごの幅が狭くなります。はしごの外側から削られるため、はしごの幅が短くなったら塗りなおしで問題無いです。
また、はしごの縦棒の内側と外側で高さが違うので、薄くなったかどうか検知も理論上は可能です。
ーー雪以外の天気についてーー
車両の下側にセンサがついているため、日没や雨でも線を見失いません。前方が砂嵐で何も見えなくても道路だけなら走行できます。
【0009】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・ルールを改正しないといけない部分
はしごの道路標示と干渉するものが1つ有ります。それは、ダイヤマークです。ダイヤマークだけは法律で道路標示にしないといけません。それ以外の干渉するものは全て道路標識に変更できます。
そのため、幅1m程度のはしごの中に描けるダイヤマークもダイヤマークとして認めてもらわなければいけません。はしごの道路標示は真ん中に切れ目を入れても良いので、幅80cm、長さ80cm程度のダイヤマークをダイヤマークとして認めてもらう必要があります。
止まれの道路標示等は、緑色の塗料等ではしごの道路標示の下に重ねて記載すれば問題無いです。看板だけでは分かりにくい場合は、はしごの道路標示の下に別の色で重ねて道路標示を記載します。
高速道路と、高速道路の出口からパーキングスポットまでの横断歩道を無くすことも可能です。そのため、高速道路とその出口近くを自動運転する場合は、ダイヤマークとは干渉しません。
図3のようにはしごの道路標示の間にダイヤマークを入れられるようにルール改正する必要が有ります。また、ひし形のQRコードがあって、はしごの道路標示の内側にひし形のQRコードを見つけたら、徐行するというプログラムにしても良いと思われます。
あと、車の下にラインカメラを付けても良いのかといった、法律に則った車の改造は一切分かりません。
【0010】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・どか雪対策について
自動運転車の前に除雪車を走らせ、道路についた雪を根元から全て除雪します。一般的に下手な人の行う除雪です。しかし、それで十分です。大雪が降るたびに透明な塗料を適当にかけ直せば保守はできます。
除雪車は、除雪して新たに見えるようになった部分のはしごの道路標示を読み取ってさらに除雪できるため、除雪車自身も自動運転車にできます。一番良いのは自動運転車に除雪機能を付けることですが、コストなどを考えて現実的となるのは、除雪車と一緒に走らせて、自動運転車には簡単な除雪用アタッチメントを付けるぐらいでしょうか。
【0011】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・車両の下につけるセンサの汚れ防止装置
回転するガラスなどを付けることで解決する発明があります。センサの周りに回転するガラス等を取り付け、ガラスに付着した雪をブラシで取り除きます。車両の上にセンサが付いている場合、雪で使えなくなります。しかし、車の下にセンサがあり、根こそぎ除雪された道であれば、雪であってもセンサは普通に動作します。
【0012】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・アイスバーン対策について
元の色は透明だが、気温が低くなると白線やグレーとなるサーモクロミック塗料を使用して対策します。はしごの道路標示のふみさん4分の3を、おおよそ4度以下で白と判定されるサーモクロミック塗料で描くことで、寒い時は制限速度を4分の1にすることができます。一般道は別に普通の塗料でも良い気もするのですが、高速道路では300km/hで自動走行させることを想定しているので、高速道路はサーモクロミック塗料でのアイスバーン対策は必須です。レインセンサを併用すれば雨の日と雪の日と晴れの日の区別ができます
曇りの日に速度を落とすことはプログラムでできますが必要ないです。
【0013】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・はしごの色について
下記の条件を全て満たした色であれば問題ないと思います。
ーーーーーーーーーー
1.サーモクロミック塗料で色の変化を実現しやすい色であること。
2.錯視(リープマン効果)等が発生しない配色とすること
3.どの道路に塗っても見分けが付く配色であること(白と灰色の組み合わせ等)
ーーーーーーーーーー
具体的には縦棒が白で、ふみさんの1色が白でもう1色がグレーや緑といった組み合わせです。
【0014】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・はしごの幅について
1mで良いと思います。ただ、はしごの幅とふみさんの間隔は世界中で統一して欲しいです。
テュクテュクを最も細い車として考慮しています。太陽光を遮断するために、テュクテュクに数十cmの小さな翼を付ければ、幅1m程度のラインまで読み取れます。
基本的な幅である1.3m程度の軽自動車が読み取ることなどを考えるとはしごの道路標示の幅は1mぐらいが妥当だと思います。縦線の内側に記載するQRコードのことも考えるとある程度の幅は必要だと思います。具体的には、はしごの縦線の幅は1本10cm~15cm、ふみさんの幅は25cm、ふみさんの1色の幅は12.5cmとする。縦線を含めたはしごの幅が1m(縦線の間の幅70~80cm)で良いと思います。ふみさんの間隔は、最高で時速300kmで走ることを考慮し、10km/hを制限速度とする時は50cm。20km/hを制限速度とする場合は100cm。30km/hを制限速度とする場合は150cm。60km/hを制限速度とする時は300cm。300km/hを制限速度とする場合は1500cmとする。
はしごの道路標示の幅は道路の表示が25cm単位なため1m00cmでも良い。幅の寸法公差は90cmから100cmまでの間の1mプラス0cmマイナス10cmとすれば良いと思う。
【0015】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・はしごの終端のQRコードについて
はしごの終端には、本発明の交差点を転がる立方体のスタート地点を示す必要がある。具体的には、QRコードのかどにある四角が必要である。QRコードの左上のかどを基準としたり、基準とする場所はQRコードのどこかとする。
なお、はしごの道路標示の始端のQRコードの中身は何でもいいため、宣伝に用いることができる。ラインの保守のお金はどこから出るのか?という問いに関しては、ラインの始端のQRコードで会社名を宣伝して、その会社から徴収すれば良い。「ここからの道路は〇〇株式会社が提供します」とカーナビに言わせても良いし、完全な自動運転なのでナビの端に会社名を表示しても良い。また、会社の法人番号と整理番号をQRコードで表示しておき、内容は適宜受信する方式でも良い。
宣伝の表示時間はおおよそはしごの長さに比例します。
数十年後はどうかは知らないが、レベル5の安全な自動運転を提供してくれるなら、多少の宣伝は仕方ないと思います。テレビも最初の頃は宣伝すら見られてました。
例えば特定の道を特定の時間に通ると飲食店のドライブスルーに勝手に入り、ジュースが一本配られるといった宣伝なども可能である。他にも、その道路に入った際にお店の入店音を鳴らしたりも考えられる。毎回名前を読み上げられるのは苦痛になりそうだが、入店音ぐらいならアリな気もします。
はしごの始端ははしごの延びる方向を示していれば何でも良いです。自動運転車が斜めにはしごに入ると、向きを補正しないといけませんが、QRコードのかどの四角があれば補正できます。
はしごの始端のQRコードの中身は本当に何でもよいが、終端に関しては自動バレー駐車との互換性を考えて、現在地の交差点番号(一意的な番号)は最低でも含んでいる方が良い。交差点の番号を入れる理由としては、地下でも自動運転可能とさせるためである。交差点番号は全世界の交差点ごとの固有の番号である。国コードから始まっており、50ビット程度の交差点番号を用意する。
また、交差点番号の代わりに、現在地のGPS情報と標高のデータでも良い。プログラム的にはGPS情報と標高のデータの方が入力者の手間が省けて良い。GPS情報にしても良い条件は、全世界の駐車場1つ1つのGPS情報だけで、駐車場を見つけられるかどうかである。「地上の」並んだ2つの駐車スペースがあって、GPSの情報だけでどちらの駐車場に止めれば良いか分かる場合はGPS情報と標高の情報で問題ない。
駐車場の入り口でGPS情報と標高同士の繋がり情報のデータを受信することができれば、あとは自動バレー駐車が完成する。具体的には「交差点AのGPSの情報、交差点の標高の情報、その交差点Aに繋がる交差点の情報、繋がり方は相互か一方通行かの1ビットの情報」配列表を自動運転車に送信すれば良いだけである。駐車場の入り口にて、交差点の繋がり情報を、連続して沢山あるQRコードで読み取らせても良い。または特定のデータのQRコードを読み込んだら短距離の通信をONにするといった方法も考えられる。
まとめると、QRコードのかどの四角x3といった、向きを補正するマークがはしごの道路標示の始端と終端に必要不可欠で、始端のQRコードについては、はしご出資者の宣伝に利用すれば良い。終端は、現在地のGPS情報と標高の情報を入れておく。
地下で一意のGPSの情報を生成する方法が必要である。ランダムなGPSの値だと周りの交差点と偶然重なる可能性もある。そのため、四角の地下駐車場の場合、地下駐車場の四隅のGPS情報を調べて、その範囲内で少しずつずらした値を利用することが考えられる。
【0016】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・はしごの道路標示の整備費用はどこから捻出するのか
はしごの上を走行した時の宣伝費用で回収する。会社の法人番号などの情報ははしごの道路標示の開始に配置するQRコードに格納する。はしごの道路標示が長ければ長いほど、整備費用は高くなり、広告が表示される時間が長くなる。
問題点としては、都会は問題なさそうだが、田舎では宣伝費用が集まらない可能性がある点である。田舎は普通に運転してもらうしかないのだろうか。
【0017】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・はしごの分岐と交差点について
はしごを分岐させる場合は、分岐の数メートル前に、分岐することを伝えるQRコードを配置する。例えば、高速道路から降りる時の分岐である。
はしごの道路標示を記載し、交差点との境目にははしごの終端を示すQRコードを記載する。交差点以外での道路の分岐に関しては、はしごの分岐前にQRコードを付けることで解決する。
後述する高速道路の入り口の合流に信号機を設置する方法も良いが、はしごの分岐を応用してはしごの道路標示間を図4のように塗りつぶしても良い。しましまを配置して、もうすぐ合流しますと合図しています。しましまは合流のなるべく手前から配置します。この方法には一つ問題があって、車の良く通る場所に塗料を塗る必要があります。なので、合流も分岐も全て交差点にすると良いかもしれません。
【0018】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・交差点のQRコードについて
交差点とはしごの道路標示の境目には終端を示すQRコードがある。その前に交差点の形状を記載したQRコードを道路に記載する。
このQRコードの内容のアルゴリズムが本発明である。
交差点の形状を3軸ロボットアームのアーム先端の軌跡から考えると、最低でも1000ビット程度の情報量となる。また、データとして非常に圧縮しにくいデータとなる。
交差点のQRコードの設置向きに関しては、統一されていれば問題ない。
【0019】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・目的地について
はしごの道路標示の終端につけるQRコードで、目的地に到着したか判別する。
なので、実現するなら交差点の端から交差点の端に自動運転するシステムとなる。大通りと大通りに隣接した駐車場のパーキングスポット(交差点)までなら自動運転が実現できそうですが、細い路地は実現できるか怪しいです。現実的な落としどころとしては、家の近くのパーキングスポットまで手動運転していき、目的地の近くのパーキングスポットまで自動運転するシステムとする形となります。自動運転可能で到着可能な家にパーキングスポットを設置したいなら、有料で設置すれば良いと思います。その際、カーナビのソフト上で誰でも行けるパーキングスポット(交差点)と、特定の車しか到着できないパーキングスポットと、誰でも駐車可能なパーキングスポットと、特定の人しか駐車できないパーキングスポットの4つに分けた方が良いと思われます。
例えば、任意に変更可能なパスワードをナビに打ち込むと、その民家の駐車場へ案内できるようにすることで、友達にパスワードを打ち込んで来てもらうといったことが可能となる。
パーキングスポットの先の交差点を駐車場とするか、はしごの道路標示の終端の1点を駐車場とするかはお任せします。1点を駐車場とした場合、1台しか止められません。また、全てのパーキングスポットの真ん中まで線を引かないといけません。交差点の中に車を止める場合、駐車場の形状を自動運転車が分かっている状態となります。なので、既に車が止まっていないか確認して自動運転させても良いですし、数mだけ手動運転させてもいいです。
【0020】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・横断歩道等のその他の道路標示について
はしごの道路標示のふみさんは中央に切れ目が入る可能性があります。進行方向の道路標示を記載する場合、はしごの道路標示の真ん中に切れ目を入れて標示します。基本的に道路の中に描くものは看板にします。島状の施設によらないで安全地帯を設ける場合や導流体等はそのまま道路標示とします。
また、規制の実効性のため、道路標示及び道路標識の双方を設置する必要のあるものがいくつかあるが、はしごの内側に記載するか潜り抜けるタイプの看板に記載するもので良い。
【0021】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・交差点前に設置するQRコードの内容について
「>>」で囲った下記リストの情報を道路に記載するQRコードの情報とする。QRコードのバージョン8の誤り訂正レベルHは84x8=672bitまでデータを保存できる。iQR等なら更に小さくすることも可能である。また、道路への印刷が辛い場合は、バージョン5の誤り訂正レベルMの全く同一のQRコードを2つ縦に並べるといった方法でも良い。それでも道路への印刷が辛いなら、バージョン2の誤り訂正レベルMのQRコードを縦に4つ連結するという手もある。
はしごの道路標示が無い道路を表現する時は、車両の高さ制限を0mにすることで表現できる。
本発明では、交差点上にあって、表現したいものとして考慮しているのは、自動運転車が最高速で入っても良い道の形状、横断歩道といった人や車が入ってくるかもしれないスペース(歩道)、はしごの道路標示の始端、駐車スペースの4つである。中央分離帯等は自動運転車が入って良いスペースには無いはずなので問題ない。
全てのQRコードのデータ量を固定長とする場合は、本発明の立方体がスタート地点に戻ってきても、データの終わりとしなくても良い。可変長とする場合は立方体がスタート地点に戻ってきたらデータの終わりとすればよい。
小さいマルチコプターとは道路の上4.5mのトンネルを車と一緒に通過できるサイズのマルチコプターを想定しています。
はしごの道路標示の両端から車が侵入できるように、始端1と終端1をペアとして使います。また、始端2と終端2をペアとして使います。始端1の後に終端2が来たら終端2のQRコードは無視します。自分なら対向車両が来るのは危ないので、全ての道路を一方通行として考えます。
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコードはラインカメラで読み取れるように縦長のQRコードにする。他のQRコードは速度が低い状態で読み取るので、カメラで読み取る前提である。
QRコードのいずれかを表す情報(最低3bit)は念のため5bit以上あった方が良い。例えば特殊な道路のそこだけを、例外的な処理をさせる場合にQRコードのいずれかを表す情報に余裕があると簡単に対応できる。例えば、「ここからはしごの道路標示に沿って数メートルは徐行しろ」みたいな指示を出したい場合は、ここで新しい種類のQRコードを追加する。「警笛を鳴らせ」をどこかに分類する必要がある。中身の容量の少ないQRコードは、新たに分類するのではなく、他の容量の少ないQRコードとまとめてしまって良い。例えば、「駐車場データの短距離通信のONOFFを指令するQRコード」と「車線変更の指示をするQRコード」はまとめてしまっても良い。
工事の指示をするQRコードは工事の場合に使う。工事については後述する。
QRコードを配置する場所の例(分岐を線の分岐で行う)を図6に示す。分岐を全て交差点としたQRコードの配置例を図7に示す。
001は「はしごの道路標示」である。002に後述する「交差点の始端に配置するQRコードの中身」が格納される。003に後述する「交差点の終端に配置するQRコードの中身」が格納される。004に後述する「交差点のちょっと前に配置するQRコード2の中身」が格納される。005に後述する「交差点のちょっと前に配置するQRコード1の中身」が格納される。006に後述する「道路の分岐前に配置するQRコードの中身」が格納される。007に後述する「駐車場データの短距離通信のONOFFを指令するQRコードの中身」が格納される。図6図7には無いが、QRコードの手前にはラインカメラで読み取り可能なQRコードである、後述する「もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコードの中身」が格納される。
「その道への進入角度」とは交差点の形状とはしごの道路標示の始端の基準点がの位置が分かっているものとして、おおよそどんな角度でその基準点に車が重なるように移動すれば良いかを示す。
>>>>>>>>>>>>>>>>>>
交差点のちょっと前に配置するQRコード1の中身
>>>>>>>>>>>>>>>>>>
ーーーーーーーーーー
ー初期バージョンであることを示すために始めの1bitを1とする(1bit)
1bitx1=1bit
ーーーーーーーーーー
ー下記QRコードのいずれかを表す情報(最低3bit)
交差点のちょっと前に配置するQRコード1
交差点のちょっと前に配置するQRコード2
交差点の始端1に配置するQRコード
交差点の終端1に配置するQRコード
道路の分岐前に配置するQRコード
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコード
駐車場データの短距離通信のONOFFを指令するQRコード
工事の指示をするQRコード
3bitx1=3bit(種類を増やすなら3bitより多くなる)
ーーーーーーーーーー
ー今いる道路が最も優先される優先道路かどうか(1bit)
ーこの交差点は通信可能な信号が設置してあるか(普通の信号の場合と、通信可能な信号の場合と、信号無し)(2bit)
ー交差点の全範囲が横断歩道であるものとして考えるか(1bit)
ー今いる車線が左から何車線目か(4bit)
ー交差点内の制限速度(10km/h単位で0km/hから310km/hまで)(5bit)
(曲がるときはここの数値に限らず安全な速度とする)
ー認識すればよい信号機の番号(30bit)(後述する信号機のLEDを送信回路にする場合に必要)
43bitx1=43bit
ーーーーーーーーーー
ーその道を進む場合の車両の高さ制限(0mから4.5mを10cm単位)(6bit)
ーその道を進む場合の車両の幅制限(0mから6.3mを10cm単位)(6bit)
ーその道の重量制限(0.5tから10tまで0.5t単位、10tから1t単位で記載)(6bit)
ー自動車は通行可能かどうか(1bit)
ー危険物積載車両は通行可能かどうか(1bit)
ー大型貨物自動車等は通行可能かどうか(1bit)
ー大型乗用自動車等は通行可能かどうか(1bit)
ーバスは通行可能かどうか(1bit)
ー道路に引かれているラインの種類(2bit、幅1mのはしごの道路標示とマルチコプター用の細い線と水中に引ける線(ロープの道)と磁気テープの道の最低でも4種類)
ー宅配用といった小さいマルチコプターは通行可能かどうか(1bit)
ー空飛ぶ車といった大きいマルチコプターは通行可能かどうか(1bit)
ー前方から車が来る可能性があるかどうか(1bit)
ーその道への進入角度(6bit)
27bitx11=297bit
(前提条件として道は最高11に分岐しているものとする。15に増やせば108bit増える。20個に分岐しているとする場合540bitとなる。駐車場が最も分岐数の多い交差点である)
ーーーーーーーーーー
ーパリティビット
ーーーーーーーーーー
>>>>>>>>>>>>>>>>>>
交差点のちょっと前に配置するQRコード2の中身
>>>>>>>>>>>>>>>>>>
ーーーーーーーーーー
ー初期バージョンであることを示すために始めの1bitを1とする(1bit)
1bitx1=1bit
ーーーーーーーーーー
ー下記QRコードのいずれかを表す情報(最低3bit)
交差点のちょっと前に配置するQRコード1
交差点のちょっと前に配置するQRコード2
交差点の始端1に配置するQRコード
交差点の終端1に配置するQRコード
道路の分岐前に配置するQRコード
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコード
駐車場データの短距離通信のONOFFを指令するQRコード
工事の指示をするQRコード
3bitx1=3bit(種類を増やすなら3bitより多くなる)
ーーーーーーーーーー
ー本発明のアルゴリズムで保存された交差点の形状
4bitで最大1mの範囲を示せるので、中サイズの交差点の通っても良い部分を1周するのに100m(400bit)程度かかるものとする。1周の仮定が200mの場合は800bit必要となる。歩道等のエリア表示も考えて最低でも800bitぐらいは必要である。表現の幅が広がるので欲を言うと1200bit程度は欲しい。2000bit程度あれば広い駐車場にも楽々対応できると思われる。それ以上は有っても使うか分からない。広い駐車場は分割すれば良いだけである。ここの容量が少ないと分割数が多くなる。駐車場にある交差点の外周が500mの場合2000bit程度必要となる。
約800bitx1=約800bit(圧縮前のデータ量の場合)
ーーーーーーーーーー
ーパリティビット
ーーーーーーーーーー
>>>>>>>>>>>>>>>>>>
交差点の終端に配置するQRコードの中身
>>>>>>>>>>>>>>>>>>
ーーーーーーーーーー
ー初期バージョンであることを示すために始めの1bitを1とする(1bit)
1bitx1=1bit
ーーーーーーーーーー
ー下記QRコードのいずれかを表す情報(最低3bit)
交差点のちょっと前に配置するQRコード1
交差点のちょっと前に配置するQRコード2
交差点の始端1に配置するQRコード
交差点の終端1に配置するQRコード
道路の分岐前に配置するQRコード
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコード
駐車場データの短距離通信のONOFFを指令するQRコード
工事の指示をするQRコード
3bitx1=3bit(種類を増やすなら3bitより多くなる)
ーーーーーーーーーー
ー終端1か2かどちらに配置するか(道を全て一方通行にするなら不要)(1bit)
ーこの交差点は車を止めても良いか(1bit)
ーGPSの方位角(QRコードの設置角度のため)(64bit)
ー交差点の番号(交差点のGPSと標高の情報または交差点番号)(64bit)
130bitx1=130bit
ーーーーーーーーーー
ーパリティビット
ーーーーーーーーーー
>>>>>>>>>>>>>>>>>>
交差点の始端に配置するQRコードの中身
>>>>>>>>>>>>>>>>>>
ーーーーーーーーーー
ー初期バージョンであることを示すために始めの1bitを1とする(1bit)
1bitx1=1bit
ーーーーーーーーーー
ー下記QRコードのいずれかを表す情報(最低3bit)
交差点のちょっと前に配置するQRコード1
交差点のちょっと前に配置するQRコード2
交差点の始端1に配置するQRコード
交差点の終端1に配置するQRコード
道路の分岐前に配置するQRコード
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコード
駐車場データの短距離通信のONOFFを指令するQRコード
車線変更の指示をするQRコード
3bitx1=3bit(種類を増やすなら3bitより多くなる)
ーーーーーーーーーー
ー始端1か2かどちらに配置するか(1bit)
ー法人番号といった企業の宣伝用データ(数百bit)
ーーーーーーーーーー
ーパリティビット
ーーーーーーーーーー
>>>>>>>>>>>>>>>>>>
駐車場データの短距離通信のONOFFを指令するQRコードの中身
>>>>>>>>>>>>>>>>>>
ーーーーーーーーーー
ー初期バージョンであることを示すために始めの1bitを1とする(1bit)
1bitx1=1bit
ーーーーーーーーーー
ー下記QRコードのいずれかを表す情報(最低3bit)
交差点のちょっと前に配置するQRコード1
交差点のちょっと前に配置するQRコード2
交差点の始端1に配置するQRコード
交差点の終端1に配置するQRコード
道路の分岐前に配置するQRコード
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコード
駐車場データの短距離通信のONOFFを指令するQRコード
工事の指示をするQRコード
3bitx1=3bit(種類を増やすなら3bitより多くなる)
ーーーーーーーーーー
短距離通信を開始するかどうかの1bitのフラグ(1bit)
1bitx1=1bit
ーーーーーーーーーー
ーパリティビット
ーーーーーーーーーー
>>>>>>>>>>>>>>>>>>
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコードの中身
>>>>>>>>>>>>>>>>>>
ーーーーーーーーーー
ー初期バージョンであることを示すために始めの1bitを1とする(1bit)
1bitx1=1bit
ーーーーーーーーーー
ー下記QRコードのいずれかを表す情報(最低3bit)
交差点のちょっと前に配置するQRコード1
交差点のちょっと前に配置するQRコード2
交差点の始端1に配置するQRコード
交差点の終端1に配置するQRコード
道路の分岐前に配置するQRコード
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコード
駐車場データの短距離通信のONOFFを指令するQRコード
工事の指示をするQRコード
3bitx1=3bit(種類を増やすなら3bitより多くなる)
ーーーーーーーーーー
ーパリティビット
ーーーーーーーーーー
>>>>>>>>>>>>>>>>>>
道路の分岐前に配置するQRコードの中身
>>>>>>>>>>>>>>>>>>
ーーーーーーーーーー
ー初期バージョンであることを示すために始めの1bitを1とする(1bit)
1bitx1=1bit
ーーーーーーーーーー
ー下記QRコードのいずれかを表す情報(最低3bit)
交差点のちょっと前に配置するQRコード1
交差点のちょっと前に配置するQRコード2
交差点の始端1に配置するQRコード
交差点の終端1に配置するQRコード
道路の分岐前に配置するQRコード
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコード
駐車場データの短距離通信のONOFFを指令するQRコード
工事の指示をするQRコード
3bitx1=3bit(種類を増やすなら3bitより多くなる)
ーーーーーーーーーー
ー自分のいる車線は合流する側かされる側か(1bit)
ー2つのはしごが繋がるのか、2つのはしごに分かれるのか(1bit)
ー右か左のどちらから合流するか、右か左のどちらに分岐するか(1bit)
ー合流する場合に合流区間の距離はどれだけか(10cm単位)(10bit)
13bitx1=13bit
ーーーーーーーーーー
ーパリティビット
ーーーーーーーーーー
>>>>>>>>>>>>>>>>>>
工事の指示をするQRコードの中身
>>>>>>>>>>>>>>>>>>
ーーーーーーーーーー
ー初期バージョンであることを示すために始めの1bitを1とする(1bit)
1bitx1=1bit
ーーーーーーーーーー
ー下記QRコードのいずれかを表す情報(最低3bit)
交差点のちょっと前に配置するQRコード1
交差点のちょっと前に配置するQRコード2
交差点の始端1に配置するQRコード
交差点の終端1に配置するQRコード
道路の分岐前に配置するQRコード
もうすぐQRコードが来るので読み取り頻度MAXにして下さいと知らせるQRコード
駐車場データの短距離通信のONOFFを指令するQRコード
工事の指示をするQRコード
3bitx1=3bit(種類を増やすなら3bitより多くなる)
ーーーーーーーーーー
ー工事用タグのタイプはA~Dのどれか(2bit)
ーーーーーーーーーー
タイプAの場合
ー工事場所は交差点上かはしごの道路標示上か(1bit)
ー今いる車線はそのまま進んで安全か(1bit)
ー左に何車線までそのまま走ると危険か(5bit)
ー左に何車線までなら車線変更しても安全か(5bit)
ー右に何車線までそのまま走ると危険か(5bit)
ー右に何車線までなら車線変更しても安全か(5bit)
ーーーーーーーーーー
タイプBの場合
ー今いる車線はそのまま進んで安全か(1bit)
ー左に何車線までそのまま走ると危険か(5bit)
ー左に何車線までなら車線変更しても安全か(5bit)
ー右に何車線までそのまま走ると危険か(5bit)
ー右に何車線までなら車線変更しても安全か(5bit)
ー工事している所の制限速度(0km~300kmの10km単位)(5bit)
ー何メートル先から工事が始まるか(0mで始まらない)(20bit)
ー何メートルの間で工事が設定されているか(20bit)
ーーーーーーーーーー
タイプCの場合
ー交差点上の工事範囲を本発明のアルゴリズムで表現する。
ーーーーーーーーーー
タイプDの場合
ーこの工事は対向車線に入らなければ避けれない工事か(1bit)
ー交差点で何番目の分岐に入ると工事しているか(5bit)
ーーーーーーーーーー
【0022】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・交差点形状を示すQRコードの方向補正について
このままだとはしごの道路標示の終端に付けるQRコードの設置方向がとてもシビアになる。交差点で25m先を示している場合、QRコードの設置角度が1度でもズレたら交差点の形状が正しく伝えられない。
そこで、交差点の形状をおおよそ把握してQRコードの角度を補正するアルゴリズムが必要となる。車両に取り付けたカメラからの画像をニューラルネットワークを用いて道路の範囲を予測し、本発明で表現されたマップと照らし合わせて、はしごの道路標示の終端のQRコードの向きを補正すれば良さそうな気がする。
【0023】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・車線変更について
自動運転車の側面または前方または上に取り付けられたカメラで他車線のはしごの道路標示を読み取ってそこに移動すれば良い。はしごの道路標示が途切れている場合に車や人間といった障害物がそこにいることが分かる。
DNNで認識した、多分道路の上に乗った何かを検出するのではなく、はしごの道路標示の上に乗った障害物を認識すれば良いので難易度は格段に下がる。はしごの道路標示の幅が1mと決まっている場合、左右にあるはしごの道路標示の位置はDNNを使わなくても認識は可能だと思われる。補助でDNNを使用しても良い。
【0024】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・工事について
工事している部分は2つに分けることができる。交差点上と、はしごの道路標示上の2つである。
はしごの道路標示上を工事している場合は、片側の車線の数が2以上ならば車線変更だけで良いが、1車線の場合、対向車線を走行する必要が出てくる。現在の技術では対向車線を走るのは危険極まりないため、そもそもとして、片側1車線の工事しているところには入らないようにする。そのため、はしごの道路標示上の工事時には、まずは車線を変更させるQRコードで車線変更させて、特定の方向へ道路を曲がることを制限するQRコードを配置し、それでも工事している道路へ入った時用に車線を変更させるQRコードで車線変更させる、必要がある。
交差点上を工事している場合は、本発明で表現する交差点の形状から、通行不可な領域を新たに設ければ良い。
後述するRFIDにQRコードの情報を全て保存する場合、はしごの道路標示の始端と終端のタグに「工事の指示をするQRコードの中身」を書き込んで車線を規制する。
工事用タグのタイプAは、工事しているはしごの道路標示が接続する交差点に繋がるはしごの道路標示の始端タグにデータを追加する。
工事用タグのタイプBは、工事しているはしごの道路標示の始端のタグにデータを追加する。工事用タグのタイプBは車線が外の方を優先する。例えば左に3車線は安全で、左に1車線は危険な場合、左に2車線目と3車線は安全で左に1車線目が危険とする。例えば左に3車線は危険で、左に1車線は安全な場合、左に2車線目と3車線は危険で左に1車線目が安全とする。例えば3車線の道路の真ん中を走行していて、今いる車線にいて欲しくない場合、左に1車線は安全で、左に0車線は危険とすれば良い。また、この情報は重複して与えられても大丈夫なように設計する。例えば、交差点間では、複数の工事用タグがある場合、全て考慮して運転する必要がある。
全ての車線で工事している場合は、車両の制限高さを0mにして、道路自体を通行止めとすればよい。
はしごの道路標示上を工事していた場合の工事用タグのタイプAとタイプBとタイプDの配置場所を図8に示す。
交差点が工事していた場合の工事用タグのタイプAとタイプCの配置場所を図9に示す。
工事をさらに安全にするために、工事看板は車の後ろ姿の写真とし、「工事中」の文字を車に被らないように重ねると良い。「工事中」の文字が見えなくても車間距離を空ける機能で最低でも停止する。車の写真のブレーキランプが赤くなっているとなお良い。プログラム側の処理としては停止している車両の上方に「工事中」の文字やマークやQRコードが浮いていれば工事中であると判断させればよい。工事看板の例を図5に示す。図5の真ん中に書いてあるのは車の後ろ姿です。
峠道といった、1本迂回するだけで距離が大きく変わる場合、工事用のQRコードを読み取って、ルート変更した場合に、音声かなにかで搭乗者にお知らせする方が良い。例えば、「工事によって100km目的地が遠くなりました。工事場所の手動運転を行いますか」といった案内である。無視しても100km多めに走れば良いだけだが、効率を考えると、工事場所だけ手動運転した方が良い。
お金がかかるが片側1車線の道路工事のすれ違いを全自動にする場合は、移動式の信号を設置してしまえば良い。交差点は対向車線の道路内に設定し、その入り口に交互に青になる信号を設置すればよい。移動式の信号の場合、工事用に新しく一時設置するタグの数が少なくなる。しかし、移動式の信号の場合、交差点上の工事には対応しにくい。
【0025】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・すれ違いについて
すれ違いについては、別途すれ違える場所を示したQRコードが必要となる。
例えば道の広い場所に特定のQRコードを配置しておき、前方から車両が来た場合にすれ違い可能なQRコードの位置までバックすることが考えられる。すれ違いに関しては、搭乗者にジャンケンのゲームを行わせても良いし、普通にランダムに戻る方を決めても良い。また、より遠くに移動しようとしている方を優先にしたり、バックした回数が多い方を優先にしたり、その道の開始からの距離が短い方がバックしたり、といったことが考えられる。バック自体はライントレースするだけである。
【0026】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・道路のマンホールについて
マンホールははしごの道路標示と道路の色のどちらでもない色に塗っておけば、ソフト側で対応可能です。例えば赤色にマンホールを塗っておき、赤色をラインカメラで読み取ったら、直前の色を読み取ったものとしても良い。
【0027】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・グレーチングについて
グレーチング等ではしごの道路標示が途切れることがあります。その対策として、車の前と後ろと真ん中の3ラインにラインカメラを取り付けます。前のセンサがグレーチングによってはしごの道路標示を見失ったら、真ん中と後ろのラインカメラでライントレースすれば問題無いと思われます。
【0028】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・信号の認識について
名古屋等で信号機と通信させる実証実験が既に有るので、それを利用すれば良いと思います。
交差点の信号の色(応用すれば列車の時刻表も可だと思う)と交差点の形状と道路の形状が分かって、歩道橋などで歩行者を分離すれば、限りなく安全な自動運転は可能だと思われます。
必要な技術としては、交差点の信号の色と交差点の形状が分かっている場合に、交差点を安全に自動運転で左折する技術である。
また、実証実験とは別の方法で信号機との通信を実現したい場合も説明する。信号機はLEDの塊である。つまり、各色ごとのLEDの内の1つを送信回路にすれば良い。図7の005のQRコードの情報に、見るべき信号機ナンバーを追加して、各信号機のLEDの内の1つから信号機ナンバーとONかOFFかを送信すればよい。LEDと同じ電圧で動作し、電流の流れている間だけ情報を発信する装置を作れば、LED式の全ての信号機をほぼ未改造のまま自動運転車用に改造できる。心配ならLEDの内の2つを送信回路にすればよい。この方式の場合、回路の交換修理も容易である。コンデンサを付ければ回路をONにしたままにでき、前回消灯時からの時間を計測することで、次に赤になるまでのおおよその時間を予想して送信することもある程度は可能である。
【0029】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・高速の入り口について
既に存在する発明として高速道路の入り口に信号を付ける方法が考案されている。高速道路の入り口に車両感知式の信号機がついていれば、自動運転車が限りなく安全に高速道路に入ることができる。
高速に乗って目的地まで行く際に、インターで右側に行かなければいけない時は車線変更が必要となる。高速で左車線を走るだけで目的のインターに着く場合、パーキングエリアからぺーキングエリア間の車線変更の回数はゼロとなる。車線変更が必要な場合でも、インターに着くまでの長い距離のどこかで1回車線変更すれば良いだけである。
【0030】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・自動運転車だと周りから判別する方法
自動運転車の証としてに動物の尻尾をつける方法が考案されています。モーターで動いたり、車内の状態に応じて動くと他の特許を侵害するので、動かない単なる尻尾を自動車登録番号標に生やすといいと思います。
【0031】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・高速から近くのパーキングエリアまでの運転について
具体的なパーキングエリアの位置を図2に示す。パーキングエリアの土地自体は比較的どこでも良いが、高速の出入口の配置が重要である。4つの出入口が良い感じに並んでいれば、左に曲がるだけでパーキングエリアに入ることができて、パーキングエリアから出て左に曲がるだけで再び高速に乗ることができる。高速の出口の位置さえ正しく配置されていれば、一番左の車線から車線変更なしで、左に曲がるだけでパーキングエリアにたどり着く。パーキングエリアがインターに近ければ近いほど、交差点を歩道橋にする数が減る。
図2の場合、高速道路の下道が、インターのある部分だけ細くなる。対策としては、インターから降りて出た車線は左に曲がる専用とし、パーキングエリアをインターの左右に配置する方法が考えられる。
【0032】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・マルチコプターについて
道路になら墜落しても良いので、道路の上のみをライントレースさせることができれば比較的安全に飛行させることが可能となります。もしも車に落下しても車が守ってくれると思います。
ただし、はしごの道路標示の上に自動車が乗った状態でラインを認識する必要があるので、少し誤動作の可能性があります。
マルチコプター用に自動運転車の上部には、はしごの道路標示(縦棒とふみさん1段から2段)を記載しておいた方が良いかもしれません。
【0033】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・実証実験のおおよその流れの例について
以下の順番で実験すると良いと思います。
ーーーーーーーーーー
1.実験都市の道路にはしごの道路標示を記入して、除雪車でライントレースしながら除雪しつつ、自動走行させる。
2.はしごの道路標示に出資したい企業を募って全国の高速にはしごの道路標示を記載して、高速近くのパーキングエリア同士をトラックで自動運転させる。
3.一般車で、高速道路近くのパーキングエリア同士を自動運転させる。
4.マルチコプターで高速道路近くのパーキングエリア同士を自動運転させる。(空飛ぶ車に応用できる)
5.大通り限定で拡大して自動運転させる。
6.対向車が来るかもしれないで道など、細い道にも拡大して自動運転させる。
ーーーーーーーーーー
人が乗るといった大きいマルチコプター用に特別しないといけないことは、車がくぐり抜けられて、上から読み取れる交差点形状を表すQRコードの看板を用意するぐらいである。交差点を上手く処理できるなら、地上のはしごの道路標示と車の天井の模様だけでパーキングスポット同士を自動運転できるので、技術の発展次第では何も追加しなくても空飛ぶ車が実現可能だと思います。後述するrfidならば上から読み取るだけだが、車が居る場合に読み取れない。そのため、上からrfidを読み取られたら道路の読み取った情報を上に送信する機能があった方が良い。
【0034】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・3次元のQRコードについて
既存のQRコードやiQRコードを用いても良いが、それだと本発明の情報をQRコードに印刷する場合に、49x49マス程度で、1マスが2cm程度のQRコードを道路に印刷しなければいけない。そこで、QRコードに改良を加えてiQRコードよりもさらに情報を圧縮できる道路に印刷可能な3次元のQRコードを考える。
カメラの発達により、QRコードは白黒である必要が無い。そこで画像認識を確実にできる白色赤色緑色青色黒色の5色を使ってQRコードを描く。しかしそのままではマス目を少なくできない。マス目を最小にするには、全ての色のQRコードを同時に描画すれば良い。
例として、赤色緑色青色が全て重なるなら白色。全て塗らない場合は黒色。赤色と緑色だけ重なる場合は黄色で塗る。緑色と青色が重なる場合はシアンで塗る。赤色と青色が重なる場合はマゼンタで塗る。赤、黄、緑、シアン、青、マゼンタ、白、黒の計8色でQRコードを作成する。8色ぐらいなら確実に読み取れる。また、実際に読み取り装置を製作する場合も、赤色のガラスを付ければ赤色のデータだけ、緑色のガラスを付ければ緑色だけ抜き出すことができる。もちろんフルカラーで読み取って色を分別しても良い。
これで道路に塗れる3次元コードとなる。本発明の方法では1つの従来のQRコードに600bit程度の情報を付与する必要があるので、誤り訂正レベルHのバージョン8のQRコードを道路に印刷する必要がある。しかし、3次元のQRコードを使うことで、マス目の数を1/3に減らせるため、誤り訂正レベルHのバージョン3のQRコードを道路に印刷するだけで良くなる。
と、ここまで書いたが、調べてみるとPMコードなる名前で検索すれば出てきました。PMコードならマス目を小さくできます。
あと数年で20年間経過して自由に使えるようになります。今すぐ使いたかったら減法混色で実現する必要があります。
例えば、赤、黄、緑、シアン、青、マゼンタ、白、黒の計8色でQRコードを作成するのは変わりませんが、ベースの色が黄色、シアン、マゼンタとなり、3色とも無い場合は白色、3色とも重なる場合は黒、黄色とマゼンタが重なる場所に赤色を使ってQRコードを作成します。読み取る場合は、カメラからの読み取り画像を8色に減色して色ごとに分けるしかありません。
減法混色の場合まで特許になっていたらもう知らないです。加法混色と減法混色の2つで安い方を使えば良いと思います。
【0035】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・DNNの必要な場面
交差点をより安全に曲がるための補助に必要かもしれないです。
合流で必要かもしれないです。
車線変更時に必要かもしれないです。
前の車と距離を取るのに必要かもしれないです。
はしごの道路標示の上にビニールとかが乗っている場合に轢いて良いか判断するのに必要です。
はしごの道路標示の上に人が飛び出してきた場合に止まるのに必要かもしれません。
交差点に横断歩道がある場合に、横断歩道の上に人がやってきそうだからと停止するのに必要です。
道路の反対側から車が来たときにいち早く認識するのに必要かもしれないです。
形状の分かっているはずの交差点で迷子になった時の運転に必要です。
【0036】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・QRコードではなくRFIDタグにて実装する場合について
ここまで書いて、QRコードでは工事に対応できないことに気付きました。そして容量的にRFIDでも同様のことが実現できることに気付きました。
データの容量の観点から、日立のミューチップライクなRFIDx2と、消えても良い何回でも書き込み可能なRFIDを1つ追加した3チップ構成のカードを作ります。交差点の情報は書き換え不可なミューチップに書き込んで、工事の情報は書き換え可能なタグに書き込みます。工場で書き込みではなく車両に載せられる規模の機械で書き込みができると良い。
図7の003の終端のQRコードと、004のQRコードと、005のQRコードは、はしごの道路標示の終端にあるタグに全て格納しても良い。全て終端に配置することによる弊害は、交差点の形状を知ることができるのが、交差点に入る直前となる。004と005の情報は交差点に入る少し前に知りたい。
006のQRコードは無くしても良い。
はしごの道路標示の終端には塗料やGNSSのデータ等といった何らかの基準点が必要となる。基準点が無いと、交差点の形状が定まらない。
RFIDを読み込む装置をONにするQRコードを用意するか、読み取り装置を常にONにする必要がある。例えば60km/h以下で走行中のみONにする等も考えられる。
3チップ構成だと、予備が無いので、全く同じ内容が書き込まれた3チップ構成のタグをすぐ隣に配置しても良い。
UHF帯のRFIDの読み取り速度に関する文献が見当たらないので、車両が移動している状態での読み込み速度が足りるかは不明です。
【0037】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・QRコードやRFID読み取り装置のONOFFについて
QRコードをRFIDに変更しても、はしごの終端と始端のマークと、RFIDかQRコード読み取り装置のONOFFを切り替えるマークの3つは道路に描く必要がある。そこで図11のようにはしごの道路標示を読み取るラインカメラで読み取り可能なマークを付けることで、RFIDのタグがもうすぐ存在していることを伝える。例えば、図11のふみさんを読み取った場合、次のふみさんにRFIDが埋まっていることとする。
はしごの道路標示の終端のタグ(図7の003と004と005)は最後のふみさんに埋まっている必要は無く、最後から10つ目等のふみさんに埋まっていても良い。終端に求められるのは交差点の基準となることだけである。そこで、ふみさんが約25cmであることを利用して、図12のようにはしごの道路標示の終端のふみさんに基準点を設ける。交差点の基準をふみさんに記載し、交差点の情報は数個前のふみさんに格納する。そうすることで、QRコードを配置しなくても済む。基準点は読み取りやすければ何でもよい。最後と最初のふみさんに基準点を設ける関係で、カーブのふみさんの幅は25cmの長方形(台形ではない)にする必要がある。
始端のタグ(図7の002)は始端にある必要は無い。単に法人番号等の情報は始端から数本目のふみさんに埋め込まれたRFIDを読み取って取得すればよい。始端のふみさんは基準点があるだけで良い。そこで、図12の終端のふみさんをそのまま始端にも配置すると良い。本発明のアルゴリズムではその場でくるくるを数回転することで別のはしごの基準点を示し、終端のふみさんの基準点は厳格な位置決めが必要だが、始端の基準点はおおよそで良い。おおよそそこにあればはしごの道路標示を読み取れば良いだけである。
【0038】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・自動倉庫との連携について
はしごの道路標示タイプの自動運転車が実現するとできることとして、自動倉庫との連携が挙げられる。自動倉庫のラックをトラックの荷台に付けて、スタッカークレーンで直接荷物をトラックに入れることも金さえあれば可能である。
例えば人間がトラックに乗っている場合、100km/h超えの速度でスタッカクレーンが横を通り過ぎるので安全上問題がある。しかし、無人であれば安全上の問題は無い。(300km/hの自動運転車ができたら、相対速度がMAX600km/hですれ違う事になるのは考えないでおく)また、トラック荷台の位置決め精度に関しては、はしごの道路標示の終端やふみさんを停車位置とし、タグの種類に自動倉庫用を追加することで、前後左右方向の誤差を1センチにすることも期待できる。そしてトラックに取り付けたアウタートリガーをおろし、床に空いたすり鉢状の穴に突き刺すことで、ラックの位置決め精度を高くする。自動倉庫の開発・販売等している会社の開発者に簡単に尋ねたところ、「規格の問題と、トラック整備の問題がある。トラック業者は個人も多くて普及が難しく、考えは難しくないけど商売にはならないかな」という旨の回答を戴いた。
誰か是非どうぞ。金で解決しちゃってください。
【0039】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・総括
はしごの道路標示を道路に描いて、始端と終端近くのふみさんにRFIDタグのカードを貼り付けて、RFIDタグの読み取り装置とラインカメラを従来の自動運転車に追加して、信号機のLEDと同じ動力で動く信号の色送信機を作れば、最高速度300km/hの自動運転車が実現できるはずです。300km/hは無理でも、60km/h程度は普通に出せそうです。
高速道路とインターから降りてすぐの場所の自動運転は、人と出遭わないので、事故の責任の所在がはっきりしています。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
【課題を解決するための手段】
【0040】
従来のはしごの道路標示を使用する上で、問題として交差点の形状をどうやって表現するかという問題がある。
そこで以下の方法を用いて交差点の形状を表現する。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(請求項1)
1点から見た交差点の形状を保存するアルゴリズムであって、
前記保存とは、
1次元コードや、2次元のコードや、タグや、ハードディスクや、SSDや、ROMや、RAMといった、情報を保存できる媒体に情報を蓄えることを特徴とし、
前記交差点とは、
交差点とは、道路の交わる部分や、道路の行き止まり(袋小路)の先の部分や、横断歩道といった道路と歩道の交わる部分や、歩道を挟んで道路の交わる部分や、道路の合流地点や、道路の分岐地点や、急な曲がり角や、ビルの壁や、部屋の天井といった、道の接続部であることを特徴とし、
前記アルゴリズムとは、
交差点の1点に置かれた、一定サイズの立方体を、鉛直上側から突き刺すZ軸を中心とするその場での回転方向か、回転移動方向か、平行移動方向の中の、いずれか2方向で1ビットの情報を持つ、前記2方向の中から、好きな方向に、90度ずつ、立方体を回転移動または平行移動させていき、前記立方体が通過した部分でできた閉ループを、前記交差点の形状とすることと、
同じ方向に複数回、前記回転方向または回転移動方向または平行移動させることで同じ位置同じ姿勢に戻ることを利用して、横断歩道などの交差点に存在するオブジェクトの位置を表現することを特徴とする、交差点の形状を保存するアルゴリズム。を用いる。
また、
(請求項2)
前記平行移動方向のみで構成される1bitの場合、常に転がった方向を前といった、一方向と定義しなおし続けるという特徴を有する請求項1に記載の
交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項3)
前記アルゴリズムは、
立方体がスタート地点に戻ってきたらデータの終わりを示すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項4)
前記立方体の一辺の長さが25cmであることを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項5)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、横断歩道や歩道といった、人の存在するエリアの開始と終了を表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項6)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、はしごの道路標示の開始位置を表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項7)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、この先ははしごの道路標示が無いことを表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項8)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、パーキングスポットといった駐車可能なエリアの開始と終了を表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項9)
前記アルゴリズムは、
前記立方体が通過した部分でできた閉ループの内側のかどを立方体の一辺の長さで面取りした範囲を交差点とすることを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項10)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、車両の発生ポイントを表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項11)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、2点を指定し、2点の間に読み取るべき信号機があることを表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項12)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、立方体を後ろに向かせることを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項13)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、2点で示す線で道路が90度手前側に折れ曲がっていることを表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項14)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、2点で示す線で道路が90度奥側に折れ曲がっていることを表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項15)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、道路ではなくビルとビルの間といった空中を表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項16)
前記2方向の内の1方向を選択した場合だけ、1回の選択で1回転がし、2回連続で選択した場合に3回同じ方向に転がし、3回連続で選択した場合に4回同じ方向に転がし、5回連続で選択した場合に8回、6回連続で選択場合に12回といったように、以降連続で同じ方向が選択されたときに、転がす回数が4回ずつ増加することを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項17)
前記2方向の内の1方向を選択した場合だけ、1回の選択で1回向きを変更し、2回連続で選択した場合に3回同じ方向に向きを変更し、3回連続で選択した場合に4回同じ方向に向きを変更し、5回連続で選択した場合に8回、6回連続で選択場合に12回といったように、以降連続で同じ方向が選択されたときに、向きを変更する回数が4回ずつ増加することを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いたり、
また、
(請求項18)
前記アルゴリズムは、
一定回数連続で左か右に転がす、もしくは向きを変える命令にて、線路の範囲を表すことを特徴とする、請求項1に記載の交差点の形状を保存するアルゴリズム。を用いることで解決する。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
【図面の簡単な説明】
【0041】
図1】はしごの道路標示(規制標示)の例
図2】インター周辺の例
図3】ダイヤマークと共存するはしごの道路標示の例
図4】分岐するはしごの道路標示の例
図5】自動運転車用工事看板の例
図6】QRコードの記載例1
図7】QRコードの記載例2
図8】道を工事していた場合の例1
図9】道を工事していた場合の例2
図10】アルゴリズムの補助の例
図11】rfidやQRコードがもうすぐ来るのを表示するふみさんの例
図12】終端のふみさんの例
図13】交差点の例1
図14】交差点の例2
図15】交差点の例3
図16】交差点の例3の展開図
図17】交差点の例4
図18】かどにシンボルが来たときの処理1
図19】かどにシンボルが来たときの処理2
図20】実際の交差点の例
【発明を実施するための形態】
【0042】
まず、交差点の2次元データを取得しなければいけない。交差点の形状を取得する方法は、最新VRゴーグル(2019年製)に搭載されている「部屋の領域」の設定を流用する。(ガーディアン設定で検索)最新のVRゴーグルは部屋の領域を設定でき、部屋から出そうになると注意喚起する。それの部屋設定と同じ方法で交差点の形状を設定する。交差点の領域を設定したら、横断歩道等を設定していく。はしごの道路標示の始端や終端はQRコードの位置を読み込めば良い。そうすれば後は本アルゴリズムで交差点の領域データを小さくしてタグに書き込むだけである。大きな交差点は地道に測定するしかないが、小さな交差点はVRで領域指定すれば効率良く設定できる。本発明のアルゴリズムはVRゴーグルでの領域設定と相性が良い。
以下にVRゴーグルで作成したガーディアン設定のデータを用いて本アルゴリズムの情報に変換する例を示す。(左回りで領域を作成する場合)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・ガーディアンのデータから2次元のマップに展開する
・while(元の位置に戻ってくるまで繰り返すOR特定の長さのデータ長になるまで繰り返す)
{
・if(左に転がす領域がある
{
左に向きを変える
前に1回転がす
}
・elseif(前に転がす領域がある)
{
前に1回転がす
}
・elseif(右に転がす領域がある)
{
左に2回向きを変える(実質的に右を向く)
前に1回転がす
}
・else
{
・if(前々回は左に向きを変えた)
{
処理を2回戻す(前、左、を戻す)
・while(前に転がす領域ができるまで)
{
左に2回向きを変える(実質的に右を向く)
}
前に1回転がす
}
・elseif(前々回は前に向かって転がした)
{
処理を1回戻す(前、を戻す)
左に2回向きを変える(実質的に右を向く)
・while(前に転がす領域ができるまで)
{
処理を3回戻す(左、左、前、を戻す)
左に2回向きを変える(実質的に右を向く)
}
}
}
・if(他のはしごの道路の始端におおよそ重なった)
{
左に4回向きを変える(向きは変わらない)
前に1回転がす
}
・elseif(横断歩道や歩道といった歩行者がいるかもしれない領域に侵入した)
{
左に3回向きを変える(向きは変わらない)
前に1回転がす
}
・elseif(横断歩道や歩道といった歩行者がいるかもしれないの領域から出た)
{
左に3回向きを変える(向きは変わらない)
前に1回転がす
}
・elseif(交差点のXXの範囲に侵入した)(XXは何でもよい)
{
左に5回向きを変える(向きは変わらない)
前に1回転がす
}
・elseif(交差点のXXの範囲から出た)(XXは何でもよい)
{
左に5回向きを変える(向きは変わらない)
前に1回転がす
}
・elseif(交差点に置かれたXXの場所)(XXは何でもよい)
{
左に6回向きを変える(向きは変わらない)
前に1回転がす
}
}
・交差点の形状を2次元配列にマッピングし、横断歩道などの情報を3次元方向にマッピングする。
・幅が2マスしかないような小さな突起を無くす
(縦横9マス(2m25cm)の正方形を配置できないマスは除外する。図10参照)
・突起を無くした領域を上記のwhile文と同じ要領でもう一度囲む
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
前提条件として、ガーディアンの端に交差点の開始点があるものとする。
【0043】
次に十字の交差点を本アルゴリズムで表現する例を図13に沿って説明する。なお、左を向くか、前に転がるかの1bitの方向で交差点の形状を表現する。図13をのバツ印をスタートとして、左回りに一周し、閉ループを交差点の形状とする。バツ印に置かれた立方体は最初、左を向いているものとします。なので、最初のかどまではまっすぐ転がります。(前、前、)そして最初の右折は左に2回回転する命令を与えます。(左、左、)次のかどまで真っすぐ転がります。(前、前、前、前、)左折します。(左、)横断歩道のあるところまで真っすぐ転がります。(前、)横断歩道に入ったので、その場で一回転します(左、左、左、)横断歩道の2つ目のかどまで直進します。(前、)横断歩道の2点目に来たので1回転します。(左、左、左、)次のかどまで真っすぐ転がります。(前、前、前、)右に曲がります(左、左、)他のはしごの道路標示の始端にある基準点まで直進します。(前、前、前、)他のはしごの道路標示の始端にある基準点を表現したいのでその場で2回転します。(左、左、左、左、)次のかどまで真っすぐ転がります。(前、前、)右折します。(左、左、)横断歩道の3点目まで真っすぐ転がります。(前、前、前、)横断歩道の3点目に来たので、1回転します。(左、左、左、)横断歩道の4点目まで真っすぐ転がります。(前、)横断歩道の4点目に来たので、1回転します。(左、左、左、)2つ目の他のはしごの道路標示の始端にある基準点まで進みます(前、左、前、前、前、前、左、左、前、前、) 2つ目の他のはしごの道路標示の始端にある基準点まで来たので2回転します。(左、左、左、左、) 3つ目の他のはしごの道路標示の始端にある基準点まで進みます(前、前、前、左、左、前、前、前、前、左、前、前、前、前、前、左、左、前、前、)3つ目の他のはしごの道路標示の始端にある基準点まで来たので2回転します。(左、左、左、左、)スタート地点まで戻ります。(前、前、前、左、左、前、前、前、前、前、左、前、前、前、前、左、左、前、前、前、)スタート地点に戻ってきたので残りは閉ループにならないよう、前にずっと転がしておきます(前、前、前、前、前、前、、、、、、)以上で図13の交差点を最低100bitのデータで表現できました。
横断歩道は4点の座標指定で表現できます。また、アーチ状の形の横断歩道があった場合はアーチを囲える四角形で表現します。なお、横断歩道が2本ある場合は5点目から8点目が追加されるだけです。5点目から8点目も変わらず、1回転をすることで横断歩道があることを示します。
請求項11に示すように、例えば5回回転させることで、後ろを向くことができれば、面積ゼロの線を伸ばすことができる。そのため、道路の外周部よりさらに外側の何かの位置を表現する事ができる。例えば見るべき信号などが道路の上に無い場合、信号の位置まで線を伸ばして、信号のことを表して、後ろを向いて、元の道路上まで戻ってこればよい。
【0044】
実際に存在するもう少し大きい交差点の例を挙げる。片側3車線の道路の交差点について考える。図14のように、交差点では進める方向というものがある。片側1車線であれば図13の例にUターンを追加すればよい。しかし、片側の車線が2車線以上の場合、車線ごとに交差点の情報が異なっている方が良い。何故なら、交差点が歪曲している場合、2車線の輪郭を表現しても、どこを走ればよいか一意に決まりにくいからである。また、図14で一番左の車線から来たトラックが曲がる場合は、図14の矢印が分岐している全ての方向への道の輪郭を交差点情報とすることで、内輪差で入って良い場所とそうでない場所の計算が容易になり、経路生成が簡単になる。各車線ごとに交差点情報を登録することで、自然とトラックに対応することができる。
【0045】
次にマルチコプターといったドローン用の交差点を考える。例えば図15のような車用の道2つとマルチコプター用の道1つの計3つに分岐する道があるものとします。図15にはビルの上に分岐先の一つが有ります。そこは車両は走行禁止にしておき、マルチコプターのみ走行可能にします。そこで問題となるのが、交差点に10mの段差ができることです。本発明は2次元のデータのため、図16のように、ビルの段差を展開図にしてその交差点の輪郭を立方体でなぞります。その際、道路が折れ曲がった部分は2点で指定して、そこが壁であることを表現します。
ビルの側面全部を交差点で表現していると凹凸のあるビルだと事故になる可能性があります。そこで、図17のようにビルの壁の高さ1mぐらいまでを交差点とし、壁の途中からラインを引くことで、交差点の広さを狭くすることができる。ラインはマルチコプター用に細いものでも良い。しかし、人が乗るタイプのマルチコプター用に幅1mのはしごの道路標示をそのまま壁に描いてもいいと思われる。
2回折れ曲がることで天井を走行する事も出来ます。例えば高さ9mのトンネルがある場合、下側4.5mを車用とし、天井にラインを引いてマルチコプター用としても良い。
【0046】
交差点は基本的に地面の展開図の輪郭をなぞるが、一つだけ例外がある。それは空中をなぞっている場合である。例えば横のビルに移動したい場合、壁にラインを描いていると地上まで降りる必要がある。そこで、高さを変えない場合限定で、空中を表現できるようにする。すると、ビル間で、同じ高さに窓がある場合にマルチコプターは窓の間を移動できる。
【0047】
かどに横断歩道などのシンボルが来た場合は、立方体の転がる進路を図18のようにルートを膨らませても良いが、1マス戻るのが確実である。その場で数回回転して前に1マス進んだら方向そのままに1マス進まなかった事にするのが良い。例えば図19の場合、バツ印からスタートして最初のかどに横断歩道のシンボルがあるとする。本発明の方法で表現すると、(前、前、前、左、左、左、左、左、前、左、左、左、左、左、左、左、左、前、左、前、前、前)となる。横断歩道があることはその場で3回回ることで表現し、1マス戻ることは6回回って前に1回進むことで表現する。
【0048】
例として実際の交差点を本発明のアルゴリズムで表現してみる。図20のAからスタートするものとする。交差点を時計回りに回る場合、前と左ではなく、前と右の2つにした方が数bitデータ量が少なくなる。別のはしごの道路標示の始端を表す場合はその場で1回転するものとする。(右に3回動くと右に4回動いたことになる)また、交差点の基準点で最初から左を向いているものとする。
立方体の大きさは25cmとする。
図20の横断歩道を無視した場合の変換例を下記に示す。なお、図20の場合、左側の横断歩道のみ横断歩道として登録するため、40bit程度の追加となる。
ーーーーーーーーーーーーーーーーーー
・AからB
前、前、前、前、前、前、右、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、
・BからC
前、前、前、前、前、前、右、右、前、右、前、前、右、右、前、右、前、前、右、右、前、右、前、右、右、前、右、前、右、右、前、右、前、右、右、前、右、前、右、右、前、右、前、右、右、前、前、右、前、右、右、前、前、右、前、右、右、前、前、前、前、前、
・CからD
前、前、前、前、前、前、前、前、前、右、前、前、前、前、前、前、右、右、右、前、前、前、前、前、前、前、前、前、前、前、前、前、右、右、右、前、前、前、前、前、前、右、前、前、前、前、前、前、前、前、前、
・DからE
前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、
・EからF
右、右、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、
・FからG
前、右、前、前、前、前、前、前、右、右、右、前、前、前、前、前、前、右、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、前、
・GからA
前、前、前、前、前、前、前、前、前、右、前、前、前、前、前、前、
ーーーーーーーーーーーーーーーーーー
この例は実際にプログラムで作った物ではないので間違っている可能性が有る。おおよその作り方を学ぶのに活用してください。
図20の交差点形状が約374bitで表現できた。横断歩道を含めても410bit程度の情報量となる。横断歩道を追加する場合に、かどから横断歩道が始まっているならば、横断歩道の領域に入ったら、「右、右、右、右、前、右、右、右、右、右、前」を入れる事になる。かどではなく、直線状で横断歩道の領域を表す場合、「右、右、右、右、」を入れるだけである。
実際には道路は斜めになってたりするため、もう少しデータ容量が増加する。
信号との通信を考えて、自分の読み取るべき信号のおおよその位置を表しても良い。その場合、立方体の通った道を通りなおしている場合、通ってなかったことにする必要がある。例えば何回かその場で回転すると、真後ろを向けるようにする。先ほど登場した1マス戻る時に後ろを向くようにすると良い。
【0049】
実施例をまとめると、基本的には前と右の1bitの方向で閉ループを表して、横断歩道といった交差点上のシンボルや、1マス戻りたいといった特殊な操作は、その場での回転に任せる形です。
【感想】
【0050】
発明は趣味なのでお金目的じゃないです。誰か利用してくれて、お金が貰えたらそのお金でアニメを作りたいなって思っています。
自分は教習所で道路の逆走をしたり、歩道を走ろうとしたりしたし、アクセルとブレーキを普通に公道で間違えて何回かぶつかりかけるぐらい運転が苦手なので、どんな方法でもいいからさっさと、めっさ安全な自動運転車を実現して欲しいです。
300km/hぐらい出れば自動運転でもスリリングに乗れると思い、目標を300km/hで設定しました。(ジェットコースターに乗る感覚)
あくまでも真っすぐな見通しの良い高速があれば理論上300km/h出る気がするだけです。線を書くだけなら簡単にできますが、実際にできるかどうかは未知数です。60km/hとか低い目標なら容易に実現できそうですが、自動運転車が1回普及すると仕様変更が難しいので、普及する自動運転車はやっぱりロマンを追い求めて300km/h出して欲しいですね。
自分が出願した物と同一の発明を外国へ出願することに関しては、一言連絡していただければ名前を貸します。自分に対して特に何も払わなくていいです。誰も欲しがらない自分の発明を使おうと思って貰えただけでありがたいです。できればアニメ制作の支援をして頂けると助かります。あと、世界中を自動運転車用のはしごで埋め尽くして欲しいです。
あと、もっとオープンカーの自動運転車とか作らないのでしょうか。300km/h出すならオープンカーの方が楽しいと思います。単眼でも複眼でも画像から深度情報が得られる時代ですし、屋根の上に全部載せる必要も無い気がします。
【符号の説明】
【0051】
1 なし
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20