roadrunner-build-scenario-from-osc

Name: roadrunner-build-scenario-from-osc
Author: matlab

815stars105forks

How to install roadrunner-build-scenario-from-osc?

matlab/matlab-agentic-toolkit/roadrunner-build-scenario-from-osc

$npx -y skills add matlab/matlab-agentic-toolkit --skill roadrunner-build-scenario-from-osc

Installs into the current project.

Summary

Build a RoadRunner Scenario programmatically from an OpenSCENARIO 1.x (.xosc) file using the roadrunner-scenario-authoring skill. Use when the user wants to recreate a scenario from a .xosc file, interpret an OpenSCENARIO file and build it programmatically, reconstruct a .xosc

Files · 1

View on GitHub

SKILL.md

1	# Build RoadRunner Scenario from OpenSCENARIO
2
3	Interpret an OpenSCENARIO 1.x (.xosc) file and recreate the scenario in
4	RoadRunner using the `roadrunner-scenario-authoring` skill. Translates positions,
5	maps constructs, preserves relative references, and builds correct phase logic.
6
7	## When to Use
8
9	- User has a .xosc file and wants to recreate it in RoadRunner
10	- User wants to programmatically build a scenario from OpenSCENARIO
11	- User says "build this .xosc in RoadRunner" or "recreate this scenario"
12	- User has an OpenSCENARIO file from a partner or standards body (e.g., Euro NCAP, ALKS)
13	- User wants to generate a MATLAB script from a .xosc file
14	- User says "convert this xosc to matlab" or "recreate with a matlab script"
15
16	## When NOT to Use
17
18	- User says "import" a .xosc file — they want `importScenario(rrApp, xoscPath)`, not this skill. Simply call the API directly.
19	- User wants to use RoadRunner's built-in `importScenario` (let them — it works for simple cases)
20	- User wants to create a scenario from scratch without a .xosc file (use `roadrunner-scenario-authoring`)
21	- User wants to export a scenario TO OpenSCENARIO (use `roadrunner-export-scenario`)
22
23	## Critical Rules
24
25	1. Never fabricate actions or conditions not present in the source XOSC.
26	If a construct cannot be mapped, skip it and warn the user.
27
28	2. Never propose workarounds. Do not replace DistanceToPointCondition with
29	DurationCondition, do not substitute SimulationTimeCondition for unsupported
30	triggers, do not add any construct not in the source.
31
32	3. Never simplify or duplicate trajectory vertices. Extract exactly the
33	polyline vertices present in the source XOSC — no fewer, no more. Do not
34	reduce 90 vertices to 5. Do not duplicate start/end points during extraction.
35
36	4. Never guess scenes. Only report the .xodr filename from `<LogicFile>`.
37	Import it — do not search for a scene with a similar name.
38
39	5. Never convert relative references to absolute. If the source uses
40	`RelativeTargetSpeed delta=-8`, preserve it as `SpeedReference="actor"` with
41	`Direction="slower"`, `Speed=8`. Do not compute and hardcode `7 m/s`.
42
43	6. Never omit unsupported features silently. Always flag them explicitly in
44	the Scenario Description under "Unsupported Constructs."
45
46	7. Describe intent, not XOSC structure. Collapse placeholder Acts
47	(MW_WaitAction) into end conditions. Do not create phases for scaffolding
48	elements that have no meaningful actor actions.
49
50	## Workflow
51
52	This skill operates in two steps. Complete Step 1 first, present the description
53	to the user for review, then proceed to Step 2 only after approval.
54
55	---
56
57	### Step 1: Analyze the .xosc and Produce a Scenario Description
58
59	Parse the .xosc and its referenced .xodr following this strict logical order.
60
61	#### 1a. Validate the input
62
63	Read the .xosc XML. If the file is invalid XML, missing required elements, or
64	fails basic structural checks, stop and report the error. Do not guess or
65	assume missing data. If data is ambiguous, state the assumption explicitly.
66
67	#### 1b. Resolve parameters, expressions, and catalogs
68
69	Before interpreting any values, resolve all references:
70
71	- ParameterDeclarations / VariableDeclarations: Evaluate `${...}` expressions
72	to concrete numeric values. Process in declaration order (later params may
73	reference earlier ones).
74	- CatalogReferences: Read the referenced catalog XML file (from
75	`<CatalogLocations>`), find the entry by `catalogName` + `entryName`, extract
76	the vehicle/pedestrian definition (model3d path, category, bounding box).
77
78	```matlab
79	% Parameter expression resolution example
80	params.HostSpeed_kph = 80;
81	params.LeadTime_s = 6;
82	params.hostSpeed_ms = params.HostSpeed_kph / 3.6; % 22.2222
83	params.leadSpeed_ms = params.hostSpeed_ms * 0.5; % 11.1111
84	params.initSeparation = (params.hostSpeed_ms + params.leadSpeed_ms) * params.LeadTime_s; % 200
85	```
86
87	#### 1c. Describe the Init phase
88
89	For each actor's Private actions in `<Init>`:
90
91	1. TeleportAction — convert position to world [x, y, z]:
92	-

People who liked this also viewed

6 picks

Type

roadrunner-build-scenario-from-osc

815stars105forks

View on GitHub

How to install roadrunner-build-scenario-from-osc?

matlab/matlab-agentic-toolkit/roadrunner-build-scenario-from-osc

$npx -y skills add matlab/matlab-agentic-toolkit --skill roadrunner-build-scenario-from-osc

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Build RoadRunner Scenario from OpenSCENARIO
2
3	Interpret an OpenSCENARIO 1.x (.xosc) file and recreate the scenario in
4	RoadRunner using the `roadrunner-scenario-authoring` skill. Translates positions,
5	maps constructs, preserves relative references, and builds correct phase logic.
6
7	## When to Use
8
9	- User has a .xosc file and wants to recreate it in RoadRunner
10	- User wants to programmatically build a scenario from OpenSCENARIO
11	- User says "build this .xosc in RoadRunner" or "recreate this scenario"
12	- User has an OpenSCENARIO file from a partner or standards body (e.g., Euro NCAP, ALKS)
13	- User wants to generate a MATLAB script from a .xosc file
14	- User says "convert this xosc to matlab" or "recreate with a matlab script"
15
16	## When NOT to Use
17
18	- User says "import" a .xosc file — they want `importScenario(rrApp, xoscPath)`, not this skill. Simply call the API directly.
19	- User wants to use RoadRunner's built-in `importScenario` (let them — it works for simple cases)
20	- User wants to create a scenario from scratch without a .xosc file (use `roadrunner-scenario-authoring`)
21	- User wants to export a scenario TO OpenSCENARIO (use `roadrunner-export-scenario`)
22
23	## Critical Rules
24
25	1. Never fabricate actions or conditions not present in the source XOSC.
26	If a construct cannot be mapped, skip it and warn the user.
27
28	2. Never propose workarounds. Do not replace DistanceToPointCondition with
29	DurationCondition, do not substitute SimulationTimeCondition for unsupported
30	triggers, do not add any construct not in the source.
31
32	3. Never simplify or duplicate trajectory vertices. Extract exactly the
33	polyline vertices present in the source XOSC — no fewer, no more. Do not
34	reduce 90 vertices to 5. Do not duplicate start/end points during extraction.
35
36	4. Never guess scenes. Only report the .xodr filename from `<LogicFile>`.
37	Import it — do not search for a scene with a similar name.
38
39	5. Never convert relative references to absolute. If the source uses
40	`RelativeTargetSpeed delta=-8`, preserve it as `SpeedReference="actor"` with
41	`Direction="slower"`, `Speed=8`. Do not compute and hardcode `7 m/s`.
42
43	6. Never omit unsupported features silently. Always flag them explicitly in
44	the Scenario Description under "Unsupported Constructs."
45
46	7. Describe intent, not XOSC structure. Collapse placeholder Acts
47	(MW_WaitAction) into end conditions. Do not create phases for scaffolding
48	elements that have no meaningful actor actions.
49
50	## Workflow
51
52	This skill operates in two steps. Complete Step 1 first, present the description
53	to the user for review, then proceed to Step 2 only after approval.
54
55	---
56
57	### Step 1: Analyze the .xosc and Produce a Scenario Description
58
59	Parse the .xosc and its referenced .xodr following this strict logical order.
60
61	#### 1a. Validate the input
62
63	Read the .xosc XML. If the file is invalid XML, missing required elements, or
64	fails basic structural checks, stop and report the error. Do not guess or
65	assume missing data. If data is ambiguous, state the assumption explicitly.
66
67	#### 1b. Resolve parameters, expressions, and catalogs
68
69	Before interpreting any values, resolve all references:
70
71	- ParameterDeclarations / VariableDeclarations: Evaluate `${...}` expressions
72	to concrete numeric values. Process in declaration order (later params may
73	reference earlier ones).
74	- CatalogReferences: Read the referenced catalog XML file (from
75	`<CatalogLocations>`), find the entry by `catalogName` + `entryName`, extract
76	the vehicle/pedestrian definition (model3d path, category, bounding box).
77
78	```matlab
79	% Parameter expression resolution example
80	params.HostSpeed_kph = 80;
81	params.LeadTime_s = 6;
82	params.hostSpeed_ms = params.HostSpeed_kph / 3.6; % 22.2222
83	params.leadSpeed_ms = params.hostSpeed_ms * 0.5; % 11.1111
84	params.initSeparation = (params.hostSpeed_ms + params.leadSpeed_ms) * params.LeadTime_s; % 200
85	```
86
87	#### 1c. Describe the Init phase
88
89	For each actor's Private actions in `<Init>`:
90
91	1. TeleportAction — convert position to world [x, y, z]:
92	-

People who liked this also viewed

6 picks

Type