Дипломный проект … ↩

1. Цели урока

Продолжительность урока — пять часов: полчаса теории и четыре с половиной часа практики. Это время на план, основную часть работы и защиту; большой проект потребует дополнительной самостоятельной работы. После урока слушатель:

• выполняет законченный проект в полётной прошивке: от постановки задачи до измерения результата;
• подтверждает результат тестами, которые запускаются автоматически при каждом изменении;
• пишет отчёт и защищает решения перед преподавателем.

2. Термины и сокращения

3. Автоматическая проверка

Весь курс тесты запускались командами make test, make navtest и другими. Для защиты они собраны в одну цель make ci:

ci: test arch-check mavtest navtest luatest dumptest
	$(MAKE) -f target.mk
	@echo "ci: все проверки пройдены"

Цель выполняет модульные тесты всех уровней, проверку архитектуры, проверку MAVLink, полёт по заданию через MAVLink, тесты сценария Lua, проверку дампов и сборку прошивки для STM32F405. На компьютере курса вся цепочка занимает около двадцати секунд.

В репозитории та же цель запускается рабочим процессом GitHub Actions при каждой отправке изменений:

Файл .github/workflows/ci.yml

ci:
  runs-on: ubuntu-24.04
  steps:
    - uses: actions/checkout@v4
    - name: Компилятор для STM32
      run: sudo apt-get update && sudo apt-get install -y gcc-arm-none-eabi libnewlib-arm-none-eabi
    - name: Библиотеки Python
      run: pip install pymavlink pyubx2 numpy geographiclib pymap3d lupa
    - name: Тесты, проверки и сборка прошивки
      run: make ci TC=arm-none-eabi-
    - name: Размер прошивки
      run: arm-none-eabi-size build/target/beefc.elf

Вторая часть сравнивает BeeFC с ArduPilot в программной имитации и проверяет сценарий Lua. Она дольше и зависит от внешней программы, поэтому выполняется только после успешной основной части, а результаты сохраняются артефактом:

Файл .github/workflows/ci.yml

sitl:
  runs-on: ubuntu-24.04
  needs: ci
  steps:
    - uses: actions/checkout@v4
    - name: Библиотеки Python
      run: pip install pymavlink numpy pymap3d
    - name: ArduCopter 4.7.2 для Linux
      run: |
        mkdir -p ~/.cache/ap && cd ~/.cache/ap
        curl -fsSL -o arducopter https://firmware.ardupilot.org/Copter/stable-4.7.2/SITL_x86_64_linux_gnu/arducopter
        curl -fsSL -o copter.parm https://raw.githubusercontent.com/ArduPilot/ardupilot/Copter-4.7.2/Tools/autotest/default_params/copter.parm
        chmod +x arducopter
    - name: BeeFC и ArduPilot на одном задании, сценарий Lua
      run: make ci-sitl
    - uses: actions/upload-artifact@v4
      with:
        name: nav-results
        path: build/nav_*.json

4. Темы проектов

Каждая тема задаёт минимальный результат, обязательный автоматический тест и измерение для отчёта. Свою тему можно предложить преподавателю, если она проверяется тестами так же.

1. Двунаправленный DShot и фильтр по частоте вращения. Регулятор двигателя возвращает частоту вращения по тому же проводу. BeeFC принимает ответ, проверяет контрольную сумму и настраивает режекторный фильтр гироскопа на частоту вращения. Тест: разбор ответов регулятора по эталонным кадрам. Измерение: спектр гироскопа на тяговом стенде с фильтром и без него.

2. Перенос на AT32F435. BeeFC собирается для микроконтроллера Artery AT32F435 через слой абстракции аппаратной части; модули core не меняются. Тест: все тесты курса и проверка архитектуры проходят, обе прошивки собираются. Измерение: время цикла и размер прошивки на двух микроконтроллерах.

3. Автоматическая настройка регулятора релейным методом. Регулятор временно заменяется реле, по амплитуде и периоду автоколебаний вычисляются коэффициенты. Тест: программная имитация качелей, коэффициенты в пределах заданного отклонения от расчётных. Измерение: переходный процесс на стенде «Качели» до и после настройки.

4. Геозона. BeeFC принимает границу геозоны по протоколу MAVLink и включает возврат при её пересечении. Тест: программная имитация с ветром, сносящим аппарат к границе, и проверка загрузки границы кадрами pymavlink. Измерение: наибольший выход за границу при разном ветре.

5. Сценарий Lua с отчётом по журналу. Сценарий для ArduPilot с собственными параметрами и реакцией на отказы, например облёт по спирали или поиск по галсам. Тест: макет окружения и программная имитация ArduPilot, разбор журнала полёта. Измерение: отклонение от заданной траектории по журналу.

6. Драйвер нового датчика. Датчик оптического потока или лазерный дальномер: драйвер, модель датчика для тестов и использование в регуляторе. Тест: драйвер на модели датчика, включая ошибки связи. Измерение: показания на столе и сравнение с линейкой или известным расстоянием.

5. Отчёт и защита

Отчёт занимает 4–8 страниц и содержит:

1. Постановку задачи и критерии успеха в числах.
2. Устройство решения: модули, данные, ограничения.
3. Тесты: что проверяет каждый тест и как проверено, что тест ловит ошибку.
4. Измерения: условия, таблицы, графики, разброс.
5. Сравнение с решением в одной из больших прошивок со ссылками на исходный код.
6. Что не сделано и почему.

Защита длится пятнадцать минут: пять минут доклада с показом журнала полёта, видео со стенда или записи программной имитации и десять минут вопросов. Перед защитой преподаватель проверяет, что автоматическая проверка зелёная.

6. Тесты

Обязательная проверка — make ci в репозитории проекта, зелёная на последнем изменении. Тесты проекта добавляются в цель test или отдельной целью, которая включается в ci. Для четвёртой и пятой тем к проверке добавляется цель с программной имитацией, как make ci-sitl.

7. Практика

8. Как это сделано в больших прошивках

• В Betaflight рабочий процесс ci.yml собирает прошивки для всех описаний плат и выполняет команды make checks и make test-all с флагом -Werror: предупреждение компилятора считается ошибкой, как в BeeFC.
• В INAV рабочий процесс ci.yml собирает прошивки для всех плат группами и программную имитацию с флагом «предупреждения как ошибки», а если изменение касается одной платы — только её. Отдельный процесс pr-test-builds.yml выкладывает пробные прошивки для каждого предложенного изменения.
• В ArduPilot процесс test_sitl_copter.yml выполняет полётные тесты из arducopter.py урока A7 в программной имитации. Тесты разбиты на группы от tests1a до tests2b и выполняются параллельно, иначе проверка занимала бы часы.
• В PX4 процесс mavros_mission_tests.yml выполняет полётное задание MC_mission_box в программной имитации и проверяет его. Отдельный процесс flash_analysis.yml следит за размером прошивки на платах fmu-v5x и fmu-v6x.

Все четыре прошивки принимают изменения только после зелёной автоматической проверки. Курс BeeFC построен по тому же правилу с первого урока.

9. Проверьте себя

1. Почему часть проверок с ArduPilot вынесена в отдельный этап?
2. Как убедиться, что тест проекта действительно проверяет поведение?
3. Зачем в отчёте раздел о том, что не сделано?
4. Почему ArduPilot разбивает полётные тесты на группы?

10. Чек-лист самопроверки

• Тема выбрана, план и критерии согласованы
• Тесты проекта входят в make ci, каждый проверен мутацией
• make ci зелёный в репозитории на последнем изменении
• Измерения выполнены, разброс указан
• Отчёт написан, доклад подготовлен

11. Источники

1. Рабочий процесс CI Betaflight.
2. Рабочий процесс CI INAV.
3. Полётные тесты ArduCopter в CI.
4. Тест полётного задания PX4 в CI.
5. Контроль размера прошивки PX4.
6. Документация GitHub Actions.

12. Что дальше

• Ответы на вопросы уровня собраны в статье «Курс BeeFC: ответы на контрольные вопросы уровня „Автопилот“».
• Полный перечень уроков приведён в статье «Курс BeeFC: содержание уровня „Автопилот“».

Проверено: 13.10.2026