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/d04b8220-13a1-4982-b90a-d9331c12c062n%40googlegroups.com.
