Integrate hand-crafted nice meshes into the repo-pipeline #263
Comments
Nicogene
added
domain-software
Nicogene
changed the title
|
As first step I simply added all the new meshes to the repo and find/replace I am getting this warning on gazebo side: and unfortunately the meshes seems to collapse:
|
Sorry @Nicogene, I've forgotten to change some of the mtl references. It should be ok now. |
The warning are now disappeared thanks! For the pose of the meshes instead, with stl usually happens when we export them wrt the part csys (that usually is not where is the link csys), but for these obj I don't know how the procedure work.
It is strange indeed that I am experiencing this problem, I just changed the paths too 🤔 |
@Nicogene
Did you replace just collision ao also visuals? |
|
The curious thing is that with the 1.1 meshes this does not happen:
Yes it should! The good news is that I didn't see change in the real time factor ~0.98 on my machine. |
|
Is anything printed if you run gazebo --verbose ? |
|
I found out what the problem is.
Comparing side-by-side the V1 <visual>
<origin xyz="0 0 0.1785" rpy="0 0 1.5707963267948966"/>
<geometry>
<mesh filename="package://ergoCub/meshes/simmechanics/sim_ecub_root_link.obj" scale="0.001 0.001 0.001"/>
</geometry>
<material name="root_link_color">
<color rgba="0.9 0.9 0.9 1"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0.1785" rpy="0 0 1.5707963267948966"/>
<geometry>
<mesh filename="package://ergoCub/meshes/simmechanics/sim_ecub_root_link.obj" scale="0.001 0.001 0.001"/>
</geometry>
</collision>V1_1 <visual>
<origin xyz="0 0 0" rpy="0 -0 0"/>
<geometry>
<mesh filename="package://ergoCub/meshes/simmechanics/sim_ecub_1-1_root_link.obj" scale="0.001 0.001 0.001"/>
</geometry>
<material name="">
<color rgba="0.6 0.6 0.6 1"/>
</material>
</visual>
<collision>
<origin xyz="0 0 0" rpy="0 -0 0"/>
<geometry>
<mesh filename="package://ergoCub/meshes/simmechanics/sim_ecub_1-1_root_link.obj" scale="0.001 0.001 0.001"/>
</geometry>Long story short, using the old pipeline we have meshes exported w.r.t the csys and then the pose is adjusted using the @Supermonkey-design just changed the names of the meshes and changed the color starting from the V1_1 ones, probably the V1 have to be export respect |
|
I was wondering if it makes sense to also update the meshes of the sn000 since it is created with a machinery not supported anymore |
|
As the meshes are basically the same but in different csys, I've made a little definition in Grasshopper to remap the position of V1_1 meshes into the frame of V1 meshes (so without exporting everything again from creo).
It seems to work. This is an overlapping comparison with the actual v1 shrink-wrapped meshes (in red).
The wrists and hand meshes are not visible in the screenshots because I've just made the obj directly from V1 meshes. |
You are right, my only fear is that if we want to roll-back to the "ugly" meshes, if we change the urdf the stl meshes have the wrong placement. I quickly tested the impact on the rtf and seems that these new meshes are quite light, but I did not do "complex" task, such as walking grasping etc |
|
Instead about the weight of these meshes, I don't know if we might commit them with git lfs or not, until now for using |
|
Also, what file size we're talking about? |
How is this process done? I am always a bit afraid of process that rely on visually checking the aligned of meshes. Did the kinematics changed between ergoCubSN000, 1, 2? If not, we can compute the correct placement from the kinematics, without trying to align the meshes. |
A part of the fingers they should be kinematically identical
I would apply in case only to
@pattacini we are passing from 43.8 MB to 96.8 MB, this means we are doubling the size, but still seems a reasonable size |
Good 👍🏻
Not really, we're approaching the GH limit of 100 MB per file, hence LFS seems necessary. |
Me too, honestly, in this case. My idea was also simple: if the meshes are identical, I can read the shrinkwrapped mesh from SN001 and SN000, compute their bounding box centroids, create a vector from these two points, and use it to remap the position of the detailed meshes. |
|
Yes, that is exactly what I was afraid of. If the meshes are indeed identical, perhaps to use the V1_1 meshes in V1 we can simply set the |
My concern about this, is that I have to do it 132 times for each urdf manually(SN000, V1, V1_mincontacts), and then we cannot roll back on the stl without reverting this change, something doable but I am afraid error prone too. Maybe finding a regex that work can save the day |
|
For curiosity I just exported the SN000 urdf using
Maybe this is solved: Because in these months |
Sure, I typically found more useful to do this kind of changes via simple ad-hoc Python scripts rather then manually, especially now that llm can drastically speedup the process of creation of such Python scripts. |
Here's a Python script that parses a URDF (Unified Robot Description Format) file, finds all import xml.etree.ElementTree as ET
def set_origin_to_zero(urdf_file, output_file):
# Parse the URDF file
tree = ET.parse(urdf_file)
root = tree.getroot()
# Find all <visual> and <collision> elements
for element_type in ['visual', 'collision']:
for elem in root.findall(f".//{element_type}"):
# Find the <origin> element inside <visual> or <collision>
origin = elem.find('origin')
if origin is not None:
# Set xyz and rpy attributes to '0 0 0'
origin.set('xyz', '0 0 0')
origin.set('rpy', '0 0 0')
# Save the modified URDF to a new file
tree.write(output_file)
print(f"Updated URDF saved to {output_file}")
# Example usage
urdf_file = 'input.urdf'
output_file = 'output.urdf'
set_origin_to_zero(urdf_file, output_file)How it works:
Usage:
You can expand this script to handle other attributes or tags as needed. Let's see if it works :D |
|
Note that this may change the formatting of the existing xml if |
Yes it works (good job chatGPT), but changes a bit the formatting, in particular it added a space before every |
|
@Supermonkey-design Here: I put all the origin to 000, I can take the old meshes and see if now they work |
|
Unfortunately setting all the collisions' origin to 000 broke the collision boxes we put in the SN000/V1 soles
I manually put the correct offset and now is fine
@Supermonkey-design is flipping the tight covers meshes, since the V1 is still affected by this: I hope this is the last step |
Unfortunately the meshes for the hands are different, so right now the V1 hands looks like this:
This is due to the fact that the URDF contains the V1 transform between links, but the meshes are the ones of the V1_1, that are longer and have some problems of frame definitions: "This is not creating problems, just to be aware of it" Naif me of 2023 :D So with @Supermonkey-design we decided to:
That's it? Not really, the simulation model of V1 has yet another problem: That was fixed by @xEnVrE by removing the leverism by hand and committing the stl directly. So @Supermonkey-design we re-remove those leverism before converting to obj and we should land finally. |
About this point maybe I was not clear, but 96.8 MB is the total of the entire The limit on the repo seems to be 1 GB. I would rather avoid using |
@pattacini
|
We finally landed 🛬
Thanks @Supermonkey-design ! |
Task description
This task is probably cross-repository with
creo2urdf, @Supermonkey-design did an amazing job on remeshing the the existing URDF mesh, and after a chat w/ @fiorisi @traversaro @GiulioRomualdi and @Supermonkey-design it came out that it would be nice to add them to this repo, alongside the "ugly" ones.In case these meshes are heavy for the simulation we might think to change creo2urdf in order to make
assignedCollisionGeometryhandle also complex meshes, and then use the ugly ones for the collisions, keeping the nice one as visualDefinition of Done
We integrated the @Supermonkey-design meshes
cc @maggia80 @pattacini
The text was updated successfully, but these errors were encountered: