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

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

▶ 株式会社デンソーの特許一覧

特開2025-87411支援システム、支援方法、支援プログラム
<>
  • 特開-支援システム、支援方法、支援プログラム 図1
  • 特開-支援システム、支援方法、支援プログラム 図2
  • 特開-支援システム、支援方法、支援プログラム 図3
  • 特開-支援システム、支援方法、支援プログラム 図4
  • 特開-支援システム、支援方法、支援プログラム 図5
  • 特開-支援システム、支援方法、支援プログラム 図6
  • 特開-支援システム、支援方法、支援プログラム 図7
  • 特開-支援システム、支援方法、支援プログラム 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2025087411
(43)【公開日】2025-06-10
(54)【発明の名称】支援システム、支援方法、支援プログラム
(51)【国際特許分類】
   G08G 1/00 20060101AFI20250603BHJP
   G08G 1/09 20060101ALI20250603BHJP
   G16Y 10/40 20200101ALI20250603BHJP
   G16Y 20/20 20200101ALI20250603BHJP
   G16Y 40/20 20200101ALI20250603BHJP
【FI】
G08G1/00 D
G08G1/09 V
G16Y10/40
G16Y20/20
G16Y40/20
【審査請求】未請求
【請求項の数】16
【出願形態】OL
(21)【出願番号】P 2023202046
(22)【出願日】2023-11-29
(71)【出願人】
【識別番号】000004260
【氏名又は名称】株式会社デンソー
(74)【代理人】
【氏名又は名称】矢作 和行
(74)【代理人】
【識別番号】100121991
【弁理士】
【氏名又は名称】野々部 泰平
(74)【代理人】
【識別番号】100145595
【弁理士】
【氏名又は名称】久保 貴則
(72)【発明者】
【氏名】今井 謙一郎
(72)【発明者】
【氏名】田中 基木
(72)【発明者】
【氏名】平山 泰弘
【テーマコード(参考)】
5H181
【Fターム(参考)】
5H181AA01
5H181AA27
5H181BB04
5H181BB20
5H181CC03
5H181CC04
5H181CC11
5H181CC12
5H181CC14
5H181FF04
5H181FF10
5H181FF13
5H181FF22
5H181FF27
5H181FF32
5H181MB01
(57)【要約】
【課題】適切なサポータへサポートを要請可能な支援システム等を、提供する。
【解決手段】支援システムは、プロセッサを有し、自律走行装置を支援する。プロセッサは、自律走行装置の動作履歴データを生成することを実行するように構成される。プロセッサは、自律走行装置の走行が阻害される状態としてのスタックの発生を監視することを実行するように構成される。プロセッサは、リカバリサポートレベルに対してマッチングするサポータへ、サポート要請データを出力することを実行するように構成される。リカバリサポートレベルは、スタックからのリカバリサポートを実行可能なサポータへ要請するスタックからのリカバリサポートのレベルである。リカバリサポートレベルは、スタックの発生タイミングから遡った動作履歴データに応じたレベルである。
【選択図】図4
【特許請求の範囲】
【請求項1】
プロセッサ(5)を有し、自律走行装置(10)を支援する支援システムであって、
前記プロセッサは、
前記自律走行装置の動作履歴データを生成することと、
前記自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
前記スタックからのリカバリサポートを実行可能なサポータ(20)へ要請する前記スタックからの前記リカバリサポートのレベルであって前記スタックの発生タイミングから遡った前記動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングする前記サポータへ、サポート要請データを出力することと、
を実行するように構成される支援システム。
【請求項2】
前記サポート要請データを出力することは、
前記動作履歴データから解析されるスタック要因別の前記リカバリサポートレベルにマッチングする人数の前記サポータへ、少なくとも前記サポート要請データを出力することを含む請求項1に記載の支援システム。
【請求項3】
前記サポート要請データを出力することは、
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルのレベル範囲が、前記動作履歴データに応じた前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む請求項1に記載の支援システム。
【請求項4】
前記サポート要請データを出力することは、
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルの前記レベル範囲が、前記動作履歴データから解析されるスタック要因別の前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む請求項3に記載の支援システム。
【請求項5】
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルの前記レベル範囲が、前記スタック要因から予測されるサポートリスクに応じた前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む請求項4に記載の支援システム。
【請求項6】
前記サポータの種別は、事前登録されてサポートサービスを専門とする、専門スタッフ(21)を含む請求項3に記載の支援システム。
【請求項7】
前記サポータの種別は、事前登録されて前記自律走行装置の周囲における位置条件を満たす場合にサポートサービスを提供する、臨時スタッフ(22)を含む請求項3に記載の支援システム。
【請求項8】
前記プロセッサは、
事前登録された前記臨時スタッフによる前記リカバリサポートに対して、インセンティブデータを出力することを実行するように構成される請求項7に記載の支援システム。
【請求項9】
前記サポータの種別は、前記自律走行装置の周囲における未登録の、他道路ユーザ(23)を含む請求項3に記載の支援システム。
【請求項10】
前記プロセッサは、
前記サポート要請データの出力に応答して前記自律走行装置にアクセスした前記他道路ユーザのユーザ情報を、登録することを実行するように構成される請求項9に記載の支援システム。
【請求項11】
前記プロセッサは、
登録された前記他道路ユーザによる前記リカバリサポートに対して、インセンティブデータを出力することを実行するように構成される請求項10に記載の支援システム。
【請求項12】
前記サポート要請データを出力することは、
複数種別の前記サポータがマッチングした場合において、前記レベル範囲の上限が最も低い種別の前記サポータに対して、優先的に前記サポート要請データを出力することを含む請求項3に記載の支援システム。
【請求項13】
前記サポート要請データは、前記自律走行装置から通信出力される、通信データを含む請求項1に記載の支援システム。
【請求項14】
前記サポート要請データは、前記自律走行装置の周囲へ報知出力される、報知データを含む請求項1に記載の支援システム。
【請求項15】
自律走行装置(10)を支援するために、プロセッサ(5)により実行される支援方法であって、
前記自律走行装置の動作履歴データを生成することと、
前記自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
前記スタックからのリカバリサポートを実行可能なサポータ(20)へ要請する前記スタックからの前記リカバリサポートのレベルであって前記スタックの発生タイミングから遡った前記動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングする前記サポータへ、サポート要請データを出力することと、
を含む支援方法。
【請求項16】
自律走行装置(10)を支援するために記憶媒体(4)に記憶され、プロセッサ(5)に実行させる命令を含む支援プログラムであって、
前記命令は、
前記自律走行装置の動作履歴データを生成させることと、
前記自律走行装置の走行が阻害される状態としてのスタックの発生を監視させることと、
前記スタックからのリカバリサポートを実行可能なサポータ(20)へ要請する前記スタックからの前記リカバリサポートのレベルであって前記スタックの発生タイミングから遡った前記動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングする前記サポータへ、サポート要請データを出力させることと、
を含む支援プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ホスト車両及び自動運転可能なターゲット車両の走行を遠隔支援する支援技術に、関する。
【背景技術】
【0002】
特許文献1には、搬送ロボットの運行を管理する管理センタが開示されている。管理センタは、搬送ロボットの走行不能状態からの復帰支援を含むサポート動作を実行した登録ユーザの識別情報と、サポート動作の内容と、を含むサポート情報を取得する。管理センタは、取得したサポート動作の内容に応じて、登録ユーザにポイントを付与する。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2021-64119号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、搬送ロボットに必要なサポートは状況に応じて異なり、当該サポートを実行するサポータの負担度合もサポートに応じて異なる。特許文献1の技術では、登録ユーザであれば一律サポートを要求するため、状況に応じたサポートを、適切なサポータに対して要請することはできない。
【0005】
本開示の課題は、適切なサポータに対してサポートを要請可能な支援システムを、提供することにある。本開示の別の課題は、適切なサポータに対してサポートを要請可能な支援方法を、提供することにある。本開示のさらに別の課題は、適切なサポータに対してサポートを要請可能な支援プログラムを、提供することにある。
【課題を解決するための手段】
【0006】
以下、課題を解決するための本開示の技術的手段について、説明する。尚、特許請求の範囲及び本欄に記載された括弧内の符号は、後に詳述する実施形態に記載された具体的手段との対応関係を示すものであり、本開示の技術的範囲を限定するものではない。
【0007】
本開示の第一態様は、プロセッサ(5)を有し、自律走行装置(10)を支援する支援システムであって、
プロセッサは、
自律走行装置の動作履歴データを生成することと、
自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
スタックからのリカバリサポートを実行可能なサポータ(20)へ要請するスタックからのリカバリサポートのレベルであってスタックの発生タイミングから遡った動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングするサポータへ、サポート要請データを出力することと、
を実行するように構成される。
【0008】
本開示の第二態様は、自律走行装置(10)を支援するために、プロセッサ(5)により実行される支援方法であって、
自律走行装置の動作履歴データを生成することと、
自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
スタックからのリカバリサポートを実行可能なサポータ(20)へ要請するスタックからのリカバリサポートのレベルであってスタックの発生タイミングから遡った動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングするサポータへ、サポート要請データを出力することと、
を含む。
【0009】
本開示の第三態様は、自律走行装置(10)を支援するために記憶媒体(4)に記憶され、プロセッサ(5)に実行させる命令を含む支援プログラムであって、
命令は、
自律走行装置の動作履歴データを生成させることと、
自律走行装置の走行が阻害される状態としてのスタックの発生を監視させることと、
スタックからのリカバリサポートを実行可能なサポータ(20)へ要請するスタックからのリカバリサポートのレベルであってスタックの発生タイミングから遡った動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングするサポータへ、サポート要請データを出力させることと、
を含む。
【0010】
これら第一~第三態様によると、自律走行装置のスタックが発生した場合に、スタックの発生タイミングから遡った動作履歴データに応じたリカバリサポートレベルに対してマッチングするサポータへ、サポート要請データが出力される。故に、リカバリサポートレベルに適したサポータに対して、サポートを要請することが可能となり得る。したがって、適切なサポータに対してサポートを要請可能となり得る。
【図面の簡単な説明】
【0011】
図1】第一実施形態の全体構成を示す概略図である。
図2】第一実施形態による自律走行装置の機能構成を示すブロック図である。
図3】第一実施形態による支援システムの機能構成を示すブロック図である。
図4】第一実施形態による支援フローを示すフローチャートである。
図5】第一実施形態による支援フローにおけるサポート要請データ出力処理の詳細を示すフローチャートである。
図6】スタック要因別に設定されるリカバリサポートレベル等の一例を示す表である。
図7】サポータの種別に応じたサポート可能なレベル範囲等の一例を示す表である。
図8】第二実施形態による支援フローにおけるサポート要請データ出力処理の詳細を示すフローチャートである。
【発明を実施するための形態】
【0012】
以下、本開示の実施形態を図面に基づき複数説明する。尚、各実施形態において対応する構成要素には同一の符号を付すことで、重複する説明を省略する場合がある。又、各実施形態において構成の一部分のみを説明している場合、当該構成の他の部分については、先行して説明した他の実施形態の構成を適用することができる。さらに、各実施形態の説明において明示している構成の組み合わせばかりではなく、特に組み合わせに支障が生じなければ、明示していなくても複数の実施形態の構成同士を部分的に組み合わせることができる。
【0013】
(第一実施形態)
図1に示す第一実施形態の支援システム3は、自動運転可能な自律走行装置10の外部施設であるリモートセンタ1において構築される。支援システム3は、複数のオペレータにより操作可能に構成されており、自律走行装置10の自動運転を遠隔支援する。自律走行装置10は、前後左右の任意方向に自律走行可能な自律装置(autonomous robot)である。尚、自律走行装置10は、自律走行車(autonomous vehicle)と称することもできる。自律走行装置10は、例えば自律走行により積載物を搬送する搬送車両である。又は、自律走行装置10は、積載物の搬送以外の用途(例えば情報収集等)に供されるものであってもよい。
【0014】
自律走行装置10には、図2に示す通信系11、センサ系12、地図データベース15、情報提示系16、及び制御システム17が搭載される。通信系11は、自律走行装置10により利用可能な通信情報を、無線通信により取得する。通信系11は、自律走行装置10の外界に存在するV2Xシステムとの間において通信信号を送受信する、V2Xタイプであってもよい。V2Xタイプの通信系11は、例えばDSRC(Dedicated Short Range Communications)通信機、及びセルラV2X(C-V2X)通信機等のうち、少なくとも一種類である。V2Xタイプの通信系11により、自律走行装置10は、支援システム3と無線通信可能となる。通信系11は、自律走行装置10の周囲に存在する端末との間において通信信号を送受信する、端末通信タイプであってもよい。端末通信タイプの通信系11は、例えばBluetooth(登録商標)機器、Wi-Fi(登録商標)機器、及び赤外線通信機器等のうち、少なくとも一種類である。
【0015】
センサ系12は、制御システム17又は支援システム3により利用可能なセンサ情報を、自律走行装置10の外界と内界とに対して取得する。そのためにセンサ系12は、外界センサ13と内界センサ14とを含んで構成される。
【0016】
外界センサ13は、自律走行装置10の周辺環境となる外界から、センサ情報としての外界情報を取得する。外界センサ13は、自律走行装置10の外界に存在する物標を検知する、物標検知タイプであってもよい。物標検知タイプの外界センサ13は、例えば外界を撮像するカメラ、照射したレーザ光の反射光を点群画像として検出可能なLiDAR(Light Detection and Ranging / Laser Imaging Detection and Ranging)、レーダ及びソナー等のうち少なくとも一種類を含んでいる。外界センサ13は、自律走行装置10の外界に存在するGNSS(Global Navigation Satellite System)の人工衛星から測位信号を受信する、測位タイプであってもよい。測位タイプの外界センサ13は、例えばGNSS受信機等である。
【0017】
内界センサ14は、自律走行装置10の内部環境となる内界から、センサ情報としての内界情報を取得する。内界センサ14は、自律走行装置10の内界において特定の運動物理量を検知する、物理量検知タイプであってもよい。物理量検知タイプの内界センサ14は、例えば速度センサ、加速度センサ、ジャイロセンサ、車輪回転数センサ、音センサ等のうち、少なくとも一種類である。
【0018】
地図データベース15は、制御システム17により利用可能な地図情報を、記憶する。地図データベース15は、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体(non-transitory tangible storage medium)を含んで構成されている。地図データベース15は、自律走行装置10の自己位置を含む自己状態量を推定するロケータの、データベースであってもよい。地図データベース15は、自律走行装置10の走行経路をナビゲートするナビゲーションユニットの、データベースであってもよい。地図データベース15は、これらのデータベース等のうち複数種類の組み合わせにより、構成されていてもよい。
【0019】
地図データベース15は、例えばV2Xタイプの通信系11を介した外部との通信等により、最新の地図情報を取得して記憶する。ここで地図情報は、自律走行装置10の走行環境を表す情報として、二次元又は三次元にデータ化されている。特に三次元の地図データとしては、高精度地図のデジタルデータが採用されるとよい。地図情報は、例えば道路自体の位置、形状、及び路面状態等のうち、少なくとも一種類を表した道路情報を含んでいてもよい。地図情報は、例えば道路に付属する標識及び区画線の位置並びに形状等のうち、少なくとも一種類を表した標示情報を含んでいてもよい。地図情報は、例えば道路に面する建造物及び信号機の位置並びに形状等のうち、少なくとも一種類を表した構造物情報を含んでいてもよい。
【0020】
情報提示系16は、自律走行装置10の周囲の人へ向けた報知情報を提示する。情報提示系16は、視覚を刺激する視覚刺激タイプであってもよい。視覚刺激タイプの情報提示系16は、例えばディスプレイ及び発光ユニット等のうち、少なくとも一種類である。情報提示系16は、乗員の聴覚を刺激する、聴覚刺激タイプであってもよい。聴覚刺激タイプの情報提示系16は、例えばスピーカ、及びブザー等のうち、少なくとも一種類である。
【0021】
制御システム17は、例えばLAN(Local Area Network)回線、ワイヤハーネス、内部バス、及び無線通信回線等のうち、少なくとも一種類を介して通信系11、センサ系12、地図データベース15及び情報提示系16に接続されている。制御システム17は、少なくとも一つの専用コンピュータを含んで構成されている。
【0022】
制御システム17を構成する専用コンピュータは、例えば自律走行装置10の自律走行を制御する、走行制御ECU(Electronic Control Unit)である。制御システム17を構成する専用コンピュータは、メモリ18とプロセッサ19とを、少なくとも一つずつ有している。メモリ18は、コンピュータにより読み取り可能なプログラム及びデータ等を非一時的に記憶する、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体(non-transitory tangible storage medium)である。ここで記憶とは、自律走行装置10の起動オフによってもデータが保持される蓄積であってもよいし、自律走行装置10の起動オフによりデータが消去される一時的な格納であってもよい。プロセッサ19は、例えばCPU(Central Processing Unit)、GPU(Graphics Processing Unit)、RISC(Reduced Instruction Set Computer)-CPU、CISC(Complex Instruction Set Computer)-CPU、DFP(Data Flow Processor)、及びGSP(Graph Streaming Processor)等のうち、少なくとも一種類をコアとして含んでいる。
【0023】
制御システム17においてプロセッサ19は、自律走行装置10の将来経路、将来軌道、将来行動での動的運転タスクを、センサ情報等に基づき計画する。制御システム17は、例えばシミュレーションモデル又は機械学習モデル等の車両走行モデルを用いて、判断且つ計画を遂行してもよい。
【0024】
さらに、制御システム17においてプロセッサ19は、支援システム3へと支援に利用可能な情報を提供するために、メモリ18に記憶された、制御プログラムに含まれる複数の命令を実行する。これにより制御システム17は、自律走行装置10の支援において利用可能な情報を提供するための機能ブロックを、複数構築する。制御システム17において構築される複数の機能ブロックには、図2に示すように情報収集ブロック170、周辺監視ブロック171、通信制御ブロック172、及び提示制御ブロック173が含まれている。
【0025】
情報収集ブロック170は、自律走行装置10の状態に関する状態情報を収集する。情報収集ブロック170は、内界センサ14からの内界情報を、状態情報として収集する。例えば、情報収集ブロック170は、速度データ、加速度データ、姿勢データ、音データ、及び車輪回転数データ等を、状態情報として収集する。又、情報収集ブロック170は、自律走行装置10の制御に関連するプロセッサ及びメモリの使用状況に関するデータとして、プロセッサ使用率データ及びメモリ使用率データを、状態情報として収集する。
【0026】
周辺監視ブロック171は、自律走行装置10の周囲の外界を監視する。監視において周辺監視ブロック171は、外界センサ13からの外界情報を収集する。例えば、周辺監視ブロック171は、カメラにより外界を撮像した画像データ、及びLiDARやレーダ等により外界をセンシングしたセンシングデータ等を、外界情報として収集する。
【0027】
通信制御ブロック172は、通信系11を介して、制御システム17と自律走行装置10の外部との間の通信を制御する。通信制御ブロック172は、情報収集ブロック170にて収集された状態情報を、支援システム3に対して送信する。通信制御ブロック172は、周辺監視ブロック171にて収集された外界情報を、支援システム3に対して送信する。又、通信制御ブロック172は、他道路ユーザ23へのサポート要請データ(後述)を、通信系11を介して支援システム3から受信する。加えて、通信制御ブロック172は、サポートの完了後において、後述のインセンティブ付与対象のサポータ20に対して通信系11をアクセスポイントとして機能させてもよい。
【0028】
提示制御ブロック173は、情報提示系16を介して自律走行装置10の周辺に対する情報提示処理を実行する。提示制御ブロック173は、他道路ユーザ23へのサポート要請データの受信に応じて、情報提示系16を介してサポート要請を報知する。提示制御ブロック173は、サポート要請データに含まれる報知指示に応じた内容にて、音声データ及び映像データの少なくとも一種類による報知を実行する。
【0029】
支援システム3は、例えばLAN回線、ワイヤハーネス、内部バス、及び無線通信回線等のうち、少なくとも一種類を介して通信系2に接続されている。通信系2は、自律走行装置10及び端末等と無線通信可能に構成されている。支援システム3は、少なくとも一つの専用コンピュータを含んで構成されている。支援システム3を構成する専用コンピュータは、自律走行装置10の自律走行を監視する監視サーバであってもよい。支援システム3を構成する専用コンピュータは、複数の自律走行装置10の運行を統合的に管理する管理サーバであってもよい。支援システム3を構成する専用コンピュータは、複数のサーバにより構成されてその機能が分散されていてもよい。
【0030】
支援システム3を構成する専用コンピュータは、メモリ4とプロセッサ5とを、少なくとも一つずつ有している。メモリ4は、コンピュータにより読み取り可能なプログラム及びデータ等を非一時的に記憶する、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体である。ここで記憶とは、支援システム3の起動オフによってもデータが保持される蓄積であってもよいし、支援システム3の起動オフによりデータが消去される一時的な格納であってもよい。プロセッサ5は、例えばCPU、GPU、RISC-CPU、CISC-CPU、DFP、及びGSP等のうち、少なくとも一種類をコアとして含んでいる。
【0031】
支援システム3においてプロセッサ5は、自律走行装置10の走行を、遠隔支援するためにメモリ4に記憶された、支援プログラムに含まれる複数の命令を実行する。これにより支援システム3は、自律走行装置10の走行を、遠隔支援するための機能ブロックを、複数構築する。支援システム3において構築される複数の機能ブロックには、図3に示すように履歴生成ブロック100、スタック監視ブロック110、設定ブロック120、マッチングブロック130、及び出力ブロック140が含まれている。
【0032】
これらのブロックの共同により、支援システム3が自律走行装置10の走行を支援する支援方法は、図4に示す遠隔支援フローに従って実行される。本支援フローは、支援システム3の起動中に繰り返し実行される。尚、本支援フローにおける各「S」は、支援プログラムに含まれた複数命令によって実行される複数ステップを、それぞれ意味している。
【0033】
まず、S10では、履歴生成ブロック100が、自律走行装置10の動作履歴に関する動作履歴データを生成する。動作履歴データは、自律走行装置10の動作に関連する動作情報の時系列データである。履歴生成ブロック100は、今回サイクルにおいて自律走行装置10から送信された動作情報を取得する。履歴生成ブロック100は、取得した動作情報を前回サイクルまでの動作履歴データに追加することで、動作履歴データを更新する。これにより、履歴生成ブロック100は、今回サイクルまでの動作情報を含んだ動作履歴データを生成する。
【0034】
動作履歴データは、例えば速度データ、加速度データ、姿勢データ、音データ、温度データ、車輪回転数データ、外界監視データ、プロセッサ使用率データ、メモリ使用率データの、少なくとも一種類を含む。尚、外界監視データは、例えばカメラによる画像データ、カメラ以外の外界センサ13によるセンシングデータの少なくとも一種類を含む。
【0035】
続くS20では、スタック監視ブロック110が、自律走行装置10のスタックの発生を監視する。ここで、スタックは、自律走行装置10の走行が阻害された状態である。スタックは、自律走行装置10の走行継続が不可能になった状態ということもできる。例えば、スタック監視ブロック110は、動作履歴データ及び自律走行装置10の位置情報等に応じて、スタックが発生したか否かを判定する。
【0036】
スタック監視ブロック110は、車輪が回転しているにもかかわらず位置の変化が無い等、車輪回転数データと位置情報との不整合の検知によりスタックが発生したと判定してもよい。又は、スタック監視ブロック110は、走行計画通りに自律走行装置10が移動できていない等、走行計画と位置情報との不整合の検知によりスタックが発生したと判定してもよい。又は、スタック監視ブロック110は、姿勢データに応じて、自律走行装置10がスタック状態と推測できる姿勢を取っている場合に、スタックが発生したと判定してもよい。
【0037】
スタックが発生していないと判定されると、本フローはS10へと戻り、動作履歴データの生成が継続される。一方で、スタックが発生したと判定されると、本フローはS30へと移行する。
【0038】
S30では、設定ブロック120が、サポータ20へ要請するスタックからの復帰支援(リカバリサポート)に対して設定されるレベルであるリカバリサポートレベルを設定する。例えば、リカバリサポートレベルは、発生したスタックから復帰するために必要とされるリカバリサポートをサポータ20が実行するにあたって生じる、サポートリスクの大きさに相関して設定される。
【0039】
ここで、サポートリスクとは、サポートにおいて生じるサポータ20の負担の度合である。例えば、サポートリスクは、サポートにおけるサポータ20の肉体的な負担度合、精神的な負担度合、サポータ20に課される責任の程度の少なくとも一種類を含む。サポートリスクの大きさは、復帰に必要なサポートの種類、ひいてはスタック要因に応じて規定される。
【0040】
このため、設定ブロック120は、リカバリサポートレベルの決定において、まずスタックの発生タイミング(以下、スタックタイミング)から遡った動作履歴データを解析することで、スタック要因を判別する。そして、設定ブロック120は、判別したスタック要因別にリカバリサポートレベルを、設定する。
【0041】
スタック要因は、動作履歴データのパターンに相関するように予め複数規定されている。例えば、スタック要因は、衝突、転落、姿勢異常、センサ異常、異物付着、ハードウェアの故障、ソフトウェアの故障、原因不明等の少なくとも一種類を含んで規定されている。尚、ここで異物付着は、例えばカメラのレンズやレーダのレドーム等、外界センサ13において外界情報を取り込むための外界に露出した部位に対する異物の付着を意味する。図6に示す例では、スタック要因としての衝突は、転倒有と転倒無とでさらに2種類の要因に細分化されて規定されている。さらに、スタック要因としての転落も、転倒有と転倒無とでさらに2種類の要因に細分化されて規定されている。又、スタック要因としての姿勢異常は、転倒による姿勢異常、脱輪による姿勢異常、乗り上げによる姿勢異常の3種類の要因に細分化されて規定されている。
【0042】
設定ブロック120は、スタックタイミングから遡った、スタックタイミングから規定の時間前までの動作履歴データに基づき、スタック要因を判別する。例えば、設定ブロック120は、動作履歴データからスタックに関連するパターンの有無を判定し、パターンの有無に応じたスタック要因を特定する。例えば、設定ブロック120は、加速度データ等に相関して自律走行装置10に加わった衝撃が許容範囲を超えていた場合、衝突又は転落がスタック要因に含まれると特定する。設定ブロック120は、衝突及び転落のいずれがスタック要因であるかについては、衝撃の大きさや時系列の衝撃のパターン等により判断すればよい。
【0043】
又、設定ブロック120は、姿勢データ等に相関する通常姿勢に対する傾きの大きさが許容範囲を超えていた場合、転倒がスタック要因に含まれると特定する。又、設定ブロック120は、姿勢データ等に相関する通常姿勢に対する傾きの大きさが、許容範囲内且つ許容範囲よりも上限の小さい設定範囲を超えていた場合、脱輪又は乗り上げがスタック要因に含まれると特定する。設定ブロック120は、脱輪及び乗り上げのいずれがスタック要因であるかについては、姿勢の傾きの大きさや時系列の姿勢変化パターン等により判断すればよい。
【0044】
すなわち、設定ブロック120は、衝撃が許容範囲外且つ傾きの大きさが許容範囲外であった場合、衝突及び転倒がスタック要因であると特定する。一方で、設定ブロック120は、衝撃が許容範囲外で、傾きの大きさが許容範囲内であった場合、転倒無しの衝突がスタック要因であると特定する。
【0045】
又、設定ブロック120は、車輪回転数データに相関して車輪空転が有ると判定した場合、脱輪、乗り上げ、転倒のいずれかがスタック要因に含まれると特定する。すなわち、設定ブロック120は、傾きの大きさが設定範囲外且つ車輪空転有りの場合、転倒による姿勢異常がスタック要因であると特定する。そして、設定ブロック120は、傾きの大きさが設定範囲内且つ車輪空転有りの場合、脱輪又は乗り上げによる姿勢異常がスタック要因であると特定する。
【0046】
又、設定ブロック120は、音データに相関して異音を検出した場合に、ハードウェアの故障がスタック要因に含まれると特定する。さらに、設定ブロック120は、プロセッサ使用率データに相関するプロセッサ使用率が異常であった場合に、ソフトウェアの故障がスタック要因に含まれると特定する。又、設定ブロック120は、メモリ使用率データに相関するメモリ使用率が異常であった場合に、ソフトウェアの故障がスタック要因に含まれると特定する。さらに、設定ブロック120は、外界監視データに相関して外界センサ13の視野異常を検出した場合に、異物付着がスタック要因に含まれると特定する。又、設定ブロック120は、動作履歴データのいずれにもスタックに関連するパターンが無い場合には、スタック要因が不明であると特定する。
【0047】
そして、設定ブロック120は、判別したスタック要因に応じて、リカバリサポートレベルを設定する。各スタック要因に対応するリカバリサポートレベルは、例えば、当該スタック要因から予測されるサポートリスクに応じて、予め設定されている。設定ブロック120は、予めメモリ4等に記憶されたスタック要因とリカバリサポートレベルとの対応関係情報と、実際に判別したスタック要因とから、リカバリサポートレベルを設定する。例えば、設定ブロック120は、サポートリスクが大きくなるほど、大きなレベルを設定する。
【0048】
例えば、図6に示すように、設定ブロック120は、転倒有りの衝突、転倒無しの衝突、転倒有りの転落、転倒無しの転落、転倒による姿勢異常、脱輪による姿勢異常、乗り上げによる姿勢異常、センサ異常、異物付着、ハードウェア故障、ソフトウェア故障の順に、大きなリカバリサポートレベルを設定する。又、設定ブロック120は、スタック要因不明の場合、センサ異常と同じリカバリサポートレベル、すなわちレベル4を設定する。尚、設定ブロック120は、複数のスタック要因が判別されていた場合、各スタック要因に対応するリカバリサポートレベルのうち最も大きなレベルを設定すればよい。
【0049】
以上により、設定ブロック120は、リカバリサポートレベルを、スタックタイミングから遡った動作履歴データからに応じたレベルとして設定する。
【0050】
続くS40では、マッチングブロック130が、設定したリカバリサポートレベルに対するサポータ20のマッチングを実行する。具体的には、マッチングブロック130は、リカバリサポートレベルに対するサポータ20の人数のマッチングと、サポータ20の種別のマッチングと、を実行する。
【0051】
例えば図6に示すように、サポータ20の人数は、リカバリサポートレベル別に予め設定されている。換言すれば、サポータ20の人数は、スタック要因別に予め設定されている。設定される人数は、例えば、サポートを実行するために最低限必要であると規定される人数(必要人数)である。リカバリサポートレベルと必要人数との対応関係情報は、メモリ4等に予め記憶されている。マッチングブロック130は、この対応関係情報から実際の必要人数を特定することで、人数のマッチングを実行する。
【0052】
種別のマッチングについて、マッチングブロック130は、サポータ20の種別ごとに予め設定される、サポート可能なリカバリサポートレベルのレベル範囲に、実際のリカバリサポートレベルが含まれるか否かを判断する。マッチングブロック130は、レベル範囲に実際のリカバリサポートレベルが含まれる場合、当該種別のサポータ20がリカバリサポートレベルにマッチングする、と判断する。
【0053】
例えば、サポータ20の種別は、専門スタッフ21、臨時スタッフ22、及び他道路ユーザ23を少なくとも含む。専門スタッフ21及び臨時スタッフ22は、各スタッフ21,22の所持する端末等を介して予めスタッフデータベース150に登録されている。スタッフデータベース150には、スタッフ21,22の識別ID及び種別が少なくとも登録されている。スタッフデータベース150には、スタッフ21,22の位置及び対応可能時間帯等が、登録されていてもよい。
【0054】
専門スタッフ21は、事前登録されてサポートサービスを専門とするサポータ20である。ここで、サポートサービスを専門とするとは、自律走行装置10のサポートサービスに、業務として従事することを意味する。専門スタッフ21は、自律走行装置10の提供するサービスの事業者に関連する人員であり、例えば、当該事業者に雇用されている人員である。ここでのサービスは、本実施形態の場合は搬送サービスである。又、専門スタッフ21は、サポートサービスへの従事において、サポートを実施しない場合には待機場所にて待機している人員である。
【0055】
こうした専門スタッフ21は、サポート可能なリカバリサポートレベルの範囲がHighレベルに設定されている。すなわち、専門スタッフ21は、臨時スタッフ22及び他道路ユーザ23よりも、サポート可能なレベル範囲の上限が高く設定されている。具体的には、図7に示すように、専門スタッフ21は、レベル1~11までの全レベルのリカバリサポートが可能であると設定されている。
【0056】
臨時スタッフ22は、事前登録されて自律走行装置10の周囲における位置条件を満たす場合にサポートサービスを提供するサポータ20である。ここで、位置条件は、例えば自律走行装置10から所定の距離範囲内に存在する場合に成立する。臨時スタッフ22は、例えば自律走行装置10の提供するサービスの事業者とは関連しない人員であり、例えば、当該事業者と雇用関係には無い人員である。換言すれば、臨時スタッフ22は、サポートサービスに通常の業務としては従事しない人員である。臨時スタッフ22は、例えば自律走行装置10の提供するサービスの提供エリア内における店舗の店員等である。
【0057】
こうした臨時スタッフ22は、サポート可能なレベル範囲がMidレベルに設定されている。すなわち、臨時スタッフ22は、サポート可能なレベル範囲の上限が専門スタッフ21よりも低く、且つ他道路ユーザ23よりも高く設定されている。具体的には、臨時スタッフ22は、レベル1~9までのレベルのリカバリサポートが可能であると設定されている。
【0058】
他道路ユーザ23は、自律走行装置10の周囲における未登録の人員である。他道路ユーザ23は、例えば自律走行装置10の周辺を通行する通行人である。
【0059】
こうした他道路ユーザ23は、サポート可能なリカバリサポートレベルの範囲がLowレベルに設定されている。すなわち、他道路ユーザ23は、サポート可能なレベル範囲の上限が専門スタッフ21及び臨時スタッフ22よりも低く設定されている。具体的には、他道路ユーザ23は、レベル1~7までのレベルのリカバリサポートが可能であると設定されている。
【0060】
マッチングブロック130は、以上のサポータ20の種別ごとに、サポート可能なレベル範囲に実際のリカバリサポートレベルが含まれか否かを判定する。マッチングブロック130は、リカバリサポートレベルがレベル範囲に含まれると判定した種別のサポータ20について、リカバリサポートレベルにマッチングする、と判断する。
【0061】
続くS50では、出力ブロック140が、リカバリサポートレベルにマッチングするサポータ20に対して、サポートを要請するサポート要請データを出力する。S50の詳細処理について説明すると、まず図5のS501において、出力ブロック140は、サポータ20のマッチング結果を判断する。リカバリサポートレベルがHighレベルに含まれ、専門スタッフ21にのみマッチングしたと判断すると、本フローはS502へと移行する。
【0062】
S502では、出力ブロック140は、専門スタッフ21のみに対して、サポート要請データを出力する。サポート要請データは、例えばサポート要請を通知する通知情報を少なくとも含んでいる。サポート要請データは、スタック要因、必要なサポート内容、スタックした自律走行装置10の位置情報、サポートに必要な見込み時間等の少なくとも一種類を含んでいてもよい。又、出力ブロック140は、サポートにおける役割に関する役割情報を、サポート要請データに含めて出力してもよい。サポートにおける役割は、図6に示すように、リカバリサポートレベル別、換言すればスタック要因別に、予め規定されている。例えば、役割は、実際に自律走行装置10を操作して動かすサポート操作、所定の機関等への通報、安全確認、及び交通整理を、含んでいる。
【0063】
出力ブロック140は、専門スタッフ21に対しては、サポート要請データを、通信データとして通信系2を介して通信出力する。例えば、出力ブロック140は、サポート要請データを、専門スタッフ21が所持するスマートフォン等の端末に対して、通信出力する。又は、出力ブロック140は、専門スタッフ21の待機場所に設置された通信機器に対して、サポート要請データを通信出力してもよい。
【0064】
一方、S501において、リカバリサポートレベルがMidレベルに含まれ、専門スタッフ21及び臨時スタッフ22にマッチングしたと判断すると、本フローはS503へと移行する。S503において、出力ブロック140は、専門スタッフ21及び臨時スタッフ22に対して、サポート要請データを出力する。専門スタッフ21に対するサポート要請データに含まれる情報は、S502において出力されるものと実質同種であってよい。又、臨時スタッフ22に対するサポート要請データは、例えば専門スタッフ21に対して出力される種類の情報と実質同種の情報を含む。尚、臨時スタッフ22に対するサポート要請データは、後述のインセンティブデータに関する情報をさらに含んでいてもよい。出力ブロック140は、臨時スタッフ22に対するサポート要請データを、臨時スタッフ22が所持するスマートフォン等の端末に対して、通信出力する。
【0065】
又、S501において、リカバリサポートレベルがLowレベルに含まれ、専門スタッフ21、臨時スタッフ22及び他道路ユーザ23にマッチングしたと判断すると、本フローはS504へと移行する。S504において、出力ブロック140は、専門スタッフ21、臨時スタッフ22及び他道路ユーザ23に対して、サポート要請データを出力する。出力ブロック140は、専門スタッフ21及び臨時スタッフ22に対しては、S502,S503と同様に、サポート要請データを通信出力する。尚、専門スタッフ21及び臨時スタッフ22に出力されるサポート要請データは、例えば、S502及びS503における情報に加えて、他道路ユーザ23を何人集めればよいかに関する情報を含んでいてもよい。
【0066】
さらに、出力ブロック140は、自律走行装置10の周囲の他道路ユーザ23に対しては、報知データとして、サポート要請データを出力する。出力ブロック140は、自律走行装置10の情報提示系16を介して、他道路ユーザ23に対してサポートを要請する。
【0067】
このため、報知データは、例えば自律走行装置10に対するサポート要請の報知指示を少なくとも含んでいる。又、報知データは、スタック要因、必要なサポート内容、サポートに必要な見込み時間等の少なくとも一種類に関する報知指示を含んでいてもよい。又、報知データは、インセンティブデータに関する情報をさらに含んでいてもよい。
【0068】
尚、スタック要因が不明であると判別されていた場合には、出力ブロック140は、サポート要請データとして追加データの収集依頼を出力してもよい。追加データは、例えば、自律走行装置10の画像データ等である。出力ブロック140は、追加データの収集依頼を出力する場合、二次元コード等から送信フォームに誘導する。出力ブロック140は、二次元コードの偽造防止のため、自律走行装置10の情報提示系16に表示させる。尚、自律走行装置10の画像データにおいて、映っている自律走行装置10から時刻等が確認できるように、自律走行装置10に情報提示させてもよい。
【0069】
図4に戻り、S60では、出力ブロック140が、サポータ20によるサポートが完了したか否かを判定する。出力ブロック140は、例えば、スタッフ21,22の端末からのサポート完了報告、自律走行装置10によるサポート完了通知等に基づき、サポートが完了したか否かを判定すればよい。サポートが完了したと判定されると、本フローはS70へと移行する。S70では、出力ブロック140が、サポートを実施したサポータ20がインセンティブ対象者であるか否かを判定する。インセンティブ対象者は、例えば、臨時スタッフ22及び他道路ユーザ23である。
【0070】
サポータ20がインセンティブ対象者であると判定されると、本フローはS80へと移行する。S80では、出力ブロック140が、インセンティブ付与処理を実行する。具体的には、出力ブロック140は、インセンティブデータを、サポータ20に対して出力する。インセンティブデータは、例えば、電子マネー、サービスポイント、及びクーポン等のうち少なくとも一種類である。
【0071】
尚、出力ブロック140は、付与するインセンティブの多寡を、シーンに応じて変更してもよい。例えば、出力ブロック140は、搬送中の荷物の優先度が高いほど、多くのインセンティブを付与してもよい。荷物の優先度は、例えば指定された配達のリミット時刻までの残り時間が少ないほど高く設定される。又、出力ブロック140は、実際にサポート対応可能と推定されるサポータ20の人数が少ないほど、多くのインセンティブを付与してもよい。
【0072】
又、出力ブロック140は、インセンティブ付与対象に他道路ユーザ23が含まれる場合、登録を促す通知を、実行する。この場合、出力ブロック140は、自律走行装置10に対して、登録を促す通知の提示指示と、自律走行装置10の通信系11のアクセスポイントとしての利用指示と、を出力すればよい。
【0073】
尚、出力ブロック140は、ユーザ登録した他道路ユーザ23に対しては、以降において臨時スタッフ22として扱ってもよい。又は、出力ブロック140は、臨時スタッフ22及び未登録の他道路ユーザ23とは別種のサポータ20として、別のレベル範囲を設定してもよい。又は、出力ブロック140は、登録済みの他道路ユーザ23についても、未登録の他道路ユーザ23と同一のレベル範囲としてもよい。
【0074】
以上の第一実施形態によれば、自律走行装置10のスタックが発生した場合に、スタックの発生タイミングから遡った動作履歴データに応じたリカバリサポートレベルに対してマッチングするサポータ20へ、サポート要請データが出力される。故に、リカバリサポートレベルに適したサポータ20に対して、サポートを要請することが可能となり得る。又、これにより、当該要請に応えるサポータ20がサポートを負担できる可能性を高めることが可能となり得る。これにより、要請したサポートをサポータ20が負担できずに負担可能なサポータ20をさらに招集する状況等を回避し易くなるため、サポート開始までの時間が短縮可能となり得る。
【0075】
又、第一実施形態によれば、動作履歴データから解析されるスタック要因別のリカバリサポートレベルにマッチングする人数のサポータ20へ、サポート要請データが出力される。故に、リカバリサポートレベルに適した人数のサポータ20に対して、サポートを要請することが可能となり得る。したがって、当該要請に応えるサポータ20が要請された人数にてサポートを負担できる可能性を高めることが可能となり得、サポート開始までの時間が短縮可能となり得る。
【0076】
さらに、第一実施形態によれば、サポータ20の種別毎に予め設定されるサポート可能なリカバリサポートレベルのレベル範囲が、動作履歴データに応じたリカバリサポートレベルにマッチングする種別のサポータ20へ、サポート要請データが出力される。故に、動作履歴データに応じて、リカバリサポートを負担可能な種別のサポータ20に対して、確実にサポートが要請され得る。
【0077】
加えて、第一実施形態によれば、サポータ20の種別毎に予め設定されるサポート可能なレベル範囲が、動作履歴データから解析されるスタック要因別のリカバリサポートレベルにマッチングする種別のサポータ20へ、サポート要請データが出力される。故に、スタック要因に応じて必要となるサポートを負担可能な種別のサポータ20に対して、確実にサポートが要請され得る。したがって、スタック要因に応じたサポートを要請に応えたサポータ20から受けることができる可能性が高まり得る。
【0078】
又、第一実施形態によれば、サポータ20の種別毎に予め設定されるサポート可能なレベル範囲が、スタック要因から予測されるサポートリスクに応じたリカバリサポートレベルにマッチングする種別のサポータ20へ、サポート要請データが出力される。故に、スタック要因から予測されるサポートリスクを許容可能な種別のサポータ20に対して、確実にサポートが要請され得る。
【0079】
さらに、第一実施形態によれば、サポータ20の種別は、事前登録されてサポートサービスを専門とする、専門スタッフ21を含む。故に、サポートサービスに特化したサポータ20としての専門スタッフ21に対して、サポート要請が可能となる。
【0080】
加えて、第一実施形態によれば、サポータ20の種別は、事前登録されて自律走行装置10の周囲における位置条件を満たす場合にサポートサービスを提供する、臨時スタッフ22を含む。故に、位置条件に応じて、事前登録された臨時スタッフ22に対して、サポート要請が可能となる。
【0081】
又、第一実施形態によれば、事前登録された臨時スタッフ22によるリカバリサポートに対して、インセンティブデータが出力される。故に、臨時スタッフ22に対して、サポートを負担する動機付けを与えることが可能となり得る。したがって、サポートを要請した臨時スタッフ22から実際にサポートを受ける可能性が高まり得る。
【0082】
さらに、第一実施形態によれば、サポータ20の種別は、自律走行装置10の周囲における未登録の、他道路ユーザ23を含む。故に、未登録の他道路ユーザ23に対しても、マッチング結果に応じて適宜サポートが要請され得る。したがって、他道路ユーザ23にマッチングするサポートであれば、サポートサービスに特化したサポータ20に対して逐一サポートを要請することなく、サポートを受けることが可能となり得る。
【0083】
加えて、第一実施形態によれば、サポート要請データの出力に応答して自律走行装置10にアクセスした他道路ユーザ23のユーザ情報の登録が実行される。故に、サポートの要請に対して応答した他道路ユーザ23を、把握することが可能となり得る。これにより、サポートに比較的積極的な他道路ユーザ23に対して、サポートに関連した情報提供が、容易となり得る。
【0084】
又、第一実施形態によれば、登録された他道路ユーザ23によるリカバリサポートに対して、インセンティブデータが出力される。故に、登録された他道路ユーザ23に対して、次回以降にもサポートを負担する動機付けを与えることが可能となり得る。したがって、サポートを要請した他道路ユーザ23から実際にサポートを受ける可能性が高まり得る。
【0085】
さらに、第一実施形態によれば、サポート要請データは、自律走行装置10から通信出力される、通信データを含む。故に、遠隔のサポータ20に対して、確実にサポートが要請され得る。
【0086】
加えて、第一実施形態によれば、サポート要請データは、自律走行装置10の周囲へ報知出力される、報知データを含む。故に、自律走行装置10に比較的近いサポータ20に対して、確実にサポートが要請され得る。
【0087】
(第二実施形態)
図8に示すように第二実施形態は、第一実施形態の変形例である。
【0088】
第二実施形態において、S501にてリカバリサポートレベルがLowレベルであると判定されると、本フローはS505へと移行する。S505では、出力ブロック140が、自律走行装置10へと報知データを出力する。そして、出力ブロック140は、通信データとしてのサポート要請データの出力を中止する。換言すれば、出力ブロック140は、リカバリサポートレベルが他道路ユーザ23でもサポート可能なレベルである場合には、専門スタッフ21及び臨時スタッフ22に対するサポータ要請を実行せずに中止する。すなわち、マッチングブロック130は、レベル範囲に現在のリカバリサポートレベルが含まれる複数の種別のサポータ20が存在する場合、レベル範囲の上限がより低い種別のサポータ20を、マッチングするサポータ20として優先的に選択する。
【0089】
続くS506では、出力ブロック140が、他道路ユーザ23からのサポートを待機する待機時間を、設定する。続くS507では、出力ブロック140が、推定サポータ人数が、許容数に達しているか否かを判定する。推定サポータ人数は、自律走行装置10のサポータ20として見込めると推定される、他道路ユーザ23の人数である。出力ブロック140は、自律走行装置10からの外界情報を取得し、当該外界情報から推定サポート人数を推定する。例えば、出力ブロック140は、自律走行装置10へと向かっていると認識される他道路ユーザ23を、サポータ20として見込めると推定される他道路ユーザ23とする。
【0090】
尚、出力ブロック140は、自律走行装置10の外界センサ13による撮像画像データに対する画像認識により、他道路ユーザ23の性別、体格、年齢層等のユーザ情報を判定し、リカバリサポートレベルにマッチングする人数を、推定サポータ人数としてもよい。
【0091】
そして、許容数は、他道路ユーザ23のみでサポートを実行できると推定できる推定サポート人数の閾値である。許容数は、例えばリカバリサポートレベルに相関して設定される。許容数は、図6に示すようなリカバリサポートレベルに対して設定される必要人数であってもよいし、当該必要人数にマージンを加算した人数であってもよい。
【0092】
推定サポータ人数が許容数に満たないと判定されると、本フローはS508へと移行する。S508では、出力ブロック140が、設定した待機時間の減少処理を実行する。出力ブロック140は、予め規定された時間分を減少してもよい。又は、出力ブロック140は、推定サポータ人数に相関した時間分を減少してもよい。
【0093】
一方で、推定サポータ人数が許容数に到達すると判定されると、本フローはS509へと移行する。S509では、出力ブロック140が、設定した待機時間の増加処理を実行する。出力ブロック140は、予め規定された時間分を増加してもよいし、推定サポータ人数に相関した時間分を減少してもよい。
【0094】
尚、出力ブロック140は、サービスの提供エリアにおいて一定範囲内にいる人数の統計として予め蓄積された統計情報から、S508及びS509における時間の増減の大きさを決定してもよい。この場合、出力ブロック140は、曜日、時間帯、天候、周辺のイベント有無等に応じて、時間の増減分に重みを付与してもよい。
【0095】
次に、S510では、出力ブロック140が、自律走行装置10の発見容易度が許容範囲に到達しているか否かを判定する。発見容易度は、自律走行装置10の他道路ユーザ23からの見つけ易さに関連するパラメータである。例えば、発見容易度は、自律走行装置10からの周囲の見通し範囲、すなわち障害物によって遮られていない範囲の大きさとされる。発見容易度が大きいほど、自律走行装置10は他道路ユーザ23から発見され易い状態とされる。ここで、許容範囲は、発見容易度が閾値以上又は超過となる範囲である。例えば、出力ブロック140は、方位角が閾角度且つ自律走行装置10からの距離が閾距離以上となる、障害物の無い範囲が存在する場合に、発見容易度が許容範囲内であると判定し、存在しない場合に発見容易度が許容範囲外であると判定する。
【0096】
発見容易度が許容範囲に未達であると判定されると、本フローはS511へと移行する。S511では、出力ブロック140が、設定した待機時間の減少処理を実行する。出力ブロック140は、予め規定された時間分を減少してもよいし、発見容易度に相関した時間分を減少してもよい。一方で、発見容易度が許容範囲に到達していると判定されると、本フローはS512へと移行する。S512では、出力ブロック140が、設定した待機時間の増加処理を実行する。出力ブロック140は、予め規定された時間分を増加してもよいし、発見容易度に相関した時間分を減少してもよい。
【0097】
続くS513では、出力ブロック140が、他道路ユーザ23によるサポートが開始されたか否かを判定する。出力ブロック140は、例えば、自律走行装置10から取得した外界情報等に応じた他道路ユーザ23の位置や動作等に基づいて、サポートの開始有無を判定する。サポートが開始されていないと判定されると、本フローはS514へと移行する。S514では、出力ブロック140が、サポートを要請してから待機時間が経過したか否かを判定する。待機時間経過していないと判定されると、本フローはS514へと戻る。
【0098】
一方で、サポートを要請してから待機時間が経過したと判定されると、本フローはS515へと移行する。S515では、出力ブロック140が、専門スタッフ21及び臨時スタッフ22に対して、サポート要請データを出力する。すなわち、出力ブロック140は、対応可能なリカバリサポートレベルの上限が他道路ユーザ23よりも高い上位サポータに対して、サポート要請データを出力する。尚、出力ブロック140は、専門スタッフ21及び臨時スタッフ22のいずれか一方に対して選択的にサポート要請データを出力してもよい。又、出力ブロック140は、レベル範囲の上限がより低い種別のサポータ20の優先的な選択を、S503においても適用してもよい。すなわち、出力ブロック140は、S503において、臨時スタッフ22にのみサポート要請データを出力してもよい。
【0099】
(他の実施形態)
以上、複数の実施形態について説明したが、本開示は、それらの実施形態に限定して解釈されるものではなく、本開示の要旨を逸脱しない範囲内において種々の実施形態及び組み合わせに適用することができる。
【0100】
変形例において支援システム3を構成する専用コンピュータは、デジタル回路及びアナログ回路のうち、少なくとも一方をプロセッサとして有していてもよい。ここでデジタル回路とは、例えばASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)、SOC(System on a Chip)、PGA(Programmable Gate Array)、及びCPLD(Complex Programmable Logic Device)等のうち、少なくとも一種類である。又こうしたデジタル回路は、プログラムを記憶したメモリを、有していてもよい。
【0101】
変形例において、出力ブロック140は、スタック要因が不明であった場合は、追加情報の収集を、他道路ユーザ23に加えて、又は代えて、インフラ設備、周辺の他の自律走行装置等に依頼してもよい。
【0102】
変形例において、設定ブロック120は、スタック要因に加えて、スタック要因以外の情報に応じてリカバリサポートレベルを設定してもよい。例えば、設定ブロック120は、スタック要因以外にサポートリスクに関連する環境情報がある場合、スタック要因に対応するリカバリサポートレベルを補正して設定してもよい。環境情報は、例えば、自律走行装置10に関する内部環境情報及び自律走行装置10の外部に関する外部環境情報の少なくとも一種類を含む。内部環境情報は、例えば、自律走行装置10の重量、発熱有無等である。外部環境情報は、例えば、スタックしたエリアにおける天候情報等である。
【0103】
変形例において、出力ブロック140は、他道路ユーザ23がサポートを実行しようとした場合、サポート前にユーザ登録を実行するように促す通知の指示を、自律走行装置10に対して出力してもよい。
【0104】
変形例において、設定ブロック120は、リモートセンタ1のオペレータによるスタック要因の判断結果を取得することで、スタック要因を判別してもよい。例えば、設定ブロック120は、オペレータが外界画像等から判断したスタック要因の入力を受け付けることで、スタック要因を判別してもよい。又、設定ブロック120は、スタック要因が不明であった場合に、オペレータによる判断結果を取得してもよい。
【0105】
変形例において、出力ブロック140は、サポート要請データとして、サポータ20の端末による認証依頼を出力してもよい。出力ブロック140は、サポートを実行するサポータ20の遠隔監視を行ってもよい。
【0106】
変形例において、自律走行装置10は、サポートにおいて利用可能な装備品を備えていてもよい。例えば、自律走行装置10は、車体に設けられた格納空間内に、装備品としてのジャッキ等の工具を格納されていてもよい。尚、装備品は、自律走行装置10に一体的に取り付けられた部品であってもよい。又、支援システム3の出力ブロック140は、装備品の存在や使用法等の装備品情報を、サポート要請データに含めて出力してもよい。
【0107】
変形例において、設定ブロック120は、自律走行装置10における装備品に応じたリカバリサポートレベルの設定を行ってもよい。又は、マッチングブロック130は、自律走行装置10における装備品に応じたサポータ20のマッチングを行ってもよい。
【0108】
変形例において、自律走行装置10は、スイッチ操作で手動移動可能なインターフェイスを備えていてもよい。又、出力ブロック140は、サポータ20に対して他のサポータ20のスイッチ操作を許可する監視の役割の依頼をサポート要請データに含めて出力してもよい。又、出力ブロック140は、特定のサポータ20に対して、他のサポータ20による自律走行装置10の車体を押す操作を監視する役割の依頼をサポート要請データに含めて出力してもよい。
【0109】
変形例において、出力ブロック140は、複数種別のサポータ20に対してサポート要請データを出力する場合、依頼するサポートの役割を、種別に応じて変更してもよい。例えば、出力ブロック140は、リカバリサポートレベルがレベル5~7の場合に、安全確認の役割を専門スタッフ21又は臨時スタッフ22のみに依頼し、他道路ユーザ23には他の役割を依頼するようにしてもよい。
【0110】
変形例において自律走行装置10は、荷物搬送以外の用途に供されるものであってもよい。例えば、自律走行装置10は、路面等の清掃を行う清掃ロボットであってもよい。
【0111】
ここまでの説明形態の他に上述の実施形態及び変形例における支援システム3は、プロセッサ5及びメモリ4を少なくとも一つずつ有する制御装置として実施されてもよい。具体的には、支援システム3は、処理回路(例えば処理ECU等)又は半導体装置(例えば半導体チップ等)の形態で実施されてもよい。
【0112】
(技術的思想の開示)
この明細書は、以下に列挙する複数の項に記載された複数の技術的思想を開示している。いくつかの項は、後続の項において先行する項を択一的に引用する多項従属形式(a multiple dependent form)により記載されている場合がある。さらに、いくつかの項は、他の多項従属形式の項を引用する多項従属形式(a multiple dependent form referring to another multiple dependent form)により記載されている場合がある。これらの多項従属形式で記載された項は、複数の技術的思想を定義している。
【0113】
(技術的思想1)
プロセッサ(5)を有し、自律走行装置(10)を支援する支援システムであって、
前記プロセッサは、
前記自律走行装置の動作履歴データを生成することと、
前記自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
前記スタックからのリカバリサポートを実行可能なサポータ(20)へ要請する前記スタックからのリカバリサポートのレベルであって前記スタックの発生タイミングから遡った前記動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングする前記サポータへ、サポート要請データを出力することと、
を実行するように構成される支援システム。
【0114】
(技術的思想2)
前記サポート要請データを出力することは、
前記動作履歴データから解析されるスタック要因別の前記リカバリサポートレベルにマッチングする人数の前記サポータへ、少なくとも前記サポート要請データを出力することを含む技術的思想1に記載の支援システム。
【0115】
(技術的思想3)
前記サポート要請データを出力することは、
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルのレベル範囲が、前記動作履歴データに応じた前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む技術的思想1又は技術的思想2に記載の支援システム。
【0116】
(技術的思想4)
前記サポート要請データを出力することは、
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルのレベル範囲が、前記動作履歴データから解析されるスタック要因別の前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む技術的思想3に記載の支援システム。
【0117】
(技術的思想5)
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルのレベル範囲が、前記スタック要因から予測されるサポートリスクに応じた前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む技術的思想4に記載の支援システム。
【0118】
(技術的思想6)
前記サポータの種別は、事前登録されてサポートサービスを専門とする、専門スタッフ(21)を含む技術的思想3から技術的思想5のいずれか1項に記載の支援システム。
【0119】
(技術的思想7)
前記サポータの種別は、事前登録されて前記自律走行装置の周囲における位置条件を満たす場合にサポートサービスを提供する、臨時スタッフ(22)を含む技術的思想3から技術的思想6のいずれか1項に記載の支援システム。
【0120】
(技術的思想8)
前記プロセッサは、
事前登録された前記臨時スタッフによるリカバリサポートに対して、インセンティブデータを出力することを実行するように構成される技術的思想7に記載の支援システム。
【0121】
(技術的思想9)
前記サポータの種別は、前記自律走行装置の周囲における未登録の、他道路ユーザ(23)を含む技術的思想3から技術的思想8のいずれか1項に記載の支援システム。
【0122】
(技術的思想10)
前記プロセッサは、
前記サポート要請データの出力に応答して前記自律走行装置にアクセスした前記他道路ユーザのユーザ情報を、登録することを実行するように構成される技術的思想9に記載の支援システム。
【0123】
(技術的思想11)
前記プロセッサは、
登録された前記他道路ユーザによる前記リカバリサポートに対して、インセンティブデータを出力することを実行するように構成される技術的思想10に記載の支援システム。
【0124】
(技術的思想12)
前記サポート要請データを出力することは、
複数種別のサポータがマッチングした場合において、前記レベル範囲の上限が最も低い種別の前記サポータに対して、優先的に前記サポート要請データを出力することを含む技術的思想3から技術的思想11のいずれか1項に記載の支援システム。
【0125】
(技術的思想13)
前記サポート要請データは、前記自律走行装置から通信出力される、通信データを含む技術的思想1から技術的思想12のいずれか1項に記載の支援システム。
【0126】
(技術的思想14)
前記サポート要請データは、前記自律走行装置の周囲へ報知出力される、報知データを含む技術的思想1から技術的思想13のいずれか1項に記載の支援システム。
【0127】
尚、以上の技術的思想1~14は、支援方法及び支援プログラムの形態で、実施されてもよい。
【符号の説明】
【0128】
3:支援システム、4:メモリ(記憶媒体)、5:プロセッサ、10:自律走行装置、20:サポータ、21:専門スタッフ、22:臨時スタッフ、23:他道路ユーザ
図1
図2
図3
図4
図5
図6
図7
図8