Generated banner for Roadrunner Rrhd Authoring
Generated logo for Roadrunner Rrhd Authoring

Roadrunner Rrhd Authoring

MathWorksOfficialCreated by MathWorks

  • Skill
  • Tool integration
  • Software development
  • BSD-2-Clause
  • No issues found

From the author

Build RoadRunner HD Map entities in MATLAB — lanes, boundaries, markings, junctions, signs, signals, barriers, parking. Use when creating driving scenes from scratch, authoring road networks for simulation and testing automated driving systems, or assembling RRHD maps from Lanelet2 or other HD map sources.
— the description by MathWorks

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The RoadRunner HD Map (RRHD) Authoring skill provides a structured, programmatic approach to constructing high-definition map data within MATLAB. It offers a comprehensive set of building blocks for defining lanes, boundaries, markings, junctions, and other road infrastructure. Designed for both synthetic scene creation and the assembly of maps from external formats like Lanelet2, this skill ensures geometric and topological consistency through mandatory validation gates and standardized construction patterns.

What it does

  • Provides a verified API reference for constructing roadrunner.hdmap.* objects.
  • Implements geometry algorithms for alignment detection, center line synthesis, and junction polygon creation.
  • Enforces spatial and topological integrity through mandatory validation checks before file export.
  • Supports the creation of complex road networks including lanes, barriers, signs, and parking entities.
  • Facilitates the conversion of external map data into the .rrhd format via standardized construction patterns.
  • Includes post-processing routines for boundary deduplication, height conflict resolution, and endpoint snapping.

When to use it

  • When building synthetic driving scenes or test roads from scratch in MATLAB.
  • When assembling RRHD maps from converted data sources like Lanelet2, OpenDRIVE, or custom formats.
  • When you need to ensure map data meets RoadRunner's strict geometric and alignment requirements.
  • When automating the generation of road networks for testing automated driving systems.

Advantages

  • Ensures compatibility with RoadRunner by enforcing strict API and geometry rules.
  • Reduces rendering errors like green-surface artifacts through robust alignment algorithms.
  • Provides reusable, format-agnostic patterns for consistent map construction.
  • Includes built-in validation gates to catch errors before file writing.

Usage examples

“How do I create a basic two-lane road in MATLAB using the RRHD API?”
The agent will provide a script that initializes a roadrunnerHDMap object, defines lane boundaries and lanes, assigns them with correct alignment, and performs the mandatory validation checks before writing the .rrhd file.
“My road boundaries are rendering as green grass. How do I fix this?”
The agent will guide you through the alignment verification process, specifically checking if your boundary alignment is set to 'Forward' or 'Backward' correctly relative to the lane direction, and suggest using the multi-sample spatial verification algorithm.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/matlab/roadrunner-rrhd-authoring/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip roadrunner-rrhd-authoring.zip -d .agents/skills

Documentation by MathWorks

RRHD Authoring Skill

Build RoadRunner HD Map (.rrhd) entities directly using the roadrunnerHDMap API in MATLAB. Provides the generic building blocks for constructing RRHD from any source — synthetic scenes, converted map data, or custom formats.

When to Use

  • Building RRHD maps from scratch (synthetic scenes, test roads)

  • Assembling RRHD entities from converted map data (Lanelet2, HERE, NDS, OpenDRIVE, custom formats)

  • Need reusable geometry algorithms: alignment detection, center line synthesis, junction polygons, endpoint snapping, closed-loop splitting

  • Adding lanes, boundaries, markings, junctions, signs, barriers, or parking to an HD Map

  • Need verified roadrunner.hdmap.* class/property reference and construction patterns

  • Debugging RRHD construction errors (wrong property names, alignment issues)

Role in Map Conversion Pipelines

This skill provides format-agnostic RRHD construction patterns that any converter skill invokes:

Reusable Building BlockReferenceUsed By
Alignment detection (Forward/Backward)alignmentRules.mdAny converter with shared/opposing boundaries
Center line synthesis (resample + average)synthesizeCenterLine.mdAny converter deriving lanes from boundary pairs
Junction polygon constructionjunctionPolygon.mdAny converter inferring junctions from topology
Closed-loop splittingsplitClosedGeometry.md, orthogonalSplit.mdAny converter handling circular/oval roads
Left-gap topology filterleftGapFilter.mdAny converter with node-matched topology
Endpoint snappingsnapEndpoints.mdAny converter with topology connections
Height conflict resolutionresolveHeights.mdAny converter with overlapping lanes
Boundary deduplicationdeduplicateBoundaries.mdAny converter with shared/opposing boundaries from source
RRHD object API patternsapiReference.mdAny code constructing roadrunner.hdmap.* objects
Enforcement gate (validation)validateMap.mdAny converter before write()

Skill Boundaries

This skill owns (format-agnostic RRHD construction):
ResponsibilityDescription
roadrunner.hdmap.* APIClass/property reference, constructor patterns, type rules
Geometry algorithmsAlignment, center line, resampling, orthogonal split, snapping
Junction polygonOuter boundary tracing, boundary(), convhull techniques
Validation/enforcementSpatial checks, alignment verification, geometry dimensions
Entity constructionLanes, boundaries, markings, junctions, barriers, signs, signals, parking
Import optionsroadrunnerHDMapImportOptions, build options, bridge detection
Converter skills own (source-format-specific):
ResponsibilityDescription
Source parsingXML/protobuf/JSON reading, node/way/relation extraction
Coordinate projectionlat/lon → ENU, map_projector_info.yaml, local_x/local_y
Topology extractionNode matching, opposing-direction filter, left-gap filter
Junction detectionBFS clustering from tags, fallback fan-in/fan-out, lane additions
Semantic mappingSource subtypes → RRHD LaneType, marking assets, sign codes
Discovery & completenessScan all elements, report unmapped, enforce nothing is dropped
Decision rule:
  • "How do I build this RRHD object?" → RRHD authoring skill

  • "How do I extract this from my source format?" → Converter skill

When NOT to Use

  • Converting Lanelet2 .osm files — use roadrunner-convert-lanelet2-to-rrhd (which invokes this skill)

  • Looking up asset paths for markings/signs/barriers — use roadrunner-asset-mapping

  • Importing finished .rrhd into RoadRunner — use roadrunner-import-scene

  • Editing an existing RoadRunner scene interactively (this skill writes .rrhd files, not scene edits)

Key Rules

  • Always write to .m files when executing code. Never put multi-line MATLAB code directly in evaluate_matlab_code. Write to a .m file, run with run_matlab_file, edit on error. Exception: if the user asks to "show the pattern" or says "do not execute", show code inline without writing files.

  • Read only the specific reference needed for the task — do not read all references upfront. Use apiReference.md for property lookups, other references only when directly relevant.

  • Only build what the user asked for. Do not add extra lanes, junctions, or objects unless explicitly requested.

  • rrMap = roadrunnerHDMap; must come first — loads the namespace before any roadrunner.hdmap.* usage.

  • Create-then-assign pattern — never pass constructor args (except RelativeAssetPath and AlignedReference).

  • Empty typed arrays — use ClassName.empty not [].

  • All geometry must be Nx3 — always include Z column (default 0 if flat).

  • Run enforcement gate before write() — alignment, spatial, and geometry checks are mandatory.

  • Track maps (closed-loop ovals/circuits): OMIT topology (no Predecessors/Successors), OMIT marking attributes (no ParametricAttribution), OMIT Z bumps. Use natural elevation only. See references/orthogonalSplit.md.

Critical API Rules

You MUST create a roadrunnerHDMap object before using any roadrunner.hdmap.* classes (lazy namespace loading):

rrMap = roadrunnerHDMap;  % REQUIRED — loads the namespace

Create-then-assign pattern — never pass constructor args (except Name=Value for two classes):

ref = roadrunner.hdmap.Reference;
ref.ID = "myID";  % assign after creation

Name=Value constructors — ONLY RelativeAssetPath and AlignedReference accept Name=Value:

rap = roadrunner.hdmap.RelativeAssetPath(AssetPath="Assets/Markings/StopLine.rrlms");
ar = roadrunner.hdmap.AlignedReference(Reference=ref, Alignment="Forward");
% WRONG: positional args error with "A name is expected"

Empty typed arrays — never use [] for typed properties:

lane.Predecessors = roadrunner.hdmap.AlignedReference.empty;  % CORRECT
lane.Predecessors = [];  % WRONG: "Value must be of type AlignedReference"

Verified Property Names (R2025a+)

See references/apiReference.md for the complete verified class/property table. Key gotchas:

Common MistakeCorrect
LeftBoundaryLeftLaneBoundary
RightBoundaryRightLaneBoundary
SpeedValue (int32)
Unit = "KPH"VelocityUnit = "Kph"
ParametricAttribParametricAttribution
pa.Value = mrpa.MarkingReference = mr
pa.StartFraction/EndFractionpa.Span = [0 1] (double array)
JunctionPhase / Phase (direct)Configurations (JunctionConfiguration array with nested .Phases)
roadrunnerHDMap("file.rrhd")rrMap = roadrunnerHDMap; read(rrMap, "file.rrhd")
Nx2 geometryNx3 geometry (always include Z column)
cm.CurveMarkingTypeIDcm.MarkingTypeReference
b.BarrierTypeIDb.BarrierTypeReference
s.SignTypeIDs.SignTypeReference
s.BoundingBoxs.Geometry (takes GeoOrientedBoundingBox)
bb.Positionbb.Center (1x3 double)
bb.Orientationbb.GeoOrientation ([h,p,r] double array)
pg.OuterRingpg.ExteriorRing (Nx3 double)
bt.AssetPathbt.ExtrusionPath (for BarrierType only)
roadrunner.hdmap.GeoOrientationNOT a class — use [h,p,r] double array directly
Lane.Predecessors = []Lane.Predecessors = roadrunner.hdmap.AlignedReference.empty
lb.ParametricAttributes = []Cannot clear — skip assignment for no markings
RelativeAssetPath("path")RelativeAssetPath(AssetPath="path") — Name=Value required
AlignedReference(ref, "Fwd")AlignedReference(Reference=ref, Alignment="Forward")
Junction.Geometry = polygonJunction.Geometry = multiPolygon (wrap in MultiPolygon)
MarkingReference.MarkingID = 5MarkingReference.MarkingID = ref (Reference object, NOT numeric)
SpeedLimit.VelocitySpeedLimit.Value (int32) + .VelocityUnit = "Kph"

Synthetic Scene Construction

Lane Width and Geometry

Standard lane width: 3.7m (US highway). Compute boundary positions by offsetting perpendicular to the lane center line direction.

Shared Boundaries Between Adjacent Lanes

Adjacent lanes MUST share boundary geometry. The right boundary of lane N is the same object as the left boundary of lane N+1. For N lanes, create N+1 boundaries.

  LB_0 (left edge)
  ───────────────────
  │    Lane_1        │  left=LB_0(Fwd), right=LB_1(Fwd)
  ───────────────────
  LB_1 (shared)
  ───────────────────
  │    Lane_2        │  left=LB_1(Fwd), right=LB_2(Fwd)
  ───────────────────
  LB_2 (right edge)
Alignment Rules

See references/alignmentRules.md for complete rules, diagrams, and green-surface debugging.

Alignment specifies how boundary geometry direction relates to lane geometry direction:

  • Same direction → "Forward"

  • Opposite direction → "Backward"

Which algorithm to use:

  • Map conversion (left/right known from source, e.g., Lanelet2 roles) → dp-based approach below

  • Synthetic scenes (left/right must be determined from geometry) → Multi-sample spatial verification in references/alignmentRules.md

Dp-based algorithm (for conversion — left/right already known):

lDir = leftPts(end,:) - leftPts(1,:);
rDir = rightPts(end,:) - rightPts(1,:);
dp = dot(lDir(1:2)/(norm(lDir(1:2))+1e-10), rDir(1:2)/(norm(rDir(1:2))+1e-10));

if dp >= -0.3
    % Normal: both boundaries go same direction
    leftAlign = "Forward"; rightAlign = "Forward";
else
    % Opposing boundaries: use proximity to determine which is backward
    d_ls_re = norm(leftPts(1,1:2) - rightPts(end,1:2));
    d_ls_rs = norm(leftPts(1,1:2) - rightPts(1,1:2));
    if d_ls_re < d_ls_rs
        leftAlign = "Forward"; rightAlign = "Backward";
    else
        leftAlign = "Backward"; rightAlign = "Forward";
    end
end

The -0.3 threshold (not 0) handles lanes with slight boundary curvature that produce small negative dot products but are NOT truly opposing.

Left/Right spatial verification (for synthetic scenes where left/right must be verified):

nSamples = min(5, size(centerGeom,1)-1);
sampleIdx = round(linspace(2, size(centerGeom,1)-1, nSamples));
leftOnLeft = 0;
for si = 1:numel(sampleIdx)
    idx = sampleIdx(si);
    localTan = centerGeom(min(idx+1,end),1:2) - centerGeom(max(idx-1,1),1:2);
    localTan = localTan / norm(localTan);
    localLeftN = [-localTan(2), localTan(1)];
    distsL = vecnorm(leftBndGeom(:,1:2) - centerGeom(idx,1:2), 2, 2);
    [~, closestL] = min(distsL);
    toBndL = leftBndGeom(closestL,1:2) - centerGeom(idx,1:2);
    if dot(toBndL, localLeftN) > 0, leftOnLeft = leftOnLeft + 1; end
end
assert(leftOnLeft >= numel(sampleIdx)/2, ...
    'Left boundary is spatially on the RIGHT — swap boundaries or fix assignment');

Wrong alignment or swapped left/right causes green grass instead of road surface.

Standard Marking Assets
Marking IDAsset Path
SolidSingleWhiteAssets/Markings/SolidSingleWhite.rrlms
DashedSingleWhiteAssets/Markings/DashedSingleWhite.rrlms
SolidDoubleYellowAssets/Markings/SolidDoubleYellow.rrlms
DashedSolidYellowAssets/Markings/DashedSolidYellow.rrlms
SolidDashedYellowAssets/Markings/SolidDashedYellow.rrlms
Multi-Lane Road Recipe
  1. Compute N lane center lines (evenly spaced at laneWidth intervals)

  2. Compute N+1 boundary lines (edges + between each lane pair)

  3. Assign shared boundaries — same-direction: lane i uses left=LB_(i-1), right=LB_i. Opposing-traffic lanes: swap left/right (driver's left is toward the road edge, not the center)

  4. Detect alignment via dot product (boundaries going same direction as lane → Forward, opposite → Backward)

  5. Apply markings (edges: SolidSingleWhite, divider: SolidDoubleYellow, separators: DashedSingleWhite)

  6. Wire topology (if multiple segments, connect with pred/succ)

  7. Assemble map and write

Additional steps for converted maps only (skip for synthetic scenes):

Complete 2-Lane Road Example
rrMap = roadrunnerHDMap;
w = 3.7;

% Lane Markings
lm1 = roadrunner.hdmap.LaneMarking; lm1.ID = "SolidWhite";
rap1 = roadrunner.hdmap.RelativeAssetPath; rap1.AssetPath = "Assets/Markings/SolidSingleWhite.rrlms";
lm1.AssetPath = rap1;
lm2 = roadrunner.hdmap.LaneMarking; lm2.ID = "DashedWhite";
rap2 = roadrunner.hdmap.RelativeAssetPath; rap2.AssetPath = "Assets/Markings/DashedSingleWhite.rrlms";
lm2.AssetPath = rap2;

% Boundaries (3 for 2 lanes)
lb = roadrunner.hdmap.LaneBoundary;
lb(2) = roadrunner.hdmap.LaneBoundary;
lb(3) = roadrunner.hdmap.LaneBoundary;
lb(1).ID = "LB_0"; lb(1).Geometry = [0 w 0; 100 w 0];
lb(2).ID = "LB_1"; lb(2).Geometry = [0 0 0; 100 0 0];
lb(3).ID = "LB_2"; lb(3).Geometry = [0 -w 0; 100 -w 0];

% Markings on boundaries
for i = [1 3]  % solid on edges
    pa = roadrunner.hdmap.ParametricAttribution; pa.Span = [0 1];
    ref = roadrunner.hdmap.Reference; ref.ID = "SolidWhite";
    mr = roadrunner.hdmap.MarkingReference; mr.MarkingID = ref; mr.FlipLaterally = false;
    pa.MarkingReference = mr;
    lb(i).ParametricAttributes = pa;
end
pa = roadrunner.hdmap.ParametricAttribution; pa.Span = [0 1];
ref = roadrunner.hdmap.Reference; ref.ID = "DashedWhite";
mr = roadrunner.hdmap.MarkingReference; mr.MarkingID = ref; mr.FlipLaterally = false;
pa.MarkingReference = mr;
lb(2).ParametricAttributes = pa;

% Lanes
ln = roadrunner.hdmap.Lane;
ln(2) = roadrunner.hdmap.Lane;
ln(1).ID = "Lane_1"; ln(1).Geometry = [0 w/2 0; 100 w/2 0];
ln(1).TravelDirection = "Forward"; ln(1).LaneType = "Driving";
ln(2).ID = "Lane_2"; ln(2).Geometry = [0 -w/2 0; 100 -w/2 0];
ln(2).TravelDirection = "Forward"; ln(2).LaneType = "Driving";

% Assign boundaries with alignment
bndIDs = ["LB_0","LB_1","LB_2"];
for i = 1:2
    arL = roadrunner.hdmap.AlignedReference;
    refL = roadrunner.hdmap.Reference; refL.ID = bndIDs(i);
    arL.Reference = refL; arL.Alignment = "Forward";
    ln(i).LeftLaneBoundary = arL;

    arR = roadrunner.hdmap.AlignedReference;
    refR = roadrunner.hdmap.Reference; refR.ID = bndIDs(i+1);
    arR.Reference = refR; arR.Alignment = "Forward";
    ln(i).RightLaneBoundary = arR;
end

% Assemble and write
rrMap.Lanes = ln;
rrMap.LaneBoundaries = lb;
rrMap.LaneMarkings = [lm1 lm2];
write(rrMap, "two_lane_road.rrhd");

Enforcement Gate (MANDATORY before write())

Run this validation block before writing any multi-lane map. Do NOT skip. If any check FAILS, fix the issue (run the appropriate post-processing step) before proceeding to write().

%% --- ENFORCEMENT: Topology — no excessive connections (left-gap filter applied) ---
lanes = rrMap.Lanes;
nExcessiveJunc = 0;
for i = 1:numel(lanes)
    nConn = numel(lanes(i).Predecessors) + numel(lanes(i).Successors);
    if nConn > 4  % junction lanes should have at most ~4 (multi-lane merge/diverge)
        nExcessiveJunc = nExcessiveJunc + 1;
    end
end
if nExcessiveJunc > 0
    warning('TOPOLOGY WARNING: %d lanes have >4 connections — run left-gap filter (references/leftGapFilter.md)', nExcessiveJunc);
end
fprintf('Topology check: %d lanes with >4 connections\n', nExcessiveJunc);

%% --- ENFORCEMENT: Alignment computed (not all Forward) ---
if numel(lanes) > 2
    nFwd = 0; nBwd = 0;
    for i = 1:numel(lanes)
        if lanes(i).LeftLaneBoundary.Alignment == "Forward", nFwd = nFwd+1;
        else, nBwd = nBwd+1; end
        if lanes(i).RightLaneBoundary.Alignment == "Forward", nFwd = nFwd+1;
        else, nBwd = nBwd+1; end
    end
    assert(nBwd > 0 || numel(lanes) <= 2, ...
        'ALIGNMENT ERROR: All boundaries Forward for %d lanes — compute dot product per lane.', numel(lanes));
    fprintf('Alignment: %d Forward, %d Backward — OK\n', nFwd, nBwd);
end

%% --- ENFORCEMENT: Left boundary spatially on left ---
bnds = rrMap.LaneBoundaries;
bndMap = containers.Map;
for i = 1:numel(bnds), bndMap(bnds(i).ID) = bnds(i).Geometry; end
nBadSide = 0;
for i = 1:numel(lanes)
    lGeom = lanes(i).Geometry;
    lDir = lGeom(end,1:2) - lGeom(1,1:2);
    lDir = lDir / norm(lDir);
    leftN = [-lDir(2), lDir(1)];
    leftBndID = lanes(i).LeftLaneBoundary.Reference.ID;
    if bndMap.isKey(leftBndID)
        leftBndGeom = bndMap(leftBndID);
        toBnd = mean(leftBndGeom(:,1:2)) - mean(lGeom(:,1:2));
        if dot(toBnd, leftN) < 0, nBadSide = nBadSide + 1; end
    end
end
assert(nBadSide == 0, ...
    'SPATIAL ERROR: %d lanes have left boundary on wrong side — fix alignment algorithm.', nBadSide);
fprintf('Spatial left-side check: PASS\n');

%% --- ENFORCEMENT: Geometry is Nx3 ---
bnds = rrMap.LaneBoundaries;
for i = 1:numel(bnds)
    assert(size(bnds(i).Geometry, 2) == 3, ...
        'Boundary %s geometry must be Nx3 (got Nx%d)', bnds(i).ID, size(bnds(i).Geometry,2));
end
fprintf('Geometry dimensions: PASS\n');

%% --- ENFORCEMENT: GeoReference set ---
assert(any(rrMap.GeoReference ~= 0), 'GeoReference is [0,0] — set lat/lon origin');
fprintf('GeoReference: PASS\n');

%% --- ENFORCEMENT: No duplicate boundaries (deduplication applied) ---
bnds = rrMap.LaneBoundaries;
nDupBnd = 0;
for i = 1:numel(bnds)
    for j = i+1:numel(bnds)
        g1 = bnds(i).Geometry; g2 = bnds(j).Geometry;
        if size(g1,1) ~= size(g2,1), continue; end
        if max(vecnorm(g1 - flipud(g2), 2, 2)) < 0.001
            nDupBnd = nDupBnd + 1; break;
        end
    end
    if nDupBnd > 5, break; end  % early exit for performance
end
if nDupBnd > 0
    warning('DEDUP WARNING: Found reversed-duplicate boundaries — run deduplicateBoundaries (references/deduplicateBoundaries.md)');
end
fprintf('Boundary deduplication check: %d duplicates found\n', nDupBnd);

Post-Processing (MANDATORY — execute in order before write())

Left-Gap Topology Filter (MANDATORY for converted maps)

Removes false predecessor/successor connections caused by shared boundary endpoint nodes. For each lane with multiple successors (or predecessors), computes left boundary gap — if any connection has gap < 3m and others > 3m, removes the far ones. Without this, junction lanes get 2-4x too many connections. See references/leftGapFilter.md.

Endpoint Snapping

For connected lanes (pred/succ), snap successor start to predecessor end. See scripts/snapConnectedEndpoints.m and references/snapEndpoints.md.

Height Conflict Resolution

Overlapping unconnected lanes at the same Z cause grass artifacts. Use graph coloring to assign Z-levels. See scripts/resolveHeightConflicts.m and references/resolveHeights.md.

Boundary Deduplication (MANDATORY for converted maps)

When building from source formats that assign separate boundary objects to opposing lanes (Lanelet2, HERE, NDS, etc.), scan all boundary pairs for identical geometry (forward or reversed within 1mm tolerance). Merge duplicates and update lane references with flipped alignment. Without this step, shared boundaries render doubled markings. See references/deduplicateBoundaries.md.

Additional Entity Types

For all entity classes (Signs, Signals, Barriers, Parking, CurveMarkings, StencilMarkings, StaticObjects, LaneGroups), see the class/property table in references/apiReference.md. Key references by task:

Key Functions

FunctionPurpose
roadrunnerHDMapCreate HD Map object (loads namespace)
read(rrMap, file)Read existing .rrhd file
write(rrMap, file)Write HD Map to .rrhd file
roadrunner.hdmap.LaneLane entity (Geometry, TravelDirection, LaneType)
roadrunner.hdmap.LaneBoundaryBoundary entity (Geometry, ParametricAttributes)
roadrunner.hdmap.LaneMarkingMarking definition (ID, AssetPath)
roadrunner.hdmap.JunctionJunction area (Geometry as MultiPolygon)
roadrunner.hdmap.AlignedReferenceReference with alignment (Name=Value constructor)
roadrunner.hdmap.RelativeAssetPathAsset path wrapper (Name=Value constructor)
roadrunner.hdmap.ParametricAttributionMarking placement (Span, MarkingReference)

Known Limitations

  • SignalTypes/Signals survive RRHD write/read in MATLAB, but RoadRunner silently ignores them on scene import — signals will not appear in the RoadRunner scene

  • RoadRunner cannot render self-closing lanes — split using N-way orthogonal algorithm (see references/orthogonalSplit.md)

  • Geometry must always be Nx3 (include Z=0 if flat)

  • For track maps (closed-loop ovals): omit topology (Predecessors/Successors), Z bumps, and marking attributes (ParametricAttribution) — see orthogonalSplit.md Track-Specific Guidance

Conventions

  • Always use create-then-assign pattern for roadrunner.hdmap.* objects

  • Use RelativeAssetPath(AssetPath="...") and AlignedReference(Reference=ref, Alignment="...") — Name=Value only

  • Use ClassName.empty for empty typed arrays, never []

  • All geometry is Nx3 with Z column (default 0 for flat terrain)

  • Shared boundaries: one object per way, multiple lanes reference with different alignments


Copyright 2026 The MathWorks, Inc.

Files

references/alignmentRules.md

Alignment Rules — Lanes, Boundaries, and Travel Direction

Reference implementation: scripts/detectAlignment.m

Defines the geometry alignment conventions that prevent green surface (grass/terrain) rendering bugs in RoadRunner.

Core Concept: Digitization Direction

Every geometric object has a direction defined by point order:

  • First point = START

  • Last point = END

All alignment is relative to this direction.

Alignment Enum

ValueMeaning
ForwardReferenced object runs same direction as the referring object
BackwardReferenced object runs opposite direction

Lane Boundary Alignment

LeftLaneBoundary.Alignment and RightLaneBoundary.Alignment describe how boundary geometry relates to lane geometry:

Forward:  lane start──────►lane end
          bnd start───────►bnd end    (same direction)

Backward: lane start──────►lane end
          bnd end◄─────────bnd start  (opposite direction)
Detection Algorithm (Proximity + Multi-Sample Spatial Verification)

A simple dot product or overall direction vector is NOT sufficient — it fails on highly curved lanes (split half-ovals, U-turns, tight curves) where the chord direction (start→end) doesn't represent travel direction.

Use this two-step algorithm:

Step 1: Proximity-Based Direction

Compare boundary start/end distance to the lane center start point:

% For each boundary independently:
dStartToLaneStart = norm(bndGeom(1,1:2) - centerGeom(1,1:2));
dEndToLaneStart   = norm(bndGeom(end,1:2) - centerGeom(1,1:2));
if dStartToLaneStart <= dEndToLaneStart
    alignment = "Forward";
else
    alignment = "Backward";
end
Step 2: Multi-Sample Spatial Verification

Sample multiple points along the center line, use LOCAL tangent at each to verify which side boundaries are on:

nSamples = min(5, size(centerGeom,1)-1);
sampleIdx = round(linspace(2, size(centerGeom,1)-1, nSamples));
leftOnLeft = 0;
for si = 1:numel(sampleIdx)
    idx = sampleIdx(si);
    % Local tangent (NOT overall direction)
    localTan = centerGeom(min(idx+1,end),1:2) - centerGeom(max(idx-1,1),1:2);
    localTan = localTan / norm(localTan);
    localLeftN = [-localTan(2), localTan(1)];  % 90 deg CCW = left normal
    % Find closest point on left boundary to this center point
    distsL = vecnorm(leftBndGeom(:,1:2) - centerGeom(idx,1:2), 2, 2);
    [~, closestL] = min(distsL);
    toBndL = leftBndGeom(closestL,1:2) - centerGeom(idx,1:2);
    if dot(toBndL, localLeftN) > 0
        leftOnLeft = leftOnLeft + 1;
    end
end
% If left boundary is NOT on the left at majority of samples → swap left/right
if leftOnLeft < numel(sampleIdx)/2
    % Swap boundary assignments and recompute proximity alignment
end

Why multi-sample? The overall direction vector geom(end,:) - geom(1,:) fails catastrophically on half-oval segments where the chord cuts across the curve interior. Local tangent at each sample point always correctly identifies the geometric left/right regardless of overall curvature.

Simplified Algorithm for Map Conversion (Lanelet2-proven)

For converting maps where left/right boundary assignment is already known (e.g., Lanelet2 lanelets define which way is left vs right), a simpler approach works reliably:

lDir = leftPts(end,:) - leftPts(1,:);
rDir = rightPts(end,:) - rightPts(1,:);
dp = dot(lDir(1:2)/(norm(lDir(1:2))+1e-10), rDir(1:2)/(norm(rDir(1:2))+1e-10));

if dp >= -0.3
    % Normal: both boundaries go same direction
    rightAlign = "Forward";
    leftAlign = "Forward";
else
    % Opposing boundaries: use proximity to determine which is backward
    d_ls_re = norm(leftPts(1,1:2) - rightPts(end,1:2));  % left start to right end
    d_ls_rs = norm(leftPts(1,1:2) - rightPts(1,1:2));    % left start to right start
    if d_ls_re < d_ls_rs
        % left_start near right_end → right is Backward
        rightAlign = "Backward";
        leftAlign = "Forward";
    else
        rightAlign = "Forward";
        leftAlign = "Backward";
    end
end

Key insight: The -0.3 threshold (not 0) handles lanes with slight boundary curvature that produce small negative dot products but are NOT truly opposing. True opposing boundaries (shared center lines between lanes going opposite directions) typically have dp < -0.7.

This approach is simpler than multi-sample verification because the source data guarantees correct left/right assignment. It has been validated on 184-lane Japanese urban maps with 46 backward-right boundaries.

Legacy Algorithm (d_starts/d_cross)

The d_starts vs d_cross approach below works for straight/mildly curved lanes but MUST NOT be used as the sole spatial verification for highly curved geometry. It is acceptable as a quick first-pass for typical road networks, but always validate with the multi-sample check above:

d_starts = norm(leftGeom(1,1:2) - rightGeom(1,1:2));
d_cross  = norm(leftGeom(1,1:2) - rightGeom(end,1:2));

if d_starts <= d_cross
    % Both boundaries go same direction
    laneDir = (leftGeom(end,1:2)+rightGeom(end,1:2))/2 ...
            - (leftGeom(1,1:2)+rightGeom(1,1:2))/2;
    laneDir = laneDir / norm(laneDir);
    leftNormal = [-laneDir(2), laneDir(1)];
    toLeft = mean(leftGeom(:,1:2)) - mean(rightGeom(:,1:2));
    if dot(toLeft, leftNormal) >= 0
        leftAlign = "Forward"; rightAlign = "Forward";
    else
        leftAlign = "Backward"; rightAlign = "Backward";
    end
else
    % Boundaries go opposite directions
    laneDirA = leftGeom(end,1:2) - leftGeom(1,1:2);
    laneDirA = laneDirA / norm(laneDirA);
    leftNormalA = [-laneDirA(2), laneDirA(1)];
    toLB = mean(leftGeom(:,1:2)) - mean(rightGeom(:,1:2));
    if dot(toLB, leftNormalA) >= 0
        leftAlign = "Forward"; rightAlign = "Backward";
    else
        leftAlign = "Backward"; rightAlign = "Forward";
    end
end

Why proximity first? The d_starts vs d_cross comparison tells you whether the two boundary geometries were digitized in the same direction or opposing directions. This determines whether their alignments should match or be opposite.

Why spatial verification? The leftNormal check ensures the boundary assigned as "left" is actually on the geometric left side when looking in the lane's travel direction. Without this, you can get alignment values that are technically consistent (dot product passes) but physically wrong (boundaries swapped).

Critical: Use overall direction (end - start), NOT first-segment direction (2,:) - (1,:). First-segment fails for wide turn lanes where initial tangent is nearly perpendicular to overall direction.

Left vs Right Boundary Determination

Standing at lane START, facing lane END:

  • Left boundary = on your left-hand side

  • Right boundary = on your right-hand side

Verification Algorithm
laneDir2D = laneGeom(end,1:2) - laneGeom(1,1:2);
laneDir2D = laneDir2D / norm(laneDir2D);
leftNormal = [-laneDir2D(2), laneDir2D(1)];  % 90 deg CCW rotation

centerToBnd = mean(bndGeom(:,1:2)) - mean(laneGeom(:,1:2));
if dot(centerToBnd, leftNormal) > 0
    % Boundary IS on the left → assign as LeftLaneBoundary
else
    % Boundary is on the right → assign as RightLaneBoundary
end

Green Surface Bug — Root Causes

RoadRunner constructs road mesh by walking left boundary then right boundary (respecting alignment) and filling between them.

SymptomRoot CauseFix
Green grass on roadLeft/Right boundaries swappedVerify with cross product; swap assignment
Green patches at curvesAlignment Forward/Backward incorrectRecompute dot product using overall direction
Half-lane greenShared boundary has wrong alignment for one laneEach lane computes alignment independently
Green at intersectionsFirst-segment direction usedUse geom(end,:) - geom(1,:)

Travel Direction

Describes traffic flow relative to lane digitization direction:

ValueTraffic flows...Use case
ForwardSTART → END (same as digitization)Standard one-way lanes
BackwardEND → START (opposite)Opposing lane sharing geometry
BidirectionalBoth directionsTwo-way undivided roads
UndirectedNo dominant directionSidewalks, curbs, parking

TravelDirection does NOT affect surface rendering. It only affects:

  • Routing/navigation logic

  • Lane arrow visualization in scenario editing

  • Which end is entry/exit for actors

Predecessor/Successor Alignment

AlignmentConnection
ForwardConnected lane flows same direction (predecessor END → current START)
BackwardConnected lane flows opposite (predecessor START → current START)
Forward predecessor:   [pred]────►  ────►[current]
                         end      start

Backward predecessor:  ◄────[pred]  ────►[current]
                       start        start

Lane Group Alignment

LaneGroup.Lanes[i].Alignment:

  • Forward: lane geometry same direction as LaneGroup geometry

  • Backward: lane geometry opposite (allows opposing lanes in one group)

Shared Boundary Between Adjacent Lanes

Each lane computes alignment independently against the same boundary:

Lane A (W→E):          ────────────►
Shared boundary (W→E): ────────────►  (Right of A → Forward, Left of B → Forward)
Lane B (W→E):          ────────────►

Lane A (W→E):          ────────────►
Shared boundary (E→W): ◄────────────  (Right of A → Backward, Left of B → Backward)
Lane B (W→E):          ────────────►

Copyright 2026 The MathWorks, Inc.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
MathWorks
Publisher
MathWorks (Official)
Source
matlab/matlab-agentic-toolkit · skills-catalog/automotive/roadrunner-rrhd-authoring · commit 2a7f215
Licence
BSD 2-Clause License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE.md)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by MathWorks.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download roadrunner-rrhd-authoring.zip