Qtを活用した
QGroundControlの
実行時カスタマイズ

ドリフトのないカスタマイズ

通常、ドローンメーカーは、コンパイル時の拡張機能を通じて、QGroundControl を自社のユースケース向けにカスタマイズします。この仕組みは強力ですが、そのコードベースに不慣れな開発者にとっては、かなりの学習コストを伴います。

新しいパネル、新しい MAVLink メッセージ、追加のメニューオプションといった、ささやかなカスタマイズであっても、時間と労力を要します。

フォークによるカスタマイズが増えるほど、アップストリームのリリースへ追従するための保守負担やコストも大きくなります。

リリースのたびにマージ作業が発生し、アップグレードは先送りにされ、セキュリティ修正は手作業でバックポートすることになります。

ランタイム設定レイヤーがあれば、製品を特徴づける変更について、こうした負担そのものが不要になります。

メンテナンスと、メインラインとの差分

フォークすることは想定の範囲内です。QGroundControl の開発者ガイドも、チームにフォークしてカスタム例をコピーするよう案内しています。メンテナンスコストは、フォーク内で編集した範囲に比例し、ガイドにも明確にこう記されています。

「QGC のメインラインソースへの変更は、最小限に抑えることが最善です。」 

設定レイヤーがあれば、この差分をほぼゼロに保てます。作業は、カスタムビルドディレクトリやプラグインのサブクラス化といった、QGroundControl がサポートする拡張アーキテクチャの範囲内に収まり、それ以外は Qt がすでに提供している仕組みに頼ることができます。 

 現行のアップストリームに対する定期的なリビルドにより、残存する差分を継続的に可視化でき、汎用性のある変更についてはアップストリームへコントリビュートすることで、差分を恒久的に解消できます。QGroundControl の開発者ガイドも、それを推奨しています。 

ライセンスと規制上の考慮事項

QGroundControl は、Apache 2.0 と GPL v3 のデュアルライセンスで提供されており、どちらを選択するかによって、出荷する製品に課される義務が決まります。

GPL v3 のもとでは、変更内容を公開する必要があります。Apache 2.0 のもとでは、プロプライエタリのまま維持できますが、その場合は商用の Qt ライセンスが必要になります。

この選択は、自社がプロプライエタリとして維持したい部分を左右するため、コードができてから切り分けるよりも、開発に着手する前に決めておく方が、はるかにコストを抑えられます。