SLAM-навігація для сервісних роботів: AI-система під ключ

AI-система навігації сервісних роботів (SLAM)

Завдання навігації без GPS у закритих приміщеннях — виклик для будь-якого мобільного робота. Simultaneous Localization and Mapping (SLAM) у зв'язці з deep reinforcement learning дозволяє роботу будувати карту, локалізуватися на ній з точністю до 2–5 см і приймати рішення в динамічному середовищі з людьми та об'єктами. Ми спеціалізуємося на впровадженні таких систем під ключ: від вибору сенсорів до розгортання флоту. Наша команда — 5+ років практичного досвіду в SLAM, 15+ впроваджених проєктів для ресторанів, готелів та складів, сертифіковані інженери NVIDIA. В основі лежить гібридний підхід: LiDAR SLAM як основний сенсор, vSLAM як резерв. Такий тандем забезпечує відмовостійкість і точність, недосяжну для одного типу сенсорів. Наприклад, в умовах низької освітленості Cartographer перевершує ORB-SLAM3 на 20–30%, а при великій кількості візуальних текстур vSLAM бере гору.

Thrun et al., Probabilistic Robotics, MIT Press

Архітектура SLAM-системи

Сучасні реалізації використовують factor graph-підхід. Дві основні гілки:

LiDAR-based SLAM

• Алгоритми: Cartographer (Google) або LOAM/LeGO-LOAM для 3D-сенсорів
• Сенсори: Velodyne VLP-16, Ouster OS1, Livox Mid-360
• Частота оновлення карти: 10-20 Гц
• Точність локалізації: 2-5 см у статичному середовищі

Visual SLAM (vSLAM)

• ORB-SLAM3, OpenVINS для стерео/monocular камер
• Основні платформи: Intel RealSense D435i, Zed 2
• Fusion з IMU через EKF (Extended Kalman Filter)
• Працює при збоях лідара (дим, яскраве світло)

На практиці використовується гібридний підхід: LiDAR SLAM як основний, vSLAM як резервний і для візуальної верифікації.

Чому гібридний SLAM?

Тому що він забезпечує відмовостійкість: якщо один сенсор деградує, другий підхоплює. Порівняння: Cartographer перевершує ORB-SLAM3 за точністю в умовах низької освітленості на 20–30%, але поступається в текстурованих сценах. Гібридна система бере найкраще від обох світів.

Deep RL для навігації в динаміці

Класичні планувальники (A*, Dijkstra, RRT) добре працюють у статичному середовищі. Проблема — динамічні перешкоди: люди, рухомі візки, роботи-колеги. Тут підключається RL.

Формалізація задачі:

• Стан: локальна карта occupancy grid 64×64 навколо робота + швидкість + вектор до цілі
• Дії: лінійна швидкість [0, 0.8 м/с], кутова швидкість [-1.0, 1.0 рад/с]
• Нагорода: просування до цілі - штраф за близькість до перешкод - штраф за зупинку

Алгоритм: SAC (Soft Actor-Critic) — найкращий баланс дослідження/експлуатації для безперервних просторів дій. Навчання в симуляторі Gazebo/Isaac Sim, sim-to-real transfer через domain randomisation.

Як deep RL вирішує проблему динамічних перешкод?

Ключове завдання — передбачення траєкторій людей для соціально прийнятної навігації. Використовується Social Force Model та його нейромережеве розширення — Social LSTM або DESIRE. Метрики соціальної навігації:

• Personal Space Intrusion (PSI): частка часу в зоні < 0.5 м від людини
• Path Efficiency: відношення фактичного шляху до оптимального
• Freeze ratio: частка часу в стані «завмер перед людьми»

Для сервісного робота в ресторані або готелі PSI має бути < 1%, інакше користувачі сприймають його як агресивний. Ми гарантуємо досягнення цього показника через калібрування RL-нагороди та симуляцію з реальними даними.

Як забезпечується соціальна навігація?

Social navigation — це не лише уникнення зіткнень, а й дотримання соціальних норм: робот має об'їжджати людей зліва, не блокувати проходи, не підходити надто близько до груп. Для цього в RL-нагороду додається штраф за вторгнення в personal space та бонус за дотримання «правої сторони». Додатково використовується соціальна карта — розподіл ймовірностей знаходження людей.

Multi-robot координація

При кількох роботах на майданчику виникають deadlock-ситуації. Рішення:

• Centralized: сервер планування (CBS — Conflict-Based Search) + ROS2 Nav2 Multi-robot
• Decentralized: ORCA (Optimal Reciprocal Collision Avoidance) — кожен робот самостійно вирішує конфлікти
• Hybrid: зональне розділення + локальний ORCA

Для складу з 10-20 роботами рекомендовано централізований CBS. Для відкритих торгових залів — децентралізований ORCA з м'якими зонами пріоритету.

Стек технологій

Pipeline розробки

1. Фаза 1 (тижні 1–6): Вибір та налаштування SLAM-алгоритму під конкретний сенсорний пакет. Картування тестового приміщення, оцінка точності локалізації.
2. Фаза 2 (тижні 7–14): Створення симуляційного середовища в Isaac Sim з реальними CAD-моделями приміщення. Навчання RL-агента навігації, 20–50 млн кроків симуляції.
3. Фаза 3 (тижні 15–20): Sim-to-real transfer на фізичному роботі. Domain randomisation: випадкові затримки датчиків, шум одометрії, випадкове розташування меблів.
4. Фаза 4 (тижні 21–26): Fleet management, моніторинг, інтеграція з операційними системами (PMS для готелів, WMS для складів).

Підсумкові метрики продакшн-системи: успішність місій > 97%, середня швидкість пересування 0.4–0.6 м/с у людних місцях, автономна робота 8–12 годин на одному заряді.

Що входить в роботу

• Аналіз приміщення та вимог до навігації
• Вибір та калібрування сенсорів (LiDAR, камери, IMU)
• Розробка та налаштування SLAM-алгоритму (Cartographer/ORB-SLAM3)
• Створення симуляційного середовища та навчання RL-політики
• Sim-to-real transfer та налагодження на фізичному роботі
• Інтеграція з ROS2 та fleet management
• Документація, навчання ваших інженерів, підтримка 3 місяці

Зв'яжіться з нами для консультації щодо вашого проєкту. Замовте оцінку сценарію — запропонуємо оптимальну архітектуру під ключ. Отримайте детальний пайплайн та розрахунок термінів індивідуально.

Навчання з підкріпленням: PPO, SAC, DQN та промислове застосування

Ми щодня бачимо проєкти, які гинуть не через слабкий алгоритм, а через неправильну винагороду. Інженер пише reward = +1 за правильну дію, запускає навчання, а через 10 млн кроків агент знаходить спосіб отримати максимум, не вирішивши завдання. Це reward hacking — системний біль промислового RL. Наш досвід показує: правильний reward займає 70% успіху.

Чому RL складніше, ніж supervised learning?

У supervised learning є датасет з правильними відповідями. У RL правильної відповіді немає — є скалярний сигнал «краще/гірше», який надходить із затримкою в сотні кроків. Агент сам досліджує простір і знаходить стратегію.

Наслідки: нестабільність навчання, висока чутливість до гіперпараметрів, повільна збіжність. PPO (Proximal Policy Optimization) на Atari сходиться за 10 млн кроків — це години. На роботизованих завданнях з реальною фізикою — дні або тижні в симуляторі.

Чому reward engineering вирішальний для RL?

Без якісної reward-функції навчання перетворюється на лотерею. Reward hacking — класична пастка: агент знаходить неочевидний спосіб максимізувати винагороду, ігноруючи справжню ціль. Один із проєктів — сортування компонентів на PCB — demand: ми витратили 2 тижні на формалізацію reward: штраф за зіткнення, бонус за швидкість, penalty за неправильне розташування. Без цього агент навчився скидати деталі з конвеєра, отримуючи +1 за кожну скинуту, а не за відсортовану.

Як обрати алгоритм під задачу?

Як налаштувати PPO та уникнути типових проблем?

PPO — робоча конячка RL. Основна ідея: обмежуємо оновлення політики через кліпування ratio clip_range=0.2. Це дає стабільність порівняно з vanilla policy gradient. Але без грамотного налаштування агент не сходиться.

Одна з частих пасток — entropy collapse: агент занадто швидко стає детермінованим, перестає досліджувати. Симптом — entropy coefficient падає до нуля. Лікування — ent_coef=0.01–0.05 і не знижувати нижче 0.001. Інша проблема — value function розходиться, коли vf_loss_coef високий, а explained_variance від'ємний. Рекомендуємо vf_coef=0.5 і gradient clipping max_grad_norm=0.5.

Неправильний n_steps також ламає навчання. n_steps=2048 — дефолт Stable‑Baselines3. Для завдань з довгим горизонтом (>500 кроків) потрібно збільшувати, для швидких (10–50 кроків) — зменшувати до 256–512.

Для швидкого старту використовуємо stable‑baselines3 + sb3‑contrib. Для research і кастомних алгоритмів — tianshou або CleanRL.

SAC для безперервного керування

SAC (Soft Actor‑Critic) додає в objective максимізацію ентропії — агент вчиться бути і ефективним, і різноманітним. Це дає відмінну sample efficiency та стійкість до шуму в reward. На задачах керування техпроцесами SAC зазвичай обходить PPO за збіжністю: потребує на 30–40% менше взаємодій для досягнення тієї ж якості. Ключовий параметр — target_entropy. Стандартне значення ‑dim(action_space) часто підходить, але для специфічних завдань краще налаштовувати вручну.

Як перенести навченого агента на реальний пристрій?

Навчати RL на реальному роботі — дорого та небезпечно. Стандартний підхід: навчання в симуляторі → трансфер на реальне залізо. Основна проблема — reality gap: симулятор не відтворює фізику, тертя, шум датчиків.

Головний інструмент — domain randomization. Під час навчання випадково варіюємо параметри середовища: маса об'єктів ±30%, коефіцієнт тертя ±50%, затримка дій 0–100 мс, шум спостережень σ=0.01–0.1. Агент навчається бути робастним до варіацій, і реальний світ стає лише ще однією варіацією.

Порівняння популярних симуляторів:

RLHF: навчання LLM з людського зворотного зв'язку

RLHF став стандартом після InstructGPT. Класична схема: supervised fine‑tuning → reward model → PPO.

Проблеми класичного PPO: нестабільність (KL‑дивергенція може вибухнути), повільна збіжність, складність налаштування. Тому популярні альтернативи:

• DPO — обходить reward model, вчиться на парах уподобань. Простіше, стабільніше, але менш гнучкий.
• GRPO — використовується в DeepSeek‑R1, хороший для reasoning tasks.
• ORPO — об'єднує SFT та alignment в одну стадію.

Бібліотека trl від Hugging Face — стандарт. Підтримує PPO, DPO, ORPO, GRPO з коробки, працює з PEFT/LoRA для memory‑efficient fine‑tuning.

Reward hacking залишається однією з головних причин провалів у RL, поряд з неправильно обраною архітектурою середовища. Це підтверджують дослідження з відкритих джерел (Reward hacking in reinforcement learning, Wikipedia).

Що входить в роботу

• Архітектурне рішення та обґрунтування вибору алгоритму
• Розробка та документування reward‑функції
• Створення симулятора або налаштування існуючого
• Навчання, hyper‑parameter sweep (Optuna / Ray Tune)
• Трансфер на реальне залізо або інтеграція в продукт
• Документація, доступи до коду та симуляторів
• Навчання команди та 3‑місячна підтримка після деплою

Процес роботи

1. Аудит завдання — фіксуємо цілі, ресурси, обмеження.
2. Reward engineering — формалізація бажаної поведінки, перевірка на reward hacking.
3. Вибір середовища та алгоритму — baseline, перші прогони.
4. Систематичний hyperparameter sweep — використовуємо Optuna.
5. Навчання в симуляторі з domain randomization.
6. Тестування на реальному обладнанні (за потреби).
7. Деплой, моніторинг, підтримка.

Терміни: proof of concept — 2–4 тижні; production‑система з sim‑to‑real — 3–8 місяців; RLHF для LLM — 4–10 тижнів. Вартість розраховується індивідуально — оцінимо ваш проєкт за 2 дні. Замовте консультацію, щоб уникнути типових пасток RL.

Наша команда — понад п’ять років досвіду в RL, 30+ успішних проєктів у роботиці, оптимізації ланцюгів постачання та LLM alignment. Гарантуємо прозору архітектуру та повну технічну документацію. Зв'яжіться з нами для отримання детальної оцінки вашого проєкту.