ドローンのフライトコントローラ周りのOSSプロジェクトについて

  • 37
    Like
  • 0
    Comment
More than 1 year has passed since last update.

1.はじめに

ドローンのフライトコントローラを開発するオープンソースプロジェクトについてよくわからなかったので調べてみた。色々と誤解しやすいポイントや情報不足があったので、備忘録として書いてみた。

有力なプロジェクトには、「Dronecode」、「APM/Ardupilot」、「PX4/Autopilot」の3プロジェクトが存在する。

それぞれの公式サイトを見ると、これら3つのプロジェクトが互いに関係しているかのように見受けられるが、その関係が非常にわかりづらい。

例えば、PX4/AutopilotではPixhawkというハードウェアを開発している。しかし、Pixhawkに関して、APM/Ardupilotの公式サイトで言及され、さらに購入まで出来てしまう。これだけを見ると、PixhawkとAPM/Ardupilotの関係が非常にわかりづらい。

また、公式Websiteの情報も不十分であり、細かな事実を知るためには、他のサイトの情報を総合しないと全貌が見えない。(注:この文書を書いている間にDronecodeのWeb Pageが非常にわかりやすくなっていた。活発なOSSプロジェクトは仕事が早い!)

さらに、ソフトウェアアーキテクチャの概要がわかりにくいプロジェクトもある。そのため、概要を知ろうとすると、コードを読むしかないのが現状だったりする。

よって、この文書を書いてみた。
調べたことをまとめることで、以下のいいことがあると思う。

  • アーキテクチャやプロジェクトに関する誤解を防ぐ
  • フライトコントローラ周りの開発に必要な情報を追加で提供する。
  • 私の認識に間違いがあれば、マサカリが飛んできて、目が覚める(笑)

2.オープンソースプロジェクトと開発物件の概要

2-1.Dronecode

DronecodeはLinux Foundatitonが運営するプロジェクトである。Dronecodeは「to spread the collaborative DNA of Linux to new fields to enable innovation and access for all. 」(参考ページはここ)を目的とした、ドローンのオープンプラットフォームを整えるために横串活動をする組織のひとつである。
例えば、ドローンを考えると、ハードウェアプラットフォーム、OS、その上で動く各種ライブラリなどのモジュールがある。これらモジュールはそれぞれ別個のオープンソースプロジェクトで運営されているが、横串活動によってモジュール間の人的な交流を促したり、システムとしてあるべき姿を追求しやすくできる。
なお、モジュールの開発は各プロジェクトごとに行い、Linux FoundatitonだからといってプラットフォームをLinuxにすることを目指していない点は注意が必要である。

2-2.APM/Ardupilot

3D Robotics社によって創設されたオープンソースプロジェクト。

APM/Ardupilotはもともと、Arduinoという8bitマイコンボードをベースとしたフライトコントローラを開発していた。そのハードウェア名称がArdupilotである。
Ardupilotのアーキテクチャを32bit化して、ArduPilot Mega(APM)と名称を変更した経緯がある。

2-2-1.APM/Ardupilotの構造

APM/Ardupilotは、大きく分けて以下4つの要素で成り立っている。
(1)ハードウェア。ハードウェアとしてのArdupilot、APMを開発・販売していた。
しかし、現在、3D Robotics社で販売しているハードウェアはPX4プロジェクトによって開発されたPixhawkである(後述)。ハードウェアとしてのArdupilot、APMは販売終了となった。

(2)(1)のハードウェア上で動作するファームウェア。ドローンの場合はAPM:Copterというソフトウェアコードを用いる。こちらは現在も精力的に開発が続いている。
アーキテクチャ概要は、以下図を参照のこと。
※APM/Ardupilotプロジェクトでは、以下のようなアーキテクチャ図を用意していない。そのため、全体観が極めてわかりにくい。各部位の詳細な説明は、このページを参照のこと。

apm_framework.png

現状、APM:CopterはNuttxというリアルタイムOS上で動作する(このページを参考)。よって、Nuttxがサポートするハードウェア上でAPM:Copterを動作させることは可能である。例えば、後述するPixhawkがこれに該当する。なお、APM:Copterが動作するハードウェアアーキテクチャ一覧については、このページ参照のこと。

(3)(2)を搭載したドローンの操縦を支援するためのソフトウェア。これはMISSION PLANNERという自動操縦のためのソフトウェアがあったりする。この点はPX4も同様である。
なお、DroneKitというドローン操縦ソフトウェアを開発するためのフレームワークがあるので、別途参照されたい。
(4)デバッグのためのシミュレーション環境。これについては、後述するPX4も同様なのだが、SITLというシミュレート環境があったりする。

2-2-2.APM/Ardupilotの特徴

  • 構成が単純でシンプル
  • 先発プロジェクトで動作実績も多く、枯れている ○HAL(Hardware abstruction layer)上にソフトを構築する。これによって、ハードウェアやOSの違いを吸収するため、移植が楽で再利用性が高い。
  • フライトコントローラ単体では賄えない機能(e.g.画像処理、機会学習的な処理)追加がやりにくい。
  • イベントループを基本としたシンプルなやや古いアーキテクチャでかつスレッドも時分割なので、ライブラリを多数呼ぶと反応が鈍くなる。
  • ソフトウェアのライセンスがGPLのため、商用利用がしづらい一面もある。

2-3.PX4/autopilot

チューリッヒ工科大学のLorenz Meier氏により2009年に創設されたPixhawkプロジェクトが、PX4/autopilotの前身である(他には、dronecode設立に関する日本語記事チューリッヒ工科大学のLorenz Meier氏紹介ページPX4と3D Robotics社の関係が参考になる)。

ややこしいのだが、Pixhawkプロジェクトにより、PX4というフライトコントローラが開発されたのである。
PX4はフライトコントローラ機能が複数ボードで構成されていたが、1枚にフライトコントローラ機能をまとめ、さらにポートを追加したフライトコントローラがハードウェアとしてのPixhawkである。
現在、Pixhawkハードウェアの開発はPX4/autopilotプロジェクトが行い、販売は3D Robotics社が行っている。(※この文書では断りのない限り、「Pixhawk」という単語はフライトコントローラのハードウェア名称を指す。)

2-3-1.PX4/autopilotの構造

PX4/autopilotは、大きく分けて以下4つの要素で成り立っている。
(1)ハードウェア。これは原則、Pixhawkである。

pixhawk.png

(2)(1)のハードウェア上で動作するファームウェア。これは「PX4 Flight Stack」と呼ばれている。
このアーキテクチャでは、モジュール間通信をするために「ORB」と呼ばれる1対多のPublisher-Subscriberパターンを用いている。

この仕組みにより、他のモジュールとのイベント通知が簡潔になっており、イベント通知側は具体的な相手を意識しなくても良い。このことが、シミュレーションとの相性を良くしている。(シミュレータ相手にイベントを通知するためのコードをわざわざPublisher側に書かなくても良い)。

さらに、ロボット開発ではROSと呼ばれるイベント通知の仕組みがよく使われているが、このROSのノードとも通信が可能である。
フライトコントローラ単体で賄いきれない高度な機能を実現したい場合は、別ボードでLinuxなどの高級なOSを動かしてお互いにノード間通信を行う必要がある。今述べたORBにより、こうした拡張がやりやすくなっている。これを示したのが以下の図である。

px4_stack.png

※PX4 Flight Stackは以下の図中の「DEEPLY EMBEDDED CONTROLLER」にあたる。また、LINUX COMPANION COMPUTERはオプショナルなものであり、必須ではない。Pixhawkの開発者向けドキュメントの記述では、PX4が諸々のライブラリを含む大掛かりなシステムであるかのように誤解する可能性があるため、注意されたい。

また、ライセンスはBSDライセンスであり、ソースコードの公開は任意となる。
なお、PX4/AutopilotはNuttxというリアルタイムOS上で動作する。
ソフトウェアアーキテクチャの詳細は、論文を参照されたい。

(3)(2)を搭載したドローンの操縦を支援するためのソフトウェア、デバッグのためのシミュレーション環境については、APM/Ardupilotと同様。

2-3-2.PX4/Autopilotの特徴

  • フライトコントローラ単体では賄えない機能(e.g.画像処理、機械学習)追加が比較的容易。
  • ソフトウェアのライセンスが修正BSDライセンスであり、商用利用しやすい。
  • APM/Ardupilotに比較すると開発者やコミット数が少ないが、それでもプロジェクトは活発。
  • APM/Ardupilotに比べると、アーキテクチャがやや複雑。単に飛ばすだけならそこまで大掛かりにする必要はないとも思える。
  • APM/Ardupilotに比べると、実績が少ないが、世の中で広く使われれば枯れてくると思われるのであまり問題にならないと考えている。

// 以上