# الاستدلال عن بُعد

تتطلب السياسات الكبيرة وحدة معالجة رسومية (GPU)، ومع النشر المتزامن يتوقف الروبوت عن الحركة في كل مرة تحسب فيها السياسة شريحة أفعالها التالية. يقسم الاستدلال عن بُعد المهمة إلى جزأين: يعمل **خادم السياسة** على نقطة التفتيش (checkpoint) على وحدة معالجة رسومية، بينما يحتفظ **حاسوب الروبوت** بالتحكم في الكاميرات والمحركات والتشغيل عن بُعد والتسجيل. يستمر الروبوت في تنفيذ الأفعال التي لديه بالفعل بينما يحسب الخادم الأفعال التالية، فلا تتوقف الحركة بعد الآن من أجل الاستدلال.

استخدمه عندما:

- الحاسوب المتصل بالروبوت لا يحتوي على وحدة معالجة رسومية، أو تحتوي على وحدة معالجة رسومية صغيرة جدًا لتنفيذ السياسة: حاسوب محمول أو حاسوب لوحية واحدة بجانب الذراع، ومحطة عمل مجهزة بوحدة معالجة رسومية في الجهة المقابلة من المختبر؛
- يستغرق الاستدلال جزءًا ملحوظًا من كل مجموعة إجراءات، وتريد حركة مستمرة؛
- تريد أن تقرر مدى تكرار إعادة تخطيط الروبوت دون لمس نقطة الحفظ.

المفاضلة الوحيدة التي تضبطها هي **الطراوة مقابل الاستمرارية**. طلب خطة جديدة في وقت أبكر يتيح للروبوت الاستجابة لما يراه، بينما الالتزام بمزيد من الخطة الحالية يحافظ على تقدم المهمة.

## كيف يعمل

```mermaid
flowchart LR
  %% The server subgraph is declared first so that the layout keeps the robot computer on the left.
  subgraph server["Policy server (GPU)"]
    P["Policy checkpoint"]
  end
  subgraph robot["Robot computer"]
    direction TB
    B[("Action buffer")] -->|next action, every tick| R["Cameras and motors<br/>teleoperation, recording"]
  end
  R -->|observation + instruction| P
  P -.->|chunk of upcoming actions| B
```

يحافظ حاسوب الروبوت على مخزن مؤقت للإجراءات القادمة. عندما ينخفض مستوى المخزن، يرسل ملاحظة جديدة، ويستمر في الحركة من المخزن المؤقت بينما يقوم الخادم بالحساب، ثم يدمج الجزء الجديد في الجزء من الخطة الذي لم يُنفَّذ بعد.

```mermaid
sequenceDiagram
  participant R as Robot computer
  participant S as Policy server (GPU)
  Note over R: executing actions from the buffer
  Note over R: buffer runs low (refill threshold)
  R->>S: observation + instruction
  rect rgb(235, 245, 255)
    Note over R: keeps moving from the buffer
    S->>S: predict the next chunk
  end
  S-->>R: chunk of upcoming actions
  Note over R: new plan replaces the part of the buffer not yet executed
```

تحدد ثلاثة إعدادات للعميل هذا السلوك. يحدد `refill_seconds` مدى استباقية طلب الخطة التالية، ويحدد `chunk_merge` كيفية دمج الخطة الجديدة في الخطة القديمة، بينما يعمل المزج على تنعيم الحد الفاصل بينهما. لا يحتاج الخادم سوى إلى نقطة التفتيش ووصف للروبوت الذي تم تدريبه عليه. تبدأ الأقسام أدناه من إعداد عامل، ثم تبني الفهم الحدسي لكل إعداد.

**RTC المحلي** (`--inference.type=rtc`) هو الخيار غير المتزامن الآخر: يتم تنفيذ الاستدلال في خيط خلفية من عملية التمرير، على نفس الجهاز، دون خادم. أما الاستدلال عن بُعد على نفس المضيف فيستخدم ما يزال عمليتين و`--inference.type=remote`، ويقدم المحاذاة والدمج للسياسات التي لا تدعم RTC. راجع [كيف يرتبط RTC بالاستدلال عن بُعد](./rtc#how-rtc-relates-to-remote-inference).

### السياسات والروبوتات المدعومة

يمكن تقديم نقطة تفتيش عندما تتنبأ المعالجات المحفوظة بها بقطعة إجراء من ملاحظة حالية واحدة؛ ويتطلب ACT تعطيل الدمج الزمني. وقد شغلت نقاط التفتيش الخاصة بـ ACT وSmolVLA وXVLA وEVO1 وLaWAM روبوتات حقيقية عبر هذا المسار. كما تُدعم عدة سياسات أخرى على مستوى العقد، لكنها لم تُتحقق من صحتها على الأجهزة، وتحتاج السياسات المعتمدة على التاريخ إلى تكامل إضافي. ويحدد [جدول دعم السياسات](https://github.com/huggingface/lerobot/blob/main/src/lerobot/remote_inference/README.md#policy-support) حالة كل سياسة وقيودها.

يجب على سائق الروبوت أن يُعلن عن دعمه لخاصية تثبيت الموضع، لأن العميل يُحدّث الهدف المطبَّق الأخير أثناء انتظاره للأفعال. لذلك، تُعلن متابعات SO وOMX وKoch وHopeJr وRebot وYAM عن ذلك؛ وتعتمد أغلفة OpenArm وReachy2 والأغلفة ثنائية الذراع على إعداداتها؛ بينما يُعلن Unitree G1 عن ذلك فقط مع متحكم SONIC، حيث يكون الهدف المحفوظ هو رمز الحركة الأخير؛ ولا تفعل ذلك القواعد المتنقلة. راجع [جدول الأجهزة](./integrate_hardware#waiting-between-predictions). تُرفض عقود الروبوت أو السياسات غير المدعومة عند القبول، قبل أي حركة.

## ابدأ من عملية نشر (rollout) تعمل

احتفظ بأمر `lerobot-rollout` متزامن ناجح كمرجع، وأبقِ على إعدادات الروبوت والكاميرات والمهمة ومعدل الإطارات (FPS) ومشغّل البث عن بُعد (teleoperator) والاستيفاء (interpolation). تنتقل نقطة التفتيش (checkpoint) وجهاز النموذج إلى الخادم؛ ولا يقوم العميل عن بُعد بتحميل الأوزان.

تصف الأمثلة أدناه **SO-101 عامًا بستة محركات مع كاميرا أمامية واحدة**. عدّل نقطة التفتيش، وعروض الكاميرا، وترتيب المكونات، والوحدات معًا.

### 1. ثبّت على كلا الحاسوبين

تحتاج كلتا الجهتين إلى الإضافة `remote`. احتفظ بإضافات الأجهزة على العميل وإضافة السياسة المختارة على الخادم:

```bash
uv sync --locked --extra remote --extra core_scripts --extra feetech
# Add the policy extra on the server when required, for example --extra pi.
```

النطاق المدعوم من Zenoh هو `>=1.9.0,<1.11.0`؛ حيث يقوم `uv sync --locked` بتثبيت الإصدار المحدد في ملف القفل، وهو حالياً 1.10.1.

### 2. تكوين الخادم وبدئه

انسخ [التكوين العام](https://github.com/huggingface/lerobot/blob/main/examples/remote_inference/server.yaml)، ثم عدّله:

```bash
cp examples/remote_inference/server.yaml server.yaml
```

اضبط `model.repo_or_path` و`model.device`. بالنسبة إلى نقطة تحقق من Hub، ثبّت `model.revision` على الالتزام الذي تنوي التحقق منه. طابق `features` و`action_feature` و`semantics` و`robot_type` و`execution.action_fps` مع إعدادك التشغيلي؛ راجع [أمثلة المخطط وإعادة تسمية الكاميرات](#configuration-and-networking) أدناه.

```bash
uv run --no-sync lerobot-policy-server --config_path=server.yaml
```

تحمّل الخادم نقطة التفتيش، وتحقّق من إعلاناتها، ثم يشغّل عملية الإحماء، وبعد ذلك يسجّل `Policy server ready: deployment=<name> instance=<id>; awaiting one client`. تقبل كل حقل في ملف YAML تجاوزًا مضمّنًا عبر سطر الأوامر:

```bash
uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --model.device=cuda \
  --execution.idle_timeout_s=10
```

### 3. ابدأ عميل الروبوت

في طرفية أخرى، اضبط معاملات العتاد على نفس التهيئة:

```bash
uv run --no-sync lerobot-rollout \
  --inference.type=remote \
  --inference.endpoint=tcp/127.0.0.1:7447 \
  --inference.deployment=manipulation \
  --inference.mode=chunk \
  --inference.chunk_merge=aligned \
  --inference.semantics=so101-degrees-gripper-percent-v1 \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.use_degrees=true \
  --robot.cameras='{front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}' \
  --fps=30 \
  --task="pick up the cube" \
  --interactive=true
```

بعد القبول، اكتب `/start`. يُنهي الأمر `/stop` التشغيل؛ راجع [ما يفعله الروبوت أثناء الانتظار أو التوقف](#what-the-robot-does-while-waiting-or-stopping). احتفظ بخيارات التشغيل عن بُعد والتسجيل من عملية النشر التي تعمل بها. لا تمرّر `--policy.path` أو تجاوزات الجهاز المحلي للنموذج أو أعلام التجميع إلى العميل البعيد.

`deployment` يختار الخادم، و`semantics` يحدد وحدات الإجراء المعتمدة وترتيبها؛ ويجب أن يتطابق كلاهما مع إعدادات الخادم. يستخدم المثال درجات مفصل الجسم ونطاقًا مُعايرًا للقبضة يتراوح بين 0 و100.

استخدم شبكة LAN موثوقة بدلاً من localhost

اربط الخادم بواجهة الشبكة المحلية (LAN) الخاصة به، مع استبدال العنوان الموضح في المثال بعنوان IP الفعلي:

```bash
uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --zenoh.listen_endpoints='[tcp/172.18.133.214:7447]'
```

على العميل، استخدم العنوان نفسه: `--inference.endpoint=tcp/172.18.133.214:7447`. يجب أن تكون كلتا العُقدتين قادرتين على الوصول إلى تلك النقطة النهائية.

يحدّ ربط واجهة محددة من نطاق التعرّض، لكنه لا يوثّق الأطراف المتصلة. استخدم [اتصالات الموجّه الموثّقة](#configuration-and-networking) خارج شبكة المختبر الموثوقة.

## اختر كيفية مواصلة الحركة

بحلول الوقت الذي يصل فيه مقطع جديد، تكون الملاحظة التي حُسب منها قديمة بعض الشيء، وقد تحرّك الروبوت بالفعل. يحدد وضع الدمج ما يجب فعله حيال ذلك: تشغيل المقطع الجديد بعد القديم، أو حذف الخطوات التي تجاوزها الروبوت بالفعل، أو تنعيم نقطة الالتقاء.

| الاختيار               | إعدادات العميل                                          | نقطة بداية مفيدة                                                                                                     |
| -------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| إضافة               | `mode=chunk`, `chunk_merge=append`                       | الحفاظ على الشريحة الكاملة للتنفيذ المقبول؛ مفيد كخط أساس، لكن يمكن أن تبدأ الشريحة التالية من ملاحظة أقدم. |
| المواءمة            | `mode=chunk`، `chunk_merge=aligned` (الافتراضي `auto`) | إزالة الخطوات الواردة التي تم تجاوزها مسبقًا واستبدال المستقبل فقط، مما يقلل من الارتدادات الخلفية بين المقاطع المستقلة.     |
| المواءمة + الدمج | المواءمة بالإضافة إلى `blend_steps > 0` ومكونات صريحة | تداخل سلس بين الأهداف القديمة والجديدة بعد أن تعمل وتيرة التنفيذ وتقدم المهام بشكل صحيح.                                           |
| RTC                  | `mode=rtc_guided` أو `rtc_trained`                       | استخدمه عندما يدعم نقطة الحفظ (checkpoint) تقنية RTC: حيث تعتمد عملية الاستدلال (inference) نفسها على المسار المتبقي.                            |

تستخدم الإعدادات في هذه الجدول بادئة `--inference.`. تُضبط المقاطع العادية افتراضيًا على المحاذاة مع تعطيل الدمج. الهدف الذي يخضع بالفعل للاستيفاء يُثبَّت ولا يمكن استبداله.

تتجاهل المحاذاة الخطوات الواردة التي تم التأكيد عليها مسبقًا. يقوم المزج بمتوسط الأهداف المستقبلية المتداخلة. تضيف الاستيفاء أوامر حركة وسيطة بين النقاط النهائية. يغيّر RTC طريقة توليد التنبؤ. لا يضمن أيٌّ منها حركة سلسة أو قبضة ناجحة.

أضف مزيجًا قصيرًا إلى المثال

يتم تكوين الدمج بالكامل على جانب العميل؛ فلا يحتاج الخادم إلى أي إعدادات للدمج أو إعادة تشغيل. اختر إحداثيات الذراع المستمرة من أسماء الإجراءات الخاصة بالنشر:

```bash
--inference.chunk_merge=aligned \
--inference.blend_steps=5 \
--inference.blend_weight=0.5 \
--inference.blend_components='[shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos]'
```

هذه إعدادات للمقارنة، وليست توصية مُعدّلة. استبعد الماسك وغيرها من عناصر التحكم المنفصلة أو الحساسة للتلامس ما لم يتم التحقق منها. تستخدم المكونات غير المحددة الهدف الوارد.

تُحسب عملية الدمج كالتالي: `q_t + b_w * (i_t - q_t)`: حيث يمثل `q_t` الهدف المُدرج في قائمة الانتظار، و`i_t` الهدف الوارد لنفس الخانة المستقبلية، و`b_w` النسبة الواردة (`blend_weight`). تمنح القيمة 1 استبدالًا كاملًا. يحدد التداخل الفعلي نافذة الدمج؛ فلا يمكن لخطوات مهيأة بعدد عشرة أن تُنشئ عشر خطوات متداخلة. قد يؤدي الاستبدال المتكرر إلى دمج هدف غير مُثبَّت أكثر من مرة، مما يحافظ على التأثير الأقدم وعمره الأصلي. لا تُحدِّث عملية الدمج أبدًا البيانات المنتهية الصلاحية.

استضافة RTC الموجّه على نقطة تحقق متوافقة

احتفظ بالمخطط المُتحقَّق منه وقم بإعداد الخادم:

```bash
uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --execution.supported_modes='[rtc_guided]' \
  --execution.rtc.enabled=true \
  --execution.rtc.mode=guided \
  --execution.rtc.execution_horizon=15
```

على العميل، اضبط `--inference.mode=rtc_guided`. يستخدم RTC آلية خاصة به للتعامل مع الاستمرارية، وليس محاذاة أو مزج المقاطع العادية. أعد قياس زمن الاستجابة، لأن التوجيه يضيف عملاً إضافياً. أفق الخطوات الخمس عشرة مثال توضيحي وليس قيمة مُعدّلة.

يتطلب تدريب RTC نقطة تفتيش مُدرَّبة لتكييف بادئة الإجراء وإعدادات تأخير/أفق متوافقة؛ راجع [إعداد RTC](./rtc). يؤدي طلب وضع غير مدعوم إلى فشل العملية قبل الحركة.

## المعاملات ذات الأهمية

تستخدم خيارات العميل أدناه البادئة `--inference.` ما لم يُذكر خلاف ذلك. القيم الافتراضية هي قيم بداية وليست ضمانات لروبوت معين.

| معامل                    | افتراضي / وحدة                      | التأثير والتنازل                                                                                                      |
| ---------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `refill_seconds`             | `0.5` ثانية من وقت التشغيل المتبقي | تطلب القيم الأعلى عادةً طلباتٍ مبكرةً؛ بينما تسمح القيم الأدنى بتنفيذ المزيد من الخطة. يمكن لحدٍّ أدنى مُقاسٍ للزمن المستغرق أن يتجاوز ذلك.     |
| `blend_steps`                | `0` خطوات السياسة                    | تُعطّل القيمة صفر عملية الدمج. كلما كانت النوافذ أكبر، زاد مزج الأهداف المستقبلية المتداخلة.                                              |
| `blend_weight`               | `0.5` نسبة الدخل             | يحافظ الإعداد المنخفض على المزيد من الهدف القديم: تغييرات قد تكون ألطف، لكن تصحيحًا أبطأ.                                |
| `blend_components`           | `[]`                                | مجموعة فرعية صريحة من الإحداثيات المسموح بها على الخادم؛ مطلوبة عند تمكين الدمج.                                |
| `max_observation_age_s`      | `5.0` ثانية                       | أقصى عمر للمصدر الأصلي عبر التنفيذ، بما في ذلك المساهمون الأقدمون في الدمج. يجب أن يغطي الاستدلال والتشغيل. |
| `action_starvation_grace_s`  | `1.0` ثانية                       | انتظار محدود بعد نفاد التشغيل؛ `0` يُسبب عطلاً فورياً. لا يتجاوز المواعيد النهائية الأخرى.                         |
| `--fps`                      | مطابقة `action_fps` لخادم           | تكرار إجراء السياسة. بالنسبة إلى `N` إجراءات، يكون التشغيل الاسمي `N / fps` ثانية.                                         |
| `--interpolation_multiplier` | `1`                                 | أوامر حركية وسيطة أكثر؛ لا يمدد التشغيل ولا يضيف قرارات سياسة.                                      |

التعبئة الفعالة هي `max(refill_seconds, recent maximum turnaround + 1 / fps)`. يشمل زمن الدورة الترميز والشبكة والتصفية والاستدلال وفك الترميز. يوفر الطلب المقبول الأول تقديرًا مبدئيًا؛ بينما تستخدم التقديرات اللاحقة ما يصل إلى 100 عينة من حالة الاستقرار.

لذلك، لا يُمثّل Refill فترة طلب ثابتة ولا عددًا مضمونًا من الإجراءات المنفذة. افحص قيمة **Refill** المُعدّة والفعّالة في السجلات. يؤدي تحديد حدّ يغطي أفق التنفيذ بأكمله إلى استبدال متكرر للغاية.

مواعيد انتهاء المهام وامتلاك الخوادم

جميع القيم بالثواني.

| معامل العميل      | افتراضي | الحدود                                                     |
| --------------------- | ------- | ---------------------------------------------------------- |
| `handshake_timeout_s` | `10`    | الاكتشاف/القبول؛ الميزانية الأساسية لتبادلات التحكم     |
| `startup_timeout_s`   | `10`    | إجراء جديد يبدأ بعد الإقرار بإعادة الضبط/الإبطال |
| `action_timeout_s`    | `5`     | طلب إجراء واحد معلق                             |
| `language_timeout_s`  | `60`    | طلب نص واحد                                           |

يحتوي الخادم أيضًا على `execution.action_deadline_s=5` و`language.deadline_s=60`. تُطبَّق حدود العميل والخادم معًا؛ فالتغيير في أحدهما لا يُرخي الحد الآخر. كما تتيح عمليات تبادل التحكم في إعادة الضبط/الإبطال ميزانية عمل الخادم المُعلَن، لأنها يجب أن تنتظر خلف استدعاء نموذج قيد التشغيل.

يتحكم خادم `execution.idle_timeout_s=10` في التنظيف بعد **غياب العميل المُلاحظ**، وليس في مهلة انعدام الإجراءات. ينتظر التنظيف خلف عمل النموذج الجاري؛ ولا يمكن الاستيلاء على مكالمة متعثرة. يحتفظ العميل المتصل والموقوف بجلسته.

## ما يفعله الروبوت أثناء الانتظار أو التوقف

أثناء انتظار مدعوم، يقوم العميل بتحديث **آخر هدف تم تطبيقه فعليًا بواسطة المُشغِّل**، بما في ذلك الاستيفاء والقص والمقبض. قبل الأمر الأول، تُهيّئ وضعية مقاسة هذا الهدف. يؤدي ذلك إلى إيقاف تقدّم المسار؛ وقد يستمر الروبوت في الاستقرار نحو ذلك الهدف. لا يُطفئ هذا الوضع عزم الدوران ولا يضمن عدم الحركة. يستخدم RTC المحلي نفس الانتظار المحدود على الروبوتات المدعومة، ويُسجِّل عطلًا فوريًا عند استنفاد المهلة على غيرها.

| الوضع                                                           | السلوك المتوقع                                                                                                                          |
| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| الاستدلال الأولي                                                   | انتظر محليًا حتى تصل الإجراءات القابلة للاستخدام، ضمن المهلة الزمنية للإقلاع.                                                                     |
| تنتهي إجراءات التشغيل                                                     | أنهِ الاستيفاء المُلتزَم به، ثم احتفظ بالهدف حتى انتهاء مهلة السماح للجوع. استأنف فقط من ملاحظة وتنبؤ جديدين.  |
| `/vqa` أو استعلام التوجيه التلقائي                                        | إيقاف مؤقت قبل توليد النص؛ استئناف من إجراءات جديدة بعد ذلك إذا بقي التشغيل نشطًا. تنطبق حدود اللغة.                        |
| تغيير التعليمات أثناء الاستدلال                                 | تخلَّ عن التنبؤ القديم، وأوقف العملية، واحصل على إجراءات جديدة للتعليمات الجديدة. قد تحافظ التغييرات بين الطلبات على الحركة المقبولة. |
| تسجيل حفظ أو إيقاف المشغل                                    | احتفظ بالهدف، أو سلّم التحكم إلى التشغيل عن بُعد. تستأنف أعمال التسجيل المحجوز مع استدلال جديد عند الحاجة.                |
| المهلة النهائية، إجراء قديم، رد غير صحيح الصيغة أو انتهاء مهلة السماح للجوع | عطل في الطرفية: إلغاء حركة السياسة والالتزام بإيقاف التشغيل المُعدّ.                                                                       |
| `/stop` أو Ctrl+C العادي                                            | إنهاء حركة السياسة والالتزام بسلوك الإرجاع/القطع المُهيّأ.                                                                         |

تُفرّغ استعادة الجوع تنبؤًا قديمًا قيد التنفيذ وتُحصّل تنبؤًا جديدًا من لقطة أُخذت بعد بدء الانتظار. لا يمكن للنتائج القديمة إعادة بدء الحركة. لا تُجدِّد الحزم والنتائج غير القابلة للاستخدام فترة السماح. تشير الانتظارات المتكررة إلى عدم كفاية تغطية التشغيل أو الكمون.

**لا يتم استعادة فقدان الخادم أو الاتصال تلقائيًا.** قد تُستنفد الإجراءات المخزّنة مؤقتًا الصالحة، يليها الانتظار حتى انتهاء مهلة السماح أو مهلة أخرى. بمجرد ملاحظة فقدان حضور الخادم، لا يمكن استئناف تلك الجلسة عند عودة الاتصال؛ أعد تشغيل التمرير لجلسة جديدة. أثناء العمل على النصوص، يؤدي فقدان الخادم المرصود إلى تعطل الاستعلام.

مع جمع الملاحظات السليم وتحكم المُشغِّلات، يحترم إيقاف التشغيل النهائي الخيار `--return_to_initial_position=true` (الافتراضي)، ثم يفصل الاتصال. تتضمن عملية العودة قراءة ملاحظة كاملة، لذا قد تمنع الكاميرا المعطلة بشكل دائم هذه العملية. كما أن فشل الإجراء أو تطبيق الإمساك يوقف أي حركة إضافية. ضبط الخيار على `false` يتخطى عملية العودة، وليس فصل الاتصال. قد يؤدي فصل الاتصال إلى تحرير العزم وفقًا لتكوين الروبوت. تنتهي أخطاء التشغيل النهائي بحالة غير صفرية بعد التنظيف؛ ولا يمكن ضمان التنظيف في العملية التي تم إنهاءها قسريًا.

## ضبط مهمة واحدة تعمل

ابدأ بالقرب من المرجع المتزامن: نفّذ جزءًا كبيرًا من كل تنبؤ، لكن اطلب ذلك مبكرًا بما يكفي لإخفاء زمن استجابة الاستدلال. ثم قيّم ما إذا كان إعادة التخطيط بشكل أكثر تكرارًا يساعد.

1. **استخدم المحاذاة دون المزج أولاً.** حافظ على معدل الإطارات والتدبير والإعداد ثابتة. افحص أفق التنفيذ والوقت الكلي للدورة والطلبات البطيئة.
2. **اختر تغطية إعادة التعبئة بهامش أمان.** اترك وقت تشغيل كافٍ لطلب آخر وتباين زمن الاستجابة، دون استبدال الخطة بشكل مستمر.
3. **أضف مزيجًا قصيرًا عند ذلك الإيقاع.** قارن بين إكمال المهمة، والإمساك/الإفلات، والارتطامات بشكل منفصل. قد يؤدي متوسط سلس لخطط غير متوافقة إلى تفويت الهدف.
4. **اطلب في وقت مبكر فقط من أجل منفعة.** زيادة معدل إعادة التعبئة يمكن أن يحسّن الاستجابة، لكنه قد يقاطع تقدّمًا مفيدًا. عُد إلى الإيقاع المستقر إذا تدهورت أداء المهمة.
5. **غيّر إعدادًا واحدًا في كل مرة.** زيادة مهل الانتهاء أو فترة السماح لا توفر الإجراءات الناقصة. تقليل إعادة التعبئة ليس علاجًا شاملًا لاستنفاد الموارد.

لأفق تنفيذ مدته `0.8 s` ومحاذاة ناجحة مستقرة، يكون التباعد بين الطلبات تقريباً `0.8 - effective_refill`:

| إعادة تعبئة فعّالة | التباعد التقريبي | ما يجب مراقبته                                              |
| ---------------- | ------------------- | ---------------------------------------------------------- |
| `0.2 s`          | `0.6 s`             | متابعة أكثر، وحماية أقل من الطلبات البطيئة |
| `0.4 s`          | `0.4 s`             | كلما كان الاستبدال مبكرًا، زادت فرص التصحيح         |
| `0.6 s`          | `0.2 s`             | تغييرات متكررة؛ تحقق من تقدم المهمة                      |

يستثني هذا تأثيرات الإقلاع، والاحتفاظ، والتشبع، ودقات التحكم. طلب يبدأ مع `0.2 s` متبقية ويستغرق `0.1 s` لا يترك سوى `0.1 s` للدمج، أي ثلاث خطوات عند 30 هرتز. لذلك قد يحتاج الإيقاع شبه المتزامن إلى دمج قصير فقط.

لمواءمة RTC، تحقق من **مدة التشغيل المتاحة بعد القص**، وليس طول المقطع الاسمي. إذا استغرق الاستدلال ثانية واحدة من توقع مدته 1.67 ثانية، فإن ما يتبقى هو حوالي 0.67 ثانية فقط. لا يمكن استيعاب طلب آخر مدته ثانية واحدة؛ ولا قيمة إعادة تعبئة تُصلح ذلك. قلّل زمن الدوران، أو استخدم أفقًا مدعومًا أطول، أو تحقق من تردد إجراء مختلف.

يشمل عمر المصدر التنفيذ. فيما يتعلق بالإضافة، يُسمح تقريبًا بـ `execution horizon + effective refill` بالإضافة إلى هامش الالتقاط/الاستدلال. مقطع من 100 خطوة عند 30 هرتز يمتد بالفعل إلى 3.33 ثانية. عادةً ما يقلل المحاذاة من العمر، لكن الدمج المتكرر قد يحافظ على مساهمين أقدم.

## اقرأ السجلات وشخّص التشغيل

تُظهر سجلات INFO إعدادات القبول والإعدادات الفعلية، ونتائج طلبات النص، وانتقالات الانتظار/الإيقاف، وملخص نشاط كل خمس ثوانٍ تقريبًا. اقرأ زمن الاستجابة وتشغيل الطابور معًا. للتفاصيل، استخدم `--log_level=DEBUG` على الخادم و`--inference.log_level=DEBUG` على العميل. تُخفت جلسات التفاعلية سجلات العميل دون مستوى ERROR؛ استخدم تشغيلًا غير تفاعلي عند جمع سجلات التوقيت الحية.

عند حفظ السجلات، استخدم `2>&1 | tee -i server.log` (أو `client.log`). يحافظ `-i` على بقاء `tee` نشطًا عندما يصل Ctrl+C إلى خط الأنابيب بأكمله، مما يتيح له التقاط رسائل الإيقاف السليم أيضًا.

| ملاحظة                                | التحقق المفيد التالي                                                                                                      |
| ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| يسبب الإلحاق نتوءات عكسية               | قارن المحاذاة عند نفس الإعداد؛ فقد يبدأ المقطع الكامل التالي من ملاحظة أقدم.                          |
| تكون عملية المحاذاة سلسة لكن نجاح المهمة ينخفض | خفّض حدّ إعادة التعبئة ضمن هامش زمن الاستجابة لتقليل تكرار الاستبدال. اضبط الإيقاع قبل الدمج.                  |
| يبدو الدمج متردداً                  | قَصِّر نافذته أو زِد الوزن الوارد؛ قارِن دون خلط عند الإيقاع التشغيلي.                       |
| استنفاد الانتظار المتكرر / الإجراءات       | تحقق من بطء الاستجابة، والطلبات المفقودة أو المتوقفة، والتشغيل بعد التقليم. زد هامش الأمان فقط إذا سمح الأفق بذلك. |
| لا تفعل تغييرات إعادة التعبئة شيئاً                  | قد تهيمن حدّ الكمون المقاس؛ افحص إعادة التعبئة الفعلية.                                                     |
| عطل المصدر القديم                         | افحص أقدم مصدر من حيث العمر والأفق والدمج. الردود الجديدة لا تحدّث المساهمين القدامى.                          |
| `BUSY` بعد إعادة تشغيل العميل              | انتظر تنظيف العملاء الغائبين والعمل الجاري. لا تُجدِّد إعادة الاتصالات المرفوضة مهلة الملكية.                 |
| عدم تطابق العقد                          | قارن مخططات البيانات وأوضاع التشغيل وبيانات الوصفية لبرامج الإقلاع؛ أعد تشغيل العملية غير المتوافقة أو حدّثها.                      |

يتضمّن DEBUG إعادة تشغيل كل طلب عند الإرسال، وعمر الملاحظة، وتقدّم المؤشّر، بالإضافة إلى الخطوات المقصوصة/القابلة للاستخدام والتداخل لكل نتيجة. تصف هذه العناصر التقدّم المُمرَّر بالأوامر، وليس التنفيذ الفيزيائي المقاس.

## التكوين والشبكات

احتفظ بملف YAML واحد للنشر يجمع بين نقطة التفتيش ومخطط الروبوت وإعدادات الخادم؛ واستخدم تجاوزات سطر الأوامر المتداخلة للتجارب. امنح التجارب المستقلة أسماء نشر مختلفة. تسجّل كلتا العمليتين إصدارات الحزمة والبروتوكول؛ وتتحقق عملية القبول من البروتوكول وعقود التنفيذ/البيانات، دون اشتراط تطابق إصدارات الحزمة.

المخطط وأسماء الكاميرات ومتطلبات نقاط التفتيش

يتضمن [server.yaml](https://github.com/huggingface/lerobot/blob/main/examples/remote_inference/server.yaml) المُدار جميع الحقول المطلوبة. تُعلن `features` و`action_feature` عن الشكل ونوع البيانات والدلالات، كما تُعلن متجهات الحالة/الإجراء عن ترتيب المكونات. تُستخدم الصور بصيغة `uint8` بألوان RGB، بأبعاد الارتفاع × العرض × 3. على سبيل المثال:

```yaml
features:
  - name: observation.state
    shape: [6]
    dtype: float32
    names:
      [
        shoulder_pan.pos,
        shoulder_lift.pos,
        elbow_flex.pos,
        wrist_flex.pos,
        wrist_roll.pos,
        gripper.pos,
      ]
    semantics: so101-degrees-gripper-percent-v1
  - name: observation.images.front
    shape: [480, 640, 3]
    dtype: uint8
    kind: rgb
    semantics: rgb-front-table-v1
```

استخدم الأسماء الموجهة نحو نقطة التفتيش. لربط كاميرا الروبوت المسماة `scene` بمنظر `front` في نقطة التفتيش، اضبط `--rename_map='{"observation.images.scene":"observation.images.front"}'` للعميل. لا يمكن لإعادة التسمية تغيير المنظر أو الدقة أو المعايرة. يمكن أن تبقى الكاميرات الإضافية متاحة للتسجيل دون إرسالها إلى الخادم.

تستخدم السياسات المدعومة المعالجات المحفوظة والتنبؤ المباشر بالقطع من الملاحظة الحالية. تتطلب السياسات المعتمدة على التاريخ ومخرجات المتحكم الكامن والإعدادات المتاحة فقط عبر `select_action()` تكاملاً إضافياً. لا يُثبت الاستدلال المتزامن الناجح أو الإحماء وحده جودة المهمة عن بُعد أو دعم اللغة/RTC.

في حالة نقطة تفتيش مدعومة تعتمد على المقاطع فقط، يُقصّر الخادم `--execution.n_action_steps=30` شريحة التنفيذ الخاصة به دون الحاجة إلى تعديل نقطة التفتيش. ولا يمكن أن يتجاوز هذا الإعداد أفق التنبؤ، كما يُرفض في حالات النشر الخاصة بالتفاعل في الوقت الفعلي (RTC). أما الخيار الاختياري للعميل `--inference.expected_artifact=...` فيثبّت محتوى النموذج/المعالج وإعدادات الاستدلال الفعلية؛ فاسم النشر وحده لا يُعدّ هوية لنقطة التفتيش.

النشر المستقل وفقدان النطاق الترددي والاتصال

أقرن خادم `--deployment=arm-a` بعميل `--inference.deployment=arm-a`. يجب أن تكون الأسماء مقاطع أحادية تحتوي على أحرف وأرقام وعلامات شرطة سفلية ونقاط وشرطات فقط. لا يزال كل عملية خادم تخدم عميلاً نشطاً واحداً. إذا أعلنت عدة كائنات عن نفس الاسم، فاختر `--inference.instance=...` أو استخدم أسماء مميزة؛ فالاكتشاف لا يختار بشكل عشوائي.

تُحدَّد نطاقات الحركة تحت `lerobot/inference/v1/deployments/{deployment}`، ثم حسب خادم الحالة والجلسة. تتولى طلبات/ردود اكتشاف القبول والتحكم؛ بينما ينقل النشر/الاشتراك بيانات الاستدلال؛ وتتتبع الحيوية الحضور. تعطّل نقاط النهاية الصريحة اكتشاف البث المتعدد/الثرثرة. تحكّم هويات التسلسل/الجيل والتوقيت المحلي للعميل في الحركة؛ ولا حاجة إلى ساعات مضيف متزامنة.

الصيغة الخام RGB خالية من الفقد وهي الافتراضية. جرّب `--inference.encoding=jpeg --inference.jpeg_quality=90` لتقليل عرض النطاق الترددي للصور، ثم قارن زمن الاستجابة وجودة المهمة. تتراوح الجودة من 1 إلى 100؛ ولا يتم ترميز الموترات (tensors) العشوائية بصيغة JPEG أبدًا.

قد لا تكشف ميزة Liveliness عن انقطاع الاتصال إلا بعد انتهاء مدة إيجار النقل. يمكن لملف Zenoh JSON5 المُقدَّم عبر `--inference.zenoh_config_path` للعميل أو `--zenoh.config_file` للخادم تعديل `transport/link/tx/lease`. ولا يغيّر هذا الأمر مواعيد انتهاء المهل للإجراءات، أو مهلة السماح للجوع، أو تنظيف ملكية العميل الغائب. يؤدي الازدحام في المراقبة إلى إسقاط البيانات بدلاً من تعطيل إرسال الأوامر إلى المحركات.

إعادة `presence restored` للخادم تلغي تنظيف الملكية؛ ولا يمكنها إحياء عميل تعطل بالفعل. يؤدي فشل إعادة تعيين السياسة إلى جعل النشر غير متاح حتى لو ظلّت العملية حية؛ عالج الفشل وأعد تشغيلها.

اتصالات خاصة عبر موجّه مُوثّق

يوفر الموجّه نقطة التقاء قابلة للوصول لعمليات الروبوت ووحدات معالجة الرسوميات (GPU)، بما في ذلك عدة تجارب منفصلة. يضيف الموجّه زمن استجابة ونقطة فشل محتملة؛ ولا يوفر تجاوز الجدار الناري تلقائيًا، أو جدولة النماذج، أو استعادة الحركة. لا تُوثّق بروتوكولات TCP العارية ومعرفات الجلسات الأطراف المتصلة.

استخدم [إعدادات Zenoh](https://github.com/huggingface/lerobot/tree/main/examples/remote_inference/zenoh) المُصانة: `router.json5` و`server.json5` و`robot.json5`. تستخدم هذه الإعدادات TLS والتحقق المتبادل من الشهادات وتعطيل الاكتشاف وقوائم التحكم في الوصول القائمة على الأدوار. جهّز سلطة شهادة خاصة (CA) وشهادات منفصلة لكل من router وserver وrobot تحت المسارات المُحددة. يحتاج كل عملية إلى مفتاحها الخاص وشهادة CA فقط؛ احتفظ بمفتاح CA في مكان آخر. لنشر على شبكة محلية (LAN)، استبدل `localhost` بشكل متسق باسم مضيف router وأصدر شهادة تغطي ذلك الاسم.

```bash
zenohd --config examples/remote_inference/zenoh/router.json5

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --zenoh.mode=client \
  --zenoh.listen_endpoints='[]' \
  --zenoh.connect_endpoints='[tls/localhost:7447]' \
  --zenoh.config_file=examples/remote_inference/zenoh/server.json5
```

أضِف إلى أمر النشر العادي:

```bash
--inference.endpoint=tls/localhost:7447 \
--inference.zenoh_mode=client \
--inference.zenoh_config_path=examples/remote_inference/zenoh/robot.json5
```

غيّر مسارات نشر ACL مع اسم النشر. يستخدم جميع المشاركين وضع العميل دون روابط أقران مباشرة. يفصل المثال بين أدوار الروبوت والخادم، لكن مشاركة شهادات الأدوار تشارك الصلاحيات؛ استخدم هويات مصرّحًا بها منفصلة لمجموعات الثقة المختلفة. لا يمكن لقواعد ACL في الموجّه حماية عملية روبوت مُخترقة أو تنظيم حركة المرور المحلية الداخلية الخاصة بها. راجع وثائق [TLS](https://zenoh.io/docs/manual/tls/) و[ACL](https://zenoh.io/docs/manual/access-control/) الخاصة بـ Zenoh.

يجب أن تكون الإصدارتان المتوافقتان من الملف التنفيذي `zenohd` والربط بلغة بايثون. للتحقق من توافق الموجّه المثبت مع الربط المثبت، بما في ذلك فرض TLS وACL:

```bash
LEROBOT_ZENOHD=/absolute/path/to/zenohd \
  uv run --no-sync pytest tests/remote_inference/test_zenoh.py -q -rs
```

تتطلب الفحوصات أيضًا `openssl`؛ وتُبلَّغ المتطلبات غير المتوفرة كإجراءات تم تجاوزها. لم يتم التحقق بعد من تشغيل الروبوت عبر موجّه، أو وحدة معالجة رسومية خاصة مستضافة، أو مساحة Hugging Face. قِس الوقت الكلي للدورة وسلوك المقاطعة قبل تشغيل الروبوت عبر بنية جديدة؛ فالتوصيل العامل وحده لا يضمن ميزانية حركة قابلة للاستخدام.

## اللغة والتسجيل

استخدم `/vqa` و`/subtask` و`/autosteer` عبر [التنفيذ التفاعلي](./inference#interactive-sessions). فعّل خاصية `language.enabled=true` على الخادم فقط عند نقطة تحقق تدعم توليد النص؛ كما يتطلب توجيه `/autosteer` نقطة تحقق مدرّبة لتوليد المهام الفرعية مع ترميز متوافق للأهداف والمهام الفرعية. يعرض الخادم هذه الأوامر عندما تعلن نقطة التحقق عن هذه القدرة؛ أما مدى فائدة الإجابات والمهام الفرعية فيعتمد على نقطة التحقق.

توقف عمل النص يوقف الحركة ويتخلّى عن الاستمرار المخزّن مؤقتًا. أما VQA فيحافظ على تعليماتك ويستأنف بتنبؤ جديد، مما قد يؤدي إلى فقدان تقدّم المهمة لدى إعادة التخطيط، حتى بعد إجابة ناجحة. إبقاء الحركة المخزّنة مؤقتًا تعمل أثناء استعلام VQA معلوماتي مخطط له؛ راجع [الأعمال المستقبلية](https://github.com/huggingface/lerobot/blob/main/src/lerobot/remote_inference/README.md#13-future-work).

يعتمد التسجيل على صيغة مجموعة البيانات المحلية المعتادة. تتبع تسميات المهام الإجراء المُنفَّذ. تبقى التشخيصات في سجلات التطبيق؛ فهي لا تُكتب في مجموعة البيانات ولا تُرفع. عند استخدام مجموعة بيانات، استخدم `--dataset.single_task` للتعليمات الأولية؛ وإلا استخدم `--task`. يُفضَّل استخدام أحدهما لتجنب تعارض الإعدادات.

## استخدمه من بايثون

توجد المحركات المشتركة والإعدادات في `lerobot.inference`؛ بينما يوجد العميل البعيد والمحرك والخادم في `lerobot.remote_inference`. تربط حلقة تحكم خارج `lerobot-rollout` وتقبل عميلاً، ثم تغلفه في محرك، وتنشر اللقطات، وتُصدر كل نبضة محرك عبر `dispatch_tick`، التي تطبّق نفس عقد الإذن والاحتفاظ والتأكيد كما في واجهة سطر الأوامر:

```python
import time

import numpy as np

from lerobot.inference import RemoteInferenceConfig, dispatch_tick
from lerobot.remote_inference import RemoteClient, RemoteInferenceEngine
from lerobot.utils.action_interpolator import ActionInterpolator

config = RemoteInferenceConfig(
    endpoint="tcp/127.0.0.1:7447",
    deployment="manipulation",
    semantics="so101-degrees-gripper-percent-v1",
)
client = RemoteClient.connect(config)
caps = client.capabilities
client.admit(
    features=caps.features,
    action_feature=caps.action_feature,
    semantics=config.semantics,
    action_interval=caps.action_interval,
    mode=config.mode,
)
engine = RemoteInferenceEngine(client, config, task="pick up the cube")
interpolator = ActionInterpolator(multiplier=1)

engine.start()
engine.resume()
try:
    while running():
        captured = time.monotonic()
        engine.submit_observation(
            {"observation.state": state_vector(), "observation.images.front": front_rgb()},
            capture_time=captured,
        )
        # send() receives a torch tensor in the deployment's action order; hold() refreshes
        # the last applied target. Returns None when the tick was held or starved.
        dispatch_tick(engine, interpolator, send=robot_send, hold=robot_hold)
finally:
    engine.stop()  # revokes motion and closes the client
```

تُفهرس الملاحظات بأسماء الميزات الموجهة نحو نقاط التفتيش، ويجب أن تتطابق مع مخطط الخادم: متجهات `float32` بالترتيب المعلن للمكونات، وصور RGB من نوع `uint8` بالحجم المعلن. ينفّذ [`tests/remote_inference/test_library_client.py`](https://github.com/huggingface/lerobot/blob/main/tests/remote_inference/test_library_client.py) هذا المسار ضد خادم حلقة الارتداد (loopback)، وهو المرجع لتسلسل الاستدعاء. يضيف `lerobot-rollout` تحويل السائق، وفحوصات تثبيت الموضع، والأوامر التفاعلية، والتسجيل فوق ذلك؛ بينما `lerobot-policy-server` هو نقطة الدخول للتقديم، ويُهيأ فقط عبر تجاوزات YAML وواجهة سطر الأوامر الخاصة به.

الانتقال من lerobot[async]

استُبدل الإصدار الإضافي `lerobot[async]` المُتقاعس والأوامر `lerobot.async_inference` بـ `lerobot[remote]` و`lerobot-policy-server` و`lerobot-rollout --inference.type=remote`. لا يمكن استبدال عتبات حجم الدفعة القديمة وأوزان التجميع مع إعادة التعبئة والمحاذاة والدمج؛ أعد ضبطها من [المعاملات](#parameters-that-matter) المذكورة أعلاه.

تمت إزالة موقع الاستيراد القديم `lerobot.rollout.inference` لصالح `lerobot.inference` و`lerobot.remote_inference`. لا يوجد خيار `hold_mode`: يتطلب التنفيذ عن بُعد إعلان تثبيت الموضع من قبل السائق، والذي يتحقق منه التمرير تلقائيًا.

بالنسبة إلى Unitree G1 مع SONIC، اتبع [وصفة G1 عن بُعد](./unitree_g1#run-on-the-physical-robot) بدلاً من تكييف الأوامر القديمة؛ حيث تبقى متحكمات الحركة في G1 غير مدعومة.

لمعرفة البنية وعقود التنفيذ والتوسعات المخطط لها، راجع [مرجع التصميم الهندسي](https://github.com/huggingface/lerobot/blob/main/src/lerobot/remote_inference/README.md).