דלגו לתוכן

drawtonomy מול כתיבת XML ידנית ל-OpenSCENARIO

כתיבת OpenSCENARIO XML בעבודת יד היא תהליך עבודה נפוץ, ולא מעט מקרים היא עדיין הבחירה הנכונה עבורם.

מתי XML הוא הנתיב המתאים:

  • התרחיש קטן ורוצים שליטה ברמת הביט.
  • מייצרים XML פרוגרמטית מ-DSL או מצינור codegen.
  • צריכים תכונות מפרט ש-drawtonomy עוד לא פולט — רוחב-פס פרמטרים (parameter sweeps), בקרים מותאמים אישית או מבוססי-ML, מודלים צפופים של זרימת תנועה, OpenSCENARIO 1.3.
  • בונים רשת כבישים חדשה עם צמתים מאפס וצריכים גיאומטריית <junction> ברמת ייצור — ייצוא הצמתים של drawtonomy מדויק כשמעבירים הלאה קובץ .xodr מיובא שלא נערך, אבל יצירת גיאומטריית צומת חדשה מנתיבים שרטוטים ביד עדיין פחות מדויקת.
  • עובדים בשיתוף פעולה על קטלוג גדול דרך git וחשוב לשמור diff יציב ברמת הביט.

במקרים האלה, XML כתוב ביד או מיוצר-קוד הוא הגישה הקנונית. אבל כשמדובר בכתיבה והרצה של תרחיש קונקרטי בודד — פעולות, טריגרים ופסיקת PASS / FAIL — עורך ויזואלי בדרך כלל מהיר יותר.

מה drawtonomy יודע לבטא כיום

Section titled “מה drawtonomy יודע לבטא כיום”

עורך ויזואלי ל-OpenSCENARIO 1.2 שכותב storyboard מלא על הקנבס ומריץ אותו בדפדפן — בלי להקליד שורת XML אחת:

  • רשת כבישים דו-ממדית ממבט-על — נתיבים, צמתים, קווי-מתאר — מיוצאת כ-OpenDRIVE 1.8 (.xodr), לצד מיקום רכבים, הולכי רגל, רמזורים וסימוני כביש כישויות.
  • storyboard מלא: שלבים (acts), אירועים, כל 35 הפעולות שבמפרט (מהירות, החלפת נתיב, טלפורט, מעקב-מסלול, הפעלת בקר ועוד), וכל 19 תנאי ההפעלה (בתוספת 6 מתקדמים) בצירוף לוגי AND / OR.
  • תנאי END ו-FAIL שמייצרים פסיקת PASS / FAIL כשהתרחיש רץ.
  • הרצה בדפדפן על esmini שקומפל ל-WebAssembly — פקדי הפעלה, קפיצה מדויקת לפריים, מצלמת מעקב, שובל-רוח (ghost trail), ותצוגה מקדימה תלת-ממדית אופציונלית של הריצה — כך שאפשר לסקור את התרחיש בלי לעזוב את הדף. גם ה-.xosc רץ ללא שינוי בהתקנת esmini רגילה.
  • ייצוא ל-OpenSCENARIO 1.0, 1.1 או 1.2 (1.3 עוד לא זמין), לצד פרימיטיבים של <junction>/<connection> ב-OpenDRIVE ותמרורים כרשומות <signal>.

הפערים האמיתיים שעדיין מצדיקים XML כתוב ביד או מיוצר:

  • ייצוא ל-OpenSCENARIO 1.3 — הפורמט נתמך בייבוא אך עדיין לא מוצע כיעד ייצוא.
  • גיאומטריית <junction> ברמת ייצור ב-OpenDRIVE כשבונים רשת כבישים מאפס. קישוריות הצמתים עוברת במדויק כשמעבירים הלאה קובץ .xodr מיובא שלא נערך; יצירת גיאומטריית צומת חדשה מנתיבים שרטוטים ביד עדיין פחות מדויקת, וגיאומטריית קלותואיד אנליטית לא ממודלת.
  • רוחב-פס פרמטרים, בקרים מותאמים אישית או מבוססי-ML, ומודלים צפופים של זרימת תנועה.
  • OpenSCENARIO 2.0 / M-SDL (drawtonomy מכוון ל-1.x).

עבור אלה, כתיבה או ייצור קוד של XML נשארים הנתיב הנכון.

עבור רוב התרחישים שכותבים ומריצים במלואם ב-drawtonomy — הדפדפן הוא מקור האמת. פנו ל-XML כתוב ביד רק בקצוות:

  1. כתבו את הסצנה וה-storyboard ב-drawtonomy — רשת נתיבים, משתתפים, פעולות, טריגרים, תנאי סיום/כישלון — והריצו כדי לאשר את הפסיקה.
  2. אם חסרה תכונת מפרט ש-drawtonomy לא פולט (פרימיטיב צומת, רוחב-פס פרמטרים, בקר מותאם אישית), ייצאו את ה-.xosc וערכו ביד או ייצרו-קוד רק לאותו חלק.
  3. כשחשוב diff יציב ברמת הביט על פני קטלוג גדול, שמרו את ה-XML הקנוני בקוד והשתמשו ב-drawtonomy לכתיבה, סקירה והרצה חוזרת של תרחישים קונקרטיים בודדים.

drawtonomy הוא המקום שבו כותבים ומריצים את התרחיש; XML כתוב ביד נשאר פתח המילוט לפינות המפרט שהוא עוד לא מגיע אליהן.

XML כתוב ביד הוא נתיב הכתיבה הבסיסי של OpenSCENARIO — כל כלי אחר באקוסיסטם בסופו של דבר מייצר אותו (או את המקבילה שלו ב-DSL). המייצא של drawtonomy, scenariogeneration, Scenic, RoadRunner, Blender DSC וכל השאר, כולם פולטים את ה-XML בשלב כלשהו. קריאה וכתיבה ישירה של ה-XML היא מה ששומר על התקן תקן, וכלים שמייצרים אותו נהנים מהאינטראופרביליות בין-כלית שהקהילה בנתה סביבו.