INTERCEPT

INTERCEPT — первый вариант программного обеспечения компьютерного моделирования квадрокоптера в среде MATLAB.

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

Текущий уровень зрелости

Текущий уровень: оценка адекватности компьютерной модели по данным бортовой системы регистрации.

Данная проверка выполнена по данным бортового журнала и не является полной независимой валидацией реального изделия по внешним средствам измерений.

PR №2 расширяет препроцессор: добавляет анализ состава реальных бортовых журналов ArduPilot DataFlash .BIN и подготовку адаптера чтения. Полноценная идентификация по .BIN будет следующим этапом после подтверждения состава каналов.

Среда разработки и расчета

Основная среда разработки и расчета — MATLAB. Расчетное ядро отделено от препроцессора и постпроцессора, чтобы подготовить последующий перенос в Simulink.

Запуск проверок

В MATLAB выполните:

run('matlab/startup.m')
run('matlab/run_all_tests.m')

Анализ .BIN журналов

Для анализа состава сообщений DataFlash выполните:

run('scripts/analyze_bin_logs.m')

Файл scripts/07_analyze_bin_logs.m сохранен как номерной сценарий проекта. Для командного запуска в MATLAB используется технический wrapper scripts/analyze_bin_logs.m, так как имя файла сценария, начинающееся с цифры, не является допустимым именем исполняемого сценария MATLAB.

Выделение участков ВБ и идентификация ModelRate

Для PR №3 добавлен сценарий подготовки обработанных наборов данных, выделения участков-кандидатов ВБ и первой идентификации ModelRate:

run('scripts/extract_segments_and_fit_rate_model.m')

Номерной файл этапа сохранен как scripts/08_extract_segments_and_fit_rate_model.m. Команда ниже приведена как идентификатор этапа в структуре проекта, но для фактического командного запуска MATLAB используется wrapper с техническим именем:

run('scripts/08_extract_segments_and_fit_rate_model.m')

Сценарий формирует локальные расчетные выходы в result/rate_identification/ и несекретные сводные отчеты в docs/review/.

Инженерная фильтрация участков и повторная идентификация

Для PR №4 добавлен сценарий инженерной фильтрации участков ВБ, диагностики причин провала первой идентификации и сравнения непрерывной и дискретной постановок ModelRate:

run('scripts/curate_segments_and_refit_rate_model.m')

Номерной файл этапа сохранен как scripts/09_curate_segments_and_refit_rate_model.m. Команда ниже является идентификатором этапа в структуре проекта, но для фактического запуска в MATLAB используется wrapper с техническим именем:

run('scripts/09_curate_segments_and_refit_rate_model.m')

Сценарий формирует локальные расчетные выходы в result/rate_identification_curated/ и несекретные отчеты PR №4 в docs/review/.

В PR №4 невыполнение предварительных критериев ModelRate не скрывается. Отчеты фиксируют причины: перекрывающиеся окна, малая информативность части участков, насыщение RCOU, ограничения FIT при малой изменчивости эталонного сигнала и ограниченность модели первого уровня.

Визуальный демонстратор

Для PR №5 добавлен визуальный демонстратор бортовых журналов и демонстрационного полета Model6DOF:

run('scripts/visual_demo_and_model6dof_flight.m')

Номерной файл этапа сохранен как scripts/10_visual_demo_and_model6dof_flight.m. Команда ниже является идентификатором этапа в структуре проекта, но для фактического запуска MATLAB используется wrapper с техническим именем:

run('scripts/10_visual_demo_and_model6dof_flight.m')

После запуска локальные результаты находятся здесь:

result/visual_demo/

Replay по журналу показывает зарегистрированные или оцененные бортовой системой состояния. Model6DOF demo показывает работу расчетной модели, примитивного регулятора и постпроцессора. Это пока не полная независимая валидация.

Replay Model6DOF по журналу

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

run('scripts/model6dof_log_replay_and_fit.m')

Номерной файл этапа сохранен как scripts/11_model6dof_log_replay_and_fit.m. В MATLAB фактический запуск выполняется через wrapper с техническим именем, потому что исполняемые имена сценариев не должны начинаться с цифры.

Сценарий выбирает короткие replay-окна, строит начальные условия по журналу, использует RCOU.C1...RCOU.C4 как входы двигателей, выполняет расчет компьютерной модели и формирует overlay-графики журнал / расчет.

Локальные результаты сохраняются в result/model6dof_log_replay/ и не добавляются в Git. Этот режим является этапом первичной настройки и оценки пригодности Model6DOF к последующей валидации по ВБ, а не полной независимой валидацией.

Сценарий ищет локальные журналы:

• data/raw/ardupilot/bin/VB-01.alt_50m.BIN;
• data/raw/ardupilot/bin/full_fly_1.BIN;
• data/raw/ardupilot/bin/full_fly_2.BIN.

Если файлы отсутствуют, сценарий формирует понятный отчет result/bin_analysis/missing_logs_report.md и указывает, куда нужно положить журналы. Содержимое result может быть локальным расчетным результатом и по умолчанию не предназначено для обычного Git.

Данные бортовых журналов

Рабочими форматами остаются CSV, MAT, table MATLAB и timetable MATLAB. Для .BIN на PR №2 реализованы анализ структуры, чтение сообщений FMT и декодирование ключевых сообщений, необходимых для последующей подготовки данных.

Сырые журналы ArduPilot DataFlash нужно размещать локально в:

data/raw/ardupilot/bin/

Сырые журналы могут содержать координаты, время полета, параметры изделия и другую чувствительную информацию. Их не следует добавлять в обычный Git. Если принято решение хранить журналы в репозитории, используйте Git LFS или закрытый репозиторий.

Валидационный базис

Документ валидационного базиса нужно разместить локально:

docs/validation_basis/ValidationBasis_v0.pdf

Формализованный реестр случаев хранится в config/validation_basis_v0.json. Реестр локальных журналов и связи с предполагаемыми случаями ВБ хранится в config/log_manifest_v0.json.

Конфигурация изделия

Конфигурация изделия хранится в config/vehicle_qc_ardupilot_v0.json.

В конфигурации явно отражены предупреждения:

• оси CAD не считаются автоматически совпадающими со связанной системой координат изделия;
• по умолчанию используется диагональная матрица инерции;
• произведения инерции CAD сохраняются, но по умолчанию не применяются;
• в исходном описании указаны винты Gemfan 8060, а в CAD-выгрузке присутствуют винты APC 7x11E.

Ограничения первого этапа

• PR №5 не является этапом полной независимой валидации реального изделия.
• Проверка выполняется по данным бортового журнала, а не по внешним средствам измерений.
• Визуальный replay не заменяет формальную матрицу валидации.
• Демонстрационный полет Model6DOF проверяет работоспособность решателя и постпроцессора.
• Инженерная фильтрация участков не превращает автоматическую разметку в окончательный валидационный базис.
• ModelRate остается моделью первого уровня и не заменяет полную модель движения изделия.
• Model6DOF и параметры винтомоторной группы будут уточняться на следующих этапах.
• Расчетное ядро предназначено для подготовки к переносу в Simulink, но модель Simulink в этом PR не создается.

Калибровка мотор-маппинга и системы координат

PR №7 добавляет диагностический этап для проверки базовой физической конфигурации Model6DOF:

• порядок каналов RCOU.C1...RCOU.C4 относительно физических моторов;
• знаки вращения моторов и знак момента рыскания;
• матрица распределения QUAD/X;
• преобразование CAD -> body;
• нормирование RCOU по параметрам ArduPilot PARM;
• согласованность FRAME_CLASS, FRAME_TYPE, MOT_* и SERVO* с конфигурацией изделия.

Команда запуска:

run('scripts/calibrate_motor_map_and_frame.m')

Номерной файл этапа сохранен как scripts/12_calibrate_motor_map_and_frame.m. Фактический запуск выполняется через wrapper с техническим именем.

Локальные результаты сохраняются в result/motor_map_frame_calibration/ и не добавляются в Git. PR №7 не выполняет перенос в Simulink: это преждевременно до фиксации мотор-маппинга, знаков вращения и преобразования систем координат.

Выбранный мотор-маппинг и преобразование CAD -> body являются расчетной гипотезой, сформированной по бортовым журналам. Для окончательного подтверждения требуется физическая проверка подключения моторов, направления вращения и системы координат изделия.