Closed S-Dafarra closed 4 years ago
@S-Dafarra a few and quick words on this to kick off.
Our responsible person for generating the URDF is @salvi-mattia 👨🏻💼 We've organized an internal course to transfer the knowledge of exporting models that will take place next week.
More in general, we're set to proceed iteratively aiming at the following MVPs ♻
The exact number, as well as the content of MVPs, will be suitably detailed/discussed throughout the process.
Also, we will invite you periodically to attend our internal updates 🗣
cc @DanielePucci @maggia80
Sounds good, thanks @pattacini
Hi @S-Dafarra
We've just invited you to icub-tech-iit/cad-mechanics
where @salvi-mattia will be opening up a series of issues to address activities on the CAD side. You can follow the progress there.
We'll be using this issue instead to report on specific news regarding the URDF per se.
cc @xEnVrE
hi everyone,
In the next weeks I'll work on the cad related part. Following the hands-on and talking with @fiorisi we think it could be useful to generate different URDF related to different anatomical robot'a parts and assemble them at URDF level. [that's because e.g. different icubs share the same head, we often build partial robots, it could be possible to change the hands as they will be developed] So we thought about this modules:
we will need to define "universally accepted" interfaces between the modules
@S-Dafarra @FabioBergonti @fiorisi @xEnVrE @traversaro any opinions?
I agree @salvi-mattia. If there is a simple way (xacro?) to reassemble the URDF modules, it is the best way to handle different robot versions and upgrades (e.g. new forearm-hand system).
I think it is a great idea! I am not sure about what is the best way of composing the part URDF to generate a complete URDF, but we can sort that out.
Here you can find the last version of the procedure.
It is public and it will be the official version for this procedure, we will keep this one up to date
CC @FabioBergonti @vpunithreddy @gabrielenava
looking @ iCub2 simulation model, the head just include the three DOF in the neck, do we wanto to have also eyes' movementes?
Hi @salvi-mattia, my take is that in the long run for sure, but I would say that they are not necessary for the first simulations of whole-body dynamic control and locomotion. So, if the process of adding the eyes' DoF movements slows down considerably (e.g. days) the release date of the model, I would say to avoid adding them unless the DOFs are necessary in the short term to other research lines
CC @lornat75 @ChiaraBartolozzi
The eyes are traditionally a dull pain to deal with in Gazebo (@xEnVrE knows it quite well), so we definitely need to address the automatic generation.
That being said, I agree that for the first MVP we could skip them and proceed faster to then refine over if those small mechanical details regarding eyes don't turn out to be a walk in the park.
designing robots is traditionally way better than a walk in the park.
I have fixed some failures in the iCub3 model, at the moment it weighs 55 kg [in the CAD] while the actual robot is 51 kilos this error is not that easy to fix because it's not easy to spot where the problem is really located.
do we think we could go ahead with this mass properties?
@S-Dafarra @fiorisi @DanielePucci
Nicely done @salvi-mattia 👍🏻 I remember those old times when the weight discrepancy was used to amount to tens of kilos 😄
My hunch is that we could proceed as it is now and then once we'll have the first overall exportable model we can backtrace and bisect the CAD in order to narrow down the problem. This means that we will very likely need eventually to "bisect" the real robot in order to measure the weights of the single parts as well.
@salvi-mattia for the iCub2.5 model we had to "manually" adjust the weight of the robot by reducing the mass of the sub assemblies in the second part of the URDF generation process (from the SimMechanics model to the URDF).
See this Excel table to have an idea.
For this it would be nice to have an idea about the weight error for the main sub-assemblies (e.g. lower body, upper body and head).
In this issue, some of the robot sub-assemblies were weighted. It should be already possible to check the error.
One of the prerequisites is to have a clear list of joint and link names. Something like this (for iCub2).
Otherwise, later on we will have to rename many files and change the associated script files.
@S-Dafarra if you do have a list like that to provide it could be useful. otherwise I'm naming the link following icub2 style and we will compose the table at the end [if smthg will be terribly wrong we con always rename some stuff]
@salvi-mattia
at the moment it weighs 55 kg [in the CAD] while the actual robot is 51 kilos this error is not that easy to fix because it's not easy to spot where the problem is really located.
do we think we could go ahead with this mass properties?
I would love to weigh 4 kilos less than what my CAD model say 😄 With that said, I agree with @fiorisi on
In this issue, some of the robot sub-assemblies were weighted. It should be already possible to check the error.
So, if this process does not take too long, we would love to have already an idea where the main weight mismatch (CAD vs Reality) is. Consider that we could always unmount the robot (e.g. split it in two) and weigh it if we are in trouble (CC @Fabrizio69 @maggia80).
Unfortunately, back in time, accurate weight in the CAD was one of the important features to have in order to achieve the first balancing results, and the mismatch that @pattacini mentioned was among the things that we had to correct.
So, having an idea on where to correct the weight would later help the control algorithms, which make use of the CAD information extensively for (among other things) center of pressure and center of mass computations.
hi all, iCub3 model has plenty of simp rep whose reliability we are not sure about. I started creating a new bunch called SimIcub3[link name] es. Sim_Icub3_Chest Sim_Icub3_R Elbow Sim_Icub3_Shoulder_1 Sim_Icub3_Shoulder_2 Sim_Icub3_Upperarm
they still miss datums [axis, frames or planes] for further assembly
@FabioBergonti @fiorisi @Mick3Lozzo if you could please give a fast look at them we can check if we all got the same concepts in creating sim reps
It could be time-saving to spot systematic errors in the early part of the work.
@S-Dafarra I don't know if you have access to the cad or someone can show you what we are talking about.
Yep, @S-Dafarra can read the CAD drawings.
kudos 4 @FabioBergonti that make me notice that I didn't include in the "chest" part the small part of the neck that "doesn't move" but it's fixed with the sholuder. that is true and that is because the connection between the chest and the head is not in a joint but "in the middle" of a link to fix this minor problem I suggest to use a "fixed" joint between these two parts [as it happend for the FTsensor that is a "fixed joint" in the middle of a link]
do you think it could be a good way to proceed?
@fiorisi @S-Dafarra
it happens between the blue part and the neck itself
@S-Dafarra if you do have a list like that to provide it could be useful. otherwise I'm naming the link following icub2 style and we will compose the table at the end [if smthg will be terribly wrong we con always rename some stuff]
I don't have a list at the moment. When writing code, we tried to be as generic as possible. Clearly, having a list of joints similar to iCub2 would simplify the porting process. One thing that we usually assume is that there is a frame on the robot sole having the z axis pointing upward and the x axis pointing forward. These frames are called l_sole
and r_sole
and are kind of omnipresent in our codes. Another thing pretty common is the root_link
. Apart from these few features, we are pretty open for the naming.
@S-Dafarra I don't know if you have access to the cad or someone can show you what we are talking about.
I do have access to the repo, but I am not sure if I can provide any useful comment on this :grin: For sure I appreciate any effort in making the process of generating URDF models more reliable.
do you think it could be a good way to proceed?
I don't think it is a problem having an additional fixed joint. In view of having the URDF composable, my two cents would be to include the blue link to the head subassembly if this part can be changed according to the installed head, to the chest otherwise.
I think Ihave integrated different modifications suggested by @FabioBergonti
as we said here
I think we have now the simp reps to complete the first module: torso, shoulders and upperarms
@fiorisi if you could please give a fast check we will procede adding datums and making shrinkwrap so we can start validating the process in the next [non-CAD] steps
Great @salvi-mattia! 🚀 I had a quick look at the simplified rep and to me they look fine. Just a few comments:
iCub3 model has plenty of simp rep whose reliability we are not sure about.
I would delete all the unnecessary Sim_
SimpRep.I started creating a new bunch called Sim_Icub3_[link name]
. For the new SimpReps let's follow the naming convention.I suggest to use a "fixed" joint between these two parts
the lower neck is part of the chest, I wouldn't divide it from the neck.I suggest to use a "fixed" joint between these two parts the lower neck is part of the chest, I wouldn't divide it from the neck.
After a T2T meeting with @salvi-mattia we agreed that this division is the interface between the head assembly URDF and upperbody assembly URDF.
together with @fiorisi we are facing various problems in naming conventions, simp rep separations, joint naming... we are trying to overcome them not only for the contingency but to create a more reliable procedure [hoping it will help to be faster in the future]
@fiorisi @S-Dafarra fix is glad to invite you to our review in order to take stock of the situation. it will take few minutes [15 I guess] starting from 2pm next friday [28th of august 2020]
@fiorisi @S-Dafarra fix is glad to invite you to our review in order to take stock of the situation. it will take few minutes [15 I guess] starting from 2pm next friday [28th of august 2020]
Thanks for the invitation, but unfortunately I will be busy at that time.
@S-Dafarra our review meeting will start at 2:00 pm and is supposed to end at 4:30 pm, so if you happen to have a free 15 mins slot in this range, feel free to get back to us.
@fiorisi @S-Dafarra fix is glad to invite you to our review in order to take stock of the situation. it will take few minutes [15 I guess] starting from 2pm next friday [28th of august 2020]
Thanks @salvi-mattia, dev
has also the review meeting at the same time.
good job! I agree that having the eyes in the model is not urgent for the balancing tasks, however, it would be nice to have them to complete the work, it will be very useful to use the robots for our experiments.
@S-Dafarra our review meeting will start at 2:00 pm and is supposed to end at 4:30 pm, so if you happen to have a free 15 mins slot in this range, feel free to get back to us.
Actually, I realized I confused this Friday with the next one. I will definitely pass by today.
So we're gonna start off w/ iCub3 URDF at 14:00 if it's ok. cc @S-Dafarra @salvi-mattia
@xEnVrE if you want to attend too you're more than welcome, although we're not going to cover details like fingers and eye bulbs at this stage that you're more interested in.
@pattacini thanks for the invitation. I have two meetings in that slot but if the second ends earlier I will join for sure!
We have completed the mechanism for the first assembly. as we said here it represents torso, shoulders and upperarms.
@Nicogene is going to perform folloeing steps in the instructions pipeline and giving us feedback about his work and the problems he will face.
@fiorisi and @FabioBergonti have given a big help in naming links and joint and doublechecked my work step by step
@fiorisi is glad to help @Nicogene and whoevere else will work on this activity for the mechanical side.
if you update cad mechanics repository, you can find the mechanism assembly at this location
cad-mechanics\projects\simulation_model\icub3
opening it you can finally push the magic matlab button
cc. @DanielePucci @lornat75 @xEnVrE @S-Dafarra @traversaro @pattacini
Today I opened the asm created by @salvi-mattia for the upperbody and I pressed the magic button. Despite a warning of Creo I obtained a list of stl and an xml file that I used for obtaining a first version of the urdf.
I simply run:
simmechanics_to_urdf SIM_ICUB3_UPPERBODY.xml --yaml icub3-upperbody-options.yaml --outputfile test.urdf
Where in the yaml I simply specified the scale factor of 0.001(Creo uses mm, gazebo m)
And here is the result, the upperbody sunbathing in gazebo 🏖️
The next steps will include for sure the definition of joint limits through the csv file and maybe the renaming the link?
FYI the work is carried on this branch https://github.com/robotology/icub-model-generator/tree/feat/addiCub3Upperbody
As we decided today during fix's sprint planning I'm going to produce simp rep, shrinkwrap and mechanism for the legs, later on we will check if it's better to assemble them to the torso at CAD or URDF level.
In the mean while we will check how the ftsensor in the upperarms and its fixed joints works in this procedure
After a meeting with @salvi-mattia @FabioBergonti and @traversaro, it emerged the necessity of having the link reference frames in the CAD before the conversion to the urdf. If not defined it is generated with the z-axis passing through the joint axis, with y-x direction arbitrary. Moreover, different generations can give different axis configurations.
For these reasons before proceeding with the work on the legs, we would first define those frames following this convention.
With this naming convention: SCSYS_<child_link_name>
.
Is it ok for you?
cc @pattacini @DanielePucci @S-Dafarra @maggia80
Note that in the future we may need to also export a frame aligned with the traditional iCub http://wiki.icub.org/wiki/ICubForwardKinematics , but that is something that we can easily do later just for the root, while for all the other links I think it it is beneficial to use the REP 103 convention, as we already did when we clearly defined the frames for the legs in https://github.com/robotology/icub-model-generator/commit/97827f894a2572b10697a5a33639b530690151b0 .
For these reasons before proceeding with the work on the legs, we would first define those frames following this convention. With this naming convention:
SCSYS_<child_link_name>
.Is it ok for you?
Note that this should avoid all the problems that we had in https://github.com/robotology/icub-models/issues/20 .
this is icub3 upper body seen from top if I correctly interpret X axis will be placed like the yellow one and not like the blue
it means that we will have a lot of joint axis coincident with no frame axis.
is it correct? is it the way we want to proced?
@S-Dafarra @pattacini @DanielePucci @traversaro @fiorisi @FabioBergonti
@salvi-mattia it sounds a bit weird.
Both options have their advantages, some days ago with @salvi-mattia I defended the "yellow arrow"-option but if the plan in the long term is to consider each limb as a standalone "mechanism" that is then composed at some level in a complete robot, probably the option that makes more sense even in accordance to rep-103 is the "blue arrow", sorry if I changed my mind.
To be honest, I am not able to find particular advantages in having the yellow solution, so I would prefer the blue one and have at least one axis aligned with the axis of rotation.
Am I missing something?
In general, having parallel frames in at least one pose of the robot drastically simplifies the debugging of vectors expressed in different link frame, as it is not necessary to rotate them, or for position vectors you just need to sum them to the origin of the frame, and that is the reason why most URDF assign the link orientations to be parallel to each other, as described in REP-103 .
In general, having parallel frames in at least one pose of the robot drastically simplifies the debugging of vectors expressed in different link frame, as it is not necessary to rotate them, or for position vectors you just need to sum them to the origin of the frame, and that is the reason why most URDF assign the link orientations to be parallel to each other, as described in REP-103 .
Ah I see, thanks. Anyways, if the robot moves from the zero position, those frames will not be aligned anymore right, especially on the yellow case?
talking with @traversaro it seems to be a good solution to have a definition with no uncertainty dependig on robot position.
our proposal [shared with @FabioBergonti ] could be:
Z axis on the joint axis X axis on the link main axis [pointing next joint] Y axis according to dextrous convention
If no one spots problems in this kind of convention we can proceed and see how it will work
@S-Dafarra @xEnVrE @fiorisi
Just to clarify instead the advantage of the "all links in the same limb" strategy:
I can list a few as soon if I have time
Humanoid models that follow the convention "all frame have the same orientation in a given configuration):
The only humanoid URDF that is not using this convention is the iCub 2.5, that is using this convention for the legs but for the arms has arbitrary frame coming out from the Creo generation process (see https://github.com/robotology/icub-models/issues/20).
In general, having parallel frames in at least one pose of the robot drastically simplifies the debugging of vectors expressed in different link frame, as it is not necessary to rotate them, or for position vectors you just need to sum them to the origin of the frame, and that is the reason why most URDF assign the link orientations to be parallel to each other, as described in REP-103 .
Ah I see, thanks. Anyways, if the robot moves from the zero position, those frames will not be aligned anymore right, especially on the yellow case?
Exactly.
In order to start performing experiments with the iCub 3 robot, it is fundamental to have its urdf and the possibility of using it in Gazebo.
With this issue, I would like to track the generation and the issues arising when trying to use this model for the first time.
cc @pattacini, @traversaro, @fiorisi