Разработка мобильного приложения для управления роботом

Инженер сталкивается с задачей удаленного управления роботом через мобильное устройство с задержкой не более 100 мс. Выбор протокола передачи данных определяет скорость реакции, безопасность и стоимость разработки. Некорректная архитектура приводит к потере связи и авариям. Мы специализируемся на разработке приложений управления роботами: от AGV до коллаборативных манипуляторов. За 5+ лет реализовали 15+ проектов, где добились задержки < 100 мс даже через LTE.

Какой протокол выбрать для минимальной задержки?

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

UDP обеспечивает задержку в 10 раз меньше, чем MQTT, но не гарантирует доставку — это плюс для реального времени, где свежая команда важнее надёжности. MQTT с QoS 1 надёжнее, но добавляет overhead. Для ROS-роботов оптимален WebSocket через rosbridge, хотя JSON-сериализация может быть узким местом на высоких частотах (согласно официальной документации rosbridge_protocol).

Почему watchdog обязателен?

Критический сценарий — разрыв соединения. Без защиты робот может продолжать движение, что опасно. Мы реализуем watchdog по шагам:

1. На роботе запускаем таймер на 1–2 секунды.
2. Если за это время не пришла команда, робот переходит в состояние safe_stop (остановка всех двигателей) или удержание позиции.
3. На телефоне отображаем статус подключения и автоматически переподключаемся с индикацией 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 сложнее в настройке, но даёт наименьшую задержку и адаптивный битрейт. Для локального управления (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 мс. Нет гарантий доставки — это плюс: старая команда не блокирует новую в очереди. Применяется для управления манипуляторами, где задержка команды важнее гарантии доставки.

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 месяца. Точные сроки — после анализа платформы робота и требований к задержке.

Оценим ваш проект и предложим оптимальное решение. Получите консультацию по архитектуре протокола. Свяжитесь с нами для детального обсуждения.