AI-система автономної гірничої техніки:розробка впровадження

Ми розробляємо AI-системи керування для автономної гірничодобувної техніки. Наші рішення інтегруються з промисловими платформами — Komatsu AHS, Caterpillar MineStar, Rio Tinto Mine of the Future — і працюють у production вже понад десять років. Autonomous haulage system ML та RL розширюють можливості: адаптація до змін рудника, оптимізація завантаження флоту та предиктивне обслуговування.

Наприклад, один із наших клієнтів — рудник із 40 самоскидами та 6 екскаваторами — після впровадження RL диспетчеризації скоротив простій екскаваторів з 15% до 5% (в 3 рази) та знизив витрати пального на 12%. Окупність рішення склала 8 місяців. Отримайте консультацію щодо впровадження AI-диспетчеризації на вашому руднику.

Як RL оптимізує диспетчеризацію флоту?

Класична задача: N вантажівок, M екскаваторів та K розвантажувальних пунктів. Потрібно мінімізувати простій екскаватора (чекає вантажівку), пробіг порожняком та черги на розвантаженні. Детермінований розклад не справляється з поломками та змінами плану — RL адаптується в real-time.

class MiningFleetEnv(gym.Env):
    def __init__(self, n_trucks, n_shovels, n_dumps):
        self.n_trucks = n_trucks
        self.n_shovels = n_shovels
        self.n_dumps = n_dumps

        # observation: статус кожного грузовика + екскаватора + черги
        obs_per_truck = 6   # position, load_status, fuel, ETA, queue_wait, is_broken
        obs_per_shovel = 4  # position, dig_rate, queue_length, availability
        obs_per_dump = 3    # position, throughput, queue_length

        self.observation_space = spaces.Box(
            low=0, high=np.inf,
            shape=(n_trucks * obs_per_truck +
                   n_shovels * obs_per_shovel +
                   n_dumps * obs_per_dump,))

        # action: призначити грузовик на точку (екскаватор або розвантаження)
        self.action_space = spaces.MultiDiscrete(
            [n_shovels + n_dumps] * n_trucks
        )

    def step(self, assignments):
        for truck_id, destination in enumerate(assignments):
            self.trucks[truck_id].assign_destination(destination)
        self._simulate_step()
        reward = -(self.shovel_idle_time +
                   0.5 * self.truck_idle_time +
                   0.3 * self.queue_wait_time)
        return self._get_obs(), reward, False, False, self._get_info()

Path Planning у складному рельєфі

Гірський рудник — динамічне середовище: вибухи створюють котловани, осипи блокують дороги, вологість змінює прохідність. HD-карта оновлюється після кожного вибуху (LiDAR survey → occupancy grid → перерахунок маршрутів). A* на зваженому графі з урахуванням нахилу забезпечує прохідність для навантажених вантажівок.

def mine_astar(start, goal, terrain_map, max_grade=10.0):
    def heuristic(a, b):
        return np.linalg.norm(np.array(a) - np.array(b))
    def slope_cost(current, neighbor):
        dz = terrain_map.elevation[neighbor] - terrain_map.elevation[current]
        dx = terrain_map.cell_size
        grade = abs(dz / dx) * 100
        if grade > max_grade:
            return float('inf')
        return 1.0 + grade * 0.1
    return a_star(start, goal, heuristic, slope_cost)

На складних ділянках RL контролер адаптує швидкість та гальмування — навчання в CARLA з кастомним terrain plugin дає кращі результати, ніж PID.

Як забезпечується safety в автономній техніці?

Safety-архітектура багаторівнева. Апаратний failsafe (ASIL-D) гарантує зупинку при втраті зв'язку. Virtual barriers через GNSS не дозволяють техніці покинути зону. Proximity detection зупиняє машину при виявленні людини в 20 метрах. RL policy працює тільки в advisory mode — оператор може взяти керування в будь-який момент.

Що дає предиктивне обслуговування гірничої техніки?

Позапланова поломка кар'єрного самоскида → простій 6–24 години, втрати перевищують $100K/год. LSTM на 45 датчиках передбачає відмову за 24 години з точністю 92%. Autoencoder детектує аномалії без labelled failure data — це критично, оскільки розмічених даних мало.

class TruckHealthPredictor(nn.Module):
    def __init__(self, n_sensors=45, hidden_dim=128):
        super().__init__()
        self.lstm = nn.LSTM(n_sensors, hidden_dim, 3, batch_first=True)
        self.head = nn.Sequential(
            nn.Linear(hidden_dim, 64), nn.ReLU(),
            nn.Linear(64, 1), nn.Sigmoid()
        )
    def forward(self, sensor_history):
        out, _ = self.lstm(sensor_history)
        return self.head(out[:, -1, :])
# деплой: threshold 0.7 → alert → планове ТО на наступній зміні

Порівняння підходів до диспетчеризації

Інтеграція з MES та Dispatch

Komatsu AHS API та Cat MineStar REST API — отримуємо статус флоту, передаємо команди. RL диспетчер працює як microservice. OSIsoft PI / Aspentech Historian зберігають телеметрію для навчання. Дані Loadrite та Wenco — для reward розрахунку (t/h виробітку).

Що входить в нашу роботу

• Аудит існуючої техніки та інфраструктури зв'язку (5G Private Network, LTE, mesh radio)
• Розробка RL policy для fleet management
• Інтеграція з AHS-платформою (Komatsu, Caterpillar) через REST API
• Предиктивне ТО з LSTM та autoencoder
• Safety-архітектура: апаратний failsafe, virtual barriers, proximity detection
• Тестування в симуляторі та пілот на 1–2 вантажівках
• Розгортання в production з моніторингом (Triton Inference Server, Prometheus)
• Навчання операторів та технічна підтримка

Чому варто обрати нас

Більше 5 років досвіду в промисловій робототехніці та AI. Реалізовано 12 проєктів для відкритих і підземних рудників. Сертифіковані інженери з безпеки (ASIL). Гарантуємо зниження простоїв флоту на 30–50% та окупність рішення протягом 6–12 місяців. Зв'яжіться з нами для оцінки проєкту.

Терміни: 24–48 тижнів

Fleet management RL поверх існуючого AHS — 12–16 тижнів. Предиктивне ТО з IoT інтеграцією — 16–20 тижнів. Повний цикл з path planning та safety-сертифікацією — 36–48 тижнів.

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