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
--
You received this message because you are subscribed to the Google Groups
"ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to projectchrono+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/projectchrono/CH3PPF46CDC2185428BFBC25F842C098666A7862%40CH3PPF46CDC2185.namprd06.prod.outlook.com.
