I have attached my xml file and a video of the simulation using basic.cpp . In the video, if we observe closely the box while its interaction with the arm goes into the plane a little bit and comes out and the same happens with the arm and box. Is this normal or some problem with visualization ? I haven't changed the contype and conaffinity parameters from default. I need your opinion about what causes this behavior.
The XML references meshes and another XML which are missing so I cannot test it. If you can compile it into an MJB that would be better (with the 'compile' command line tool). Try increasing the number of solver iterations to say 200 and see what happens. The actual number of iterations will normally be smaller because the tolerance threshold will be reached. But sometimes it needs more iterations, and if the maximum is too small this can cause non-physical solutions. Also, you have default joint damping=1 which is applied to all joints, including the free joint between the box and the world. You are specifying the damping on all the robot joints directly anyway, so you could remove that default. Or, set damping=0 in the free joint. It doesn't look like a visualization problem; something about the model parameters is causing this behavior.
I have attached the corresponding .mjb file for your testing. I have also attached a simulation video after changing the free joint's damping to 0. Having the old damping values and increasing the no. of iterations to 250 doesn't change anything in the simulation it looks like the first video I sent you.
Hi.. Emo... I would really like your help in figuring out the causes of such an behavior [arm partially going into the object] as seen in the previous 2 videos. I have attached my .xml, .mjb file of the model and also tried the solutions given by you in the previous reply. Please write to me if you are in need of any more details. Thank You.
Fascinating model This is not a bug in the code, but unphysical behavior arising from a poor conditioning. Ideally the solver will be able to handle such cases automatically, and I am working on better solvers for release 1.50, so your model will be useful for testing. In the meantime, the XML and MJB models you sent have different issues. In the XML, you are setting the joint default damping to 1, and it applies to the free joint in the green box. This is a lot of damping for a light object. To get rid of this effect, set damping="0" in the free joint definition. In the MJB, the damping on the free joint is 0 but the mass of the green box is very low for some reason: 0.001. This makes the system poorly conditioned and complicates the life of the contact solver. So make sure the green box as no damping on its free joint and has reasonable mass. I made this change in the XML you sent, replacing all the meshes with boxes since I don't have the mesh files, and the simulation now behaves as expected.
Hi Emo....... many thanks for helping. Now, the simulations look realistic. I took your advice and made all the changes. My previous mistake was that I placed the mass parameter in geom tag and not in inertial tag. I have also attached 2 more videos with this reply. In these, videos close to the end of the simulation, the object keeps on moving till the end of simulation time. My guess is I have to add some friction parameters but I don't know which tag to use and whether add it to the box or to the plane. Note: As the filename indicates the damping of the free joint was 0.1 and 0 & mass of the box was 0.25Kg
Strange that it keeps moving. Can you try to set the mass to 1kg and see what happens? Also, what is the number of solver iterations you are using? Try something like 200 to make sure this is not a convergence issue. You could also increase the contact friction, or try some of the other solvers.
Thank You, Emo.... It works satisfactorily only with CG solver. In all other solvers, the box behaves in a weird manner.With default solver, the change of mass and contact friction[plane] increases and decreases the speed of object movement respectively whereas increase in solver iterations does not have any visible improvements in the performance.
Can you send your latest XML as well as the mesh files? I am currently working on new solvers, so this model would be good for testing. Have you actually looked at the solver convergence and number of iterations for CG vs PGS? PGS has linear convergence while CG can have supra-linear convergence depending on the problem; and if this is a poorly-conditioned system that might explain what you are seeing.
Hi Emo.... I have sent all the mesh files and xml files to your e-mail[todorov@roboti.us]. Regarding the solvers, I just had a look at the visual performance not any numerical value. In case of PGS and CG, in both arm and object interaction is okay but as I stated earlier the object keeps on moving with PGS and not moving in CG. While using other solvers, the object and arm interaction itself is not satisfactory.