Support of origin tag inside inertial

[wxmerkt]

Hi! I've realised that when adding an origin tag inside an inertial I quickly get a segmentation fault. Is the origin tag for inertial supported?

Edit: I confirmed that the addition of the origin tag inside an inertial element is the change that causes the simulator to crash. The tag in question is <origin rpy="1.57 0 1.57" xyz="0 0 0"/>.

Thanks, Wolfgang

[jhwangbo]

Can you share the urdf?

[jhwangbo]

anymal model also has an origin tag. not having the tag will simply set it to zero and identity rotation. So what you see is a bug, either in raisim or the urdf.

[wxmerkt]

Sadly, I cannot share the URDF. I tried replicating the same behaviour with the included Anymal URDF by rotating the base inertia - however, there it works. Since the included Anymal URDF has a heavily reduced collision model (no shank, no hip), I wonder if that is related.

We make heavy use of ignoreCollisionBetween to ignore collision pairs based on an SRDF. The segmentation fault happens on impact with the ground, and when calling getContacts, many contact pairs are included that should not exist (that are excluded explicitly using ignoreCollisionBetween), e.g., base and LF_HIP. However, this behaviour only gets triggered when the origin tag has a rotational part. Removing the <collision> tag from the hip does not help either - we continue to get the spurious contact.

Our base inertia is as follows:

<mass value="15"/>
<origin rpy="1.57 0 1.57" xyz="0 0 0"/>
<inertia ixx="1.13997384447" ixy="0" ixz="0" iyy="1.16726645833" iyz="0" izz="0.151781969474"/>

Without the rpy component, there are no spurious contacts and thus no wrong impulses and segmentation fault (from a dead getImpulse pointer) - with the rpy component we have tons of random, explicitly ignored, contacts that can result in dead getImpulse pointers.

[jhwangbo]

can you make a simplest code that reproduces your error and run Valgrind on it? This issue seems like a memory error. I can also sign an NDA for the URDF.

[wxmerkt]

I spent some more time trying to create a minimum working example, and was not able to do so. E.g. by rotating the inertia in the Anymal URDF. It seems to be very specific to the URDF we are using. It works without the rotation in the inertia, and crashes with memory issues as soon as the rotation is added.

I will close the issue for now, especially as I cannot reproduce it with a modified Anymal URDF.

[jhwangbo]

you can run valgrind and copy paste the error list. I might have a chance to resolve it if the bug is indeed on RaiSim side

[wxmerkt]

I was testing this using raisimpy. The valgrind log unfortunately did not have any mention of raisim or raisimOgre, so wasn't really useful (the only mention of an invalid memory access was within boost, but it resolved improperly to libompl which wasn't even loaded).

I went ahead and modified the C++ example in raisimOgre to use our URDF and nominal joint configuration: Here, it just flies off and the screen goes black (also the checkerboard disappears), but there is no segmentation fault - a big difference though is that in Python I am calling getContacts and then getImpulse on each contact:

Here's a gdb backtrace from the crash using raisimpy - the crash happens due to accessing getImpulse on a dead pointer:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:291
291     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:291
#1  0x00007ffff648ecc3 in raw_array_assign_array (ndim=1, shape=<optimised out>, dst_dtype=<optimised out>, dst_data=0x5555561b7bb0 "", dst_strides=<optimised out>, 
    src_dtype=<optimised out>, src_data=0x1031 <error: Cannot access memory at address 0x1031>, src_strides=src_strides@entry=0x7fffffffb880)
    at numpy/core/src/multiarray/array_assign_array.c:126
#2  0x00007ffff648f93f in PyArray_AssignArray (dst=dst@entry=0x7fffebc68580, src=src@entry=0x7fffebc68530, wheremask=wheremask@entry=0x0, 
    casting=casting@entry=NPY_UNSAFE_CASTING) at numpy/core/src/multiarray/array_assign_array.c:395
#3  0x00007ffff649c2bf in PyArray_NewCopy (obj=0x7fffebc68530, order=<optimised out>) at numpy/core/src/multiarray/convert.c:589
#4  0x00007fffd6820cff in ?? () from /home/wxm/dev/install_ws/install/lib/python2.7/dist-packages/raisimpy.so
#5  0x00007fffd6820e22 in ?? () from /home/wxm/dev/install_ws/install/lib/python2.7/dist-packages/raisimpy.so
#6  0x00007fffd6821059 in ?? () from /home/wxm/dev/install_ws/install/lib/python2.7/dist-packages/raisimpy.so
#7  0x00007fffd6867c70 in ?? () from /home/wxm/dev/install_ws/install/lib/python2.7/dist-packages/raisimpy.so
#8  0x00007fffd681ac39 in ?? () from /home/wxm/dev/install_ws/install/lib/python2.7/dist-packages/raisimpy.so

And the frozen window when the crash happens:

[jhwangbo]

This segfault occurs due to a smart hashing algorithm that ODE uses (apparently not smart enough). The cause is likely to be the collision geometry. When the solver gets an unrealistic collision geometry, the integration becomes unstable. This is as far as I can tell without checking the urdf...

[wxmerkt]

Thank you for the insights. We may try primitive shapes (cylinders/boxes) for the legs. :-)

The odd thing is... it is absolutely fine with these collision shapes as long as the inertial element does not have a rotation component.

[rohanpsingh]

Hello, @wxmerkt did you figure out why the segfault was occurring? Was it solved on using primitive shapes for collision?

[wxmerkt]

I ended up changing the URDF to no longer have a rpy component in the origin of the inertial tag.

[jhwangbo]

@rohanpsingh if you can reproduce the error, please share your code and the urdf file. I am willing to diagnose the issue

[rohanpsingh]

Unfortunately, I too cannot share the URDF file. However, I was able to get past the segfault if I use primitive shapes for collision instead of .obj meshes (I tried using simple geometry for some joints and removed collision tags altogether for the rest and the segfault doesn't occur). Also, when I tried removing rpy component in the origin of the inertial tags (as pointed by wxmerkt), the segfault remains.

So perhaps in my case the problem was that the collision meshes were too fine.