Skip to content
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

Fix iCubGazeboV2_5_visuomanip colors #124

Closed
traversaro opened this issue Jan 28, 2022 · 7 comments · Fixed by #139
Closed

Fix iCubGazeboV2_5_visuomanip colors #124

traversaro opened this issue Jan 28, 2022 · 7 comments · Fixed by #139

Comments

@traversaro
Copy link
Member

The model iCubGazeboV2_5_visuomanip added in #42 has strange "random" colors. For automatically generated models, the issue will be fixed by robotology/icub-models-generator#217, but for iCubGazeboV2_5_visuomanip if we want to fix the issue we need to it specifically for this model.

fyi @xEnVrE @pattacini

@pattacini
Copy link
Member

"Random" in which sense? Isn't the "standard" anonymous whitish color?

if we want to fix the issue we need to it specifically for this model.

Fine with me!
Since @xEnVrE authored it, I'll leave to him the final choice.

@xEnVrE
Copy link
Contributor

xEnVrE commented Jan 28, 2022

Hi @traversaro @pattacini,

fine with me. I imagine that I could check how the automatic pipeline changes the materials in the automatically generated models and apply the changes in the manually generated model.

@traversaro do you think this solution is doable? (I can take care of it.)

@traversaro
Copy link
Member Author

"Random" in which sense? Isn't the "standard" anonymous whitish color?

Actually, not. The whitish color we were mostly used to is due to a bug in URDF parsing that was both in iDynTree and in Classic Gazebo, but if you displayed the model in a ROS tool like RViz you were always getting it as an "Arlecchino". @GiulioRomualdi is fixing the issue in iDynTree (see robotology/idyntree#961), so we were going to see an arlecchino robot in iDynTree, but in Classic Gazebo we will continue to see a whitish color.

@traversaro
Copy link
Member Author

Hi @traversaro @pattacini,

fine with me. I imagine that I could check how the automatic pipeline changes the materials in the automatically generated models and apply the changes in the manually generated model.

@traversaro do you think this solution is doable? (I can take care of it.)

Ok!

@xEnVrE
Copy link
Contributor

xEnVrE commented Mar 11, 2022

I made the changes.

Some notes:

  • I took the colors from the latest icub-models (not sure why the red color was picked up for the entire robot, however I will leave it in order to have coherent colors w.r.t. the automatically generated colors)
  • I had to change the color of the part indicated with the green arrow. It is a metallic part, hence it should not be red, I guess.
  • The top and palm cover of the hand are black as in real robots
  • The fingertip should be black, however the mesh is shared with the last part of the finger, hence I could not make it better than that.
  • The following were generated using the meshcat-based visualizer provided here

image

image

Eyes bulbs

I will use the idyntree-model-viewer to show you the eyes as the meshcat-based one does not support spheres and cylinders, that are used for the visual description of the eyes.

image

If this configuration looks good I can open a PR with the changes. @traversaro @pattacini

Btw, I noticed that using the idyntree visualizer the colors of hand and fingers are not taken into account. Is this because they are daes instead of stl?

@pattacini
Copy link
Member

Fine with me 👍🏻

@traversaro
Copy link
Member Author

(not sure why the red color was picked up for the entire robot, however I will leave it in order to have coherent colors w.r.t. the automatically generated colors)

Basically the one that do the modification get to choose the color, see robotology/icub-models-generator#217 (comment) . :D

Btw, I noticed that using the idyntree visualizer the colors of hand and fingers are not taken into account. Is this because they are daes instead of stl?

Yes, in the iDynTree visualizer .dae files can specify their own color inside the file itself, so the URDF color file is not taken into account. This is also the behaviour of Gazebo if I recall correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants