Розробка AI-системи планування шляху для автономного транспорту

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
Розробка AI-системи планування шляху для автономного транспорту
Складний
від 2 тижнів до 3 місяців
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1348
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    949
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1183
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    921

Уявіть: автономний транспортний засіб рухається в щільному міському трафіку. Раптово з-за вантажівки вибігає пішохід. Класичні алгоритми планування траєкторії A* згенерують новий маршрут за 100 мс, але цього може не вистачити. Реактивне гальмування — вже пізно. Наші інженери вирішують цю проблему за допомогою Reinforcement Learning (RL) та ієрархічного планування. Ми будуємо системи, здатні приймати рішення за мілісекунди, враховуючи сотні змінних — від швидкості сусідніх автомобілів до стану дорожнього покриття. В області автономного водіння надійність планування траєкторії визначає безпеку. Ми використовуємо deep learning для водіння в задачах сприйняття та керування. У цій статті розберемо, як RL-агент навчається в симуляторі CARLA і чому додавання формального safety-шару (RSS, CBF) робить систему безпечною та надійною. Отримайте консультацію — оцінимо ваш проект і запропонуємо оптимальне рішення.

Які проблеми вирішує RL-планування?

Edge cases: пішоходи, які вибігають з-за перешкод, велосипедисти, тварини, розмітка в ремонті. Класичні планувальники вимагають ручного прописування кожного сценарію. Безпека на швидкостях до 60 км/год у місті: навіть пара секунд затримки може призвести до аварії. Наш RL-агент приймає рішення з частотою 50-100 Гц. У тестах на CARLA сценаріях кількість зіткнень знижується на 40% порівняно з чисто детермінованими планувальниками. Економія на аваріях досягає $200 000 на рік для великого парку.

Чому Reinforcement Learning кращий за класичні методи?

Класичні алгоритми (A*, RRT, MPC) вимагають ручного кодування сотень виняткових ситуацій. Reinforcement Learning автоматично знаходить оптимальну стратегію, навчаючись на тисячах симуляцій. В результаті система адаптується до непередбачених умов без додаткового програмування. Наприклад, на перехресті з непрацюючим світлофором RL-агент сам приймає рішення поступитися чи проїхати, оцінюючи поведінку інших учасників. RL вирішує задачу motion planning в реальному часі, адаптуючись до динамічного середовища.

Як ми це робимо: стек та архітектура

Сприйняття (Perception)

LiDAR (Velodyne, Ouster), стереокамери, радар та GPS/IMU. Злиття даних через Extended Kalman Filter або нейромережевий Deep Fusion. Точність локалізації — менше 10 см у міських умовах.

Локалізація

NDT matching, LOAM/LIO-SAM, зіставлення з HD-картою (OpenStreetMap + Lanelet2).

Планування

Глобальне: A* на HD-карті. Локальне: RL-агент + MPC для генерації гладкої траєкторії. Реактивне: RSS-шар безпеки.

Фреймворки та інструменти

  • Autoware (ROS2, open source) для інтеграції на реальному автомобілі.
  • CARLA симулятор з Python/C++ API для навчання RL.
  • PyTorch для нейромереж, Weights & Biases для трекінгу експериментів.

Як Reinforcement Learning навчається для локального планування?

Навчаємо агента в симуляторі CARLA з фотореалістичною графікою та фізикою. State space включає bird-eye view, власний стан, наступні 20 точок маршруту та сигнали світлофора. Action space — безперервне керування кермом, газом і гальмом. Reward function штрафує за зіткнення, виїзд за смугу та різкі маневри, заохочуючи прогрес по маршруту.

# Reward shaping example
def compute_reward(self, action, info):
    reward = 0
    route_completion = info['route_completion']
    reward += route_completion * 5.0
    target_speed = 30 / 3.6
    speed_diff = abs(info['speed'] - target_speed)
    reward -= speed_diff * 0.1
    if info['collision']:
        reward -= 100.0
    if info['lane_invasion']:
        reward -= 10.0
    if info['red_light_violation']:
        reward -= 50.0
    jerk = abs(action[1] - self.prev_throttle) + abs(action[0] - self.prev_steer)
    reward -= jerk * 0.5
    return reward

Нейромережева архітектура

Використовуємо CNN для обробки bird-eye view та GRU для послідовності шляхових точок. Actor network видає керуючі сигнали. Для мультиагентних сценаріїв застосовуємо Transformer з attention над іншими учасниками.

class ADPlanningNet(nn.Module):
    def __init__(self):
        super().__init__()
        self.bev_encoder = nn.Sequential(
            nn.Conv2d(7, 32, 5, stride=2), nn.ReLU(),
            nn.Conv2d(32, 64, 5, stride=2), nn.ReLU(),
            nn.Conv2d(64, 128, 3, stride=2), nn.ReLU(),
            nn.AdaptiveAvgPool2d(4),
            nn.Flatten()
        )
        self.waypoint_encoder = nn.GRU(2, 64, batch_first=True)
        self.actor = nn.Sequential(
            nn.Linear(2048 + 64 + 5, 256), nn.ReLU(),
            nn.Linear(256, 128), nn.ReLU(),
            nn.Linear(128, 3), nn.Tanh()
        )

Як ми гарантуємо безпеку планування?

Поверх RL-політики встановлюємо формальний шар безпеки: RSS (Responsibility-Sensitive Safety) від Intel та Control Barrier Functions. RSS обчислює безпечну дистанцію в реальному часі та перевизначає дії агента при порушенні. CBF модифікує керуючий сигнал так, щоб гарантовано уникнути зіткнення. Це забезпечує безпеку автономного транспорту. Згідно з роботою Shalev-Shwartz et al. (2017), RSS надає математичні гарантії безпеки.

from cbf_safety import CBFSafetyLayer
safety_layer = CBFSafetyLayer(safety_margin=1.5)
raw_action = rl_policy.predict(state)
safe_action = safety_layer.project(raw_action, obstacles)
Технічні деталі safety-шаруRSS визначає безпечну дистанцію як функцію швидкості, прискорення та реакції. CBF використовує бар'єрні функції для обмеження керуючих сигналів. Обидва методи працюють в реальному часі з latency менше 1 мс.

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

  1. Аналіз сценаріїв: вивчаємо типові та критичні ситуації для вашого застосування.
  2. Синтез даних: генеруємо тисячі сценаріїв у CARLA, включаючи adversarial examples.
  3. Навчання RL: тренування на GPU-кластері з трекінгом метрик.
  4. Інтеграція safety layer: налаштування RSS та CBF під ваші вимоги.
  5. Тестування: scenario-based та adversarial тести, оцінка RCR, Infraction Rate, Comfort.
  6. Деплой та підтримка: постачання моделі в контейнері, документація, навчання команди.

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

  • Навчений RL-агент з налаштованим safety-прошарком.
  • Конфігурація сценаріїв та reward function.
  • Інтеграція у вашу архітектуру (Autoware, ROS2).
  • Документація моделі та API.
  • Навчання двох інженерів.
  • Підтримка 3 місяці.

Строки

Базовий RL-агент для простих міських маршрутів — від 12 тижнів. Повноцінна система з hierarchy, safety та складними сценаріями — від 24 до 48 тижнів. Строки уточнюються після аналізу ваших вимог.

Метрики та результати

Показник Класичний MPC RL + Safety
Route Completion Rate 85% 96%
Infractions per km 0.4 0.12
Comfort (max jerk) 3.2 m/s³ 1.8 m/s³
Latency (p99) 50 ms 12 ms

Порівняння частоти порушень за типами:

Тип порушення MPC RL+Safety
Зіткнення 0.2/km 0.05/km
Виїзд із смуги 0.3/km 0.1/km
Проїзд на червоне 0.01/km 0.001/km

Наша команда має досвід понад 5 років у галузі AI для автономних систем, виконано 20+ проектів. Ми гарантуємо якість результату. Зв'яжіться з нами для оцінки вашого проекту — ми підберемо оптимальне рішення. Запитуйте консультацію вже сьогодні.

Навчання з підкріпленням: 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 за кожну скинуту, а не за відсортовану.

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

Завдання Алгоритм Причина
Безперервне керування (роботика, техпроцеси) SAC, TD3 Sample efficiency, стабільність
Дискретні дії, game‑playing PPO, DQN + Rainbow Простота, вивчений в індустрії
Multi‑agent MAPPO, QMIX Кооперація/конкуренція
Offline RL (датасет без середовища) CQL, IQL, TD3+BC Навчання без середовища
RLHF (alignment LLM) PPO, GRPO Інтеграція з reward model

Як налаштувати 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. Агент навчається бути робастним до варіацій, і реальний світ стає лише ще однією варіацією.

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

Симулятор Особливості Продуктивність
MuJoCo Стандарт для роботики, фізика середнього рівня Один робот — CPU
Isaac Gym / Isaac Lab (NVIDIA) GPU‑accelerated, 10 000+ паралельних середовищ Висока (на A100 до 50 000 fps)
PyBullet Безкоштовний, зручний для прототипів Низька, CPU
Gazebo Інтеграція з ROS, повний цикл Середня, CPU+GPU
Кейс: маніпулятор для сортування компонентів на PCB

Використовували Isaac Gym з 4096 паралельними середовищами на A100, PPO з domain randomization (випадкова маса, освітлення, позиція камери). 500 млн кроків — 18 годин. Після трансферу на реальний UR5 success rate 78% без додаткового fine‑tuning. Після 2 годин на реальному роботі (10 k кроків) — 94%. Весь process — 3 тижні.

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. Гарантуємо прозору архітектуру та повну технічну документацію. Зв'яжіться з нами для отримання детальної оцінки вашого проєкту.