トリガーと応答記録で空撮の欠落フレームを確認する
撮影指示、露光応答、保存ファイルと空間的な撮影範囲を分けて照合し、欠落画像を根拠に沿って調べます。
四つの異なる事象を区別する
計画された撮影、トリガー コマンド、露光の表示、および使用可能な保存画像は別のイベントです。ある段階でのカウントは、次の段階での完了を証明するものではありません。 ArduPilot のドキュメントでは、適切な接続が実装されている場合、トリガー レコードとカメラ フィードバックが区別されます。インストールされたシステムが実際に何を記録するかを確認します。この区別により、すべてのミッションコマンドがカード上に対応する写真を作成したに違いないと仮定するのではなく、意味のある証拠による監査が作成されます。
原本の記録を保管する
関連するフライト ログとカメラ ファイルを、元のファイルの名前を変更したり上書きしたりせずにコピーします。航空機、カメラ、カード、ミッション、時計情報を記録します。後の調整のためにタイムゾーンとタイミングの仮定を保存します。ファイル名のギャップだけでも、測量撮影を逃したというよりも、以前にカメラを使用したことを反映している可能性があります。監査では、一時停止、個別のフライト、実際のマッピング ブロックが開始される前に撮影されたテスト画像など、シーケンスを再構築するのに十分なコンテキストを保持する必要があります。
事象ごとの比較表を作る
予想されるイベントごとに、使用可能なコマンド時間、フィードバック時間、ソース ファイル ID、およびレビュー ステータスを含む 1 行を作成します。利用できない証拠を思い込みで埋めるのではなく、明確なままにしておきます。クロックがどのように関係し、不確実な対応付けがどのように処理されたかを説明します。データセット全体に自動一致を適用する前に、小さなサンプルを手動で確認します。きちんと整列されたテーブルは、そのマッチング ルールが実際のシステムの動作と既知のタイミング制限を考慮している場合にのみ役立ちます。
欠落の発生パターンを調べる
孤立した欠落ファイル、連続して欠落した撮影区間、または特定の変更後に始まった問題を探します。パターンをカメラの書き込み動作、電源状態の観察、構成、およびオペレーターのメモと比較します。 2 つのイベントが互いに近くで発生したという理由だけで原因を割り当てないでください。テストされるまで代替説明を保存しておきます。その目的は、単にもっともらしい話ではなく、どのような証拠が存在し、画像記録工程のどの部分がさらなる技術的調査を必要とするかについて、根拠を説明できる記録を行うことです。
空間的な影響を別に評価する
同じ数の画像が欠けていても、それが発生した場所と残りの範囲に応じて、非常に異なる影響が生じる可能性があります。受け入れられた画像位置をプロットし、影響を受ける領域の周囲の接続性を検査します。そこで再構築または検査の要件をテストします。割合だけでブロックを使用不可と宣言したり、処理が終了したという理由だけでブロックを受け入れたりしないでください。実際の証拠のギャップをマークし、現場への立入りがまだ可能な間に再撮影が必要かどうかを判断します。
具体的な後続作業で確認を終える
受け入れられたファイル、未解決の一致、撮影範囲の結果、および選択された技術的フォローアップを記録します。変更した構成と再試験の根拠を、最初の発見とともに保存します。すべてのインストールに 1 つのログ記録方法が存在すると主張することなく、NiVO サポート相談中に代表的な記録を共有します。監査が完了すると、別のレビュー担当者がコマンドから実際に使用可能な画像へのフィードバックを通じてフレーム欠落の決定を追跡できるようになり、システム診断をプロジェクトの成果物に関する実際の決定から切り離すことができます。
