Технологии Mavix

Общая схема работы

В системе три участника: дрон с прошивкой MavixBoard, компьютер оператора с приложением MavixDesktop и MavixServer — сервер посередине.

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

Этот выбор архитектуры приносит две выгоды. Низкая задержка — видеопоток не делает лишний прыжок через сервер. И предсказуемая нагрузка — даже если активных полётов станет тысячи, сервер не будет загружен передачей видео, потому что он его не видит.

Четыре технологии, на которых это держится, описаны ниже.

WebRTC — прямая передача видео

WebRTC (Web Real-Time Communication) — открытый стандарт W3C для передачи аудио, видео и произвольных данных напрямую между двумя устройствами, без посредника-сервера в середине потока. Изначально создавался для видеозвонков в браузере; в Mavix он используется для соединения дрона и оператора.

Что Mavix передаёт через WebRTC:

• видеопоток с камеры дрона на экран оператора;
• команды управления — позиции стиков джойстика;
• служебные данные — измерение задержки, переключение камер, смена битрейта.

Чтобы два устройства смогли установить прямое соединение, им нужно сначала обменяться техническими параметрами и определить сетевые адреса друг друга. Эту часть берёт на себя сервер — он выступает только как «телефонная книга» и «переговорщик». Когда обмен завершён, сервер выпадает из цепочки. В сложных сетях, где прямое соединение невозможно, в дело включается TURN-сервер — ретранслятор, через который проходит трафик; в обычных случаях достаточно STUN-сервера, который только помогает узнать свой публичный IP-адрес.

MAVLink — связь с полётным контроллером

MAVLink (Micro Air Vehicle Link) — отраслевой стандарт обмена сообщениями между компонентами беспилотников: полётным контроллером, наземной станцией, дополнительными бортовыми компьютерами. На MAVLink говорят все массовые прошивки полётных контроллеров — ArduPilot, PX4 и большинство коммерческих систем.

В Mavix MAVLink работает внутри дрона, между прошивкой MavixBoard на Raspberry Pi и собственно полётным контроллером, подключённым по UART или USB. По этому каналу идут:

• Телеметрия от контроллера — положение в пространстве, координаты GPS, заряд батареи, режим полёта, текущая ошибка, если есть.
• Служебные команды — арм/дизарм моторов, смена режима полёта, запрос параметров.

MAVLink не используется для передачи стиков джойстика в реальном времени — для этого существует отдельный протокол с меньшими накладными расходами (см. CRSF ниже).

CRSF — каналы управления

CRSF (Crossfire Serial Protocol) — двухсторонний протокол, разработанный для линка управления радиомоделями TBS Crossfire. Сегодня это де-факто стандарт для современных приёмников и полётных контроллеров: 16 каналов управления, минимальная задержка, кадры с контрольной суммой.

В Mavix CRSF используется между приложением оператора и полётным контроллером дрона — но не напрямую, а через мост:

1. Оператор двигает стик джойстика на ПК.
2. MavixDesktop упаковывает позиции стиков в CRSF-кадр и отправляет его в дрон через WebRTC.
3. MavixBoard на дроне получает кадр и переотправляет его на UART полётного контроллера — для него это выглядит так, будто кадр пришёл с обычного радиоприёмника.

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

JWT — авторизация пользователя

JWT (JSON Web Token) — открытый стандарт RFC 7519 для передачи подписанной информации между сторонами. Токен — это короткая строка, в которой закодированы данные о пользователе и подпись, гарантирующая, что данные не были изменены.

После входа в систему сервер выдаёт пользователю два токена:

• Access-токен — короткоживущий (15 минут). Прикладывается к каждому запросу к серверу. Сервер по подписи проверяет, что токен настоящий, и достаёт из него идентификатор пользователя — без обращения к базе данных.
• Refresh-токен — долгоживущий (30 дней). Хранится у клиента и используется только в одном случае: чтобы получить новый access-токен, когда старый истёк. Пользователь при этом не видит никакой авторизации — приложение обновляет токен само.

Для восстановления пароля используется отдельный reset-токен с временем жизни один час. Сервер кладёт его в письмо со ссылкой — подделать ссылку нельзя, потому что подпись делается секретом, который знает только сервер.

У JWT-схемы есть важное свойство: сервер не хранит активные сессии. Это делает систему легко масштабируемой и устойчивой — нет общего состояния, которое может разойтись или потеряться.