I get some strange contact behavior, please see the attached movie at speed 1/10. I attach also the model file (I know it is not most elegant). The red ball (defined as "target") sometimes seems to penetrate the arm. The movie is produced using some code in mujoco-py.
Something similar happens to me, I have a token (plink chip) that sometimes penetrates a solid object in my model during simulation.
You are using friction="5.0". Large friction combined with pyramidal friction cones has the counter-intuitive effect of making the contact soft in the normal direction. Try setting the friction to something smaller (no more than 2) and also use the elliptic solver. You can also read these sections in the documentation: http://www.mujoco.org/book/computation.html#soParameters http://www.mujoco.org/book/index.html#Soft Note that MuJoCo 1.50 has better solvers, and OpenAI just released their Python wrapper for it, so you should upgrade. You also have: mass="0.3t" in the target body. Remove the "t"
Hi Emo, Will you please look at my model. This is a plinko simulator. The plinko token sometimes goes through the plinko walls. It varies on the starting position of the token. I've loaded an example where the chip goes through the bottom box of the model. It also does it when '<body name='plinko-token' pos='-.45 -.05 0.9'>' Also, you should see what happens when '<body name='plinko-token' pos='-.455 -.05 0.9'>' it's super interesting (in an odd kind of way)
Interesting model! And now I know what a plinko is In simulate.cpp, you can pause the simulation and then use the arrow keys to advance frame by frame. Enable the rendering of contacts (press C) to see what happens when the disk penetrates the box. The collision detector is making up a contact normal that points in a weird direction, so the contact force is not really pushing the two objects apart. This is some artifact of the convex collision solver I am using (MPR as implemented in libccd). I have noticed that it has issues with objects with very large aspect ratios... I fixed the issue by setting the timestep to 1 ms and using the RK4 integrator. You could also try replacing the disk with an ellipsoid. Actually for this particular model, you don't need the bottom box to be a box, just make it a plane (plane collisions always work well). The front and back walls can also be planes. I will save this model in my collection of strange models and play with it next time I get around to improving the solvers.