Стенд для моделирования пяти БАС: ArduPilot SITL управляет полётом в Gazebo, ns-3 моделирует радиосеть, Sionna RT рассчитывает распространение сигнала. Один наземный пункт управления обменивается с пятью аппаратами реальными MAVLink-байтами через десять UART-каналов, TAP и штатный Wi-Fi PHY/MAC ns-3.48.
Быстрый старт · Тесты · Запуск стенда · Результаты · Документация
main — единственная постоянная рабочая ветка. Воспроизводимая версия
для тестов закреплена тегом test-baseline-2026-10-21. В неё входят исправления
свежести ACK, барьера приёма GCS и генерации диагностического отчёта.
Тег фиксирует исходники и зависимости. Полный запуск Gazebo/SITL/ns-3/Sionna нужно проверять на целевой машине: успешные компонентные тесты не подтверждают готовность GPU-стенда, физического контроллера или работу в реальном времени. Фактические результаты и ограничения записаны в network/STATUS.md.
Завершённые ветки и избыточные теги удалены после проверки истории. Помимо эталона
оставлены два архивных тега с историей, которой нет в main:
archive/2026-10-21/agent/publish-network-radio-milestones— старый процесс разработки.archive/2026-10-21/feature/bas-v2-rc1-stabilization— работы RC1, включая демозапись и передачу стенда.
Архивы предназначены для восстановления. Для текущих тестов используйте эталон
выше. Коммиты удалённых milestone-тегов остаются в истории main.
| Компонент | Ответственность |
|---|---|
| Gazebo + ArduPilot SITL | Физика, датчики, управление и автономная миссия каждого БАС |
| ns-3.48 | Штатные 802.11n SpectrumWifiPhy/MAC, очереди, конкуренция за эфир, доставка и потери |
| Sionna RT | Распространение, отражения и состояние радиоканала внутри процесса ns-3 |
| MAVLink и UART-адаптеры | Два канала на аппарат: control и payload; передача исходных байтов |
| Дополнительный трафик | P2P, multicast P2MP и одновременная передача через ту же радиосеть |
| Источники помех | Штатные ns-3 WaveformGenerator с заданными мощностью, частотой и расписанием |
Сценарий / MAVProxy ↔ GCS TAP ↔ ns-3 Wi-Fi + Sionna RT ↔ UAV TAP ↔ UART ↔ ArduPilot
↕
Gazebo
Профиль Wi-Fi является некалиброванной инженерной моделью. Payload UART несёт MAVLink-трафик. Прямой обход радиосети и незаявленная замена Sionna запрещены; подробности — в архитектуре.
| Задача | Окружение |
|---|---|
| Редактирование и компонентные Python-тесты | Windows или Linux; Git и Python 3.10; зависимости из lock-файла |
| Linux-проверки UART и барьеров | Linux с PTY и flock |
| Полный стенд | Ubuntu 22.04, Docker Engine с NVIDIA Container Toolkit, совместимые NVIDIA GPU/драйвер и рабочий CUDA/OptiX |
| Town01 и customer-сцена | Оригинальные внешние CAVISE assets; встроенный rock_demo их не требует |
В Windows setup-скрипт использует uv.
Полный runtime работает в Linux. WSL2 требует отдельной проверки OptiX:
успешный nvidia-smi подтверждает доступ к GPU, но не работу трассировки лучей.
Пошаговая подготовка хоста: LOCAL_DEVELOPMENT.md.
Получите фиксированную версию для тестов:
git clone https://github.com/AFETZ/bas_v2.git
cd bas_v2
git switch --detach test-baseline-2026-10-21Для работы с текущим кодом используйте git switch main. Не переносите готовые
виртуальные окружения между Windows и Linux — создайте их на целевой системе.
При установленных Python 3.10 и модуле venv:
bash scripts/setup_dev.sh
source .external/dev-venv/bin/activateВ PowerShell из корня репозитория:
powershell -ExecutionPolicy Bypass -File .\scripts\setup_dev.ps1
.\.venv\Scripts\python.exe -m pytest -q network/tests/test_gcs_lockstep.py network/tests/test_native_latency_report.pyОба setup-скрипта используют .devcontainer/requirements-dev.lock. Окружение разработки не устанавливает Gazebo, SITL или ns-3.
Базовый набор для транспортного пути, модельного времени и отчётов запускается без симуляторов. В Linux после активации окружения:
python -m pytest -q \
network/tests/test_gcs_lockstep.py \
network/tests/test_simulation_clock.py \
network/tests/test_serial_transport.py \
network/tests/test_data_transport.py \
network/tests/test_native_latency_report.py \
network/tests/test_native_wifi_five_uav_product.pyВ Windows можно передать те же файлы .\.venv\Scripts\python.exe -m pytest.
Тесты, которым нужны Linux PTY/flock, будут пропущены; этот результат нужно
учитывать отдельно от успешных проверок.
Для собственных изменений выбирайте ближайшие тесты по TEST_MATRIX.md. Проверки синтаксиса, ссылок и diff:
make test-changed
bash network/tests/check_five_uav_micro_ros_ports.shmake test-changed проверяет изменения относительно HEAD и не заменяет pytest.
Для уже созданного коммита задайте базу: BASE_REF=HEAD~1 make test-changed.
Команды этого раздела выполняются на подготовленном Linux-хосте с Docker.
Начните со встроенной сцены rock_demo, чтобы не зависеть от внешних карт.
make demo-preflight DEMO_SCENARIO=rock_demo DEMO_GUI=0 DEMO_BOOTSTRAP=1
BAS_NATIVE_FIVE_RUN_ID=baseline-rock make demo-rugged DEMO_GUI=0Bootstrap создаёт отсутствующие зависимости и собирает окружение по закреплённым версиям; первая подготовка может занять значительное время. Preflight проверяет в том числе CUDA/OptiX. При ошибке сначала устраните её причину.
По умолчанию используется SIMULATION_MODE=realtime: контролируются сроки
выполнения и возраст состояния. Для пошагового обмена модельным временем:
BAS_NATIVE_FIVE_RUN_ID=baseline-lockstep make demo-rugged \
DEMO_GUI=0 SIMULATION_MODE=lockstep LOCKSTEP_STEP_MS=20В lockstep RTT и таймауты относятся к модельному времени. Такой запуск не
подтверждает работу в реальном времени; внешние физические контроллеры в нём
не поддерживаются. При смене режима начинайте новый запуск.
После подготовки оригинальных CAVISE assets по инструкции окружения:
export CAVISE_MAPS_DIR=/absolute/path/to/bundles
make demo-preflight DEMO_SCENARIO=town01 DEMO_GUI=0 DEMO_BOOTSTRAP=1
BAS_NATIVE_FIVE_RUN_ID=baseline-town01 make demo-town01 DEMO_GUI=0Диагностика задержек без полётного сценария:
BAS_NATIVE_FIVE_RUN_ID=latency BAS_NATIVE_LATENCY_MODE=1 make demo-town01 DEMO_GUI=0Для ручного управления запустите make operator DEMO_SCENARIO=rock_demo DEMO_GUI=0,
затем во втором терминале — make gcs. Остановка из другого терминала: make stop.
Customer-сцена, источники помех, карты и режимы исследования описаны в
руководстве оператора.
Каждому запуску задавайте отдельный BAS_NATIVE_FIVE_RUN_ID. Каталог результатов:
runs/native-radio-realtime/<RUN_ID>/
runs/native-radio-lockstep/<RUN_ID>/
Внутри находятся report.md, метрики в metrics/, журналы в logs/, PCAP,
графики и кадры Gazebo. Точный набор зависит от режима запуска.
Проверяйте код завершения, итоговый отчёт и ограничения измерений: завершённый
полёт сам по себе не означает соблюдения порогов задержки.
Полные трассы, сцены, образы Docker и зависимости хранятся вне Git. Старые RC1 измерения относятся к прежнему стенду; их нельзя переносить на новую машину без повторного запуска. Аппаратная проверка внешнего контроллера остаётся отдельным этапом.
| Документ | Содержание |
|---|---|
| Текущий статус | Выполненные проверки, известные дефекты и ограничения |
| Настройка рабочего места | Windows, WSL, Linux, окружения и перенос |
| Руководство оператора | Сценарии, НПУ, карты, источники и результаты |
| Архитектура | Владение состоянием, радиопуть и ограничения моделей |
| Окружение и ресурсы сцен | Зависимости, assets и пути |
| Требования | Назначение и функциональные требования стенда |
| Матрица проверок | Минимальные проверки для изменяемого компонента |
| Область поставки RC1 | Историческая поставка и границы её верификации |
Создавайте короткую ветку от main под конкретную задачу, добавляйте проверку
исправляемого поведения и отправляйте PR. После слияния рабочая ветка удаляется.
Теги test-baseline-* сохраняйте неизменными; для нового эталона создавайте новый
тег и записывайте реально выполненные проверки в network/STATUS.md.
Сообщения об ошибках: GitHub Issues — укажите
коммит/тег, платформу, команду запуска и относящийся к ошибке фрагмент журнала.
Исходный код распространяется под GNU GPL v3. Внешние сцены и зависимости имеют собственные лицензии и не включаются в поставку автоматически.