Логи, params и другие артефакты: почему они важнее общих советов

Что пользователь обычно присылает в чат

Когда у аппарата возникает проблема, в обсуждение чаще всего приносят не только текст вопроса, но и артефакты:

  • DataFlash BIN лог;
  • TLOG;
  • файл параметров;
  • скриншоты Mission Planner;
  • фото подключения или размещения оборудования;
  • PDF, прошивки, конфиги и другие сопутствующие файлы.

Это правильно, потому что по одному описанию симптомов почти никогда нельзя уверенно диагностировать причину.

Почему текстового вопроса обычно недостаточно

Фраза вроде «не армится» или «плохо держит позицию» слишком общая. Один и тот же симптом может означать совершенно разные вещи:

  • проблема с компасом;
  • проблема с GPS;
  • плохое питание;
  • завышенные вибрации;
  • неудачная механика установки контроллера;
  • ошибочная конфигурация параметров;
  • повреждение железа после удара.

Без логов и параметров пользователь получает советы наугад. Поэтому сильный инженерный ресурс должен с самого начала приучать: обсуждение без артефактов почти всегда слабее, чем обсуждение с логом.

Что дает BIN-лог

BIN лог полезен тем, что в нем сохраняется внутренняя картина состояния аппарата:

  • датчики;
  • события;
  • режимы;
  • ошибки;
  • вибрации;
  • напряжение и ток;
  • навигационные оценки;
  • поведение системы в момент сбоя.

Если говорить просто, BIN показывает не то, что человек думал о полете, а то, что реально видел автопилот.

Что дает файл параметров

Файл параметров нужен, когда проблема может быть связана не с разовым событием, а с конфигурацией:

  • failsafe thresholds;
  • типы датчиков;
  • логика режима;
  • ограничения;
  • настройки EKF;
  • телеметрия и порты;
  • специфичные аппаратные параметры.

Практическая ценность файла параметров особенно высока в двух случаях:

  1. Нужно понять, почему аппарат ведет себя «нелогично».
  2. Нужно сравнить удачную и неудачную конфигурации.

Почему важно уметь работать с артефактами

Если ограничиваться только текстовыми советами, полезность быстро упрется в потолок. Поэтому по этой теме особенно важны материалы:

  • как скачать BIN лог;
  • как сохранить параметры;
  • какие файлы прикладывать к вопросу;
  • какие симптомы требуют лога обязательно;
  • как не путать лог автопилота и телеметрийный лог;
  • какие части конфигурации чаще всего стоит сравнивать между полетами.

Что особенно важно для диагностики

В собранном community-архиве уже видно, что пользователи регулярно прикладывают:

  • BIN;
  • .param;
  • TLOG;
  • PDF и техдокументы;
  • архивы с прошивками и сопутствующими файлами.

Это означает, что такой материал может вырасти не только в справочник, но и в практический инструмент, который помогает:

  • формировать корректный диагностический кейс;
  • хранить артефакты рядом с вопросом;
  • учиться на типовых отказах и неудачных конфигурациях.

Минимальный инженерный стандарт для вопроса

Хороший технический вопрос по ArduPilot должен по возможности включать:

  • тип аппарата;
  • контроллер;
  • версию прошивки;
  • краткое описание симптома;
  • BIN или другой релевантный лог;
  • файл параметров;
  • указание, когда именно проблема проявилась: на земле, при arm, при взлете, в AUTO, в RTL, после удара и так далее.

Практический вывод

Чем сложнее аппарат, тем меньше смысла в чисто словесных советах. Поэтому сильная база знаний должна не только отвечать на вопросы, но и обучать правильному сбору материалов для анализа.

На этой основе удобно строить:

  • log-analysis service;
  • template для подачи вопроса;
  • понятный маршрут от симптома к нужным логам;
  • база типовых кейсов по реальным артефактам.

Первоисточники

  • Downloading and Analyzing Data Logs in Mission Planner: https://ardupilot.org/dev/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html
  • Measuring Vibration with Mission Planner: https://ardupilot.org/planner/docs/common-measuring-vibration.html