Chrono::Vehicle simulations on rigid and SCM terrain patches

[Radu Serban]

Several users (both on this forum and separately) have expressed interest in using environments that combine rigid and SCM terrain patches.

 

This is possible and to illustrate how it can be done, I just pushed a new Chrono demo (demo_VEH_RigidSCMTerrain_MixedPatches) which sets up such a scenario.  The new C++ demo is available in the main branch of the Chrono git repository.

This demo defines two adjacent terrain patches (both built from height-map images), the first concave and the second convex, and allows the user to combine the type of each patch as desired. In other words, you can set it to be rigid-rigid, SCM-SCM, rigid-SCM, or SCM-rigid.

 

One of the important settings that enables this is ensuring that an axis-aligned bounding box (AABB) is specified for every single patch of SCM terrain. This prevent the SCM grid from extending beyond those limits and potentially interfering with the rigid terrain patches (or other SCM terrain patches). Note that the current default behavior of SCMTerrain is to extend the (virtual) SCM grid in all (x,y) directions. Use the function SCMTerrain:: SetBoundary() to set the bounding AABB.

 

This is probably also a good time to remind you of various performance considerations related to vehicle-terrain interaction, limiting the discussion here to only wheeled vehicles (specifics for tracked vehicles can be easily inferred from this) and only to rigid and SCM terrains (other models for deformable terrain in Chrono, such as granular through DEM or continuous representation CRM through SPH, have their specific performance considerations).

 

Performance of Chrono simulations (including vehicle and terrain) always depends on:

• Integration step size
• Integration scheme
• (Linear/DVI) solver

In addition, simulations of vehicle on rigid terrain are affected by:

• Contact formulation.
• Smooth contact (SMC) leads to stiffer problems, potentially requiring a smaller step size,  but the cost per time step of contact calculation is low.
• Non-smooth contact (NSC) can use larger step sizes than SCM but has high cost per step.
• Complexity of the geometry of collision shapes.
  Here, the rigid terrain patch(es) were generated from height-map images. A high resolution of these images results in dense collision meshes which can significantly impact performance of the rigid-rigid collision detection algorithm.
• Number of OpenMP threads used in collision detection.
  Settings for optimum performance are hardware-specific and need some experimentation. See documentation of ChSystem::SetNumThreads for more details.

On the other hand, SCM simulations are affected by:

• SCM grid resolution.
  The denser the (virtual) SCM grid, the more ray casts must be performed (one of the main computational costs of SCM terrain).

Note that, for SCM terrain patches generated from a height-map image, the image resolution does not play a role since the SCM grid is constructed by sampling the image at the specified SCM resolution.

• Use of active domains.
  To reduce the number of ray casts to the minimum necessary, I included an SCM feature that allows the caller to specify an OOBB associated with bodies expected to interact with the SCM terrain; ray casts are performed only from the SCM grid nodes that are in the projection onto the SCM reference plane of one of these OOBBs.  If no such active domains are specified, we create a default one, encompassing *all* collision shapes present in the Chrono system.
  For wheeled vehicle simulations, the most efficient setting is to use an active domain associated with each vehicle tire and set as tight as possible.
• Number of OpenMP threads used for ray casting.

In the latest SCM implementation, I used a map-reduce algorithm which performs ray casting in parallel for each grid node in an active domain. This uses an OpenMP parallel-for loop using a number of threads specified through ChSystem::SetNumThreads.

 

The new demo_VEH_RigidSCMTerrain_MixedPatches takes into consideration all of the above and provides knobs to experiment with various settings.

 

One final note: for simulations involving both rigid and SCM terrain patches, there is one other feature I intend to implement whenever I will find the time for it. The issue with such mixed scenarios is that, currently, the vehicle tires must be modeled as rigid objects (e.g., cylinders or meshes) or as FEA meshes because these are the only ones that can interact with SCM terrain. However, for interaction with rigid terrain patches, these two types of tire models are inaccurate (the rigid tire model) and can be potentially expensive (if interacting with a complex terrain mesh geometry).  The plan is to extend the handling tire models available in Chrono::Vehicle to allow them to interact with SCM terrain patches.  This would not make any difference over SCM terrain, but would be more accurate (and cheaper, depending on setup) on rigid terrain.

 

Best,
Radu