Issue with unexpected motion in ChBodyEasyMesh with Collide Enabled
Jay Jay
Hi everyone,
I’m encountering an issue while working with rigid body collisions in Project Chrono. I’ve created two cubes with a certain distance apart using the following code:
auto box = chrono_types::make_shared<ChBodyEasyMesh>(
GetChronoDataFile("models/cube.obj"), // mesh filename
500, // density (kg/m^3)
true, // automatically compute mass and inertia
true, // visualize?
true, // collide?
mat,
0.001 // mesh sweep sphere radius
);
Even though I’ve set gravity to 0 and no external forces are applied, the cubes experience rotation and translation over time when collide is enabled. If I disable collide, the cubes remain stationary. Clearly, the issue is related to the collision behavior.
Interestingly, when I create the cubes using ChBodyEasyBox with the same gravity and collision enabled, they remain stationary as expected:
auto box = chrono_types::make_shared<ChBodyEasyBox>(
3.96, 2, 4, // dimensions (x, y, z)
500, // density (kg/m^3)
true, // visualization?
true, // collision?
mat
);
Both cubes in this case are stable with no unexpected motion.
Could anyone help me understand why the behavior is different between ChBodyEasyMesh and ChBodyEasyBox? Is there something specific about the collision setup for ChBodyEasyMesh that I’m missing?
Thanks!
Best regards,
Jay
Radu Serban
Hi Jay,
Could you please provide a complete minimal code that shows the problem?
By the way, note that the two cases you list below are not exactly the same, as the cube generated by the first one will have dimensions 2x2x2.
--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
projectchron...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/projectchrono/941afeb8-5f8a-4268-b7f9-aba820c8e55en%40googlegroups.com.
Jay Jay
500, // density
true, // visualization?
true, // collision?
mat);
500, // density kg/m^3
true, // automatically compute mass and inertia
true, // visualize?>
true, // collide?
mat,
0.001
Radu Serban
Hi Jay,
It took a while until I got a chance to look at this closer.
The main issue here is that the Chrono API is confusing and unintuitive in this particular regard. I intend to change this sometime soon.
Until then, here’s what’s going on:
- Each of the ChBodyEasy*** classes creates under the hood a ChBodyAuxRef. While a ChBody always assumes that the body is defined with respect to a centroidal frame, a ChBodyAuxRef is more general in that it allows defining the body w.r.t. a non-centroidal frame. Collision and visualization shapes are defined with respect to the body frame (and not the centroidal frame); of course these two frames are the same for a ChBody but they may not be for a ChBodyAuxRef.
- With the current Chrono code, the position of a ChBodyAuxRef (and hence a ChBodyEasy***) is intended to be set with a call to ChBodyAuxRef::SetFrameRefToAbs() which positions the body reference frame relative to the global (absolute) frame. Calling this function also moves the centroidal reference frame (with a rigid body motion).
- However, SetPos and SetRot move the centroidal reference frame. The problem is that Chrono was not doing the right thing here: for a ChBodyAuxRef, it should have also moved the body reference frame. Without that, the collision system was unaware of the the actual positions of the collision shapes. In your example, the two collision shapes were initially on top of each other (at the origin of the global frame). The body reference frames were later moved at their proper positions, but that happens only during a simulation step and after the first contacts were processed. These initial contacts imparted the body motion you observed.
- I pushed a fix to SetPos and SetRot. Again, this is a temporary solution, because this is all unintuitive and prone to errors such as this. I will implement a better solution to this hopefully soon.
To make a long story short, to fix the problem you saw you can either:
- Replace SetPos with SetFrameRefToAbs (recalling that the former moves the centroidal frame, while the latter moves the body reference frame – not a problem in this particular case as the two frames happen to coincide); or
- Pull the latest code and keep using SetPos.
Hope that this helps,
--Radu
From: projec...@googlegroups.com <projec...@googlegroups.com>
On Behalf Of Jay Jay
Sent: Sunday, January 19, 2025 8:20 PM
To: ProjectChrono <projec...@googlegroups.com>
Subject: Re: [chrono] Issue with unexpected motion in ChBodyEasyMesh with Collide Enabled
Hi Radu,
Please see the attachment. I change the cube size in the case below to 2x2x2. The problems are still there. If I use :
auto box = chrono_types::make_shared<ChBodyEasyBox>(2, 2, 2, // x,y,z size
500, // density
true, // visualization?
true, // collision?
mat);
It works well. The two cubes are stationary:
If I use:
auto box= chrono_types::make_shared<ChBodyEasyMesh>(GetChronoDataFile("models/cube.obj"), // mesh filename
500, // density kg/m^3
true, // automatically compute mass and inertia
true, // visualize?>
true, // collide?
mat,
0.001
);
Then the results are as follows:
To view this discussion visit https://groups.google.com/d/msgid/projectchrono/45222c59-3105-4a2e-82ca-028a2c4f22d9n%40googlegroups.com.