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/1c3841fc-47b8-4ccb-abf7-1aaea0313666n%40googlegroups.com.
