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

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

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

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

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

كيف يعمل

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

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

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

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

يمكن تقديم نقطة تفتيش عندما تتنبأ المعالجات المحفوظة بها بقطعة إجراء من ملاحظة حالية واحدة؛ ويتطلب ACT تعطيل الدمج الزمني. وقد شغّلت نقاط التفتيش الخاصة بـ ACT وSmolVLA وXVLA وEVO1 وLaWAM روبوتات حقيقية عبر هذا المسار. كما تُدعم عدة سياسات أخرى على مستوى العقد، لكنها لم تُتحقق من صحتها على الأجهزة، وتحتاج السياسات المعتمدة على التاريخ إلى تكامل إضافي. ويحدد جدول دعم السياسات حالة كل سياسة وقيودها.

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

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

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

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

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

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

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. تكوين الخادم وبدئه

انسخ التكوين العام، ثم عدّله:

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 مع إعدادك التشغيلي؛ راجع أمثلة المخطط وإعادة تسمية الكاميرات أدناه.

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

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

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

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

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

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 التشغيل؛ راجع ما يفعله الروبوت أثناء الانتظار أو التوقف. احتفظ بخيارات التشغيل عن بُعد والتسجيل من عملية النشر التي تعمل بها. لا تمرّر --policy.path أو تجاوزات الجهاز المحلي للنموذج أو أعلام التجميع إلى العميل البعيد.

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

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

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

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

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

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

--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]'

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. ما لم يُذكر خلاف ذلك. القيم الافتراضية هي قيم بداية وليست ضمانات لروبوت معين.

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

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

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

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

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

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

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

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

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

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

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

يستثني هذا تأثيرات الإقلاع، والاحتفاظ، والتشبع، ودقات التحكم. طلب يبدأ مع 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 إلى خط الأنابيب بأكمله، مما يتيح له التقاط رسائل الإيقاف السليم أيضًا.

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

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

احتفظ بملف 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

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

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

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

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

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

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

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

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

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

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 هذا المسار ضد خادم حلقة الارتداد (loopback)، وهو المرجع لتسلسل الاستدعاء. يضيف lerobot-rollout تحويل السائق، وفحوصات تثبيت الموضع، والأوامر التفاعلية، والتسجيل فوق ذلك؛ بينما lerobot-policy-server هو نقطة الدخول للتقديم، ويُهيأ فقط عبر تجاوزات YAML وواجهة سطر الأوامر الخاصة به.

لمعرفة البنية وعقود التنفيذ والتوسعات المخطط لها، راجع مرجع التصميم الهندسي.