Mobile・Payload・Cloudの役割

Mobile SDKは対応するモバイル環境から機体やカメラの機能へアクセスするための開発基盤、Payload SDKは対応機体へ搭載するペイロードの統合、Cloud APIは対応する業務用製品のクラウド連携を扱う。名前にSDKが付くけえ同じ用途、ではないんじゃ。撮影プリセットを送信機で操作したいのか、自作センサーを積みたいのか、遠隔の運用基盤と結びたいのかを先に分けよう。一般向け機体の純正アプリにある機能を、業務向けCloud APIの説明だけで使えるとは判断できん。必要な機能から対応する層を選ぶんよ。 必要なのが録画開始と設定の統一だけなら、飛行経路の自動制御まで広げる理由はない。実装する範囲を撮影の目的に合わせて絞り、各機能がどの権限と接続を必要とするかを書く。小さい機能でも実行結果の確認は省かんことじゃ。

対応表は四つ組で読む

対応を確認する単位は、機体、送信機、SDK版、ファームウェアの組み合わせじゃ。OSやカメラ型式、接続方式も必要になる。今回確認したV5資料にはMini 4 Proなどの対応記述があり、昔の「MiniはSDK非対応」といった一括説明は使えん。一方、対応製品の一覧に名前があっても、全てのミッションやカメラ機能が同じ条件で動くとは限らん。リリースノート、対象APIのSupported欄、実行時の機能照会を順に確認しよう。日付とリンクを残し、試した組み合わせを次の担当者へ渡すんじゃ。 確認表には「対応」「非対応」「未確認」を別の値で入れよう。未確認を対応へ丸めると、現場で初めて制限に気付くことになる。SDK更新の前後で同じ短いテストを走らせ、挙動が変わった項目を明示すると引継ぎが楽になるんじゃ。

空撮アプリの最小検証

独自の検証順は、接続と状態読取、カメラ設定、録画状態、ジンバル指令、最後に飛行ミッションじゃ。各段階で、指令を送れたことと実際に状態が変わったことを別々に確認する。Waypointを扱うなら、高度基準、座標、Yaw、ジンバル、到達時動作、中止、再開、通信断を項目にする。純正アプリのWaypoint、SDKのミッション、仮想スティックで自前計算する経路は、同じ実装ではないんよ。飛行前はシミュレーションやメーカーが指定する地上検証を使い、失敗時に安全側へ戻る設計を先に完成させるんじゃ。 撮影設定をまとめて送る場合も、一部だけ失敗したときの表示を設計するんじゃ。録画開始だけ成功して画角変更が失敗した状態を、全成功として扱わんこと。撮影票に必要な条件が揃ったことを確認してから、そのテイクを採用する。

YOUR NEXT STEP

実践してみんさい。

ここでつまずきやすいんじゃ
  • V4とV5、AndroidとiOSの対応を混ぜんこと。
  • 対応機体という表示だけで全API利用可能と扱わんこと。

出典と編集上の位置づけ

Sir Airffic Goの解説と練習課題は本ガイド独自の編集じゃ。製品固有の条件はリンク先の該当版を確認してつかあさい。

  1. DJI — Mobile SDK V5 release notes and supported products ↗
  2. DJI — Mobile-SDK-Android-V5 official repository ↗
  3. DJI — Cloud API documentation ↗
  4. DJI — Payload SDK official repository ↗

資料確認:2026年10月21日。製品の対応機種・版、制度の適用条件はリンク先で確認してつかあさい。出典には本文確認済みと公式検索索引での確認が含まれるで。

調査方法・未確認事項を見る →