Матриця сумісності компонентів

Для стабільної лабораторної експлуатації необхідно фіксувати «базову конфігурацію» стенду (software + platform + firmware) і оновлювати її тільки через контрольований процес (див. 14.2).

Таблиця 14.1.1. Базові software-версії (за поточним станом репозиторіїв)

КомпонентПоточне значенняДжерело
codroid-ball-picker0.1.0codroid-ball-picker/pyproject.toml
codroid-api0.1.0codroid-api/pyproject.toml
onrobot-api0.1.0onrobot-api/pyproject.toml
Python runtime>=3.11pyproject.toml усіх трьох проєктів
depthai3.2.1codroid-ball-picker/pyproject.toml
Контейнер UI (base image)ubuntu:22.04codroid-ball-picker/Dockerfile

Таблиця 14.1.2. Platform/runtime сумісність для Jetson

Компонент платформиВимога / робочий діапазонПримітка
JetPack5.x або 6.xза деплой-інструкцією docs/deploy_jetson_docker.md
NVIDIA Container RuntimeОбов’язково встановленопотрібен для GPU-доступу в контейнері
Docker + Compose pluginОбов’язково встановленозапуск/оновлення контейнера через docker compose
Мережевий режим контейнераnetwork_mode: hostпотрібен прямий доступ до підмережі робота/грипера
UI endpointhttp://<jetson-ip>:8050контейнер запускається з --host 0.0.0.0 --port 8050

Таблиця 14.1.3. Інтеграційні адреси й протоколи (baseline)

ВузолЗначення за замовчуваннямПротокол
Robot controller host192.168.101.100WS
Robot WS port9000ws://…:9000/
User WS port9098ws://…:9098/
OnRobot Compute Box IP192.168.101.95XML-RPC / Socket.IO
OnRobot XML-RPC port41414http://…:41414/
OAK-D ProUSB-C (без IP)USB (DepthAI)

Таблиця 14.1.4. Firmware baseline (заповнюється на конкретному стенді)

КомпонентФактична версія на стендіДата перевіркиВідповідальний
Estun Robot Controller firmware(заповнюється)(заповнюється)(заповнюється)
OnRobot Compute Box firmware(заповнюється)(заповнюється)(заповнюється)

Принцип сумісності:

  1. Достатньою вважається конфігурація, що пройшла acceptance tests після оновлення (див. 10.12 та 14.2).
  2. Зміна будь-якого шару (контейнер, JetPack, firmware) без повторної перевірки сумісності не допускається.
  3. Для аудиту стенду потрібно зберігати журнал: дата зміни, що оновлено, хто виконав, результат acceptance tests.

Політика оновлення та відкату

Оновлення стенду виконується тільки в контрольованому вікні обслуговування, коли робот не перебуває в активному виробничому циклі.

Порядок штатного оновлення:

  1. Зафіксувати поточний стан: зберегти ID поточного контейнерного образу codroid-ui і створити резервну копію каталогу data/ (калібрування, workspace, drop target, налаштування).
  2. Перевести стенд у сервісний режим: зупинити активні програми в UI та переконатися, що робот у безпечному стані.
  3. Оновити контейнер: виконати docker compose pull ui, потім docker compose up -d –force-recreate ui.
  4. Переконатися, що контейнер працює: перевірити docker ps; контейнер codroid-ui має бути у стані running.
  5. Виконати післяоновлювальні acceptance tests (див. нижче).

Політика автооновлення:

  1. Якщо використовується systemd-таймер codroid-ball-picker-auto-update.timer, це має бути зафіксовано в журналі стенду.
  2. Після автоматичного оновлення також обов’язковий повний acceptance check перед роботою зі студентами.
  3. Якщо потрібен ручний контроль версій, автооновлення вимикають на період навчального циклу.

Порядок rollback (відкат):

  1. Умова для відкату: критична регресія (камера, робот, грипер, safety-логіка або UI), яку не усунуто оперативно.
  2. Відкотити контейнер до попереднього стабільного тегу/образу й перезапустити ui.
  3. За потреби відновити data/ з резервної копії (якщо змінились формати артефактів або дані пошкоджено).
  4. Повторно виконати acceptance tests і зафіксувати результат у журналі змін.

Мінімальний післяоновлювальний acceptance tests:

  1. UI доступний за http://<jetson-ip>:8050, сторінка завантажується без критичних помилок.
  2. OAK-D визначається, є стабільний RGB потік; depth-перевірка проходить у доступному режимі.
  3. Тест robot connection успішний; Acquire/Release robot control працює коректно.
  4. Тест gripper (OnRobot) успішний; Compute Box досяжний.
  5. Завантажуються збережені артефакти data/calibration_bundle.npz, data/workspace_definition.npz, data/robot_calibration.json.
  6. Виконано безпечний dry-run і мінімум один контрольний цикл pick -> drop без аварійних зупинок.