364 lines
18 KiB
Markdown
364 lines
18 KiB
Markdown
# Инженерный журнал SDR Rover Link
|
||
|
||
## Назначение журнала
|
||
|
||
Этот файл содержит хронологию разработки проекта SDR Rover Link.
|
||
|
||
В журнале фиксируются:
|
||
|
||
- выполненные работы;
|
||
- полученные результаты;
|
||
- обнаруженные ошибки;
|
||
- принятые технические решения;
|
||
- результаты экспериментов;
|
||
- планы следующего этапа.
|
||
|
||
Записи не следует удалять. Если решение изменилось, необходимо добавить новую запись и объяснить причину изменения.
|
||
|
||
---
|
||
|
||
# Запись 001
|
||
|
||
## Дата
|
||
|
||
10 июля 2026 года
|
||
|
||
## Тема
|
||
|
||
Создание структуры проекта и локального Git-репозитория.
|
||
|
||
## Выполнено
|
||
|
||
1. Проверена установленная версия Git:
|
||
|
||
```text
|
||
git version 2.51.1.windows.1
|
||
```
|
||
|
||
---
|
||
|
||
# Запись 002
|
||
|
||
## Дата
|
||
|
||
27 июля 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab028: пакетирование синхронного BASE + ROI.
|
||
|
||
## Выполнено
|
||
|
||
- Реализован фиксированный бинарный заголовок размером 32 байта.
|
||
- Добавлены packet CRC32 для заголовка и payload и object CRC32 для полного JPEG.
|
||
- Исследованы размеры payload 64, 128, 256, 512 и 1024 байта.
|
||
- Размер payload 512 байт принят как рабочий кандидат.
|
||
- Окончательный выбор размера пакета перенесён в Lab029.
|
||
|
||
---
|
||
|
||
# Запись 003
|
||
|
||
## Дата
|
||
|
||
27 июля 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab029: моделирование потерь и ошибок видеопакетов.
|
||
|
||
## Выполнено
|
||
|
||
- Исследованы независимые потери пакетов и независимые битовые ошибки.
|
||
- Проверены короткие, средние и длинные серии потерь по модели Gilbert–Elliott.
|
||
- Выполнено сравнение payload 256, 512 и 1024 байта.
|
||
- Подтверждены packet CRC32, изоляция соседних кадров и атомарная сборка BASE + ROI.
|
||
- Зафиксировано ограничение пакетной временной шкалы Lab029.
|
||
- Сравнение помех одинаковой физической длительности перенесено в Lab029B.
|
||
|
||
---
|
||
|
||
# Запись 004
|
||
|
||
## Дата
|
||
|
||
27 июля 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab029B: временная модель серийных потерь.
|
||
|
||
## Выполнено
|
||
|
||
- Помехи смоделированы на непрерывной временной шкале.
|
||
- Контрольная скорость передачи установлена равной 300 кбит/с.
|
||
- Исследованы средние длительности Bad 10, 50, 200 и 1000 мс.
|
||
- Payload 512 байт выбран для дальнейшей разработки.
|
||
- Payload 1024 байта оставлен резервным вариантом.
|
||
- Подтверждено, что без исправления ошибок возможны длительные прерывания видеопотока.
|
||
|
||
---
|
||
|
||
# Запись 005
|
||
|
||
## Дата
|
||
|
||
29 июля 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab030: блочное исправление стираний.
|
||
|
||
## Выполнено
|
||
|
||
- Реализовано блочное исправление стираний над GF(256).
|
||
- Проверены режимы без исправления, 8+1, 8+2 и 8+4.
|
||
- Режим 8+2 выбран основным рабочим режимом.
|
||
- Режим 8+4 оставлен контрольным.
|
||
- Подтверждено, что без перемежения продолжительные серии потерь не исправляются.
|
||
- Следующая лабораторная посвящена перемежению пакетов.
|
||
|
||
---
|
||
|
||
# Запись 006
|
||
|
||
## Дата
|
||
|
||
29 июля 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab031: перемежение блоков исправления ошибок.
|
||
|
||
## Выполнено
|
||
|
||
- Исследовано перемежение блоков исправления ошибок.
|
||
- Проверены глубины D=1, 2, 4 и 8.
|
||
- Подтверждено, что глубокое перемежение повышает задержку сильнее, чем полезность для операторского видеопотока.
|
||
- D=1 оставлен основным режимом.
|
||
- D=2 сохранён как резервный вариант.
|
||
- D=4 и D=8 исключены из основной линии разработки.
|
||
- Следующая лабораторная подбирает размер блока и количество проверочных пакетов.
|
||
|
||
---
|
||
|
||
# Запись 007
|
||
|
||
## Дата
|
||
|
||
29 июля 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab032: параметры блочного исправления потерянных пакетов.
|
||
|
||
## Выполнено
|
||
|
||
- Исследованы параметры блочного исправления потерянных пакетов.
|
||
- Сравнивались режимы без исправления, 4+1, 8+2, 12+3, 6+2, 8+3, 4+2 и 8+4.
|
||
- Режим 12+3 выбран основным.
|
||
- Его транспортный поток составляет 226,951 кбит/с.
|
||
- Запас до контрольных 300 кбит/с составляет 73,049 кбит/с.
|
||
- Режим 8+4 оставлен усиленным экспериментальным вариантом.
|
||
- Режим 8+3 не принят из-за отсутствия устойчивого преимущества.
|
||
- Подтверждено, что продолжительные помехи нельзя компенсировать только увеличением числа проверочных пакетов.
|
||
- Следующий этап посвящён совместной передаче команд, телеметрии и видео с приоритетным обслуживанием.
|
||
|
||
---
|
||
|
||
# Запись 008
|
||
|
||
## Дата
|
||
|
||
3 августа 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab033: общий пакет канала и приоритетное обслуживание.
|
||
|
||
## Выполнено
|
||
|
||
- Добавлен общий 32-байтный заголовок канала для команд, телеметрии и видео.
|
||
- Общая предложенная нагрузка составляет 258,214 кбит/с.
|
||
- Подтверждено, что FIFO не обеспечивает требуемую задержку команд.
|
||
- Выбран строгий приоритет с заменой устаревших состояний.
|
||
- Аварийная команда имеет наивысший приоритет.
|
||
- Скорость 260 кбит/с практически полностью загружена.
|
||
- При 230 кбит/с видеоданные накапливаются и устаревают.
|
||
- Итоговое восстановление всех кадров после освобождения очереди не означает работу видео в реальном времени.
|
||
- Расчёты и графики выполнены с Matplotlib 3.11.1.
|
||
- Следующий этап посвящён отбрасыванию устаревших видеокадров.
|
||
|
||
---
|
||
|
||
# Запись 009
|
||
|
||
## Дата
|
||
|
||
3 августа 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab034: реактивное отбрасывание устаревших видеокадров.
|
||
|
||
## Выполнено
|
||
|
||
- Сравнены непрерывные FEC-блоки и блоки, выровненные по составным кадрам.
|
||
- Выравнивание увеличивает видеопоток на 5,975 кбит/с, или на 2,633%.
|
||
- При 300 кбит/с удаление кадров не требуется.
|
||
- При 260 кбит/с ограничения 1000 и 1500 мс не срабатывают, а ограничение 500 мс уже чрезмерно.
|
||
- При 230 кбит/с реактивное удаление устаревших кадров уменьшает очередь, но резко снижает частоту обновления.
|
||
- Ограничение 500 мс оставляет только 3 из 63 кадров.
|
||
- Ограничение 1500 мс оставляет 27 из 63 кадров.
|
||
- Подтверждено, что короткая очередь сама по себе не означает свежее изображение.
|
||
- Текущая реактивная политика не принята.
|
||
- Следующий этап посвящён упреждающему допуску кадров и обслуживанию видео целыми кадрами.
|
||
|
||
---
|
||
|
||
# Запись 010
|
||
|
||
## Дата
|
||
|
||
3 августа 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab035: упреждающий допуск и обслуживание видео целыми составными кадрами.
|
||
|
||
## Выполнено
|
||
|
||
- Lab035 исследует упреждающий допуск и обслуживание видео целыми составными кадрами.
|
||
- Начатый кадр всегда передаётся полностью.
|
||
- Команды и телеметрия могут передаваться между его пакетами.
|
||
- Реактивное удаление Lab034 окончательно не принято.
|
||
- Основная политика — хранение только самого свежего не начатого кадра.
|
||
- При 230 кбит/с опубликовано 56 из 63 кадров с частотой около 2,6 кадра/с.
|
||
- Бесполезно переданных видеобайтов нет.
|
||
- Очередь из двух кадров увеличивает возраст изображения.
|
||
- Прогноз 1000 мс не дал преимущества над более простой политикой.
|
||
- Прогноз 500 мс чрезмерно снижает частоту обновления.
|
||
- Следующая лабораторная проверяет долговременную устойчивость и изменение пропускной способности канала.
|
||
|
||
---
|
||
|
||
# Запись 011
|
||
|
||
## Дата
|
||
|
||
3 августа 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab036: долговременная устойчивость видеопланировщика при изменении пропускной способности.
|
||
|
||
## Выполнено
|
||
|
||
- Lab036 проверяет видеопланировщик на протяжении 600 секунд.
|
||
- Расчётный рост очереди без удаления совпал с моделью.
|
||
- При 230 кбит/с очередь без удаления выросла до 4139 пакетов.
|
||
- 95-й процентиль возраста изображения достиг 74,6 секунды.
|
||
- Плавное поступление сильно устаревших кадров непригодно для управления.
|
||
- Политика хранения только самого свежего не начатого кадра ограничивает очередь.
|
||
- При 230 кбит/с она обеспечила около 2,615 кадра/с.
|
||
- После восстановления скорости возраст изображения снизился ниже 500 мс за 0,077 секунды.
|
||
- Политика двух ожидающих кадров оставлена резервной.
|
||
- Следующая лабораторная объединяет планировщик с моделью ошибок радиоканала и защитой команд управления.
|
||
|
||
---
|
||
|
||
# Запись 012
|
||
|
||
## Дата
|
||
|
||
4 августа 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab037: полный транспорт с серийными потерями и повторением критических команд.
|
||
|
||
## Выполнено
|
||
|
||
- Lab037 объединяет видеопоток, обычные и аварийные команды, телеметрию и временные серийные потери пакетов.
|
||
- Близкие повторные копии команд часто попадают в один и тот же интервал помехи.
|
||
- Повторение Lab037 лишь умеренно уменьшило долю недоставленных управляющих состояний.
|
||
- Максимальный промежуток без свежей команды остался более одной секунды.
|
||
- Своевременная доставка аварийной команды по радиоканалу не гарантируется.
|
||
- Для безопасного поведения при потере связи требуется локальный сторожевой таймер на ровере.
|
||
- Следующий этап исследует сторожевой таймер, временно разнесённую аварийную команду и подтверждение получения.
|
||
|
||
---
|
||
|
||
# Запись 013
|
||
|
||
## Дата
|
||
|
||
4 августа 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab038: локальный сторожевой таймер и подтверждаемая аварийная команда.
|
||
|
||
## Выполнено
|
||
|
||
- Lab038 исследует локальный сторожевой таймер, разнесённую аварийную команду и подтверждение получения.
|
||
- Три инварианта безопасности не нарушены ни разу.
|
||
- Подтверждение не является условием выполнения аварийной остановки.
|
||
- Режим с подтверждением сохранил итоговую доставку аварийной команды 99,694%.
|
||
- Среднее число аварийных копий уменьшилось с 11 до 1,071.
|
||
- Дополнительная нагрузка подтверждаемого режима составляет около 0,0093 кбит/с.
|
||
- Дополнительное повторение обычных команд не принято как основной режим.
|
||
- Порог 100 мс вызывает слишком частые безопасные остановки.
|
||
- Порог 500 мс допускает слишком большой путь до реакции.
|
||
- Для следующей проверки принята двухступенчатая логика: предварительная реакция после 150 мс и обязательная остановка после 250 мс.
|
||
|
||
---
|
||
|
||
# Запись 014
|
||
|
||
## Дата
|
||
|
||
5 августа 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab039: двухступенчатая безопасная реакция и оценка пути до остановки.
|
||
|
||
## Выполнено
|
||
|
||
- Lab039 реализует состояния NORMAL, STAGE1_DECELERATION, STAGE2_BRAKING и EMERGENCY_LATCHED.
|
||
- Используется точное событийное интегрирование движения.
|
||
- Аналитические значения совпали с моделью с нулевой ошибкой.
|
||
- Максимальный полный путь составил 13,9642 м.
|
||
- При 25 км/ч и номинальном профиле политика 150/250 мс дала полный путь около 9,5388 м.
|
||
- Основную часть пути составляет торможение после реакции.
|
||
- Пара 150/250 мс сохраняется как предварительный кандидат, но окончательно не утверждается.
|
||
- Фактические замедления должны быть измерены на реальном ровере.
|
||
- Локальный сторожевой таймер сохранил безопасную реакцию в опытах, где аварийная команда не была доставлена.
|
||
- Следующий этап исследует постоянное аварийное намерение наземной станции и безопасное разрешение повторного движения.
|
||
|
||
---
|
||
|
||
# Запись 015
|
||
|
||
## Дата
|
||
|
||
5 августа 2026 года
|
||
|
||
## Тема
|
||
|
||
Завершение Lab040: постоянное аварийное намерение и безопасное повторное разрешение движения.
|
||
|
||
## Выполнено
|
||
|
||
- Lab040 реализует постоянное аварийное намерение наземной станции.
|
||
- Ограниченное окно повторения 500 мс признано небезопасным.
|
||
- При полностью потерянной аварийной передаче ограниченный режим допускал последующее возобновление движения.
|
||
- В одном из тяжёлых условий путь после такого восстановления достигал в среднем около 490 м при 25 км/ч.
|
||
- Постоянное аварийное намерение исключило положительные задания скорости и небезопасные возобновления движения.
|
||
- Подтверждение аварийной команды не снимает аварийное намерение.
|
||
- Сброс принимается только после остановки, при свежей связи и корректных идентификаторах.
|
||
- Подтверждение сброса не восстанавливает старую команду движения.
|
||
- Движение требует новой явной команды оператора.
|
||
- Следующий этап посвящён сеансам связи, перезапускам устройств и защите от пакетов предыдущего сеанса.
|