This should be the correct setup for the constraints, *prismatic1*->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2))); * prismatic2*->Initialize(chassis, axle, ChCoordsys<>(chassis->GetPos(), QUNIT));
prismatic joint allows translation in the z direction of the joint frame. For prismatic1, Q_from_AngX(pi/2) is a joint frame with its z aligning with global y, which is what you want for your setup. You said the screw only move in z direction, but there's no motion in y direction. Since the MBD setup is correct, there could be other issues. Have you looked at the forces from the terrain to the screw in global y direction? Thank you, Luning On Sunday, December 3, 2023 at 7:36:08 PM UTC-6 [email protected] wrote: > Hi, > > Just following up on this, > > Thank you > > On Monday, November 27, 2023 at 7:48:34 PM UTC-7 Mohammad Wasfi wrote: > >> Hi Luning, >> >> I have attached my drawing for you. To mention again, I do not have an >> actuator in my system. My components are (screw, chassis, axle, Link1 >> (ground chassis), Link2 (axle, chassis), and motor (screw, axle)). The >> screw has a *constant angular velocity *and is supposed to propel itself >> and move in the forward direction ( *y* in the picture). Additionally, *no >> motion* is allowed in the *x* direction. and the screw is *free *to move >> in the *z-direction*. >> >> Thank you, >> >> On Monday, November 27, 2023 at 12:30:08 PM UTC-7 [email protected] >> wrote: >> >>> Hello Mohammad, >>> >>> Can you attach a sketch of your setup that describes the actuator and >>> the constraints. Specifically, what rotational and translational motion of >>> the screw are supposed to be constrained? >>> >>> Thank you, >>> Luning >>> >>> On Friday, November 24, 2023 at 1:37:54 AM UTC-6 [email protected] >>> wrote: >>> >>>> Hi Luning, >>>> >>>> Thanks for the reply. I have looked into links and how they are used by >>>> simulating different options for a short amount of time. I am a little >>>> confused as testing different options did not seem to make much sense. >>>> >>>> For a prismatic joint is defined as: >>>> >>>> prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(),* >>>> QUNIT*)); >>>> >>>> The motion is allowed in the Z-dir. However, in the SingleWheel demo, >>>> the joint is defined as: >>>> >>>> prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), >>>> *Q_from_AngY*(CH_C_PI_2))); >>>> >>>> which results in the motion being allowed in both the x and z >>>> directions (two directions). However, when changing the input to this >>>> >>>> prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), >>>> *Q_from_AngX*(CH_C_PI_2))); >>>> >>>> The motion becomes restricted in both x and y and only free in z. *Why >>>> is that?* >>>> >>>> To try to navigate through this, I started by removing the actuator >>>> completely from my implementation as I only added it to be able to extract >>>> the forces on the screw (*Is there a way to extract the forces on the >>>> screw without having to use an actuator*?). Then, I have only two >>>> prismatic >>>> joints left ( one between the ground and the chassis and one between the >>>> chassis and axle). I started my tests by having the input for my prismatic >>>> joint as *Q_from_AngY*(CH_C_PI_2). This resulted in my screw moving in >>>> the z and x directions as expected. Then, I changed the input to >>>> *Q_from_AngX*(CH_C_PI_2), and also as expected, the screw was allowed >>>> to move in z-direction but not in x and y. As a result, I started thinking >>>> that maybe the second joint is what is preventing my screw from moving in >>>> certain directions. As a result, I tried the following combinations: >>>> >>>> 1 - *prismatic1*->Initialize(ground, chassis, >>>> ChCoordsys<>(chassis->GetPos(), Q_from_AngY(CH_C_PI_2))); >>>> * prismatic2*->Initialize(chassis, axle, >>>> ChCoordsys<>(chassis->GetPos(), QUNIT)); >>>> >>>> *( screw moved in both x and z)* >>>> >>>> *2- prismatic1*->Initialize(ground, chassis, >>>> ChCoordsys<>(chassis->GetPos(), QUNIT)); >>>> *prismatic2*->Initialize(chassis, axle, >>>> ChCoordsys<>(chassis->GetPos(), Q_from_AngY(CH_C_PI_2))); >>>> >>>> *(screw moved in x and z)* >>>> >>>> *3- **prismatic1*->Initialize(ground, chassis, >>>> ChCoordsys<>(chassis->GetPos(), QUNIT)); >>>> *prismatic2*->Initialize(chassis, axle, >>>> ChCoordsys<>(chassis->GetPos(), QUNIT)); >>>> >>>> *(screw moved only in z)* >>>> >>>> 4 - *prismatic1*->Initialize(ground, chassis, >>>> ChCoordsys<>(chassis->GetPos(), Q_from_AngXCH_C_PI_2))); >>>> * prismatic2*->Initialize(chassis, axle, >>>> ChCoordsys<>(chassis->GetPos(), QUNIT)); >>>> >>>> *( screw moved only in z)* >>>> >>>> *5- **prismatic1*->Initialize(ground, chassis, >>>> ChCoordsys<>(chassis->GetPos(), QUNIT)); >>>> *prismatic2*->Initialize(chassis, axle, >>>> ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2))); >>>> *( screw moved only in z)* >>>> >>>> >>>> *6- **prismatic1*->Initialize(ground, chassis, >>>> ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2) )); >>>> *prismatic2*->Initialize(chassis, axle, >>>> ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2))); >>>> *( no movement)* >>>> >>>> >>>> I then thought that maybe the type of link I was using was not correct. >>>> I looked into different links (Project Chrono: Links >>>> <https://api.projectchrono.org/links.html>) and could not find one >>>> that seems appropriate. I have also looked at the demos you specified to >>>> try to better understand (crank demo) and it does not look like the >>>> prismatic link is used there. However, the ChLinkLockPointLine link seems >>>> like something that can be used in my case but I cannot tell what the >>>> difference is between this link and the prismatic link. As for the motor, >>>> the motor seems to work well so far as the screw rotates about its axis as >>>> it is supposed to. >>>> >>>> One final note, I have multiplied the mass obtained with >>>> ComputeMassProperties() by the screw density and got 0.9888. This is still >>>> quite different from what my CAD provides (1.71kg). Any insight about >>>> this? >>>> The inertia values are also off. >>>> >>>> Sorry about the very long message and thank you so much for all your >>>> help, >>>> >>>> On Monday, November 20, 2023 at 12:22:10 PM UTC-7 [email protected] >>>> wrote: >>>> >>>>> Hello Mohammad, >>>>> >>>>> In the single wheel test demo for FSI, the longitudinal direction is >>>>> global X, the lateral direction is global Y, the wheel's motion is >>>>> restricted in Y direction, while the X direction has a prescribed motor >>>>> function. >>>>> >>>>> When you connect bodies with links, be careful with how you define the >>>>> degree of freedom of the constraint. Specifically, for prismatic joint, >>>>> it >>>>> allows translation along the Z axis. For instance in this line of your >>>>> code, >>>>> >>>>> prismatic1->Initialize(ground, chassis, >>>>> ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2))); >>>>> >>>>> The joint frame is aligned with Q_from_AngX(Ch_C_PI_2), which rotates >>>>> 90 degrees around global X, since the ground is fixed, the chassis can >>>>> move >>>>> freely in the global Z direction, but not X or Y direction. However, the >>>>> actuator is applying a motion in X direction, but restricting motion in Y >>>>> and Z. That's why the screw is not moving in any direction. >>>>> >>>>> I suggest you play with some demos in the mbs folder, such as >>>>> demo_MBS_motor.cpp or demo_MBS_crank.cpp. The visualization can help you >>>>> better understand how joint frames are defined in Chrono. You can also >>>>> have >>>>> a mbs model of the screw setup only (without the FSI terrain, but the >>>>> chassis-axel-screw setup). All you need is the code in the >>>>> CreateSolidPhase(). Again, with the visualization, it's easier to figure >>>>> out what was wrong. >>>>> >>>>> For your second question, note that ComputeMassProperties() only has >>>>> the information of the obj mesh, which is the geometry of the object, >>>>> whatever computed has to be multiplied by the density to get mass and >>>>> inertia of the object. >>>>> >>>>> Thank you, >>>>> Luning >>>>> On Saturday, November 18, 2023 at 3:31:56 PM UTC-6 [email protected] >>>>> wrote: >>>>> >>>>>> Apologies, I uploaded the wrong cpp file. Attached is my latest one. >>>>>> >>>>>> On Saturday, November 18, 2023 at 2:30:51 PM UTC-7 Mohammad Wasfi >>>>>> wrote: >>>>>> >>>>>>> Thank you, Luning, >>>>>>> >>>>>>> I have a few more questions that I hope you can answer for me. >>>>>>> >>>>>>> 1- In the single-wheel demo, the wheel's movement is restricted in >>>>>>> the x-direction, and the wheel is allowed to move in the y-direction. >>>>>>> However, for this simulation, I am trying to change the movement >>>>>>> restriction for the screw from the x to the y direction and allow the >>>>>>> screw >>>>>>> to move in the x-direction. I have tried to change multiple things but >>>>>>> nothing seems to work as I intended. Right now, it seems that my screw >>>>>>> is >>>>>>> restricted from moving in both the x and y directions. I am just trying >>>>>>> to >>>>>>> remove any restrictions put on the screw in the X-direction as the >>>>>>> screw >>>>>>> tried to propel itself and move. I was wondering if you could take a >>>>>>> look >>>>>>> at my code and tell me if you see such a restriction set. >>>>>>> >>>>>>> 2- Similar to the single wheel demo, I use the function >>>>>>> " ComputeMassProperties" to compute the screw mass, cog, and inertia >>>>>>> tensor. For some reason, the results returned by that function are >>>>>>> different from what my CAD program provides for the same material. I >>>>>>> was >>>>>>> wondering why that is. >>>>>>> >>>>>>> Example: >>>>>>> *Computed mass from code:* 0.00078467 ( I am not even sure what the >>>>>>> units of this should be. All parameters I used had units of kg/m/etc. I >>>>>>> assume that this is supposed to be kg. However, It is a very small >>>>>>> value >>>>>>> compared to what CAD provides). >>>>>>> *computed mass from CAD*: 1.71 kg >>>>>>> >>>>>>> >>>>>>> Thank you so much, >>>>>>> >>>>>>> On Monday, November 13, 2023 at 10:09:42 AM UTC-7 [email protected] >>>>>>> wrote: >>>>>>> >>>>>>>> Hello Mohammad, >>>>>>>> >>>>>>>> From the error message, the job was terminated for exceeding time >>>>>>>> limit, meaning the job is still running, it just takes a very long >>>>>>>> time. >>>>>>>> From the output message, the FSI solver did not get initialized >>>>>>>> either. >>>>>>>> Your FSI parameters look good to me >>>>>>>> >>>>>>>> Without running your simulation, I think it's likely that something >>>>>>>> is wrong with CreateMeshPoints(), which is for generating BCE markers >>>>>>>> that >>>>>>>> describe the screw geometry. Since decreasing resolution will take >>>>>>>> longer >>>>>>>> time to generate the markers, the program could still be computing the >>>>>>>> markers. The implementation right now doesn't scale well with higher >>>>>>>> resolution. It might also got stuck in some infinite loop ... I will >>>>>>>> need >>>>>>>> the screw geometry to look into this more. >>>>>>>> >>>>>>>> You can also generate the BCE markers yourself, and read the points >>>>>>>> in the FSI program, then attach them to the screw body using >>>>>>>> AddPointsBCE(). That way you have control over how to place the grid >>>>>>>> points >>>>>>>> so it can capture the geometry. You can also speed up the process by >>>>>>>> parallelize your implementation. You only need to do it once. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Luning >>>>>>>> On Sunday, November 12, 2023 at 10:53:15 PM UTC-6 >>>>>>>> [email protected] wrote: >>>>>>>> >>>>>>>>> Thank you so much, Professor. I have tested the code with some >>>>>>>>> other initial spacing values and it seems that the code starts >>>>>>>>> working >>>>>>>>> again when I set my initial spacing value to 1.5*particle diameter >>>>>>>>> (originally, the initial spacing value was set to be 0.0033m while >>>>>>>>> the >>>>>>>>> particle diam is 0.003m). It would still be helpful to look into why >>>>>>>>> the >>>>>>>>> code froze and no errors were outputted whenever you have time for >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Thank you so much for all the help, >>>>>>>>> >>>>>>>>> On Sunday, November 12, 2023 at 1:00:57 PM UTC-7 Dan Negrut wrote: >>>>>>>>> >>>>>>>>>> Mohammad – we’ll try to take a look, things are backed up, >>>>>>>>>> hopefully we can help in some way… >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> --------------------------------------------- >>>>>>>>>> >>>>>>>>>> Bernard A. and Frances M. Weideman Professor >>>>>>>>>> >>>>>>>>>> NVIDIA CUDA Fellow >>>>>>>>>> >>>>>>>>>> Department of Mechanical Engineering >>>>>>>>>> >>>>>>>>>> Department of Computer Science >>>>>>>>>> >>>>>>>>>> University of Wisconsin - Madison >>>>>>>>>> >>>>>>>>>> 4150ME, 1513 University Avenue >>>>>>>>>> >>>>>>>>>> Madison, WI 53706-1572 >>>>>>>>>> >>>>>>>>>> 608 772 0914 <(608)%20772-0914> >>>>>>>>>> >>>>>>>>>> http://sbel.wisc.edu/ >>>>>>>>>> >>>>>>>>>> http://projectchrono.org/ >>>>>>>>>> >>>>>>>>>> --------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *From:* [email protected] <[email protected]> *On >>>>>>>>>> Behalf Of *Mohammad Wasfi >>>>>>>>>> *Sent:* Sunday, November 12, 2023 1:42 AM >>>>>>>>>> *To:* ProjectChrono <[email protected]> >>>>>>>>>> *Subject:* [chrono] FSI module >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am trying to create a simulation based on the single-wheel >>>>>>>>>> demo. In my simulation, I am using a screw instead of a wheel. I >>>>>>>>>> started >>>>>>>>>> with changing the way the material properties are imported into the >>>>>>>>>> simulation. Everything worked fine as shown in the attached video. >>>>>>>>>> However, >>>>>>>>>> now, I am trying to reduce particle diameter ( as well as initial >>>>>>>>>> spacing). >>>>>>>>>> The simulation seems to freeze at the beginning and no error is >>>>>>>>>> printed. I >>>>>>>>>> was wondering if more insight could be provided into why the >>>>>>>>>> simulation >>>>>>>>>> freezes when reducing the particle diameter with no error printed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you in advance for your help, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 [email protected]. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/projectchrono/239386b1-d155-40a8-bf1c-6999db12484fn%40googlegroups.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/d/msgid/projectchrono/239386b1-d155-40a8-bf1c-6999db12484fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/c9340790-349c-4e49-9635-a9c9545c198bn%40googlegroups.com.
