ここ数年、ドローン（UAV）は目覚ましいスピードで活用されるようになってきています。中でもドローンの活躍が著しいのが空撮や建築・測量業界ですが、こういった業界では急速な普及に運用者側の理解が追いつかない面もあるようです。
こういった世間の流れの中、K-ki（K-ki@Ailerocket）は、縁あって日本測量協会の発行の「月刊測量」という専門誌に、測量業界の人が無人航空機について理解を深めるための記事を連載させてもらいました。今回の記事は、月刊測量 2018年3月号にK-kiが寄稿した記事を、月刊測量の発行元である日本測量協会の許可を得て、Ailerocketに転載したものです。2回連載のうち第2回に相当するもので、下記ページの続きになります。
-
-
UAVの飛行制御と開発プラットフォームについて（1）機体構成と製品群
ドローン(UAV)の活用はかなり普及した一方、運用者の理解が追いついていない面も多くあります。このページでは、建築・測量関係者が無人航空機の原理を簡単に理解できるよう、月刊測量 2018年2月号に寄稿したUAVの飛行制御と開発プラットフォームに関する解説記事を紹介します。
「UAVの現状と可能性」は、UAVを利用した測量に関して、各分野の専門家が様々な視点から啓発を行っているかなり興味深い連載です。測量に直接的な関係がなくても、ドローンを利用する人ならきっと役に立つ情報が掲載されているので、ぜひ月刊測量も手にとってみてくださいね！
ドローンコードとは
前回は、ドローン開発のプラットフォームとして、世界最大のシェアを持つ中国のDJI社と、米国の3DRobotics社が牽引するドローンコードの2つを紹介しました。2回連載の後半である本稿では、これらのうちドローンコードを一例として、UAVの飛行制御がどのような仕組みになっているのか、簡単に解説していきます。
まずはドローンコードが具体的にどのようなプロジェクトなのか説明しておきましょう。ドローンコードプロジェクトの運営母体は、Linuxオペレーティングシステムの普及を目指す非営利の企業団体「The Linux Foundation（リナックスファウンデーション）」です。
このLinux Foundationの指揮のもと、複数の企業がドローンコードプロジェクトに参加し、既存または開発中のオープンソースプログラムを統合し、ドローン向けのオープンソースプラットフォームを作ろうとしています。
その中でも中心的役割を果たしているのが、Solo、Iris+などのコンシューマ向けドローンや、ドローンコードの標準FCであるPixhawkの販売元として知られる「3D Robotics（3DR、3Dロボティクス）」です。ドローンコードの参加企業に対しては、開発に当たる技術者や出資金などから数段階のランク分けがなされますが、3DRと同じ最上位メンバーである「Platinum」としては他に、IntelとQualcommが参加しています。
メンバーのランクには、Platinum、Gold、Silver、Sponsorが存在し、日本からは株式会社CLUEがSilverメンバーとして参加しています（2017年11月現在）。また、かつてはドローン・ジャパン株式会社やドローンワークス株式会社、株式会社エンルートなども参加していましたが、これらの一部は現在ドローンコードではなく、ドローンコードを離脱したArduPilot Megaフライトコード（APM）のスポンサーになっているようです。
Pixhawkフライトコントローラの詳細
ドローンコードについて概要を説明したところで、第2回である今回はもう少し飛行制御に立ち入った話をしてみましょう。ドローンコードの標準フライトコントローラ（FC）であるPixhawkは、STM32プロセッサのF4シリーズという高性能なプロセッサを利用しています。一方で、センサに関しては、IMU（Inertial Measurement Unit、慣性計測装置）が二系統、コンパスが一系統、GPSは外付けという仕様です。DJIの産業向けFCであるA3が三系統のIMU、コンパス、GPSを搭載していることを考えると、相対的には安全性に欠けると言わざるを得ません。
Pixhawkでも、外付けのGPSモジュールを2つ設置することで、コンパスとGPSについても二重冗長系にすることが可能です。また、最新の「Pixhawk2」では、IMU、コンパスについては三系統を搭載しているため、GPSモジュールは外付けという考え方の違いだけで、性能面で劣るものではないとも言えます（図-1）。ただ、この辺りの違いをきちんと認識した上で、UAVを運用している人は少ないのではないでしょうか。
APMフライトコードの特徴
ハードウェアであるFCの次は、ソフトウェアであるフライトコードについて、その中身に触れてみましょう。以下では、以前ドローンコードのメインフライトコードを担っていたAPMについて、具体例を交えながらその仕組みの一部をごく簡単に説明します。現在のメインフライトコードであるPX4ではなくAPMを取り上げるのは、単に私がPX4よりもAPMに慣れているためです。
APMをはじめとした多くのフライトコードでは、FCに搭載されたIMUから取得する角速度、加速度や、気圧高度計、GPSによる位置情報などのセンサ信号から、カルマンフィルタを利用して、機体の実際の位置や高度を推定します。ここで、例として機体の位置について、カルマンフィルタがどのような処理を行っているのかを確認してみましょう。
IMUから取得された角速度及び加速度を積分することにより、機体姿勢と各軸方向の速度を算出できるため、過去の位置から機体の現在位置を予測することができます。ただし、この「予測位置」は、積分誤差が蓄積するため正確ではありません。一方で、FCはGPSから得られる現在位置の情報（観測位置）も知っていますが、これにはセンサの計測誤差が含まれるため、こちらもばらつきを持っています。カルマンフィルタでは、これら2つの不確かな位置情報から、実際の機体の位置（真位置）を推定します（図-2）。
このとき、IMU由来の慣性センサ信号から積分計算した予測位置と、GPS由来の観測位置のどちらをどの程度信用するのか、という問題が生じます。この問題は、APMの場合、GPSセンサによる観測位置がどの程度ばらつくかというパラメータをチューニングすることで決まるため、利用するGPSモジュールの特性を運用者が把握した上でパラメータを決めなければ、最適な推定はできません。
もちろん、ある程度もっともらしい値がデフォルトで設定されてはいますが、GPSモジュールの選択にそれなりの自由度があるドローンコードにおいては、最適解は結局のところ運用者側で探すことになるでしょう。
また、GPSが完全な外付けという仕様も、運用者が機体についての理解が不足している場合、危険を生み出す可能性があります。
APMでは、GPSモジュールを外付けすることで、位置情報を利用した自律飛行モードが利用できるようになります。その中には、RTH機能（Return To Home、自動帰還機能）と呼ばれる、飛行開始地点に自動的に戻ってきてくれる非常に便利な機能もあります。特に、技量の低い操縦者はこの機能に頼りがちですが、注意すべきはGPSモジュールを一つ設置しただけでもこの機能が利用可能になる点です。
もしも、唯一搭載されたGPSモジュールがフェール（故障）状態になってしまうと、正確な位置が推定できません。するとRTH機能をオンにした際に、見当外れの場所に向かって飛んでいってしまう可能性がありますし、実際私にもそういった経験があります。
まとめ
オープンソースプロジェクトであるドローンコードでは、当然ながらユーザが自由に開発できることを重要視します。そのため、UAVの開発の自由度は高いですが、なまじ自由度が高いばかりに、システムの構成をよく理解していないと、危険な操縦をしてしまう可能性があります。もちろん、DJIなどの既製品UAVの運用でも同じことがいえますが、ドローンコードの方がより自由度が高いため、システム全体としての完成度を高める作業が必要になり、機体やソフトウェアに不具合を入れ込む可能性が高くなる場合があるとか、操縦者が機体システムをより正確に理解する必要があるなどの注意点もあります。
また、ドローンコードに則ったUAVを利用する場合には、ソフトウェアについて知った上で、GPSモジュールを2つ設置するなど、ハードウェアの調整が必要になる場合もあります。十分な知識を持った担当者がシステム構成を掌握しておかなければ、安全性に欠けるシステムを作ってしまう可能性もはらんでいるのです。
本来、航空機におけるセンサやアクチュエータの冗長性は、慎重な検討を重ねた上で決定されるものです。オープンソースプロジェクトであり自由度が高いドローンコードでは、機体ハードウェアについても、ソフトウェアについても、非常に簡単にシステム構成を決めてしまえます。しかし、少なくとも産業向けの利用においては、安全性の高いシステムを慎重な検討の上に構成する必要があります。無人とは言え、航空機が墜ちるということは、非常に大きな損害を生じる恐れがあるということを、肝に銘じておきましょう。
