Road models are a fundamental, yet relatively misunderstood, aspect of vehicle modelling. In essence, all that comprises a road model is a mechanism to deliver the tyre a point in space, which represents where the ground level is. The point is then utilised within the tyre to produce a vertical force to prevent the vehicle free falling infinitely perpendicular to the road surface. Most often than not, such a point is calculated from a table of some sort, containing points representative of the road surface being modelled. VeSyMA road models are no different, with this blog post explaining how they work, how each type differs from one another, to enable users to interact and utilise road models with a greater degree of confidence.
What are the basic principles of a VeSyMA format road model?
One can consider that there are two groups of VeSyMA road models; road models which store data in a VeSyMA format, and those which store data in other (usually) external, formats. Some roads, such as the flat road or circle road, are designed to run without external road files, as they have a singular purpose.
As eluded to above, all a VeSyMA road model comprises of is a method to deliver a ground contact point to the tyre model. This ground point will be calculated from a supplied list of points – a lookup table of the centreline of the road and some other required parameters – and calculated for the position of the wheel contact point relative to the nearest points in the table. Whilst this is somewhat of a simplification, ignoring the complexities of how the point is calculated, it is enough for our purposes.
Rather than having separate library models of each road configuration you would like to run in a simulation, VeSyMA road models save all the data for each road configuration in a .mat file. Such a file is a standard format (v4) .mat file, able to be easily read in any environment which supports the reading of .mat files, such as Matlab or Octave, the open source equivalent.
Inside the road file is the data which concerns the configuration of the road itself: driving line, centreline, size, width, friction, roughness, and other pertinent data, such as velocity targets or stopping points. VeSyMA road files contain a standard set of variables which the road models expect to read from the road file. S is the naming convention used in the road model for the distance along the centreline; w is the convention for the distance perpendicular to the centreline, in the Y axis (oriented relative to the centreline). Primarily, roads are defined by the centreline matrix, and the data contained within. Other variables in the road file describe additional details required by the road model.
- velocity: The speed trace the driver model attempts to follow. A 2-column vector, the first column is distance along the road (S), the second column the velocity target. First row is the lookup table header.
- stops: Data regarding the stops the driver is required to make. A 3- column matrix, the first column is the position of the stop previously complete along the centreline of the road, the second the position of the next stop to be made (also along the centreline of the road) and the third column detailing the time the driver is to remain at each stop in seconds
- stopsActivation: Numerical identifier for the driver to determine whether the road contains stops
- roughness: Another 3-column matrix, this time detailing the bumpiness of the road. The first column details the position along the centreline of the road, the second and third detail the roughness on either side of the road centreline. Once again, the first row of the matrix is the lookup table header. This is not required to be set in a road file.
- roadSize: Numerical values regarding the maximum size of the road. First value is the maximum length of the road centreline, the second is the maximum width of the road.
- friction: Another 2D lookup table, this matrix’s first column is the distance along the centreline of the road, the subsequent columns the friction (mu) values at varying perpendicular distances to the centreline. First row concerns the lookup table headers.
It is at this point, the main VeSyMA road model types begin to diverge, with differences in the centreline and offset variables, owing to the differences in construction of the roads.
Generic Road vs Independent Driving line
For the majority of full vehicle VeSyMA simulations, one of two proprietary road models are used: the GenericRoad or the IndependentDrivingLine. Similar in operation, they store driving line data in separate ways. Being the primary difference between the two, therefore road files created for one or the other type of road model are incompatible with one another. The main functional difference concerns the offset variable.
Used most often throughout the VeSyMA suite is the GenericRoad. Defined primarily by the centreline, crucially the driving line is determined as an offset distance from the centreline of the road. If no distance is specified in the offset variable, then the vehicle will attempt to follow the centreline of the road.
The centreline variable itself contains 6 columns of data in the GenericRoad: distance along the centreline (s), x, y, z, width of road (from edge to edge) and finally banking angle of the road taken around the centreline. The offset is defined as a vector, the first column being the distance along the centreline, the second being the offset (sign sensitive) of the driving line to the centreline, perpendicular to the road surface.
Figure 1: External road file used in the GenericRoad, as opened in the open source Octave environment. Each of the matrix variables listed is used as a lookup table of some sort by the road model.
By contrast, the IndependentDrivingLine road features a centreline variable of 5 columns, as banking is optional. If the road you are building features banking, it is a good idea to include it in the road file to ensure the robustness of the road calculations, in addition to ensuring the vehicle initialises at the correct position on the road. In road files of the type for this road model, the variable offset describes the driving line in actual coordinates, rather than as a function of the centreline. Indicative of its name, it is independent. The offset variable now contains 5 columns, the first being distance along the centreline (s), the next 3 being the points of the driving line and the last column being the perpendicular distance to the edge of the road.
Figure 2: Above is the IndependentDrivingLine external road model. As you can see, there are substantial similarities with it and the GenericRoad file. Note the Centreline dimensions, however.
Other VeSyMA Road Model types/Specialist Road Models
Beyond the VeSyMA format of road models, the VeSyMA suite of libraries supports various other third-party road formats, each with their own external model format. In addition, some unique road formats exist for specific simulation purposes:
- FTireIndependentDrivingLine: Derivative of the original independent driving line VeSyMA road model for use with FTire tyre models
- OpenCRGRoad: For use with the popular OpenCRG road format, with GenericRoad style driving line override option
- CircleRoad: Specific Road model developed for producing perfectly circular road, without the need for an external road file.
Closing remarks
Often a forgotten element of vehicle simulation, road models are quite complex in their operation. Still, this doesn’t mean they have to be complex in their understanding, nor does it mean they should be hard to use. Further information can be found in the user guides located in the VeSyMA library for the GenericRoad and the Suspensions library for the IndependentDrivingLine road and its derivatives. Hopefully this blog post explains a bit about how road models work in Dymola, and expands upon the native road implementations in the VeSyMA suite!
Written by: Theodor Ensbury – Project Engineer
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion.
