k16. Протоколы и интерфейсы: слои связи «для дронов»

1. Цели урока

После изучения этого урока вы будете уметь выполнять следующие действия.

• Вы объясните, что такое протокол и почему соглашения о связи описывают слоями.
• Вы назовёте пять слоёв модели связи «для дронов» и вопрос, на который отвечает каждый слой.
• Вы отличите потоковую доставку байтов (serial-порт) от датаграммной (UDP) и объясните следствия для поиска границ сообщений.
• Вы объясните назначение каждой части кадра: синхробайт, длина, порядковый номер, адрес отправителя, идентификатор сообщения, полезная нагрузка и контрольная сумма.
• Вы объясните, что такое сериализация, и назовёте поля сообщения HEARTBEAT на уровне общего понимания.
• Вы вычислите процент потерь, среднюю задержку и джиттер канала по формулам и интерпретируете результат вердиктом OK / DEGRADED / UNUSABLE.
• Вы примените слоёную модель к диагностике: определите, на каком уровне искать проблему «телеметрия не отображается».

2. Словарь урока

3. Зачем нужна слоёная модель: диагностика связи

Рассмотрим рабочую ситуацию. Вы запустили наземную станцию, подключились к аппарату — и телеметрия на экране не появляется. Начинающий разработчик в такой ситуации перебирает действия наугад: перезапускает программу, перетыкает кабель, меняет настройки. Инженер, который держит в голове слоёную модель, проверяет слои по порядку снизу вверх и на каждом слое задаёт свой вопрос.

• Физический уровень и транспорт: кабель вставлен, порт существует, программа открыла именно тот порт? Байты из порта вообще читаются — пусть даже бессмысленные?
• Кадры: удаётся ли в потоке байтов находить начала кадров, сходятся ли длины и контрольные суммы? Если кадры рассыпаются, проблема в скорости порта (baudrate) или в помехах.
• Сообщения: приходят ли сообщения нужных типов — например, HEARTBEAT? Возможно, автопилот отправляет телеметрию на другой адрес или с другой частотой.
• Приложение: не отфильтровала ли сама программа те сообщения, которые успешно дошли? Не ждёт ли она другого идентификатора системы?

Каждый слой имеет собственный инструмент проверки, и каждый инструмент вы напишете своими руками в этом модуле: чтение байтов из порта — в K17, UDP-обмен — в K18, разбор кадра и контрольная сумма — в K21, фильтрация сообщений — в модуле M5. Слоёная модель превращает диагностику из гадания в короткий перебор четырёх вопросов.

4. Пять слоёв связи «для дронов»

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

5. Приложение     что делать со знанием: Mission Planner, ваш скрипт
4. Сообщения      о чём именно речь: HEARTBEAT, ATTITUDE, COMMAND_LONG
3. Кадры          где границы и цело ли: синхробайт, длина, CRC
2. Транспорт      как доставляются блоки байтов: поток или датаграммы
1. Физический     как передаются биты: провод, радиоволна, оптика

Бытовая аналогия — письмо. Физический уровень — дороги и транспорт: грузовик или самолёт, по которым едет почта. Транспорт — почтовая служба: она перевозит пачки корреспонденции и не читает содержимое. Кадр — конверт: на нём написан адрес, а печать позволяет получателю убедиться, что конверт не повреждён. Сообщение — текст письма, написанный на понятном обеим сторонам языке. Приложение — то решение, которое получатель примет после прочтения. Аналогия полезна, но помните, где она заканчивается: байты можно скопировать без износа, а «печать» кадра — контрольная сумма — проверяется автоматически и мгновенно.

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

# Пример: слоёная модель связи как словарь программы
layers = {
    "physical": "провод UART, радиоканал или Ethernet",
    "transport": "поток байтов serial или датаграммы UDP",
    "frame": "кадр MAVLink: границы и контрольная сумма",
    "message": "HEARTBEAT, ATTITUDE, COMMAND_LONG",
    "application": "Mission Planner или скрипт на companion",
}

for name, description in layers.items():
    print(f"{name}: {description}")

Главное свойство слоёной модели: каждый слой можно заменить, не трогая остальные. Та же самая телеметрия MAVLink летит по проводу UART в бортовой сети и по UDP в симуляторе SITL — потому что MAVLink живёт на двух верхних из средних слоёв и не зависит от того, что находится под ним. Это утверждение станет итоговой картой раздела 10.

5. Физический уровень и транспорт в мире БПЛА

Физический уровень отвечает на вопрос «как биты превращаются в физический процесс»: в электрические уровни напряжения на двух проводах UART, в радиоволны диапазона 433 или 915 МГц, в сигналы Ethernet и Wi-Fi. Его характеристики — разъёмы, уровни напряжений, частоты и скорость передачи в битах в секунду. Ошибка на этом уровне выглядит так: провод перепутан местами, скорость порта не совпала, радиоканал зашумлён.

Транспортный слой отвечает на вопрос «как блоки байтов доставляются от отправителя к получателю». Здесь важна не скорость, а форма доставки, и форм ровно две. Поток (stream) — непрерывная череда байтов без встроенных границ: так работают serial-порт и TCP. Получатель видит «реку» байтов и обязан сам искать в ней начала сообщений — эту задачу решает кадр из раздела 6. Датаграмма — самостоятельный блок с сохранёнными границами: так работает UDP. Каждый отправленный блок приходит отдельным пакетом (или не приходит вовсе), но если пришёл — его границы сохранены. Таблица ниже собирает каналы, которые встретятся в курсе.

6. Кадр: границы сообщения и целостность

Допустим, транспорт доставляет байты. В потоке serial-порта их «река» не имеет ни пауз, ни отметок: получатель видит числа одно за другим и не знает, где начинается и заканчивается осмысленный блок. Эту задачу решает кадр — заранее согласованная структура блока байтов. Любая кадровая структура, включая MAVLink, содержит примерно одни и те же части, каждая из которых отвечает на свой вопрос.

Контрольная сумма заслуживает отдельного пояснения, потому что именно она отделяет данные от шума. Радиоканал вносит искажения: отдельный бит может «перевернуться», и число в полезной нагрузке изменится. На глаз отличить искажённое значение от настоящего невозможно — оба выглядят правдоподобно. Контрольная сумма делает искажение видимым: пересчитанное значение не совпадёт с переданным, и приёмник отбросит кадр вместо того, чтобы поверить в ложные числа. Идею контрольных сумм вы соберёте руками на уроке K21, а точную анатомию кадра MAVLink 2 с шестнадцатеричным дампом настоящего HEARTBEAT разберёт урок K30.

7. Сообщение: идентификатор и поля

Полезная нагрузка кадра несёт сообщение — единицу смысла протокола. Сообщение состоит из идентификатора (какое это сообщение) и набора типизированных полей (какие именно числа внутри и что они означают). Превращение структуры данных программы в байты называется сериализацией, а обратный процесс — десериализацией; схема сообщения задаёт и порядок полей, и тип каждого поля, и единицы измерения.

Покажем на самом известном сообщении MAVLink — HEARTBEAT. Автопилот отправляет его примерно раз в секунду, и по одному факту приёма получатель понимает: система жива. Подробный разбор полей и работа с ними — уроки K29 и K32; сейчас достаточно общего знакомства.

Обратите внимание на деталь, которая станет важной в модуле M5: единицы измерения и масштаб полей задаёт схема сообщения, а не здравый смысл. В одних сообщениях углы приходят в радианах, в других — в сантиградусах; координаты — в градусах, умноженных на 10⁷, как вы видели на уроке K15. Дисциплина одна: читать схему поля до того, как интерпретировать число.

8. Приложение: кто потребляет сообщения

Верхний слой — приложение: программа, ради которой вся передача и затевалась. В системе беспилотника приложений обычно несколько, и все они обмениваются одними и теми же сообщениями MAVLink.

• Наземная станция управления (Mission Planner, QGroundControl) рисует карту, приборы и телеметрию, отправляет команды оператора и файлы миссий.
• Бортовой компьютер-компаньон (наш будущий Raspberry Pi) выполняет «умные» задачи: сопровождение цели, облёт препятствий, передачу видео — и отправляет автопилоту команды верхнего уровня.
• Сам автопилот — тоже потребитель: он принимает команды, параметры и миссии и отвечает телеметрией и подтверждениями.

Адресация на этом слое устроена просто: каждый участник обмена имеет идентификатор системы (sysid) — например, аппарат обычно получает номер 1, а наземная станция — 255, — и идентификатор компонента (compid) внутри системы: автопилот, камера, модуль питания. Получатель смотрит на адрес в кадре и решает, ему сообщение или другому участнику. По одному каналу телеметрию могут слушать несколько приложений одновременно — как это правильно организовать, расскажет урок K37.

9. Качество канала: задержка, джиттер, потери, пропускная способность

Канал связи характеризуется четырьмя числами, которые программист обязан уметь измерять и интерпретировать.

Первое — задержка (latency): время между отправкой данных и их получением, в миллисекундах. Различают одностороннюю задержку и время туда-обратно (RTT, round-trip time) — для команды с подтверждением важно второе. Задержка напрямую ограничивает управление: если команда «сместиться» доходит за полсекунды, аппарат будет «рыскать» вокруг цели, потому что контур управления реагирует на устаревшее состояние.

Второе — джиттер (jitter): нестабильность задержки. Канал со стабильными 100 миллисекундами часто лучше канала, у которого задержка прыгает от 20 до 200: предсказуемое запаздывание можно учесть, а случайные скачки ломают плавность управления. Учебная формула джиттера — средняя абсолютная разность соседних измерений задержки \(t_1, t_2, \ldots, t_n\):

\[ J = \frac{1}{n-1} \sum_{i=1}^{n-1} \left| t_{i+1} - t_i \right| \]

Третье — потери пакетов (packet loss): доля отправленных блоков, не дошедших до получателя. Если отправлено \(N_{sent}\) пакетов, а получено \(N_{recv}\), то процент потерь равен:

\[ L = \frac{N_{sent} - N_{recv}}{N_{sent}} \cdot 100\% \]

Небольшой процент потерь для радиоканала нормален, и протоколы это учитывают: телеметрия MAVLink передаётся периодическими потоками, и потерянный отсчёт просто заменится следующим через долю секунды. Опасны потери для команд: именно поэтому команды сопровождаются подтверждениями (COMMAND_ACK — разбор в модуле M5), а пропадание потока HEARTBEAT запускает защитную логику failsafe (урок K27).

Четвёртое — пропускная способность: сколько данных канал способен передать за секунду. Её измеряют в битах в секунду (бит/с) или в байтах в секунду (Б/с); между единицами перевод в восемь раз: 57600 бит/с — это примерно 7200 Б/с «грязными», а с учётом служебных полей кадров — примерно 4–6 КБ/с полезной телеметрии. Не путайте пропускную способность с задержкой: широкий канал не уменьшает время прохождения одного пакета.

Числа в таблице — ориентиры для интуиции, а не спецификация: реальные характеристики всегда измеряются на конкретном оборудовании. Именно этим занимается практика урока.

# Пример: метрики качества канала (фрагмент k16_task1_link_quality.py)
def loss_percent(sent: int, received: int) -＞ float:
    if sent ＜= 0:
        raise ValueError(f"число отправленных должно быть больше нуля: {sent}")
    if received ＜ 0 or received ＞ sent:
        raise ValueError(f"received должно быть от 0 до sent, получено: {received}")
    return (sent - received) / sent * 100.0

def jitter_ms(samples_ms) -＞ float:
    if len(samples_ms) ＜ 2:
        raise ValueError("для джиттера нужно минимум два отсчёта")
    total = 0.0
    for i in range(1, len(samples_ms)):
        total += abs(samples_ms[i] - samples_ms[i - 1])
    return total / (len(samples_ms) - 1)

10. Где живёт MAVLink: итоговая карта

Соберём картину в один рисунок. MAVLink занимает два слоя — кадры и сообщения; всё, что ниже, он оставляет на усмотрение системы, всё, что выше, — на усмотрение программиста.

Приложение    Mission Planner, скрипты на companion, логика автопилота
                                    ← ваш будущий Python
Сообщения     HEARTBEAT, ATTITUDE, COMMAND_LONG, GLOBAL_POSITION_INT
                                    ← MAVLink
Кадры         синхробайт, длина, seq, sysid/compid, msgid, payload, CRC
                                    ← MAVLink
Транспорт     serial-поток / UDP-датаграммы / TCP / USB
                                    ← уроки K17–K18
Физический    UART-провода, радиоканал модема, Ethernet, Wi-Fi
                                    ← уроки K17–K20

Отсюда следует ключевое свойство MAVLink, которое вы увидите в модулях M4 и M5: транспортная независимость. Симулятор SITL отдаёт телеметрию датаграммами UDP на порт 14550, реальный полётный контроллер — потоком байтов по UART или USB, а сообщения и кадры при этом одинаковы. Поэтому библиотека pymavlink подключается к любому каналу одной строкой соединения: в модуле M5 вы будете писать и udp:127.0.0.1:14550 для симулятора, и имя COM-порта для настоящего контроллера — и код выше строки подключения меняться не будет.

11. Типичные заблуждения

12. Практика

Урок теоретический, поэтому практика компактная: один модуль метрик качества канала и один файл тестов. Модуль превращает формулы раздела 9 в чистые функции — потерю, среднюю задержку, джиттер и сводный вердикт, — а тесты закрепляют их поведение, включая защиту от бессмысленных входных данных. Новых пакетов не требуется: только стандартная библиотека и установленный pytest. Порядок работы: создайте файлы задач 16.1 и 16.2 в каталоге code/M01_python, выполните прогоны (задача 16.3) и сохраните исходники в Git (задача 16.4).

# Каталог: code/M01_python (venv активен, новых пакетов не требуется)
python k16_task1_link_quality.py
python -m pytest k16_task2_test_link_quality.py -v

хороший канал (SITL по Wi-Fi): потери   0.0 %, средняя задержка    4.8 мс, джиттер   1.2 мс -＞ OK
радиомодем, умеренные помехи: потери   4.0 %, средняя задержка  105.0 мс, джиттер  38.0 мс -＞ DEGRADED
канал с большими потерями: потери  25.0 %, средняя задержка   95.0 мс, джиттер  10.0 мс -＞ UNUSABLE

tests: 13 passed

# Из корня репозитория курса
git add code/M01_python/k16_task1_link_quality.py code/M01_python/k16_task2_test_link_quality.py
git commit -m "K16: link quality metrics - loss, latency, jitter, verdict; 13 tests"

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

1. Что такое протокол и почему соглашения о связи описывают слоями, а не одним текстом?
2. Перечислите пять слоёв модели «для дронов» и вопрос, на который отвечает каждый слой.
3. Чем потоковая доставка байтов отличается от датаграммной и какое следствие это имеет для поиска границ сообщений?
4. Какую задачу решает каждая часть кадра: синхробайт, длина, порядковый номер, адрес, идентификатор сообщения, полезная нагрузка, контрольная сумма?
5. Что такое сериализация и десериализация сообщений?
6. Какие два слоя занимает MAVLink и почему он не зависит от того, что находится ниже?
7. Чем задержка отличается от джиттера и почему стабильные 100 мс бывают лучше прыгающих 20–200 мс?
8. Как вычисляется процент потерь и почему небольшой процент потерь нормален для радиоканала?
9. Чем пропускная способность отличается от задержки? Приведите задачу, где критична каждая из них.
10. Телеметрия не отображается в программе. Опишите порядок проверки по слоям снизу вверх.

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

• Я могу назвать пять слоёв модели связи и вопрос каждого слоя без подсказки.
• Я объясняю разницу потока и датаграммы на примере serial-порта и UDP.
• Я объясняю назначение каждой части кадра и роль контрольной суммы.
• Я могу пересказать, из чего состоит сообщение, на примере HEARTBEAT.
• Я знаю, где MAVLink живёт в слоёной модели и почему он транспортно-независим.
• Я создал оба файла практики в каталоге code/M01_python.
• Демо напечатало вердикты OK, DEGRADED и UNUSABLE для трёх сценариев, и я могу объяснить каждый вердикт.
• Команда python -m pytest k16_task2_test_link_quality.py -v завершается результатом 13 passed.
• Я сделал git commit с файлами урока K16.

15. Что дальше

• Предыдущий урок: K15 · Геокоординаты: lat/lon/alt, haversine, bearing (модуль M2 завершён)
• Текущий урок: K16 · Слои связи «для дронов» — начало модуля M3 «Протоколы и интерфейсы»
• Следующий урок: K17 · UART / Serial / USB-UART: TX/RX/GND, baudrate, COM-порты Windows, библиотека pyserial
• Модуль M3 завершится лабораторной работой K22 (два процесса: передатчик фейковой телеметрии и приёмник-разборщик), после которой сдаётся гейт G2.