ラボ

UAV(無人飛行機)のテクノロジーには、まだまだ多くの面で更なる研究開発が必要とされています。世界中で使われるのに相応しいオープンソースベースのソリューションを開発しようとするならばなおのことです。このラボのページでは、OpenReliefのボランティアと他のプロジェクトが取り組んできた分野のなかから、特に重要な内容を紹介します。

映像技術

ドローン(ロボット飛行機)は、私たちに「空からの目」をもたらしますが、完全なソリューションを提供するためには、他の技術と組み合わせる必要があります。例えば画像処理ソフトを併用することで、ロボット飛行機が道路や人々、煙などを「認識」することが可能となります。OpenReliefはこの技術に取り組み、OpenCVと呼ばれるオープンソースプロジェクトの成果物を利用したテストコードを作成しました。

これは、私たちがコンピュータに対して見るということを教えている様子です:

このようにして、写ったものを認識させました:

何が見えていたかを理解させています:

私たちのコードが道路や人、煙を認識しています:

もちろん、私たちのコードはすべて自由に利用できます。Gitoriousのリポジトリにアクセスしてください。

ロボット飛行機のコントロール

Mission Planner

飛行計画を行っている様子

ロボット飛行機を管理するために重要なのは「指令・制御」の技術です。具体的には、ロボット飛行機が飛び立つ前の飛行計画の管理、および、機体が帰還した後にそこから情報を取り出すために利用するハードウェアやソフトウェアについての技術です。

この分野では、自動操縦装置をプログラムするのに使用される”Ground Control Station”(地上管制局の意)が最も基本的な技術となります。私たちが使用しているオープンソースの自動操縦装置であるArduPilot用のMission Plannerがその好例です。Mission Planner はとても便利で、ロボット飛行機が飛行する前にウェイポイント(飛行経路を指定するための通過地点情報)を設定しておくことが可能であり、さらに、飛行後に実際にどこを飛行してきたのかを正確に表示させる機能も有しています。

しかしながら、災害救援のためのロボット飛行機には、災害時の情報管理技術との統合を行なうためにより多くのソフトウェアや機能の実装が必要となります。その重要な例としてSahana Edenがあげられます。これは世界中の災害に対するために使用できるオープンソースの人道支援プラットフォームで、災害情報の管理、開発、さらに環境管理部門のためのソリューションを提供しています。

ロボット飛行機の地上管制局である Ground Control Station と災害時救援情報共有システムとの間で情報をインポート/エクスポートする方法は、効果的なオープンソースの機能がありませんでした。そこでOpenReliefプロジェクトでは、RESTfulインタフェースを通じて双方とのやりとりを中継する小規模のサーバーを立てる事で、これに対処する事を検討しています。私たちの検討した「ドローン・マネージャ」の機能についての覚え書きを以下に示します。ただし注意して欲しいのは、これはテストシステムすらまだ出来ていないものだということです。

はじめに

「ドローン・マネージャ」は次のような機能を持った小規模のWebサーバーとして構想されています。「ドローン・マネージャ」は、ロボット飛行機に飛行データを渡したり、逆に受け取ったりするための Mission Planner ソフトウェアと接続し、それらのデータをSahana Edenに送ることができます。「ドローン・マネージャ」は、とても軽量で、モジュール式で、そして最初は重要な機能だけの小さな土台から始めて、徐々により多くの機能を追加していくのが理想的です。

最も基本的な機能は、ユースケースの1番目の項に記載されており、 Mission Planner に対して、自動操縦装置にロードするための飛行ルートデータを送り、逆に飛行後のGPSデータをSahana Eden に送り返します。

ドローン・マネージャのユースケース

「ドローン・マネージャ」には3つのユースケースが想定されています。ユースケースはそれぞれ、開発の優先順位や実装に必要な時間を考慮しながら進められています。

最初のバージョンでは、地上から飛行中のロボット飛行機を操作するのではなく、予め組み込んだ飛行ルートに基づいて飛行を行う事になるでしょう。さらに次のバージョンでは、飛行中のロボット飛行機からデータをストリーミングできれば便利です。最初はシンプルに「今どこにロボット飛行機があるのか?」から始めて、続いて「何が見えているか?」をリアルタイムで把握します。最終目標となる三番目のユースケースに必要と思われる通信ハブでは、Tegra2ベースのボードを使ってプロトタイプを作ろうとしています。これは、飛行機や配置されたセンサーからデータを取得するためのGSMやその他類似の方式と同様に、ソフトウェア無線を介して複数の通信帯域を利用することができます。

「ドローン・マネージャ」(私たちのロボット飛行機制御用のサーバソフトウェア)のユースケースを以下に示します。

  1. ラップトップとロボット飛行機の自動操縦装置とをUSBで1対1接続する。最初の段階として、1台のラップトップがロボット飛行機に1台ずつ飛行ルートを設定し、ロボット飛行機がライブ通信無しに目的地まで飛行し、戻って来ると測定結果をラップトップにダウンロードする機能を実装。Mission Planner では配布版そのままでこの機能を実装しており、同じ事を「ドローン・マネージャ」が、RESTful APIを通じて Mission Planner を操作することによって行わせる。
  2. 1台のラップトップに対して複数の飛行機の自動操縦装置をUSBで接続する。そして前項のケースと同じように自動的に飛行機を航行させ、データを出力する。これは実際の災害現場で目にする事になるであろう飛行機団管理の初期のタイプであり、「ドローン・マネージャ」は、RESTful API経由で Mission Planner を呼び出し、公開鍵によって複数のロボット飛行機をサポートする拡張機能を持ち、モジュールやプラグインを使用してロボット飛行機がどこに行ったか、そして、それらが何を見たかを視覚化する。これは実際の災害現場で目にする事になるであろう飛行機団管理の初期のタイプであり、「ドローン・マネージャ」は、RESTful API経由で Mission Planner を呼び出し、公開鍵によって複数のロボット飛行機をサポートする拡張機能を持ち、モジュールやプラグインを使用してロボット飛行機がどこに行ったか、そして、それらが何を見たかを視覚化する。
  3. 「ドローンマネージャ」は本部基地で稼働し、飛行中の複数のロボット飛行機と通信する機能を持つ。公開鍵IDシステムを使用することで複数のロボット飛行機をそれぞれ識別し、安全に管理する。ロボット飛行機は、ネットワークを介して飛行指示を受け取る事やデータを送り返すことができる。(法規や安全性が許せば)飛行中に飛行ルートを変更することができる。これは高度なユースケースであり、法規と技術との間でバランスをとる必要がある。最初の配備では(ケース2a)として、飛行ルートの指示は地上で受けるが、観測データは飛行しながら本部基地やその他の関係先にネットワーク越しに送るといった形になるだろう。

Sahana Edenとの統合

ロボット飛行機はたいへん複雑な仕組みで稼働しています。飛行機にはGPSデータや、遠隔測定、画像のデータも格納されています。GPSデータは測定データや画像をタグ付けする目的にも使用されます。ロボット飛行機が保有する複雑なデータの大部分は Mission Planner と呼ばれるソフトウェアで管理されます。Mission Plannnerは基本的に、ロボット飛行機がどこへ向かって飛行するべきかを指示し、また、ロボット飛行機の飛行記録を記録する役割を持ちます。計画では、私たちが「ドローン·マネージャー」と呼んでいる小さなサーバーを構築することを構想しています。ドローン・マネージャは、ロボット飛行機(自動操縦装置/コンピュータ)自体と、Mission Planner(飛行管理ソフト)、および管制本部で行われた処理、そしてGISデータを必要とする外的システム(すなわち、Sahana Eden)との間のブリッジとして機能します。

重要なポイントは、 Sahana Eden とロボット飛行機に直接やりとりさせる事はないということです。目的を実現するために、必要以上の事をやろうとして思い悩む必要はありません。「ドローン·マネージャー」から呼び出されるためのRESTfulモジュールを通じて Sahana Eden にデータを送り込めればそれで十分です。ジョージと私はこれまで「ドローン·マネージャー」が Mission Planner をRESTfulインターフェースを通じて操作するやり方を議論してきており、この方法はSahana Eden と機能を統合する際にもそのまま利用することができます。

要約すると、構想通りに「ドローン·マネージャー」によって Sahana Eden からデータをプルあるいはプッシュできるなら、 飛行記録や観測データをSahanaに送ったり、Sahana Eden を使って「この地点にロボット飛行機を飛ばす」といった事を指定できるようになります。

データ転送のコンセプト

「ドローン·マネージャー」と Sahana Eden との間の実用的な橋渡しを解決するための重要なポイントは、どのようなデータをやりとりさせるかを理解する事です。

ここまでで、いくつかの事柄がすでに明確になっています。

  1. 基本的なレベルでは、ミッション(個々の飛行を指し示す単位)と、それに関連付けられたロボット飛行機(の識別)・位置情報・時間情報、そして画像情報とフラグ(例えば”煙を見た”等)があります。何が・どこで・いつ・なぜ起きたのかを救援活動に携わる人々が把握するためには、「ドローン・マネージャ」はそれら全種類の情報を Sahana Eden に送る必要があるでしょう。一方、Sahana Eden が救援活動に携わる人々に通常必要とされる全ての救援活動計画やタスクを管理するのと同じように、私たちがさらに多くの種類のデータを送る必要があるかと言えば、それはどうでしょうか。私たちは、そういったデータまで全てをコピーしてきたりするつもりはありません。私たちは、ロボット飛行機が調査を行ってきた事を救援活動に関わる人々に知らせ、調査結果データにアクセスできるようにし、そして実際に起きた事柄とデータを関連付けて見極めることができるようにしたいのです。
  2. Sahana Eden の側からエクスポートするべきデータはおそらくさらに少ないはずです。まず必要となる情報は、最適な飛行ルートによる新しいミッション(飛行任務)を作成するための「ロボット飛行機に経由させる地点」の情報、そしておそらくそれに加えて既に調査されたエリアを再調査するための「やり直しミッション」の情報です。
  3. ミッションに対する識別IDは、おそらく重複して割り当てる必要があります。Sahana Eden でミッションを管理する際には、正常な作業フローを実行するため、それぞれのデータに識別IDを割り当てる必要があるでしょう。一方「ドローン・マネージャ」の側でも(Sahana Eden を併用せずにこれを利用する場合などには)、ミッションに対して独自に識別IDを割り当てる必要があります。総合運用を行うには Sahana Eden が主要なターゲットであることは確かですが、同時にOpenReliefのソリューションは、Sahanaとは独立して単独でも機能する必要があるのです。
  4. それゆえ、シームレスに相互にデータをプッシュ/プルできるようにするため、(双方の識別IDを関連付ける)共通のテーブルモジュールを持っている必要があるでしょう。OpenRelief APIとでも呼びましょうか 😉

役割分担

「ドローン・マネージャ」は、 Mission Planner ソフトウェアを介したロボット飛行機との全ての入出力・指示報告と、ミッションの識別ID管理を担うものとします。

Sahana Eden からは、飛行ルートの指定やエリアの再調査を要求できるようにします。

提案されたアーキテクチャの概要

Drone Manager Overview

Drone Manager Overview

主な構成要素は次のとおり:

  • Mission Planner は上記で説明したとおり、既存のソフトウェアです。
  • 「ドローン・マネージャ」は、 Mission Planner と Sahana Eden の間のブリッジとして機能する新しいソフトウェアです。
  • Sahana Eden は、私たちが最初のターゲットとしている救援情報管理ソリューションです。それは資産や人などの独自のデータベースを持っています。
  • Sahana Eden の OpenRelief モジュールは、「ドローン・マネージャ」との接続に必要なSahana Edenのプラグインです。

Open Reliefモジュールは、多くの役割を担います:

  1. 「ドローン・マネージャ」によって供給されたGISおよびミッションのデータを格納するために使用されるデータモデルを提供する。これらのモデルは、 Sahana Eden のデータベース内のテーブルを定義する。
  2. HTMLインターフェースを介して人間が、RESTfulインターフェースを介してコンピュータが、データモデルにアクセス可能なコントローラを提供する。
  3. 情報を表示するに任意の必要なビュー。

Sahana Eden のアーキテクチャは、RESTfulインタフェースを含むコントローラを実装するためのかなりの部分を提供するでしょう。やるべき事の大半はデータモデルとビューを定義する作業です。

地図データの視覚化

地図の上にデータポイント(例えば煙)を表示させるため、OpenReliefモジュールにはレイヤーなどを定義する機能が必要です。さらに、地図に立てた”ピン”を、元のデータと関連付ける必要があります。この機能は、例えば「この地域を再調査する」というようなオプションのために必要となります。

ドローン・マネージャとSahana Edenとのデータ転送の実装

実装は二段階で行われることが提案されています:

  1. ミッションデータを格納したCSVファイルをDrone Managerから Sahana Eden にエクスポートする。次に Sahana Eden から再飛行する必要がある飛行地点のリストを格納したCVSファイルをエクスポートする。Drone Managerは、このファイルをインポートする。
  2. これらの機能が正常に働く事が実証され、さらに双方のデータモデル設計が固まった後、Sahana Eden とドローン・マネージャの双方で、完全なRESTfulインタフェースを実装することが可能となります。

Sahana Edenの側では、ミッションのGISデータに対するCRUD操作をサポートするRESTFulインタフェースが必要です。Sahana Edenはドローン・マネージャに各ミッションイベントのイベントIDを渡さなければなりません。ドローン・マネージャ側では、ミッションの実施に必要な経路情報をEdenから作成できるようなRESTfulインターフェースが必要です。

論拠

このようにする事で、Sahana Edenの側でテーブル構造を定義し、また必要に応じて再定義することができます。これらのテーブルは、Sahana Edenがドローン・マネージャに提供するRESTfulインタフェースを通じて再利用されるでしょう。ドローンマネージャは、このインタフェースを用いCRUDスタイルの作法で、Sahana Edenにミッションの調査データをプッシュします。初めのうちはCSVファイルを使用する事で、Sahana Edenの OpenRelief モジュールとドローン・マネージャを分離しておきます。同様に、ドローン・マネージャの側でもRESTFulインタフェースが完全に定義されるまで、CSVファイルによってを航路地点情報をインポートします。

どちらの場合であっても、(相手側の)RESTFulインタフェースが完成するまでは、Webサーバから静的なファイルを送り返す事でダミーのデータを提供することができます。

データ転送APIの定義

どんなデータをドローン・マネージャからSahana Edenに渡したいのかを明確にする必要があります。 以下に1つの提案を示します:

  • a) 必要とされる特定のセンサの観測データ:
    • i) 時間(UTC形式 – GPSから取得可能)
    • ii) “事象”の発生位置(緯度、経度、+標高?)
    • iii) ミッションID
    • iv) 事象ID(SahanaのFranからの提案: UUID?
    • v) 事象のタイプ(煙/火災/人/放射線/天候など)
    • vi) もし追加データがあれば、そのデータへの情報参照(追加データの方からメインデータを参照するのが本来のやり方では? By Fran@Sahana)
    • vii) ロボット飛行機のID(Edenに必要?)
  • b) 事象の種類によって異なるデータ
    • i) 煙/火災/人の場合は、画像データ
    • ii) 放射線の場合は、センサーの値
    • iii) 天候の場合は?(提案として:現在気温、最高気温、最低気温、風向、風速)

ユーザーインターフェイスのモックアップ

ユーザーがドローン・マネージャと対話する方法についての議論の叩き台として一連のプロトタイプを作成しました。

Leave a Reply