6th Meeting - OpenDRIVE · friction double friction value [-] surface string surface material code...

January 28, 2010 copyright note according to DIN 34 Slide 1

6th Meeting

January 28, 2010

Marius Dupuis / [email protected]

Includes Notes an

d Proceedings!


Scope of the Meeting

Focus of this meeting

– The upcoming release 1.3

– Exchange of Experience

– New requirements for OpenDRIVE

– Formal standardization

Minutes of the meeting are shown in GREEN font on YELLOW background!


OpenDRIVE – What's new?



Extension of Core-Team– New Members:

• Andreas Richter, DLR, Braunschweig• Mats Lidström, VTI, Sweden• Ingmar Stel, TNO, Netherlands

– Leaving Members:• Markus Stöbe, DLR, Braunschweig

Result: accepted



User-List on OpenDRIVE Website– Logo– Statement– Link to own website– Free of charge and other obligations

Result: further users will register.



Sample Files on OpenDRIVE Website– Components:

• OpenDRIVE file• OpenFlight files• Textures

– Purpose:• Reference for various modeling tasks

– Origin:• to be provided by users

We need more!!

Result: users are planning to provide further examples



Partner Project

• road surface

• open format + open source

• tire and vibration simulation

• funded by automotive industry

• managed by VIRES

• www.opencrg.org

Result: currently applicable to some users only


OpenDRIVE 1.3

- The Next Standard -


Features in OpenDRIVE 1.3

Update: Track Co-ordinate System

– New name for z-axis: h-axis (clear distinction from inertial system)

Result: accepted



New: Local Co-ordinate System

The local system can only be positioned in track space by providing the full track co-ordinates and orientation of its origin.

Result: accepted



New: Reference for Spiral (Clothoid, Euler-Spiral) calculation

– Different algorithms with varying accuracy are used for thecalculation of clothoids

– The "ideal" algorithm should be identified and made availableas reference source code

– Identification of the algorithm:

http://en.wikipedia.org/wiki/Euler_spiral

– Source code (Provider?):

http://www.opendrive.org/tools/odrSpiral.zip

Result: accepted



Update: Header - Vendor Information

vendor namestringvendor

minimum inertial x value in [m]doublewest

maximum inertial x value in [m]doubleeast

minimum inertial y value in [m]doublesouth

maximum inertial y value in [m]doublenorth

time/date of database creationstringdate

version number of this database (format: a.bb)floatversion

database namestringname

minor revision number of OpenDRIVE® format (currently 3)ushortrevMinor

major revision number of OpenDRIVE® format (currently 1)ushortrevMajor

descriptiontypename

Delimiters: <header/>Parent: <OpenDRIVE>Maximum Instances: 1Optional: noArguments:

Result: accepted



New: Lane Offset Record

Purpose: Simplified construction of • additional "inner" lanes• 2+1 schemes

Image courtesy of VTIImage courtesy of VTI

Result: accepted



New: Lane Offset Record (cont’d)

Calculation: offset = a + b*ds + c*ds 2 + d*ds 3

Delimiters: <laneOffset.../>Parent: <lanes>Maximum Instances: unlimitedOptional: yesArguments:

parameter Ddoubled

parameter Cdoublec

parameter Bdoubleb

parameter A (offset in [m])doublea

start position (s-coordinate) doubles

descriptiontypename

Specification:

Result: accepted


New: Road Mark Types

Some road marks need a more detailed description:

- Special drawing schemes (e.g. 3_9/9_3)

- Multiple adjacent lines

- Individual shapes (e.g. line/gap ratios)


Image courtesy of VTIImage courtesy of VTIResult: accepted


New: Road Mark Types (cont’d)

default line width [m] doublewidth

name of the road mark typestringname

descriptiontypename

Specification (entry)


Delimiters: <type>...</type>Parent: <roadMark>Maximum Instances: 1Optional: yesRestrictions: noneArguments:

Result: accepted



Specification (details)


Delimiters: <line.../>Parent: <type>Maximum Instances: unlimitedOptional: noRestrictions: noneArguments:

width of the road mark (overriding default setting in parent tag) [m]

doublewidth

rule which is to be observed when passing the line from inside, e.g. “no passing”, “caution”, “none”

stringrule

initial longitudinal offset from of the line definition from the start of the road mark definition [m]

doublesOffset

lateral offset from the lane border [m]doubletOffset

length of the space following the visible part [m] doublespace

length of the visible part [m] doublelength

descriptiontypename

Result: accepted with addition of “width”Result: accepted with addition of “width”, rules tbd.



Example:


<roadMark sOffset=…><type name=”3_9/9_3” width=“0.15”>

<line length="9" space=”3” tOffset="-.1" rule=”caut ion”/><line length="3" space=”9” tOffset=".1" sOffset="3" rule=”none”/>

</type></roadMark>



Update: Object Record

Purpose: clarification

of wording


roll angle of the object relative to road roll [rad]doubleroll

pitch angle of the object relative to road pitch [rad]doublepitch

heading angle of the object relative to road direction [rad]doublehdg

height of the object [m] (local dz )doubleheight

radius of the object [m]; alternative to width and lengthdoubleradius

width of the object [m] (local dy )doublewidth

length of the object [m] (local dx )doublelength

“+” = valid in positive track direction“-“ = valid in negative track direction“none” = valid in both directions

stringorientation

extent of object's validity along s-axis in [m] (0.0 for point object)

doublevalidLength

z offset of object's origin from track level [m]doublezOffset

track position of object's origin [m] (t-position)doublet

track position of object's origin [m] (s-position)doubles

unique ID within databasestringid

name of the objectstringname

type of the objectstringtype

descriptiontypename

Result: accepted


Update: Object Repeat Record

Purpose: introduction of continuous road-side objects(e.g. wall, railing)


distance between two instances of the object [m]If this value is zero, then the object is considere d to be a continuous feature like a railing, a wall etc.

doubledistance

length of the repeat area [m]doublelength

start position (s-coordinate) [m], overrides the corresponding argument in the original <object> record

doubles

descriptiontypename

Result: accepted


Update: Object Outlines

• Deleted: <CornerInertial>

• Renamed: <CornerRelative> � <CornerLocal>


Purpose: Object outlines should only be given in track or local co-ordinates

Result: accepted


New: Object Material Record


Purpose: Flat objects within the road plane can modify the material

properties of the underlying „original“ lane(s).

Application: patches


Result: accepted


New: Object Material Record (cont’d)

Specification:


Delimiters: <material.../>Parent: <object>Maximum Instances: 1Optional: yesArguments:

roughness [-] (e.g. for sound and motion systems)doubleroughness

friction value [-]doublefriction

surface material code [-], depending on applicationstringsurface

descriptiontypename

Result: accepted


Update: Signal Reference Record


Purpose: orientation of target signal with respect to referring road

“+” = valid in positive track direction“-“ = valid in negative track direction“none” = valid in both directions

stringorientation

unique ID of the referenced signal within the databasestringid

track position [m] (t-position)doublet

track position [m] (s-position)doubles

descriptiontypename

Result: accepted


Update: Controller Record


Purpose: provision of global sequence / priority information

Delimiters: <controller.../>Parent: <OpenDRIVE>Maximum Instances: unlimitedOptional: yesArguments:

sequence number (priority) of this controller with respect to other controllers of same logical level

intsequence

name of the controllerstringname

unique ID within databasestringid

descriptiontypename

Specification:

Result: accepted


Update: Junction Controller Record


Purpose: provision of local sequence / priority information

Specification:

Delimiters: <controller.../>Parent: <junction>Maximum Instances: unlimitedOptional: yesArguments:

sequence number (priority) of this controller with respect to other controllers in the same junction

intsequence

type of control for this junctionstringtype

ID of the controllerstringid

descriptiontypename

Result: accepted


Update: Symbolic Constants


Additional lane type: tram

Additional object type: patch

Additional access restriction: none

New: Chapter 7 of Specification – Further Explanations and Examples

Road and Lane Linkage

– Direct

– Junctions

Junction Control

Result: accepted


Partner Projects - OpenCRG

Overview:

– Purpose:• provision of an open and free tool-set for the creation, modification and

evaluation of detailed road surface data

Image courtesy of DaimlerImage courtesy of Daimler



Overview (cont’d):

– Applications:

– Contents:

– Licensing:

– Location:

– Funding:

– Realization:

– Status:

• Tire simulation

• Vibration simulation

• etc.

• Matlab tool-set (creation, modification and evaluation)

• C-API (evaluation only)

• Documentation

• Sample files

• Apache License

• www.opencrg.org

• German automotive industry (Audi, BMW, Daimler, Porsche, Volkswagen)

• Daimler and VIRES

• Operable (release 0.8.0)



Next Step:

– Creation and provision of samples combining OpenDRIVE and OpenCRG information within one road.


User ReportsAudi Electronics Venture

DLR Institute of Transportation Systems

DLR Institute of Robotics and Mechatronics

TESIS DYNAware

TNO

VTI


Standardization


Situation

Standardization with OpenDRIVE

• The OpenDRIVE format is a de facto standard

– standardization by proliferation

– total number of users: unknown

– confirmed contacts: 50+

– years in service: 4

• Other formats emerged in 2009

– RoadXML by OKTAL

• TRAIN-ALL project aims for formal standardization of road description

– Nov. 20, 2009: meeting TRAIN-ALL / VIRES / OKTAL for a firstbrainstorming on the issue of formal standardization

– mission: a formal standard within 5 to 10 years

Question: Shall OpenDRIVE be part of or become a European standard?

Result: If there’s going to be a European standard, OpenDRIVE should be part of it or contribute considerably to it.


TRAIN-ALL

by TNO


RoadXML

by OKTAL


How to Proceed?


• Alternative 1:

– we already have OpenDRIVE – it‘s good and that‘s it!

– stick to the existing organization of the OpenDRIVE format

– convince TRAIN-ALL to propagate OpenDRIVE to a formal European standard

• Alternative 2:

– we already have OpenDRIVE but others may also have good ideas

– join the strengths of existing formats into a new format

– hand over control of the standardization to TRAIN-ALL

– participate in the TRAIN-ALL workgroups

• Alternative 3:

– let the market decide!

– join a formal standardization after the market has made its decision

• Alternative 4:

– the ideas of our competitors are much better than our‘s – let‘s give up!

Result: see next slide


How to Proceed?


• Alternative 1:

– we already have OpenDRIVE – it‘s good and that‘s it!

– stick to the existing organization of the OpenDRIVE format

– convince TRAIN-ALL to propagate OpenDRIVE to a formal European standard

• Alternative 2:

– we already have OpenDRIVE but others may also have good ideas

– join the strengths of existing formats into a new format

– hand over control of the standardization to TRAIN-ALL

– participate in the TRAIN-ALL workgroups (or successors)

• Alternative 3:

– let the market decide!

– join a formal standardization after the market has made its decision

• Alternative 4:

– the ideas of our competitors are much better than our‘s – let‘s give up!

Result: it’s a combination of alternatives 1-3, definitely not no. 4!


Assessment:


funding of standardization by EU, afterwards ?

funding of standardization by EU, afterwards “as usual”

funding

high (once established)highflexibility

new groups, then growing “as usual”moderately growing user base

tbd.VIRES + core teammanagement

interrupted to unknown extentguaranteedcontinuity

OpenDRIVE: medium to highother formats: medium to high

OpenDRIVE: noneother formats: high

impact on existing users

highmediumacceptance

5-10 yearsimmediatelyavailability

OpenDRIVE+X

OpenDRIVEonly

criteria

Result: see next slide


Key questions:


• Which strategy has the least overall impact on existing users?

• How to support affected users?

– free converters

– consulting

– etc.

• Who will be in charge?

• How to organize a long-term funding?

• What are the risks of NOT being part of a European standardization?

Results / Next Steps:

• Solution will be a mixture of alternatives 1 to 3

• Identify the technical discrepancies between OpenDRIVE and RoadXML

• VIRES and OKTAL will each have one professional look at the other‘s data format

- Prepare a paper providing the results of the assessment and identify possible solutions

- Ask (potential) users about their preferences and try to estimate their efforts to implementvarious solutions

- Identify the way to go and go ahead under co-ordination from a 3rd party, e.g. TNO


Discussion / Roadmap


Issues

Discussion / Roadmap

• OpenDRIVE 1.4

– major tasks

– schedule

• Standardization

– how to proceed

• Next meeting

– when?

– where?Result: depending on progress / need

Result: see above

Result: to be determined

6th Meeting - OpenDRIVE · friction double friction value [-] surface string surface material code...

Documents

Transcript of 6th Meeting - OpenDRIVE · friction double friction value [-] surface string surface material code...