Vol.47 日本の産業用ドローンで急速に浸透するArdupilot[春原久徳のドローントレンドウォッチング]

Ardupilot拡大の背景

以前から中国製ドローン（主にDJI）への様々な懸念はあったものの、DJI機の扱いやすさや機能の高さもあり、DJIの汎用機のシェアは圧倒的だった。そして、国産の産業用ドローンも、DJIがNAZA-Mのようなフライトコントローラー、そしてSシリーズ（S600など）といった作りやすいフレームを提供していたこともあり、DJIのフライトコントローラーを採用している機体メーカーが多かった。

それが2019年ぐらいより、中国リスクといった流れが出てくる中で、特に公共機関や大手企業に納める機体メーカーにおいて、DJIのフライトコントローラーからのシフト準備が始まりだした。その流れがより強くなったのは昨年9月に実施された「小型無人機に関する関係府省庁連絡会議」での"ドローンに関するセキュリティリスクへの対応について"という文書が発表されてからだ。

これはドローンのセキュリティリスク全体への方針を示したもので、必ずしも"中国リスク"のみに言及されたものではないけれど、この文書以降、大手のユーザー企業がドローンの実用化を進めるにおいて、中国機体および中国製のフライトコントローラー搭載機体（事実上DJI機体やDJIのフライトコントローラー）の展開が役員会で通らなくなった。

DJIのフライトコントローラー（Naza-M V2やA3など）を搭載した機体メーカーはそのシフトにおいて、いくつかの選択肢が考えられるが、その入手性や技術情報といった観点からすると、オープンソース系のPixhawk系のフライトコントローラーにシフトした企業が圧倒的に多かった。

そして、このPixhawk系に載せるファームウェアとして、PX4とArdupilotがあるが、これは前回のコラムで記したように、米国においてはPX4が主流に踊りでている。しかし、日本においては、その技術者が少ないといったことや、PX4に関しての情報が体系化されていないといったこと、またPX4の場合、コア部分のみがオープンソース化されているが、より高度化された機能に関しては、クローズで各機体メーカーでの実装が難しい（これはライセンス形態の関係がある）ということもあり、Ardupilotを選択している機体メーカーが多いように思う。

しかし、日本の機体メーカーの多くは、ラジコン機体の製造から継続していることもあり、フレームのバランスや部品やその他のハードウェアの選択やそこでの配置などに長けた企業や技術者は多いが、どうしてもドローンのソフトウェアエンジニアが少ない。

DJIのフライトコントローラーを搭載していた場合は、DJIのツール（DJI Assistantなど）を使って調整を行っているケースが多く、その内部に踏み込んでいるメーカーは少なく、DJI SDK（Software Development Kit：開発者向けキット）を使って開発を行っている機体メーカーも少なかった。

機体開発のため、機体メーカーが行うべきもの

■ハードウェアの選定

機体メーカーが機体開発を行う場合、まずはその機体のフレームワークや大きさなどを利用用途や必要スペックに応じて、まず決定していく。空を飛ぶ自律機の場合には、その方式－マルチコプター、シングルローター、固定翼、VTOLなどもその利用用途や必要スペックの中で検討していく。

マルチコプターを選択した場合にも、4枚機、6枚機、8枚機なども開発計画の中では当然早期に決定する必要がある（これは積載重量"ペイロード"やリスク軽減といった観点などでチョイスしていく。その中で飛行時間やコストなどをバーターとして考慮する必要がある）。

こういったところまでは、多くの機体メーカーが理解しているし、得意としている企業も多い。外形が決めていくタイミングで、各種部品の選定となる。フライトコントローラー、バッテリー、電源制御、モーター、プロペラ、ESC（モーター制御）、送受信機など、特にモーターなどはペイロードに合わせての選定となってくる。

■静止推力の計算

そのほか、プロペラの角度によって、機体制御に影響を与えている（基本的には角度が深ければ、急な動きが可能だが、推力が劣り角度が浅い場合は、推力は増すが動きが緩慢など）。

今後の産業用ドローンにおいてはより安全性や安定性を増す観点から、フライトコントローラーはもとより、バッテリーやモーターなどの部品選定も重要になってくる。トラブルに対する観点から、最近増えてきているのは、双方向のESCの選択なども重要になる（通常ESCは片方向の信号となるが、その場合、電源のモーターへの制御や監視は可能だが、モーターの停止などの情報が取得できず、ログをとった場合も判明がつかないケースが生じている）。

■ソフトウェアのインストールと設定（Ardupilotの場合）

機体が組みあがったら、フライトコントローラーにArdupilotのファームウェアをインストールする。ファームウェアのどのバージョンをインストールするか（基本的には動作検証が取れているもの）を選択し、Mission PlannerなどのGCSよりインストールするのが一般的だが、今後、ファームウェアのバージョン管理は重要な要素になってくるので、そういった管理機構（クラウドでのサービスなど）を使う必要もでてくるだろう。

設定に関しては、キャリブレーションとパラメーター（チューニング）の設定がある。

キャリブレーション

キャリブレーションは各センサーや部品の個体差や環境誤差を整えるための作業である。キャリブレーションに関しては、以下のものがある。

この後にパラメーターの設定となるが、パラメーター設定は実機を使って実作業にて行うので、この段階でいったんプロポに対して、フライトモードのスィッチ設定を実施する（基本的にはプロポのCH5にて設定）。

パラメーター（チューニング）

各種の内部設定はパラメーターといった形で管理されている。機体制御（PID制御、自己位置推定など）、フェイルセーフやペイロード制御（カメラなどの制御など）など、ドローンの様々な挙動がパラメーターで管理されている。

このパラメーターをきちんと把握することが、機体の機能や安定、リスク回避のために重要となってくる。このパラメーターを設定することで、機体のチューニングを行うが、パラメーターを個々に設定するのは、非常に難しい作業になっているので、ベーシックチューニングやAUTOTUNEチューニングが準備されている。しかし、最終的にはパラメーターを細かく調整しながら安定性の向上（部品やセンサーの個体差や操作性など）を図っていく。

フェイルセーフ

そのほかの設定としては、バッテリーの減少、通信（プロポ・テレメトリー）の切断、GPSロスト、ジオフェンス（飛行制限区域）などのフェイルセーフの設定がある。

機体メーカーとして、ソフトウェア開発が必要なこと

基本的には上記作業を行うことにより、Ardupilotの基本機能での機体制御および機体管理が可能となる。

機体メーカーから様々なソフトウェア開発に関しての質問を受けるが特に機能追加などに関しては、実際はすでにArdupilotが基本機能として実装されている場合が多く、それに伴うデバイス（例えば、高度検知のためのライダーなど）を機体に実装し、設定を行うだけで機能追加でき、実際上はソフトウェア開発が必要ない場合が多い。ソフトウェア開発が必要になるケースは以下となる。

新規のフライトモード

新規フライトモードの開発は、前記に記したフライトモード以外を開発したい場合になる。

例えば、急降下モードといったサークル動作をしながら降下するモードなど（降下するときに直線的に降下させると機体が不安定になりひっくり返りやすくなるため、安定しながら急降下させたい場合は、操縦が上手な人はサークル動作をしながら降下させる技術を使うが、それを自動で行うようなモード）。

新規フライトモードの開発には2つ方法があって、1つは似たモードのソースを引っ張ってきて、そのモードを改造する方法（急降下モードはサークルモードをコピーし、それを改造するといったやり方）とLuaスクリプトというプログラミング言語を使って、既存のフライトモードを組み合わせる方法となる。

前者は比較的自在に開発が可能になるが、フライトモードの開発は影響を与える部分も多く中には深刻な影響を与える場合もあるのでリスクも生じるが、後者はサンドボックス方式により、コアのフライトコードに手を入れないため、比較的安全に開発を行うことができる。また、前者はそのコードをArdupilotに実装するためには、GitHubを通じて、プルリクエストといったプロセスを踏み、承認される必要があるが、後者ではそういったプロセスを必要としない。

デバイスドライバーの開発

機体制御に関係するデバイスをフライトコントローラーで認識し、動作させるためのドライバーの開発。

その他の機体制御に関する新規機能や安定化のための開発

この開発は機体制御に関して、より連携が強い開発になるため、深い知識が必要（自己位置推定や衝突回避、非GPS空間での制御など）。

ここまでがC＋＋で記述されたフライトコードを修正もしくは新規コーディングする内容となる。その他の機体制御もしくは機体管理系はRaspberry Piなどのコンパニオンコンピューターを利用しての開発がある。

高度な機体制御の開発

SLAM（Simultaneous Localization and Mapping：自己位置推定と環境地図作成を同時に実行）といった非GPS空間での機体制御などが代表的で、その他、マーカーなどによってアクションを起こすなど、様々な開発がされている。基本的にはフライトコントローラーとMAVLINKといったコミュニケーションレイヤーでのメッセージプロトコルを使って接続し、Guidedなどのフライトモードを利用して機体制御を行う。

機体のログ解析

機体開発において、そのトラブルの改修や安定化のため、機体のログ解析を行いながら、調整していくことが必須である。Ardupilotには2つのログがある。1つがテレメトリーログであり、もう1つがデータフラッシュログである。

テレメトリーログ
テレメトリーという機体情報の情報を受け取るように接続されたGround Control Station（GCS：代表的なものはMission Planner）内に記録されたログ。
主に機体の移動やGCS上に示される情報のログとなる。

データフラッシュログ
フライトコントローラー内に記録される機体の内部ログ。

よく確認するデータ

• ATT（姿勢：ロール・ピッチ・ヨー）
• BARO（気圧）
• CTUN（高度・スロットル）
• BAT（電圧・電流）
• GPS
• IMU（加速度・ジャイロ）
• MAG（Compass）
• RCIN（プロポからの入力）
• RCOU（ESC/モーターへの出力）
• VIBE（振動）

ログの解析例

• 機体的破損：一般的な機械的故障としては、モーターまたはESCの故障（ESC同期不良を含む）、プロペラの滑りまたは脱落などがあります。これらは、ロール（DesRoll）およびピッチ（DesPitch）と機体の実際のロール（Roll）およびピッチ（Pitch）との突然の乖離としてログに表示される
• 原因：ESC/モーター/プロペラ
• 確認データ：ATT、DesRoll、Roll、DesPitch、Pitch

上記のグラフが突然に乖離している部分に異常が見られる。

ここまで示したように、機体開発においては、より飛行や挙動を安定させたり、新たな機能を追加したりするために、単なる調整だけでなく、様々な機能の実装や開発が必要となる。また、そこでの安定化を図るためには、細かいチューニングやログデータの解析による改善や修正が必要となってくる。

機体メーカーにとってはこういったことを理解し、また、実装したり開発したりすることができる人材の確保が重要となっている。

5月にアルデュエックス・ジャパン株式会社が創立された。アルデュエックス・ジャパンはこういったArdupilotを搭載した機体メーカーを開発支援するための会社となっている。

開発受託ではなく、開発支援としているのは、ドローンは一旦開発してしまえば終わりではなく、継続的に開発や改修を行っていく必要があるからであり、各機体メーカー内でのソフトウェア人材を育成していかないと立ちいかなくなるからであり、共に進んでいこうということからだ。

そして、日本にとって大きなアドバンテージがあるのは、Ardupilotのトップエンジニアで、アルデュエックス・ジャパンのCTOも担っているRandy Mackey氏が日本に居住を構え、日本語を理解していることであり、その利を活かしていくことは非常に重要であると考えている。