opencrg generates inconsistent road heightw when having overlapping roads

[HeyImJordi]

When having a parking garage with several levels of 'road' there is no way to indicate what road level is desired. Further more, when making road height calls the road height returned may be for different road levels, even when the points (x,y) are not far from each other

[HeyImJordi]

From Jan VANOOSTEN (Hexagon) on GitLab:

overlapping_crg_road.zip

Edit: Reuploaded attached file after repository move

[HeyImJordi]

From Jan VANOOSTEN (Hexagon) on GitLab:

I do not have a road file for a complete garage, but I have one with two layers of road. When doing initialization of the vehicle model on the road, I get road heights for the four wheels from two different layers. There should be a method to have the same layer for all tires contacts.

[HeyImJordi]

From Thomas BLEHER (BMW) on GitLab:

Do you mean you have one OpenCRG file for the whole parking garage, and the reference line is curved in a upward spiral to support the different layers?

[asadekasam]

OepnCRG CCB 2025.11.03: Classify after @jkoppena has a second look

[jkoppena]

@asadekasam: do you know how I can find the concept as mentioned in the comment below that I took from our system.

Comment from Hexagon (11 Feb 2021):

Multiple layers are not supported yet, the last ASAM version 1.2.0. lists in the release notes:

F002_MultipleDataLayers

•Concept for integrating multiple data layers was developed and discussed. •The work load for implementing this feature was far above the budget for service providers as well as the committed working hours of the working group members.

•The developed concept is available for further use in a new, potential project.

[jkoppena]

I don't know the state of the concept code. We will have to test it. For now, I would put release version 1.3.

[jorauh]

We should not confuse about "multiple layers":

The discussion I know on it relates to multiple layers at the same position of road, e.g. height, friction, temperature, wind speed, ...
I saw a proposal slide which is much too complex to have that implemented (many changes to code and file format). I am not aware of any concept code for that. There is a much simpler approach available, which could be implemented and made available soon if needed.

The question of this issue is a differnet thing: there is no unique answer to road height, if your crg describes roads like the spiral in multy story parking garages. Evaluating such a road should be no problem as long as the evaluation starts outside the non-unique area, and the evaluation point history is cleanly maintained for each contact point. Stepping into such a non-unique area could be realized by pre-setting the evaluation history adequately. Maybe this needs some additional documentation.

[CarawaySeed42]

To keep the contact point's height on the same overlapping layer, the history is important.
If not changed the following default values for the history are used:

• m : max. size of history
• c : square of distance limit for close search
• f : square of distance limit for far search

with

• m = 50;
• c = ( 10*uinc)^2;
• f = (100*uinc)^2;

-> For the overlapping crg road in question with uinc = 0.01, the history search distance is 10cm for close distance and 1m for far distance.
If there is no close enough point in history then a global search is triggered.

The default values regarding the search distance are the same for the Matlab-API and the C-API.

[jorauh]

Thank you for this quick research! Ther might be situations (depending on the current uinc) where the current distance limits are non-optimal. Please report explicit cases, where the search failed.

Background: with a typical resolution of uinc = 0.01 and a simulation step size of 0.001s, for all reasonable vehicle speeds < 100 m/s, a single contact point should always be in the close search area - and will never find the next "layer" of the road.

[jkoppena]

The problem here is statics prior to the dynamic simulation when the vehicle is located on part of the road that is overlapping. In such case, each tire may be on a different road layer, and statics will fail in that case. If the vehicle starts from a road section that does not overlap, all is fine.

[jorauh]

There will be no simple solution as long as the history is not initalized in a non-overlapping area.

We could

• preset heuristics by introducing some explicit MODS/OPTS information where to start search
• try to introduce some heuristics to always find the same "layer" during some initialzation ("static") phase

Before doing any of that, I would like to have a real example which fails, in order to be sure to at least to introduce a solution for this. This mean, we need the road and the complete trace of c-api calls during the initialization ("static") phase.

[CarawaySeed42]

The C-API has the ability to preload the history during the initialization of the contact points:
crgContactPointPreloadHistoryU( CrgContactPointStruct *cp, double u )

After evaluating the u-value of the first contact point, one could preload the history of all other contact points that should remain on same layer as the first CP. If the second contact point is 2 meters after the first, then preload with u_cp1 + 2.0.
Method untestet by me. It is just a suggestion.

This would also only guarantee that the tires/contact points are on the same layer. It would not guarantee that they are on the layer the user wants or expects

[jorauh]

I just had a look into the sample provided in overlapping_crg_road.zip :

• at least with my matlab tests, I always got results in the same layer for all contact points I evaluated in the overlapping area. Could you please provide a sample id/x/y/z-pointlist from your static phase where it fails?

Probably not related to the issue:

• in test_dec-REF.crg there is an extra data block "$ROAD_CRG_VISUALIZATION" not defined by the documentation (and ignored by the matlab tools). What is its intended purpose, is there something to be added to the documentation and/or matlab tools?