-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support import of URDF models #547
Comments
I've started the work in a private branch. |
Can you summarize what is working and what needs to be done ? |
Done. |
for collada meshes, you can have a look at |
Severin pointed out this issue to me on the ros-users mailing list, as I am working on a Blender add-on for robot modelling called Phobos (https://github.com/rock-simulation/phobos). As for multiple DoF, I'm not sure if there really is a problem. There are only two types of joints in URDF with more than one degree of freedom: planar and floating. Floating is not a real mechanical link as far as I understand it as it allows 6 DoF, and planar only allows movement on a plane or 2 DoF. Thus for instance two rotational DoF at the same position would have to be modelled with two links and two joints anyway in URDF. Which parenting method are you using? This was a bit of an issue for us until we figured out that Blender recently introduced the |
@kavonszadkowski In its current state, the URDF importer does not yet parent meshes to bones. I'm still struggling with a correct way to represent the armature. The issue I call "multi DoF" issue is not really a multi-DoF joint issue in URDF: as you said, only planar and floating are real multi-DoF joints, and those are special anyway. |
@severin-lemaignan I haven't quite figured out yet how these parenting options relate to the Anyway, this should allow you to put multiple joints with arbitrary axes at the same origin in theory, in practice I haven't really tested it thoroughly. |
Hum, yes, interesting idea. I'll check that. |
I'm wondering if you guys have made any progress on this as the idea was floating around in the Phobos project to maybe switch to one-armature-one-URDF at some point. |
As far as I'm concerned, I've not worked on URDF in MORSE since last year. |
Bump need this for Pepper :D |
I've reviving this work a little, to add initial import of Collada meshes: 28dde04 |
Just a short update. @jbaudisch has been doing a lot of work lately on the URDF import, and complex models like the Meka robot can now be imported directly from their URDF: Still not complete (in particular, @jbaudisch has introduced several changes in the way the armature is built which might require some changes to the armature actuator + some other models like Pepper still have scaling issues), but making good progress. To test:
|
This is sooo awesome. Thanks a lot |
Hi, when trying to import the Pepper urdf I get the following error: Read blend: /usr/local/share/morse/data/morse_default.blend I am using Blender 2.79. Could you please tell me whether the problem is on my side or is it the current version? |
@gabinsane: to import the URDF model, your need a Builder script that reference your URDF file. See https://github.com/severin-lemaignan/morse/blob/urdf/doc/morse/user/urdf.rst |
@severin-lemaignan I followed the link you gave https://github.com/severin-lemaignan/morse/blob/urdf/doc/morse/user/urdf.rst to add my robot urdf file but it still showed error same as Gabinsane. |
Hi @severin-lemaignan and others, I have been able to load the URDF file of my OAT Viper s60 robot using @severin-lemaignan's branch. I did some minor modifications related to ROS_SHARE_ROOT because the URDF loader was failing to find the meshes of my robot (see https://github.com/drm0hr/adept_experimental/blob/master/adept_s650_support/urdf/s650.urdf), for my understanding this part of your code is a temporary solution. The script that loads my URDF:
However, I see the robot correctly using 'morse edit' but when I use 'morse run' the links are unmounted. Do you know why this happens? Now I would like to control it using an armature actuator but I don't know how to do it. I am following the armature actuator examples in the documentation and reading the source code to check how this could be done. What I am trying:
Other way:
As neither approach is working, I have saved the simulation that loads the robot using the URDF file as a .blend file. Now I can create a new armature as KukaLWR but using new .blend file.
The simulation works when I don't use ArmaturePose() sensor, if I add this sensor the simulator crashes due to an "AttributeError: 'Armature' object has no attribute 'gettime'". In any case the links of the robot are unmounted when I start the simulation using 'morse run'. Could someone provide me some clues to solve my problem? Thanks in advance. Kind regards, |
@dgerod thanks for testing the branch! Quite clearly, many bugs remain :-) |
Sure, I am going to start digging the issue now. And I will let you know my conclusions. However, as this is my first time analyzing this type of defect, I would like to know what approach you use: debugging, adding traces, etc. In fact, I have added a Q&A issues asking people how they develop code in MORSE, see #801. Thanks. |
First, I have created a branch with my modifications: https://github.com/dgerod/morse/tree/my-work/urdf. And I am doing some tests now. [1] Difference between a Kuka LWR load using blender file provided by MORSE (left) and using URDF loader (right). The direction of the bones in the one using URDF are following joint rotational axis but in the original one no, and the bones are smaller in the second one. Do you think this is OK? For my understanding this is OK but I don't know why bones in original Kuka LWR are defined in a different way. After checking I understand that this is the bones generated by URDF class are OK, my problem is around which axis of the bone it must rotate. In my robot this is ZYYZYZ but what is happening is that all the rotations are around X axis. I have been debugging the code and I have realized that a channel in armature is returning incorrect about around which axis a bone could rotate,
Above code returns True for all DoFs of all my robot joints. However, it should only return true for the Z axis in the case of the first joint. Due to that all rotations are apply always to the X coordinate of the bone. I have added a screenshot of the variables when I am debugging the code. The After locking two axis of each joint according to ZYYZYZ configuration of my robot, the rotation of the joints are correct. So, I can move the robot now !!! However, what it still needs to be fixed is that links of the robot are unmounted when I start the simulation using 'morse run'. When the .blend file is load using 'morse edit', the robot is correctly mounted, there is no space between the links. [2] Now I am trying to load the blend file that is generated by the URDF loader so I have created two scenes to compare MORSE behavior. In the first one I am using the .blend file that I have generated using URDF:
While second one is using KUKA LWR default actuator.
Second one works while first one raises the error that is what I said in one of my previous comment: I have fixed the problem [2] after debugging MORSE, it was that the .blend file of OAT Viper armature had the 'RobotTag' property. After removing it and another property in main object of the .blend file, the 'load_simulation_3_1' approach is working. This problem was there because I imported the URDF file using Finally, what is your expectation of using URDF class? Do you expect to load always the URDF file when a simulation is started or a blend file is created so it is used for loading the simulation? At this moment I am working on the second option, let me know if I am using a wrong approach. |
Let me summarize my current situation of importing an URDF model. The approach I am using is to import a URDF file and store it as .blend file. For doing that I have to modify some properties of the .blend once I stored it.
[Q1] However, the robot links are incorrectly mounted when I am in run mode but correctly mounted in edit mode, in run mode there are some space between the robot links. This situation also affects to the how a joint is rotated, this is done around an axis that is not in the center of the joint as I have said previously. Could someone help me to solve this problem? This situation of unmounted links of robots is happening with all URDF models that I have tested. I think that some properties in the .blend file should be removed (e.g. bone transformation) as it seems that some translation is applied two times to the links and/or joints. [Q2] Finally, to be able to load the URDF file I have done modifications related to look for file paths in the URDF module, you could see the modifications in my branch: https://github.com/dgerod/morse/tree/my-work/urdf. And I should update the importer so modifications I have done by hand in the .blend file (step 3) are done there. But, I don't know how I to access these properties through Blender Python API. |
Finally I was able to load the model correctly mounted and the rotation of the joints are OK when I use it in Morse. However, to be able to do that I have to do several modifications in the .blend file after importing it. Please, find attached the URDF file I am loading and the .blend file as a zip file. My .blend model has the following parameters:
While the parameters generated directly by the URDF importer are:
Difference between my working .blend model and one importer by URDF:
After checking the code, I am able to fix somethings as correct Inverse Kinematics parameters in the bones by using "self.posebone.lock_ik_x" and remove relative parenting using "armature.data.bones[joint.name].use_relative_parent". However, the big issue is how the position of the bone is calculated in "build_editmode()" method of the URDF importer and how is calculated the position of the links in "add_link_frame()". So, before modifying these two methods I would like to know if my approach is correct or not. Could you, @severin-lemaignan, or other people let me know your opinion? Thanks. |
Just wondering if this could be of use: https://github.com/dfki-ric/phobos |
MORSE should be able to import URDF description of robots, including the full kinematic chains.
The spec is available here: http://wiki.ros.org/urdf/XML
Support for some of the Gazebo extensions could make sense as well.
Design choices for the URDF importer
URDF joints map to bones, URDF links map to objects whose origin is an empty located at the joint's bone's HEAD, and whose orientation match the URDF's joint frame.
Since Blender does not support zero-lenght bones, joints connected by zero-length links are combined into a single Blender bone (named
joint1>joint2>...
)Special care must be given to the definition of the URDF joint frame. In Blender, bones always have their own frame with Y pointing from the head of the bone to the tail of the bone. X and Z can rotate around this axis with the 'roll' parameter. This is especially important because the joint rotation axis (for revolute joints) needs
to be one of the X, Y or Z axis of the Blender bone. Hence, to match the URDF joint axis (defined as a vector in the URDF joint frame), the Blender bone must be carefully build.
Here the proposed procedure:
for each joint:
Vj
be the vector (joint origin, childjoint origin)
Mj
is the transformation matrix from the parent joint frame tothe joint frame
Vj
exists and if the joint axis is orthogonal toVj
,create a Blender bone that match
Vj
the rotation axis, and if possible, coplanar with the parent and/or
the child bones
X
axis is aligned with the joint axisMj
,parent it to the bone
After following this procedure, the rotation axis is always the
X
axis of the bone.Note that one link may be connected to several other (child) links at different places: corresponding Blender bones may not be "visually" connected.
Multi-DOFs
Attention: this procedure does not provide support for multi-DoFs links! For multi-DoFs links, a maximum of 3 DoFs can be supported, as long as they correspond to independant rotations on independant axis (ie, rotations on mutually orthogonal axis). The orientation of the bone must then be computed such as each of these rotations axis match one of the bone main axis.
If more than 3 DoFs are needed, or if the rotations are not independant, then an artifical non-null link must be added. If this can be done automatically has yet to be researched.
If the joints at the end of the kinematic chains (ie, joints whose child links are not connected to any other link) are fixed joints, we consider them as 'static frames' and we do not create a bone for them (only an empty is created, named after the link).
Current state
The text was updated successfully, but these errors were encountered: