Призначення і роль у нашому технологічному стеку

onrobot-api забезпечує пряме керування гріпером OnRobot через Compute Box і використовується як апаратно-орієнтований шар для:

  1. 2FG7 (основний сценарій pick-and-place),
  2. RG2,
  3. VGC10.

Для комірки Estun Codroid основний фокус — TWOFG (2FG7).

Транспортні інтерфейси

У коді реалізовані три канали взаємодії:

  1. XML-RPC (основний)
    • endpoint (кінцева URL-точка): http://<compute-box-ip>:41414/;
    • створюється в Device.getCB() через xmlrpc.client.ServerProxy.
  2. Резервний REST-канал (fallback) (точково)
    • використовується в set_finger_orientation() при відсутності XML-RPC методу;
    • endpoint: /api/dc/twofg/set_finger_orientation/{t_index}/{true|false}.
  3. Потік статусу Socket.IO (status stream)
    • OnRobotStatusClient підписується на повідомлення message і кешує останні дані (payload);
    • дозволяє читати device.variable без синхронного опитування (polling) XML-RPC.

Базові класи

  1. Device (onrobot/device.py)
    • зберігає IP Compute Box (Global_cbip);
    • повертає XML-RPC-проксі (getCB()).
  2. TWOFG (onrobot/twofg.py)
    • головний драйвер 2FG7;
    • має блокування потоку (thread-lock) для безпечних викликів _call_xmlrpc()/_call_rest();
    • вміє запускати потік статусу (status stream).
  3. OnRobotStatusClient (onrobot/status_client.py)
    • управляє Socket.IO підключенням;
    • надає latest_payload()/get_device_variable(…).
  4. GripperProfile (onrobot/gripper_profiles.py)
    • централізує обмеження force/speed/width і типові налаштування (default tuning).

Параметри профілю 2FG7 (фактичні межі з коду)

Для профілю twofg7 зафіксовано:

  1. force_min=20 N, force_max=140 N, force_default=20 N;
  2. speed_min=10 %, speed_max=100 %, speed_default=10 %;
  3. open_width_default=25 mm, close_width_default=5 mm;
  4. calibration_width=5 mm.

Ці обмеження використовуються для перевірок під час виконання (runtime) у TWOFG.grip().

Підключення і перевірка доступності

Базова послідовність:

  1. створити Device(<ip>);
  2. створити TWOFG(device);
  3. викликати isConnected(t_index=0).

isConnected() перевіряє cb_is_device_connected(…, TWOFG_ID=0xC0) і повертає:

  1. True — пристрій знайдено;
  2. False — недоступний/непідключений;
  3. вищі методи при відсутності підключення повертають CONN_ERR = -2.

Керування захватом: grip, move, stop

grip(…)

Метод виконує:

  1. перевірку підключення;
  2. читання min/max ширини (get_min_ext_width, get_max_ext_width);
  3. валідацію t_width, n_force, p_speed проти профілю;
  4. команду twofg_grip_external(t_index, width, force, speed);
  5. за f_wait=True:
    • очікує завершення busy-стану (до ~3 с, 30 циклів по 0.1 с),
    • потім очікує grip-detected (до ~2 с, 20 циклів по 0.1 с).

Повернення:

  1. RET_OK = 0 — успіх;
  2. RET_FAIL = -1 — тайм-аут (timeout)/невалідні параметри/інша помилка;
  3. CONN_ERR = -2 — немає підключення.

move(…)

move() також перевіряє ширину та викликає twofg_grip_external, але з фіксованими force=100, speed=80 (як у реалізації). Це важливо для розуміння, що move() у поточному коді не дає тонкого контролю сили/швидкості (force/speed).

stop(…)

stop() викликає twofg_stop(t_index) і зупиняє поточний рух пальців.

Зчитування стану 2FG7

TWOFG надає телеметрію:

  1. isBusy();
  2. isGripped();
  3. getStatus();
  4. get_ext_width();
  5. get_min_ext_width() / get_max_ext_width();
  6. get_force().

Коди статусу (з README):

  1. 0 — stable;
  2. -1 — error;
  3. -2 — connection failed.

Орієнтація пальців (inward/outward)

Реалізація підтримує:

  1. get_finger_orientation_label() -> “inward” або “outward”;
  2. set_finger_orientation(…):
    • приймає orientation як рядок/число/булеве значення (boolean),
    • нормалізує значення,
    • спочатку пробує XML-RPC (twofg_set_finger_orientation),
    • при невдачі пробує резервний REST endpoint (fallback).

Це робить поведінку стійкішою між різними версіями Compute Box API.

Потік статусу Socket.IO (status stream): коли і навіщо використовувати

Через start_status_stream() можна отримувати асинхронні оновлення змінних пристрою:

  1. OnRobotStatusClient.connect() відкриває канал до http://<cb_ip>;
  2. callback on_update дозволяє реактивно обробляти дані (payload);
  3. get_status_snapshot() повертає variable для product_code=0xC0.

Цей шлях зручний для UI та моніторингу, де важлива «остання відома» телеметрія без блокуючих XML-RPC-викликів.

Інтеграція з codroid-api у проєкті комірки

Важливо розрізняти два підходи:

  1. Прямий onrobot-api
    • пряме керування Compute Box (XML-RPC/Socket.IO),
    • повний доступ до телеметрії 2FG7.
  2. Через codroid-api (toolAction)
    • команди йдуть через контролер робота (Robot/Control/toolAction),
    • простіше інтегрувати в наявний конвеєр команд робота (robot command pipeline).

Практично в лабораторних сценаріях потрібно фіксувати один підхід на конкретну задачу, щоб уникати конфліктів керування інструментом.

Типові причини збоїв і первинна діагностика

  1. Невірний IP Compute Box -> isConnected=False, CONN_ERR.
  2. Неприпустима ширина/сила/швидкість -> RET_FAIL з повідомленням про діапазон.
  3. Busy/grip timeout -> перевірити механіку гріпера, заїдання, перешкоди, фактичні force/speed.
  4. Відсутній XML-RPC-метод орієнтації -> перевірити доступність REST fallback.
  5. Відсутні status updates -> перевірити мережу до Compute Box і роботу каналу Socket.IO.

Обмеження і рекомендації щодо експлуатації

  1. Частина реалізації повертає коди (-2/-1/0) замість винятків; у прикладному коді потрібно явно обробляти ці значення.
  2. Методи grip/move із f_wait=True блокують потік до завершення циклу очікування.
  3. Поточний move() використовує фіксовані force/speed; для контрольованого процесу захвату рекомендовано grip().
  4. Для складних сценаріїв (подвійні інструменти, специфічні поведінки прошивки firmware) використовуйте офіційну документацію OnRobot і документацію конкретної версії Compute Box API.

Обмеження прошивки (firmware) / Compute Box

Практичні обмеження інтеграції з Compute Box:

  1. Поведінка API залежить від ревізії прошивки (firmware): набір доступних методів може відрізнятися, частина команд може змінювати формат відповіді між версіями прошивки.
  2. XML-RPC і fallback: окремі можливості (наприклад, orientation/path) можуть бути недоступні як XML-RPC; у таких випадках застосунок використовує fallback-логіку (за підтримки конкретної версії API).
  3. Статус-канал: Socket.IO-телеметрія чутлива до мережевої стабільності; відсутність status updates не завжди означає відсутність XML-RPC-з’єднання.
  4. Політика для лабораторного стенду: використовувати зафіксовану «підтверджену» базову версію прошивки (firmware baseline); будь-яке оновлення прошивки Compute Box виконувати лише з повним regression/acceptance test.
  5. Документування: після зміни прошивки (firmware) обов’язково оновити матрицю сумісності (розділ 14.1) і зафіксувати всі відмінності поведінки у журналі експлуатації.