Инженер сталкивается с задачей удаленного управления роботом через мобильное устройство с задержкой не более 100 мс. Выбор протокола передачи данных определяет скорость реакции, безопасность и стоимость разработки. Некорректная архитектура приводит к потере связи и авариям. Мы специализируемся на разработке приложений управления роботами: от AGV до коллаборативных манипуляторов. За 5+ лет реализовали 15+ проектов, где добились задержки < 100 мс даже через LTE.
Какой протокол выбрать для минимальной задержки?
Выбор транспорта определяет задержку, надёжность и сложность разработки. В нашей практике мы используем три основных протокола:
| Протокол | Задержка | Гарантия доставки | Сфера применения |
|---|---|---|---|
| ROS 2 (WebSocket) | 50–200 мс | Да (TCP) | Роботы с ROS, сложная архитектура команд |
| MQTT | 20–100 мс | QoS 1 (at least once) | IoT-роботы, AGV, лёгкое управление |
| UDP | < 10 мс | Нет | Манипуляторы, высокочастотные команды |
UDP обеспечивает задержку в 10 раз меньше, чем MQTT, но не гарантирует доставку — это плюс для реального времени, где свежая команда важнее надёжности. MQTT с QoS 1 надёжнее, но добавляет overhead. Для ROS-роботов оптимален WebSocket через rosbridge, хотя JSON-сериализация может быть узким местом на высоких частотах (согласно официальной документации rosbridge_protocol).
Почему watchdog обязателен?
Критический сценарий — разрыв соединения. Без защиты робот может продолжать движение, что опасно. Мы реализуем watchdog по шагам:
- На роботе запускаем таймер на 1–2 секунды.
- Если за это время не пришла команда, робот переходит в состояние safe_stop (остановка всех двигателей) или удержание позиции.
- На телефоне отображаем статус подключения и автоматически переподключаемся с индикацией Quality of Service.
Дополнительно — PIN/QR-аутентификация для предотвращения управления чужим роботом.
Как снизить задержку видеопотока?
Для H.264-стримов с IP-камер на роботе используем ExoPlayer (Android) или AVPlayer с HLS (iOS). Задержка HLS — 5–30 секунд, что неприемлемо для управления. Правильный путь: WebRTC (latency < 200 мс) или RTSP через LibVLC / ffmpeg в MediaCodec pipeline (latency 100–300 мс).
| Тип | Компоненты | Задержка | Сложность |
|---|---|---|---|
| WebRTC | STUN/TURN, сигналинг | < 200 мс | Высокая (требуется инфраструктура) |
| RTSP | VLC, ffmpeg | 100–300 мс | Средняя (готовые библиотеки) |
| HLS | AVPlayer, ExoPlayer | 5–30 с | Низкая (простая настройка) |
WebRTC сложнее в настройке, но даёт наименьшую задержку и адаптивный битрейт. Для локального управления (Wi-Fi) RTSP — оптимальный баланс.
Транспорт и протоколы (подробнее)
ROS 2 + rosbridge (WebSocket)
Самый распространённый стек для ROS-роботов: на роботе поднимается rosbridge_server, телефон подключается через WebSocket и публикует/подписывается на топики через JSON-протокол rosbridge_protocol. Для мобильных клиентов есть библиотека roslibjs-совместимые обёртки, но для нативного Android/iOS пишем клиент сами — это 300–400 строк кода с повторным подключением и очередью сообщений.
Проблема: rosbridge — JSON поверх WebSocket, это медленно для высокочастотных топиков. Топик /cmd_vel с Twist-командами на 20 Гц через JSON даёт ~40 кб/с трафика. Если робот находится за Wi-Fi с реальной пропускной способностью 1 Мбит/с — норм. Если через LTE с джиттером — пакеты приходят пачками, команды исполняются с задержкой. Решение: снижаем частоту команд до 10 Гц и добавляем watchdog: если от телефона нет команды 500 мс, робот переходит в safe_stop.
MQTT для лёгкого управления
Для IoT-роботов без ROS (AGV, сортировщики, кастомные платформы) — MQTT брокер (Mosquitto или EMQ X) плюс лёгкий протокол команд. Телефон публикует в robot/{id}/cmd, робот подписан на этот топик. Телеметрия в обратную сторону: robot/{id}/state, robot/{id}/battery. Используем MQTT с QoS 1 (at least once) для команд управления — QoS 0 теряет пакеты при нестабильном Wi-Fi, QoS 2 создаёт лишние round-trips. Retained message для robot/{id}/state позволяет новому подключившемуся клиенту сразу получить актуальное состояние без ожидания следующего обновления.
UDP для реального времени (< 50 мс)
Если нужна минимальная задержка — прямой UDP-сокет на порт управления. На Android: DatagramSocket в CoroutineScope(Dispatchers.IO), отправка каждые 50 мс. Нет гарантий доставки — это плюс: старая команда не блокирует новую в очереди. Применяется для управления манипуляторами, где задержка команды важнее гарантии доставки.
Пример конфигурации MQTT топиков
robot/{id}/cmd — команды управления (velocity, gripper) robot/{id}/state — телеметрия (position, battery) robot/{id}/video — метаданные потока (URL, кодек) Архитектура мобильного клиента
class RobotControlViewModel( private val robotRepository: RobotRepository ) : ViewModel() { private val _robotState = MutableStateFlow<RobotState>(RobotState.Disconnected) val robotState: StateFlow<RobotState> = _robotState fun sendVelocityCommand(linear: Float, angular: Float) { viewModelScope.launch { robotRepository.publishVelocity( TwistCommand(linear = linear, angular = angular) ) } } fun connect(robotIp: String) { viewModelScope.launch { robotRepository.connect(robotIp) .onEach { state -> _robotState.value = state } .launchIn(this) } } } RobotRepository инкапсулирует конкретный транспорт — WebSocket, MQTT или UDP. Смена транспорта не затрагивает ViewModel и UI. Это критично: в реальных проектах часто меняется железо или протокол между прототипом и продакшеном.
Виртуальный джойстик и обработка ввода
MotionEvent.ACTION_MOVE приходит до 60 раз в секунду при быстром движении пальца. Отправлять команду на каждый event — перегрузка канала. Используем throttleLatest(50) из Kotlin Coroutines Flow — берём последнее значение за 50 мс. Старые промежуточные значения отбрасываются, задержка ответа — не более 50 мс.
Деадзона (dead zone) в центре джойстика: 10–15% радиуса фильтруем до нуля. Без этого микротремор руки вызывает постоянные команды малой скорости, робот «дёргается» в покое.
Что входит в разработку?
Мы предоставляем полный пакет услуг:
- Проектирование архитектуры протокола (выбор транспорта, схема команд)
- Разработка нативного мобильного приложения под Android и/или iOS
- Интеграция стриминга видео через WebRTC или RTSP
- Разработка watchdog и сценариев аварийного восстановления
- Тестирование на реальном роботе в условиях, близких к эксплуатации
- Техническая документация и обучение операторов
Сроки
Базовый клиент с джойстиком, телеметрией и видеопотоком на одной платформе — 3–5 недель. Кроссплатформенное решение с поддержкой нескольких протоколов, картой помещения и автономными миссиями — 2–4 месяца. Точные сроки — после анализа платформы робота и требований к задержке.
Оценим ваш проект и предложим оптимальное решение. Получите консультацию по архитектуре протокола. Свяжитесь с нами для детального обсуждения.