DJI Matrice 修理ガイド: フリートの診断と証拠

企業航空機の診断

DJI Matrice 修理の決定は、正確な航空機、ペイロード、コントローラー、バッテリー、ドックまたはフィールド キット、およびミッション要件から始める必要があります。 Matrice 30、Matrice 300 RTK および Matrice 350 RTK はエンタープライズ ロールを共有しますが、すべてのアセンブリ、インターフェイス、または受け入れテストを共有するわけではありません。このガイドでは、1 つの警告を部品注文として扱うことなく、フリートに関する懸念を文書化された診断パスに変換します。

簡単な答え

1 つのコンポーネントを診断する前に、エンタープライズ システム全体を特定する

正確な Matrice モデルとリビジョン、コントローラー、ペイロード、バッテリー ペア、充電機器、ファームウェア コンテキスト、イベント履歴、ミッション効果を記録します。作業を承認する前に、航空機、ペイロード、位置、リンク、および電力の証拠を分離します。 Reboot Hub は、確認された所見、未解決のリスク、修理範囲、およびサービス復帰テストを書面で報告するため、オペレーターはコンポーネントの決定だけでなく運用上の決定を下すことができます。

顧客が行動する前にどのような証拠を取得する必要がありますか?

修復ベンチの経験は障害ドメインをどのようにマッピングしますか?

実際に修理されているのはどの Matrice システムですか?

製品ラベルと物理システムから始めます。 Matrice 30 および Matrice 30T は、コンパクトな統合エンタープライズ航空機です。 Matrice 300 RTK および Matrice 350 RTK は、モジュール式ペイロード構成とさまざまなフリート ワークフローをサポートします。到着した正確な航空機、コントローラー、ペイロード、RTK コンテキスト、バッテリー モデル、充電ハードウェア、付属品を記録します。ファミリ名は互換性を示すものではなく、Matrice 互換と記載されているというだけの理由で交換アセンブリを承認することはできません。

構成証拠は、顧客をスコープのドリフトからも保護します。分解する前に、無傷のキット、識別子、ポート、マウント、バッテリー ベイ、および目に見える状態を写真に撮ってください。コンポーネントが欠落しているかどうか、および問題が 1 つのペイロード、バッテリー ペア、またはコントローラーで発生するかどうかをメモします。文書化されたモデルおよびボードのリビジョンに属する場合、ケースレベルの部品番号、チップ識別子、または測定値が開示される場合があります。 Matrice ファミリ全体にわたって一般化してはなりません。

電源なしまたはバッテリー警告はどのように分類されるべきですか?

無電力イベントをチェーンとして扱います: バッテリーのペア、ラッチと端子、通信、充電器の履歴、航空機の入力パス、調整された電源ドメイン、および電力を要求するシステム。正確なモデルと安全条件が許可する場合にのみ、サポートされている健全な機器を比較してください。 LED とアプリの動作、温度、物理的損傷、および懸念が 1 つのパック、1 つのベイ、または機体に関係するかどうかを記録します。膨れ、液状痕、焦げ臭、変形、異常発熱の場合は中止してください。

企業のダウンタイムにより、チームはコア ボードに直接アクセスしたくなる可能性がありますが、コネクタ、ハーネス、充電器、パック関係、またはローカル電源ステージで同様の症状が発生する可能性があります。ベンチ診断では、どの境界がテストされ、何が不明のままであるかを明らかにする必要があります。通電ボードのサービス手順を決して公開してはなりません。顧客は、測定された証拠、部品の出所、未解決の電力リスクの運用コストに関連付けられた修理または交換の推奨事項を受け取ります。

推進、アーム、ESC の故障を区別するものは何ですか?

推進警告には、プロペラ、モーター、ベアリング、配線パス、コネクタ、ドライブ チャネル、電流フィードバック、コマンド パス、または構造的な調整が関係する場合があります。プロペラとモーターマウントからアーム、ヒンジ、またはフレームを通る完全な負荷経路を検査します。 ESC に警告を割り当てる前に、チャネルを比較し、影響の証拠を記録します。停止時には真っすぐに見える航空機でも、負荷が加わった後はアライメント、ハーネス、またはコネクタが損傷する可能性があります。

Matrice 航空機は、単一のモーター交換を超えてミッションとペイロードに影響を及ぼします。書面化された範囲には、作業が機械的、電気的、構造的、または複合的なものであるかどうか、また、影響を受けるアセンブリが必要なミッション標準に従って検証できるかどうかを記載する必要があります。日付の付いたボード リビジョンで確認された MOSFET またはドライバの発見は、修理経験として表示される場合がありますが、それはすべてのモーター警告に対する普遍的な救済策ではなく、そのボードとイベントの証拠です。

RTK、GNSS、コンパス、および IMU の懸念はどのように分離されますか?

位置決めエラーは、記録された環境で再現する必要があります。構造物、車両、電力機器、磁性材料、空の眺め、および修正サービスの状況は、航空機の欠陥を証明しなくても観測に影響を与える可能性があります。正確な警告をキャプチャし、GNSS 取得、RTK 状態、機首方位の一貫性、IMU 状態、ミッションへの影響を比較します。校正リクエストは、解釈するためのテスト結果であり、衝撃やハードウェアの損傷を隠す許可ではありません。

Matrice 300 RTK および Matrice 350 RTK ワークフローの場合、測位はアンテナ、モジュール、コネクタ、コア処理、コントローラー データ、ミッション セットアップを含む大きなチェーンの一部です。診断では、その連鎖のどの部分が観察されたかを示す必要があります。ローカルコンポーネントまたはボードドメインが確認された場合は、正確な構成とテスト境界を開示してください。リターンゲートは、ミッション所有者が航空機を受け入れる前に、適切に制御された環境で安定した位置決め動作を検証する必要があります。

航空機ではなくペイロードに問題があるのはどのような場合ですか?

ペイロードモデル、マウント、ロック状態、コネクタ状態、電源投入時の動作、画像、記録、安定化および制御機能を記録します。懸念がペイロード、航空機のポート、または特定の構成に従うかどうかを判断します。マウントを強制したり、不安定な接続を繰り返したりしないでください。曲がったインターフェース、汚れ、衝撃、湿気、および事前の修理は、機械的な取り付けとデータの動作の両方に影響を与える可能性があります。

Matrice ペイロード診断は、航空機とペイロードの証拠が明確なままである場合に最も強力になります。ペイロード側のカメラ、ジンバル、またはインターフェイスの障害は、航空機のコアボードの修理として販売されるべきではありません。また、航空機のポートの障害は、ペイロードの交換によって隠蔽されるべきではありません。見積書には、故障した境界、提案されたアセンブリまたはコンポーネントの作業、キャリブレーションの依存関係、およびデモンストレーションされる修復後のペイロード機能が記載されています。

視覚および障害物検知警告はどのようにテストされるべきですか?

どの方向とセンサー グループが警告、地表、照度、汚染、天候、航空機の姿勢を報告するかを文書化します。サポートされている損傷のない方法でのみ清掃し、窓、ブラケット、ハーネス、周囲の構造を検査してください。低質感、まぶしさ、または不適切な光の場合に表示される警告は、制御された条件下で持続する警告とは異なります。明らかな外部破損がなくても、衝撃によってアライメントが変化する可能性があります。

受け入れテストは、安全な地上観測、サポートされる校正状態、および一貫したセンサー報告から始まり、航空機が適切な場合にのみ続行する必要があります。 1 回のホバリングの成功がすべての方向センサーや自動ミッション機能を証明すると主張してはなりません。フリート使用の場合は、オペレーターが証拠の境界を理解できるように、テストされた環境、実行された機能、および再現されなかった条件を記載します。

コントローラーとトランスミッションの診断にはどのような証拠が含まれますか?

コントローラーと航空機のペアリング、アンテナ、ケーブルまたはネットワークのコンテキスト、ファームウェアの関係、および動作環境を特定します。個別のペアリングの失敗、断続的なテレメトリ、画像の損失、制御警告、および環境干渉。懸念が 1 つの管制官、1 つの場所、1 つのペイロードまたは航空機に従うかどうかを記録します。宣伝された範囲をベンチターゲットまたは実際のサイトの約束として扱わないでください。

リンク修復は、安定したペアリング、テレメトリ、制御応答、該当する場合は画像、および顧客に関連するミッション機能を含む段階的なチェックを通じて受け入れられる必要があります。検出結果がコネクタ、アンテナ パス、無線アセンブリ、または基板コンポーネントである場合、記録には正確なモデルと基板リビジョンが記載されている必要があります。干渉を排除できない場合、その未知の干渉は、サポートされていないハードウェアという結論に変換されるのではなく、表示されたままでなければなりません。

Matrice のサービス復帰決定が信頼できる理由は何ですか?

受け入れは、最初の懸念事項から始まり、アクセス、影響、交換によって影響を受ける隣接システムをチェックします。返却された航空機、ペイロード、コントローラー、バッテリー、付属品を摂取記録と照合します。安全かつ適切な場合にのみ、ハードウェアのリンク、警告、出力の動作、ジンバルまたはペイロードの機能、位置決め、推進の観察、および制御された飛行を確認してください。承認された範囲の一部である場合、ミッション固有の機能を含める必要があります。

引き継ぎでは、修理された故障と、あらゆるミッションに承認された航空機を区別する必要があります。 Reboot Hub には、書面による所見、部品の出所、テスト、残りの観察、および保証範囲が記載されています。その後、フリート管理者は、システムをサービスに戻すか、定義された役割に制限するか、予備として保持するか、交換するかを決定できます。この透明性の高い意思決定パスは、一般的な修理ラベルよりも価値があります。

Reboot Hub は承認前に顧客の懸念をどのように取り除くのですか?

Reboot Hub は、顧客の懸念事項、正確な航空機、および決定に影響を与える可能性のあるあらゆる合理的な質問から始まります。私たちは、報告された症状、イベント履歴、提供されたキット、目に見える状態を保存します。確認された結果を修復ベンチ仮説から分離する。既知の項目と未知の項目に名前を付けます。そして承認を求める前に書面による調査結果を返送してください。ボードのリビジョンと測定された修理証拠が特定のチップまたはコンポーネントを特定する場合、そのケースレベルの経験を直接述べることができます。それは、同様の警告を発したすべての航空機に同じ欠陥があるという主張に黙って拡張されるわけではありません。

修理作業にはお見積り承認後、通常1～3営業日かかります。このワークショップ期間は、到着輸送、部品の入手可能性、関連する場合の通関処理、および返送輸送とは別です。検査と所見の書面には診断料がかかります。対象となる修理が承認されると、その診断料金は、書面による見積書に基づく作業料金または対象となるサービス料金に充当されます。顧客が断った場合でも、何が見つかったのか、何が不明のままなのかが診断によって説明されます。

対象となる完了した修理作業には、書面による条件に基づいて 30 日間の修理保証が付いています。これは、対象となる完全な 中古 製品に対する 180 日間の製品保証とは別のものです。どちらの用語も、その後の無関係な影響、液体への曝露、消耗品の摩耗、誤用、または承認された範囲外の作業について約束するものではありません。修理記録には、修理期間が適用される正確な作業と受領証拠を特定する必要があります。

これは、一般的なマーケットプレイス命令と Reboot Hub パスの商業的な違いです。顧客は、約束の前に、正確な単位の証拠、懸念ごとの対応、提案された範囲、部品パス、テスト、および書面による条件を確認します。置き換えの方が強力な場合は、匿名の見出しリストではなく、文書化されたユニットとキットを比較に使用します。単に修理情報を共有することが目的ではありません。それは、技術的な不確実性を、顧客が信頼できる透明性のある決定に変えることです。

関連する Reboot Hub パス

症状から文書化された次のステップに進む

以下の学習、正確なモデル、およびサービス パスを使用して、一般的な理解から証拠、文書化された範囲およびアクションに移行します。