تخطَّ إلى المحتوى

drawtonomy مقابل كتابة OpenSCENARIO XML يدويًا

كتابة OpenSCENARIO XML يدويًا مسار عمل شائع، وهو الخيار الصحيح في حالات كثيرة.

الحالات التي تكون فيها كتابة XML يدويًا الأنسب:

  • سيناريو صغير تريد فيه تحكمًا كاملًا على مستوى البايت.
  • تُولِّد XML برمجيًا من DSL أو أنبوب توليد شيفرة.
  • تحتاج ميزات من المواصفة لا يُصدِّرها drawtonomy بعد — جولات المعاملات، والمتحكمات المخصصة أو المستندة إلى تعلم الآلة، ونماذج تدفق مروري كثيف، وOpenSCENARIO 1.3.
  • تبني شبكة طرق جديدة بتقاطعات من الصفر وتحتاج هندسة <junction> بجودة إنتاجية — تصدير التقاطعات في drawtonomy دقيق حين يُبقي على ملف .xodr مستورد دون تعديل، لكن توليد هندسة تقاطع جديدة من مسارات مرسومة يدويًا لا يزال منخفض الدقة.
  • تتعاون على كتالوج كبير عبر git وتهمك اختلافات XML الثابتة على مستوى البايت.

في هذه الحالات، تبقى الكتابة اليدوية أو المُولَّدة بالشيفرة المسار المرجعي. أما لتأليف سيناريو واحد ملموس وتشغيله — بأفعاله ومشغّلاته وحكم PASS / FAIL — فالمحرر المرئي عادةً أسرع.

ما يستطيع drawtonomy التعبير عنه اليوم

Section titled “ما يستطيع drawtonomy التعبير عنه اليوم”

محرر مرئي لـOpenSCENARIO 1.2 يؤلف لوحة قصة كاملة على اللوحة ويشغّلها في المتصفح — دون كتابة سطر XML واحد:

  • شبكة طرق ثنائية الأبعاد من الأعلى — مسارات وتقاطعات وخطوط — تُصدَّر بصيغة OpenDRIVE 1.8 .xodr، إلى جانب وضع المركبات والمشاة وإشارات المرور وعلامات الطرق ككيانات.
  • لوحة قصة كاملة: مراحل (فصول)، وأحداث، وكل أفعال المواصفة الخمسة والثلاثين (السرعة، تغيير المسار، النقل الفوري، اتباع مسار، تفعيل متحكم، وغيرها)، وكل شروط المشغّل التسعة عشر (بالإضافة إلى ستة متقدمة) مجمَّعة بمنطق AND / OR.
  • شروط END وFAIL التي تُصدِر حكم PASS / FAIL عند تشغيل السيناريو.
  • تشغيل داخل المتصفح على esmini مُصرَّف إلى WebAssembly — أدوات تحكم بالتشغيل، وتقديم دقيق باللقطة، وكاميرا متابعة، ومسارات شبح، ومعاينة ثلاثية الأبعاد اختيارية للتشغيل — فتراجع السيناريو الجاري دون مغادرة الصفحة. الملف .xosc نفسه يعمل دون تعديل في تثبيت esmini أصلي أيضًا.
  • تصدير إلى OpenSCENARIO 1.0 أو 1.1 أو 1.2 (1.3 غير متاح بعد)، إلى جانب بنى OpenDRIVE من نوع <junction>/<connection> وإشارات المرور كإدخالات <signal>.

ما لا يستطيع drawtonomy التعبير عنه بعد

Section titled “ما لا يستطيع drawtonomy التعبير عنه بعد”

الفجوات الحقيقية التي لا تزال تستدعي كتابة XML يدويًا أو مُولَّدًا:

  • تصدير OpenSCENARIO 1.3 — الصيغة مدعومة للاستيراد لكنها ليست بعد هدف تصدير متاحًا.
  • هندسة <junction> بجودة إنتاجية عند بناء شبكة طرق من الصفر. اتصال التقاطعات يُعاد إنتاجه بدقة عند الإبقاء على ملف .xodr مستورد دون تعديل، أما توليد هندسة تقاطع جديدة من مسارات مرسومة يدويًا فلا يزال منخفض الدقة، كما أن الهندسة التحليلية (clothoid) غير مُمثَّلة أصلًا.
  • جولات المعاملات، والمتحكمات المخصصة أو المستندة إلى تعلم الآلة، ونماذج تدفق مروري كثيف.
  • OpenSCENARIO 2.0 / M-SDL (drawtonomy يستهدف الفئة 1.x).

في هذه الحالات، تبقى الكتابة اليدوية أو المُولَّدة للـ XML المسار الصحيح.

في معظم السيناريوهات التي تؤلفها وتشغّلها بالكامل داخل drawtonomy، يبقى المتصفح هو المصدر الموثوق. الجأ إلى XML المكتوب يدويًا فقط عند الأطراف:

  1. ألِّف المشهد ولوحة القصة في drawtonomy — شبكة المسارات، والمشاركين، والأفعال، والمشغّلات، وشروط الإنهاء/الفشل — وشغّله للتحقق من الحكم.
  2. إذا احتجت ميزة من المواصفة لا يُصدِّرها drawtonomy (هندسة تقاطع، جولة معاملات، متحكم مخصص)، صدِّر ملف .xosc وعدِّل ذلك الجزء يدويًا أو بتوليد شيفرة.
  3. حين تحتاج اختلافات XML ثابتة على مستوى البايت عبر كتالوج كبير، أبقِ XML المرجعي في الشيفرة، واستخدم drawtonomy لتأليف السيناريوهات الملموسة الفردية ومراجعتها وإعادة تشغيلها.

drawtonomy هو المكان الذي تؤلف فيه السيناريو وتشغّله؛ XML المكتوب يدويًا يبقى منفذ الطوارئ لزوايا المواصفة التي لم يصلها drawtonomy بعد.

كتابة XML يدويًا هي المسار التأسيسي لتأليف OpenSCENARIO — فكل أداة أخرى في المنظومة تُنتج في النهاية هذا الـ XML (أو ما يعادله من DSL). مُصدِّر drawtonomy، وscenariogeneration، وScenic، وRoadRunner، وBlender DSC، وسواها، كلها تُصدِر هذا الـ XML عند نقطة ما. قراءة الـ XML وكتابته مباشرةً هي ما يُبقي المعيار “معيارًا”، والأدوات التي تُنتجه تستفيد من قابلية التشغيل البيني التي بناها المجتمع حوله.