-
Notifications
You must be signed in to change notification settings - Fork 902
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
elastoplastic extension #560
base: main
Are you sure you want to change the base?
Conversation
skin/composit stress coloring implementation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Hi! |
Hi @mathl79 I think you have changed something in the default behavior of the cable? It looks like the test for the exact solution of the cantilever beam fails. Great that you are visualizing the stresses, this is something I always wanted to do! |
thank you for taking a look. |
Do you mean that you updated |
Great! I think it's fine if you keep pushing new commits to this branch, the PR should be updated automatically. |
inner deformation friction corrected body coloring in case of multiple cable bodies
Thanks for the revised version! My main comments are:
|
I tried to implement a plasticity deformation proportional damping by reducing the torque depending on the change of omega an the Volume. I did not run the tests - but better should have... So I will change back to the standard plugin models, add extra plastic test models and separate the viscous damping by only applying it, if elements are in plastic domain. I try to separate the coloring feature from the plasticity as you suggested. What else needs to be user controllable ? Should any scalar properties other than equivalent stress be selectable in future ? Besides the separation from the plasticity, zhe stress needs to be calculated for the elasticity model anyway, in order to be able to show it. Btw - what is a good place in the source for the color conversion and palette generation tools, that I have put inside the plugin code from now? Is this something, that could be used generally or should it stay plugin specific? |
Yes always run tests before committing :) For the stress visualisation, those are really good questions. I think plugins should decide what to write in your @yuvaltassa WDYT? Any better idea than using skins for stress visualization? |
Hi, I don't know how to correct the config tests. When building /debugging elasticity.dll, the file is placed into the /bin folder and needs to be copied into the /bin/plugin/ subfolder manually to be recognized as plugin. I think, that is also linked to the problem above. |
OK that's interesting, there is something broken with Windows then because on the main branch the dll gets copied. @saran-t what are your thoughts? As mentioned in my previous comment, could you please open a new PR for the visualisation part? You can keep this one open as well and we will get back to it once we complete the visualisation. How does that sound to you? Maybe in the meantime the Windows issues will be fixed. |
This code excludes the plugin-test from the test config for Windows builds. what is the reason for this? |
Good point, we definitely need to fix Windows. Now I remember we disabled the test because we had some issues loading the DLL. I wonder if your change to CMakeList fixes that? Perhaps you want to open a third PR with only that change and also enabling again the plugin tests for Windows by deleting the lines you quoted in your post? |
My suggestion is that we can start from the visualization PR since that doesn't requires the windows tests. |
Perfect, thanks! |
btw. - you can test the branch for the stress skin visuals without the plasticity in my fork. |
Looks like we have to rollback the commit unfortunately, hopefully we'll be able to fix it and activate the windows tests in the next days. |
Good news, Windows is fixed if you rebase from 043ed27 you'll be able to run Windows tests. For the visualisation, are you going to create a separate PR from your branch or would you prefer if we have a look and apply the changes ourselves? |
Perfect ! Thanks for fixing again! For me it absolutely ok, if you take my approach as basis to implement the coloring by our own. |
Hi @quagla, Regarding the plasticity model: I hope, that i will have some spare time the next days to finalize my testing and commit that change into my branch. br, Mathias |
Great to hear! Do you think you can write a unit test in For the skin colouring, after an internal discussion it was decided to do it in a different way so we will have to implement it ourselves. I agree however that colouring geometries (bones) is probably already giving plenty of information so when you are committing your final changes you could perhaps leave the geom colouring but remove the skin part if you can? By the way, I added a Jet color palette in my branch, maybe you like it https://github.com/deepmind/mujoco/pull/599/files#diff-f8ed3e4597989d57bd3588f824c10fe89b140ca2665a05dd3b8878f2f6f6c23b |
Thanks for the update! Tip: I think you have to set the parameters of CantileverIntoCircle such that perfect elasticity is obtained without triggering a warning because warnings cause test failures. [ RUN ] PluginTest.CantileverIntoCircle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some comments. First of all, great work! However some things must be address before continuing:
- The original tests and the original examples must be working.
- A new test for plasticity should be added.
- It would be great to remove the visualization part from the branch, unless absolutely necessary (we should use the test to validate the results instead).
else { | ||
dYield_UtY = UtStress - YieldStress; //strain hardening stress delta | ||
k_deltaStrain_G = 5 / (UtStrain - YieldStrain_G); //exponential constant for torsional strain hardening | ||
k_deltaStrain_E = 5 / (UtStrain - YieldStrain_E); //exponential constant for bending strain hardening |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these 3 variables unused?
@@ -26,6 +26,29 @@ | |||
namespace mujoco::plugin::elasticity { | |||
namespace { | |||
|
|||
|
|||
//create color scale palette | |||
void scalar2rgba(float rgba[4], mjtNum Scalar, mjtNum min, mjtNum max) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned in the main discussion, it would be great to remove the coloring part from this branch.
- stiffness[2]*(omega[2] - omega0[2]) / stiffness[3], | ||
}; | ||
|
||
void LocalForce(mjtNum qfrc[3], mujoco::plugin::elasticity::Cable::stiffness_ Sel, mujoco::plugin::elasticity::Cable::stiffness_consts_ Sconst, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the full namespace needed?
omega[2] - omega0[2] | ||
}; | ||
|
||
//actual strain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you always add a space between // and the comment?
d_omega[2] / (Sel.L_Dz + omega0[2]), | ||
}; | ||
|
||
mjtNum Yield_stress_top[] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you document this plastic model with e.g. a paper or a link and/or a more detailed explanation in the code?
} | ||
} | ||
else { | ||
mju_warning("YieldStress is notset: perfect elasticity is assumed !"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update elasticity_test such that this warning is not triggered.
<joint kind="main" damping="0.1"/> | ||
<geom type="box" size="0.03535533906 0.02 0.0015" rgba=".8 .2 .1 1" group="3"/> | ||
<skin subgrid="3"/> | ||
<joint kind="main" damping="10"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I load this model, it immediately explodes.
<geom type="capsule" size=".005" rgba=".8 .2 .1 1"/> | ||
</composite> | ||
<composite prefix="actuated" type="cable" curve="cos(s) sin(s) s" count="41 1 1" | ||
size="0.251327412 .1 4" offset="0.25 0 .05" initial="fixed"> | ||
<plugin plugin="mujoco.elasticity.cable"> | ||
<!--Units are in Pa (SI)--> | ||
<config key="twist" value="5e8"/> | ||
<config key="bend" value="15e8"/> | ||
<config key="twist" value="1e10"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I pull the second spring, at some point it looks like the simulation blows up.
We have added coloring of the geometries using a callback, please see 0d52fea |
Hi @mathl79 are you still interested in submitting this? |
implementation of the plasticity extension idea to the elasicity plugin.
see: discussion #549
googletest is not implemented yet --> need help to find sufficient test criterias