AI-система для роботов в сфере обслуживания (HoReCa, ритейл)
Сервисные роботы для ресторанов, отелей и магазинов работают в условиях постоянного контакта с людьми. Это накладывает жёсткие требования на социальное поведение, предсказуемость движений и взаимодействие с персоналом. Технически — это SLAM + social navigation + task planning, объединённые через единую систему управления.
Типология задач по вертикали
Рестораны и кафе:
- Доставка блюд от кухни к столикам (Butler, BellaBot-стиль)
- Сбор грязной посуды со столиков
- Встреча гостей и проводка к столику (hostess robot)
Отели:
- Доставка amenities (полотенца, зубные щётки) в номера
- Доставка room service заказов
- Ассистент на ресепшн: ответы на вопросы, выдача карточек-ключей
Ритейл:
- Инвентаризация полок (Simbe Tally-стиль)
- Уборка торгового зала (Avidbots ARIA)
- Ассистент покупателя: навигация по магазину, поиск товара
Каждый сценарий требует разного баланса автономии и предсказуемости.
Социальная навигация
Ключевая проблема не технологическая — юридическая и психологическая: люди должны доверять роботу. Для этого движения должны быть понятными и предсказуемыми.
Модели социального движения:
- Social Force Model (Helbing, 1995) — классика, быстрый baseline
- ORCA с социальными весами — реальное время, хорошо масштабируется
- LSTM-based trajectory prediction (Social LSTM, CIDNN) — лучший результат, требует GPU
Практический подход: ORCA для reactive avoidance + LSTM-предиктор для проактивного объезда (робот начинает маневр за 3-5 секунд, не за 0.5 секунды как реактивный).
Параметры социальной навигации:
- Минимальная дистанция до человека: 0.6 м (intimate zone boundary)
- Максимальная скорость в людных местах: 0.5-0.8 м/с
- Остановка при < 0.4 м до любого объекта
- Приоритет пропуска: дети > пожилые > взрослые
Task Management System
Роботы в HoReCa получают задания из операционных систем:
- Ресторан: POS-система (iiko, r_keeper, Square) → REST API → Task Queue → Robot
- Отель: PMS (Opera, Protel) → Middleware → Robot Fleet Controller
- Ритейл: WMS / ERP → Event Stream → Robot Scheduler
Task planning использует multi-criteria оптимизацию: расстояние + приоритет задания + уровень заряда + текущая загруженность зоны. Алгоритм: модифицированный Nearest Neighbor с look-ahead на 3-5 задания вперёд.
Человеко-машинное взаимодействие (HRI)
Экран, подсветка и звук — ключевые каналы коммуникации:
| Ситуал | Индикация |
|---|---|
| Движение к цели | Зелёная подсветка, направление взгляда экрана |
| Просьба уступить дорогу | Звуковой сигнал, анимация "жест рукой" |
| Ожидание лифта | Мигающая синяя подсветка |
| Низкий заряд | Голосовое сообщение, жёлтая подсветка |
| Доставка выполнена | Анимация, звук, открытие отсека |
Голосовой интерфейс: Whisper для speech-to-text, локальный LLM (Llama 3 8B quantized) для интерпретации команд, TTS для ответов. Весь NLU работает on-device для privacy.
Интеграция с лифтами и дверьми
Вертикальная навигация — отдельная сложность. Интеграция с системой управления лифтами:
- KONE API / Otis Compass: стандартные IoT-интерфейсы для вызова лифта
- Пожарные двери: Wiegand/OSDP протокол для временного открытия
- Автоматические двери: дополнительный IR-датчик или BLE-тригер
Для отелей: интеграция с системой управления номерами для авторизации входа через BLE или RFID.
Мониторинг и аналитика
Операционный дашборд:
- Тепловые карты зон наибольшей активности
- Heatmap времени ожидания по столикам/номерам
- KPI: задание в час, % отклонённых заданий, среднее время выполнения
Обучение на production данных: все инциденты (ручное вмешательство, столкновения, застревание) логируются и используются для fine-tuning навигационной политики каждые 2-4 недели.
Сроки разработки: MVP одного сценария (например, доставка блюд в ресторане) с 1-2 роботами — 3-4 месяца. Расширение на fleet + несколько сценариев + интеграция с POS/PMS — 6-9 месяцев.