URDF Generator

[marg...@aldebaran-robotics.com]

Sorry I should have created a new thread.

Le mercredi 18 juin 2014 12:07:49 UTC+2, Armin Hornung a écrit :

On 2014-06-18 11:47, marg...@aldebaran-robotics.com wrote:

One question to all of you:

Do you all agree with the naming used at https://github.com/iaslab-unipd/nao_description/blob/master/urdf/nao_robot_v4.urdf (including the fingers numbering) ?

I think the minimum requirement should be to follow what's defined in the standard to ensure interoperability, where applicable:
http://www.ros.org/reps/rep-0120.html

E.g. torso, wrist, and gripper frames are missing or named differently.

I agree about the REP120 naming, it's done in this version and I don't think about changing it.
I should have been more precise : There was a thread about the way of naming the other (not REP120) links.

2. The names for links in the URDF files from Armin or Stefano may be more human-friendly (eg. LElbow and LForearm instead of LElbowYawLink and LElbowRollLink for between LElbowRoll joint).

 Does everybody agree about naming all no-REP120 links with more human-friendly names ? If yes, do the names in this urdf https://github.com/iaslab-unipd/nao_description/blob/master/urdf/nao_robot_v4.urdf seems good to you ?
(Neck instead of HeadYaw, Head instead of HeadPitch etc)

[Konstantinos Chatzilygeroudis]

Hello Mikael,

Welcome to the community.

Here are some thoughts:

L/RHand are not links, but joints. According to Aldebaran's documentation, you control the fingers through ONE joint with values from 0.0 to 1.0. You can achieve that through mimic joints, see my implementation.

Also, I think that using ROS functionalities (like xacro) is the best for the ROS community and the URDF will become far more modular and easily edited/read.

Best,
Konstantinos

P.S.: I didn't see there was a new thread. Sorry for re-posting..

[marg...@aldebaran-robotics.com]

Hello,

I agree for the L/RHand wihch are joints and not links, I added them because I didn't have the relevant frames for the fingers but they shouldn't be there and will be removed on the next version.

About xacro, the point is that Aldebaran will publish complete URDF files used to generate their documentation. The goal of this script is to transform these AL-URDFs into ROS-URDFs. In this logic there is no use for xacro, furthermore the parsing library used doesn't allow to introduce xacro tags into the URDF.
But I totally agree that xacro allow smaller and more readable files than pure URDF, it will just be much more complicate to convert a complete URDF into a generic xacro. That's why we chose to generate an URDF without xacro.

The final script will allow to generate accurate urdf for any version of NAO so we shouldn't have to read/modify urdf by hand anymore.

Thanks for the reply,

Mikael

[Vincent Rabaud]

Nothing is fixed in those decisions and that's why we want more feedback: is there a need for clearer URDFs if they are auto-generated ? probably :) but how much ? We could:

- add comments in the URDF

- split it in several files (is that useful too for combining robot parts ? Maybe we should just have one URDF for the body, and one for the HEAD)

Do not hesitate to add those to the TODO list through a PR or speak up here. Everything is doable, we just want to list all the requirements to prioritize (and make sure they are necessary).

You can also help develop the code as the original Aldeb URDFs are in the binary.

We have Mikaël working full time on ROS/NAO until the end of the year, so we should make good use of him :)

--
You received this message because you are subscribed to the Google Groups "ROS Sig Aldebaran" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-aldeba...@googlegroups.com.
To post to this group, send email to ros-sig-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ros-sig-aldebaran.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-aldebaran/7002a9fe-ed10-40e9-80a1-f743aa14b5ba%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[marg...@aldebaran-robotics.com]

Hi everybody,

I created a new version of the generator based on a standard xml.minidom library.
https://github.com/keulYSMB/xml_based_urdfparser

New features :
export xacro files :
     - legs.xacro
     - arms.xacro
     - head.xacro
     - torso.xacro
     - robot.xacro
Model valid and can be visualized with RVIZ
New naming agreement (Head,Shoudler,Elbow, Bicep, ForeArm, Pelvis, Tibia....) instead of aldebaran documentation names


To do :
    - Get fingers and sensors frames from Aldebaran official URDFs
    - Add transmission and gazebo tags to the library
    - Get transmission information from official URDFs
    - Get L/RHand from documentation
    - Add mimic joints information for pelvis and fingers

Other features:
     - create new meshes with color and texture for the nao (any of you has done it already ?).
     - simulate new model in gazebo

Any additional feature you like ? any feedback or remark ? Thank you for sharing !

[Konstantinos Chatzilygeroudis]

Hello,

Nice work!!

First remarks:

• Add xacro property to choose between nao_meshes or simple cylinder/boxes (that defaults to nao_meshes). It is good to have that option, because simulation with nao_meshes is somewhat slow. See my implementation for reference.
• Make nao_meshes integration a bit more generic. Now, in order for someone to use it, he/she must rename all the filenames in the xacros. See my implementation for reference.
• Also, as Gazebo does not properly display .obj/,ply files, it'd be nice if there was a script that converts nao_meshes to collada files automatically. Maybe this is work on nao_meshes, so it can export them in the right format right away.
• To simulate your model in Gazebo, you need to create a controller manager and appropriate controllers. I have already done it in my nao_dcm repo. So, I can help you in that direction and save you some work-hours. ;)
  

I will look at your work more thoroughly next week and I will post new remarks (if any).

Keep it up.

Best,

Konstantinos

[marg...@aldebaran-robotics.com]

Hi, Thank you for your fast replies.

@Armin : I saw that you have materials in order to display cylinders in different colors but is this also working with real meshes ?

              Vincent is abroad all week, could you send me your nao_description2 package to have a reference ?

@Konstantinos:

1) When you call my script in command line you can specify several parameters including the kind of meshes you wanna use. e.g. -m meshes will look for the package on your computer and put cylinder if nao_meshes is not installed (or not in your ROS_PACKAGE_PATH). So you don't have to modify any xml file ever. Do you prefer me to add a xacro property anyway ?

2) Same remark as before, you shouldn't have to rename anything because the script will find the meshes on your computer and fill the urdf file accordingly (with the right path)

3) Creating a mesh converter in my todo list, I will tackle that as soon as I have a "quite complete" URDF generator that can be useful to all of you

4) Yes I'm using your repo as a reference for the convention of my outputs urdf files. My goal is to be able to get every actuator and transmission information from aldebaran files a automatically create the controllers accordingly

I hope that I will have a model simulated in Gazebo in the next few days (if I can get the information I need from the Aldebaran's URDFs), I'm currently adding all the missing tags to the parser library (for now there is no Transmission or Actuator classes) to be able parse these URDF elements automatically.

Thank you for these feedbacks. Don't hesitate to contact me or give me other clues of what can be useful.

Regards,
Mikael

PS: I just realized that I didn't update the nao_meshes package in order to match the new names. Let me know if you need them right now, otherwise I will export them once the textures/colors are added to the meshes.

[marg...@aldebaran-robotics.com]

Hi everybody,

I updated the version of the generator : https://github.com/keulYSMB/xml_based_urdfparser
The meshes with the new naming agreements can be found in here : https://github.com/vrabaud/nao_meshes/tree/master/binaries version 0.6.2
The original AldebaranURDF file used for generation can be found in here : https://github.com/keulYSMB/AldebaranURDF/tree/master/bin

The script can now generate model for both rviz meshes (.obj,.ply) and collada meshes (.dae)
I spawned the model in RVIZ and in Gazebo and it seems to behave correctly.

The new features are :
- the parser can now handle Transmission, Actuator and Gazebo elements
- export xacro file for gazebo tags
- export all links in the right files using kinematic chains

Missing from aldebaran library:
Frames:
- finger/toes frames
- sensor frames

Joints:
- R/LHand joint,
- mimic joints

Transmission:
transmission tags from the official Aldebaran URDFs

Features to add
- Add rospack commands in the output xacro files instead of the full path of the meshes
- Add comments to the output xml file (let me know if you find this not very useful)
- Try a real simulation in Gazebo with a controller
- Handle both NAO, Pepper and Romeo

Tools to develop:
- mesh converter
- create meshes with textures

As before please feel free to comment and give ideas about anything regarding the urdf generation.


I also have a few questions for you, I'm really new to Gazebo and I'm afraid to be missing something :
- How do the gazebo plugins work ? I didn't add this to the library because parsing these seems endless because of the various type of element it can contain.

They won't be in Aldebaran Official URDF files because they don't use them. I don't know how to generate the right ones in the right place.
- Can you explain me how did you pick these plugins, why do we need them ?
- Do you think that you will need to add some of them on the future versions of your models ?

Regards,

Mikael

[Konstantinos Chatzilygeroudis]

Nice work Mikael,

Regarding the Gazebo plug-ins, they are needed if we want to simulate the sensors (cameras, imu, tactile, touch, force e.t.c.). There's no other way as far as I know to simulate sensors in Gazebo via ROS. We don't need to add some of them or new ones, we need to develop and code all the needed plug-ins to simulate all Nao built-in sensors. If someone adds something to Nao (like I have added Xtion), he should add this plugin to a separate xacro/urdf and load it along with Nao's. We could provide a list of sample files with the most often used devices with Nao for ease.

Also, I prefer using the default Gazebo plug-ins (provided by gazebo-ros-pkgs), but some of them (e.g. IMU sensor) do not work properly.

Keep up the good work!

Best,
Konstantinos

P.S.: I will look at your implementations more thoroughly next week for more feedback. Because I am in the middle of exams right now.

[marg...@aldebaran-robotics.com]

Ok, thanks for the explaination,

Can you people tell me if you already have all the plugins needed ? If not, could you give us a list of the missing plugins ?
We will try to think of a way to develop them together.
If the plugins are always the same and based on the sensors, I should be able to generate automatically gazebo tags with the right plugins (as soon as I can get the list of sensors for a given nao model).

PS: No worry about the implementation, for now it still needs to be cleaned and optimized

[Konstantinos Chatzilygeroudis]

Well,

In nao_dcm I have implemented so far (for the built-in sensors of Nao):

• The 2 cameras (some parameters may need tuning)
• IMU sensor (the Gazebo plugin is not properly working)
  

I am planning to implement in the forthcoming weeks:

• Sonars
• Force sensors

Also, I have implemented the plugin for using Xtion or Kinect with Nao (parameters are dummy right now).

So, I am missing:

• IRs
• Microphones (I don't know if Gazebo has this type of plugin - we may not need them in simulation)
• Sonars
• Force sensors
• Bumpers
• Tactile (we may not need them in simulation though)

If anyone has implemented some of these, this is a good time to step up.

Best,

Konstantinos

[marg...@aldebaran-robotics.com]

Ok nice ! Thanks Konstantinos

I modified the library to allow parse and generate any gazebo tag/plugin/sensor. It's a huge amount of code only for gazebo and I find it very ugly, I will try to figure out how I can improve it,
Now that we have a "quite good" autogenerated model I will try to use the gazebo controllers to make a real simulation.

Next steps:
    - create a gazebo controller for nao and run an actual simulation of nao walking
    - texture the meshes
    - implement the missing sensors plugin
    - create a script to convert meshes

Pending:
    - generate automatically the plugins for each sensor (depends on the intel available on aldebaran's urdf)
    - add mimic joints, fingers, toes, transmission, R/LHand frame ...
    - get sensor list from Aldebaran URDF and generate gazebo tags accordingly.

I will try to clean and update a new version in a few days.

Regards,
Mikael

[Konstantinos Chatzilygeroudis]

Next steps: 
    - create a gazebo controller for nao and run an actual simulation of nao walking

I have already done that. I can't make it work. The main problem for making it work is that Aldebaran's Simulator SDK only provides angle (position) actuators for Nao, but Gazebo physics do not work when using setAngle functions to set joint commands. Gazebo can only work with either angle commands along with PID controller for each joint (we don't have the pid values that can make it work as the real robot) or effort commands for each joint (Aldebaran's Simulator SDK does not provide such information). So far, I have not found any solution to that.

I have contacted Vincent about this problem and talked to Tully Foote and Carlos Aguero. I am also waiting answer from Nate Koenig about this (and other problems) on Gazebo.

Best,

Konstantinos

[marg...@aldebaran-robotics.com]

I will try to see with the guys working on the integration of nao on webots to have more information about that and see how we can avoid generating configuration file with multiple PIDs which might not reflect precisely the motion of the robots.
Does anybody succeeded to control Nao by implementing a ros_controller ? I've seen some videos online with nao walking in gazebo, does anyone know anything about it ?

I updated the version of the library and the generator. The lib is now divided into two files :
- urdf.py to process the tags defined by ros
- bazeboUrdf.py to process any gazebo tag
You just need to run "python setup.py install" to use it as a python module

Regards,

Mikael

[Konstantinos Chatzilygeroudis]

I have looked into Webots .proto files and there's no information about PID values. Webots allows for setAngle-like commands without the physics being broken. But ask the guys working on Webots for clues.

Concerning Gazebo, I have created a Gazebo plugin fully working with the Aldebaran's API. When physics are switched off, I am able to fully control Nao via Choregraphe for example. (Although the robot stays stationary - no physics). When physics are switched on, robot goes to space as I am using setAngle to set joint values.

I have succeeded to control Nao by implementing a ros_controller (see nao_dcm). I don't know how to combine NaoQi with ros_controller though. I don't think it can be done, because ros_controller gets trajectories as input and provides commands to the joints. That is exactly the same functionality as NaoQi (NaoQi has many more though - predefined walk mode, behaviors, vision etc). So, you can use either the ros controllers or NaoQi. Here's a brief comparison of the two approaches:

There are 2 totally different approaches upon developing a ROS driver to Nao (and any robot with a full functional API already provided):

The first approach is to depend on the pre-developed modules provided by the (NAOqi) API. Following this approach has the following main advantages:

• You can use right away all the functionality provided by the API without any effort what so ever (almost no effort - would require some work for the integration but it is not comparable to the work required rebuilding all the functionalities from ground zero).
  
• There's almost no effort in writing the driver, as it is actually a wrapper to the API and not an actual driver to the machine.
  

On the other hand, this approach has the following main disadvantages:

• You need to find workarounds in order to implement even the simplest (driver) tasks in ROS, because you basically do not use ROS, but the (NAOqi) API. So, everything must be converted from ROS to NAOqi and vice-versa. This most certainly will lead to tedious and ugly code/workarounds. For example, if you want to use MoveIt! along with this driver, it would require that you implement or mimic the behavior of ROS trajectory controllers in order to convert the data to the (NAOqi) API format (which is similar but NAOqi cannot take commands directly from a ROS controller). Another example, is simulating Nao in Gazebo that requires developing a plug-in using Aldebaran's Simulator SDK (I have already done that..Will publish it the following days/weeks).
  
• You never really use the advantages of ROS and its features. For example, Nao has its own motion planning engine. So, when you issue MoveIt! to make a plan and send the trajectories to Nao via the (NAOqi) API, Nao will use its own motion planning engine to plan from point to point (or interpolate it), which is something you may not want.
  

The second approach is to heavily rely on ROS stacks and try to communicate with the lowest level of the API possible (because you cannot communicate with the machine - Aldebaran does not provide this information). Following this approach has the following main advantages:

• As you rely on ROS stacks, you get the most out of ROS and its features. You can use right away all of ROS capabilities with no effort (almost no effort - would require some work for setting up the prerequisites of each stack but it is not comparable to the work required finding workarounds for the API).
• As many packages exist on ROS for text to speech, object/face recognition e.t.c. it is pretty easy to mimic and extend all the behaviors/capabilities provided by the API (with the exception of biped gait generation - as far as I know).
  

On the other hand, this approach has the following main disadvantages:

• As no packages in ROS are available for biped gait (as far as I know), it would require that someone creates this capability (that's what I'm trying to do in my Diploma Thesis) which is no easy task and may lead to worse results than the one Aldebaran provides. The gait generated would be certainly different than the one Aldebaran provides.
  
• It would require more work on the integration to the machine of Nao (as Aldebaran does not provide heavy documentation in this direction). But most of the work in this direction is completed in nao_dcm. If we are able to fix the Gazebo issues, I believe there is really nothing more to add there.

As for the youtube video you posted, it seems to me that they have found pretty good PID values. It would be a good idea to contact them.

[Mikael ARGUEDAS]

Hi Konstantinos,

Thank you for this very useful information, I think we will focus on the first approach and use what is already implemented in NAOqi.

I will let you know as soon as I make any progress on this path.

Sorry for the multiple commits but here is a catkinized version of the parsing library and generator script https://github.com/keulYSMB/xml_urdf_parser. everything will be held on this repo for now on.

I will update the documentation as soon as I'm done implementing/validating the features that are still missing (automatic gazebo tag generation, frames, mimic joints ...)

Regards,

Mikael

PS: I will also start working on the mesh texturing in the following days. I will certainly need your expertise and knowledge to generate coherent,pretty and useful meshes.

--

You received this message because you are subscribed to the Google Groups "ROS Sig Aldebaran" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-aldeba...@googlegroups.com.
To post to this group, send email to ros-sig-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ros-sig-aldebaran.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-aldebaran/f21618ea-cf04-4101-8346-05b4f710ec74%40googlegroups.com.

[Séverin Lemaignan]

Guys,

First, I'm finally back from many experiments, with some time to dedicate to our beloved Nao.

Regarding URDF + Gazebo: it's difficult to catch up and know how to process/test things.

- first, could you create separate discussion threads for Gazebo?
- then, I *really* would like that the Nao URDF do not get polluted by Gazebo-specific tags/attributes. Gazebo is not the only simulator on the market, and it sometimes brings a lot of noise in the URDF files. So, as far as possible, please keep things cleanly separated.
- Mikael, could you update the README here https://github.com/keulYSMB/nao_robot/blob/devel/nao_description/README.rst to explain *all* the steps that need to be followed until I can see a Nao in RViz using robot_state_publisher. I'm getting confused with what is here:
https://github.com/keulYSMB/nao_robot/tree/devel/nao_description/bin , what is here: https://github.com/vrabaud/nao_meshes/tree/master/binaries , xml_based_urdfparser (which is a really weird name btw... urdf is xml, right?)
- regarding your old question on joint/link naming: I'll check when I'll be able to build the URDF file, but in my opinion, the most important point is: avoid any confusion. So links must have name that reflect they are links ('neck' for instance, sounds like a joint. Is it?), and if several DoF
overlap, the name of the link must reflect that as well ( xxxPitch, xxxYaw, etc).

Thanks for the good work!
Severin

[Mikael ARGUEDAS]

Hi Severin,

You're right I should create another thread dedicated to Gazebo.

For now the script I created outputs several xacro files. If you don't want the gazebo tags in your urdf (which is totally understandable) you just have to remove the macro xacro:include *Gazebo.xacro

I will update the readme shortly. I made several changes in the package and realized that because of the aldebaran policy of putting everything inside "installer with licenses" we get lost pretty easily. I'll let you know as soon as its done. I will let you know when the README is done.

About the name I didn't get any answer before so I sticked with "understandable" names :
links are named : Neck,Head,Biceps...

joints are named : LHipYawPitch, HeadYaw, LShoulderRoll

sensor frames are named : CameraTop_frame, LSonar_frame

and sensor joints : CameraTop_joint, LSonar_joint

[marg...@aldebaran-robotics.com]

Hi everyone,

The readme of xml_urdf_parser is updated. Let me know if you have any troube to use it.
If you are using xacro, the output files layout will look like that :
naorobot.xacro : xacro file including all the other xacro (the one you have to modify to remove gazebo and transmission if you don't want them in your output file)
Kinematics Links and joints :
- naoarms.xacro : links and joints from torso to hands
- naolegs.xacro : links and joints from torso to sole links
- naohead.xacro : links and joints from torso to gaze
- naotorso.xacro: base_link and torso
Sensors links and joints :
-nao sonars.xacro (other sensors will be coming soon and ideally allm of them will be declared in naosensors.xacro)

Gazebo tags :
- naoGazebo.xacro
- naoTransmission.xacro


To answer severin question about the name of the package : "xml_urdf_parser" I just wanted to highlight that I'm not using urdf_parser_py which is based on xml reflection. My script is based on xml minidom which allow me to creat xacro tags.


Let me know if you have any question about all this.

Cheers,
Mikael

[marg...@aldebaran-robotics.com]

Sorry I forgot to put the link of the package: https://github.com/keulYSMB/xml_urdf_parser
xml_base_urdf_parser will be deleted soon

[Séverin Lemaignan]

Ok, I better understand, thanks for the clarifications.

A few suggestions/questions:

- Looking at modify_urdf, xml_urdf_parser seems to be Nao-specific (or at least, Aldebaran specific). So, what about renaming the package into:
urdf_generator and move it to https://github.com/ros-nao? I may then send you a pull-request to clarify the xml_urdf_parser/README.md

or, even better, merge it into nao_description, and integrate the generation of meshes in the CMakeLists, so that when people install nao_description, it first automatically fetch the meshes and generate the URDF.
I can take care of the integration in CMake if you are not too confident with this part.

- you do not need to generate obj/ply: I recommend you to use DAE everywhere. RViz is perfectly happy with them, and this will allow you to easily create color materials. I can send you a model with materials/colors, either as Blender file, or as DAE.
- I would also suggest to generate by default xacro files for the whole robot, plus a nao.xacro with all part, but no gazebo, and a nao-gazebo.xacro with the gazebo parts.

Cheers!
Severin

> --
> You received this message because you are subscribed to the Google Groups "ROS Sig Aldebaran" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-aldeba...@googlegroups.com <mailto:ros-sig-aldeba...@googlegroups.com>.
> To post to this group, send email to ros-sig-...@googlegroups.com <mailto:ros-sig-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/ros-sig-aldebaran.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-aldebaran/9e731343-7146-4402-95a4-422dabc93a52%40googlegroups.com <https://groups.google.com/d/msgid/ros-sig-aldebaran/9e731343-7146-4402-95a4-422dabc93a52%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Mikael ARGUEDAS]

Yes this script is indeed aldebaran specific and you're right the goal is to put everything inside nao_description.

For the format of the meshes I agree to use dae for everything, we still need to specify the script if we want to use them is Rviz or gazebo (the scale of the meshes is not the same: 0.001 for rviz and 0.1 for Gazebo). Do you knbow any way to specify the scale in the mesh without having to generate one URDFs specific to the visualization tool?

Regarding the color, we would like to add nice textures instead of simple color to the meshes but I didn't have time to tackle that yet (neither Konstantinos). If you have any experienc on that matter we will really appreciate your help.

- I would also suggest to generate by default xacro files for the whole robot, plus a nao.xacro with all part, but no gazebo, and a nao-gazebo.xacro with the gazebo parts.

I agree with that too, I kept it this way because it was easier to develop but this will certainly be the case in the near future. I don't know when I will have time to do it, I would rather have a complete and functioning script (with all sensors, all mimic joints etc) before merging into nao_description.

No problem for the pull request, thanks for your involvement,

Cheers,
Mikael