Open GiulioRomualdi opened 4 years ago
The recent changes in the icub-models-generator
for iCubV3
models have not been accounted for.
I think a rebase would make things complicated.
As suggested by @traversaro, https://github.com/dic-iit/component_ANA-Avatar-XPRIZE/issues/82, the right way to do this is through icub-models-generator and since the URDF is constantly evolving, rebasing everytime would be painful.
Instead we might have to consider including the URDF that's constantly evolving along with the custom modifications we would like to have on the model.
Instead we might have to consider including the URDF that's constantly evolving along with the custom modifications we would like to have on the model.
@GiulioRomualdi I had to investigate it but currently I am working on the iFeel sprint. I am not sure if I will be able to do that at the quickest.
I think a rebase would make things complicated.
I agree but I hope that this current situation is only temporary
I think a rebase would make things complicated.
I agree but I hope that this current situation is only temporary
if we are successful with the icub-models-generator workflow, I suppose this situation will be temporary.
I did not understand two things:
I did not understand two things:
- which version is the correct one in terms of axis direction?
The latest icub-models
in remote origin
would be the correct, since it accounts for the fixes introduced by @GiulioRomualdi
- what are the difficulties in rebasing?
It could be error-prone in case of merge conflicts. And we might have to do it repeatedly to be aligned with continuous changes in the remote.
It could be error-prone in case of merge conflicts. And we might have to do it repeatedly to be aligned with continuous changes in the remote.
Where possible merge conflict could occur?
It could be error-prone in case of merge conflicts. And we might have to do it repeatedly to be aligned with continuous changes in the remote.
Where possible merge conflict could occur?
I am speculating even in the above scenario, trying to rebase would result in us resolving some changes manually.
and In case we happen to resolve any conflicts manually, there are possibilities of
It could be error-prone in case of merge conflicts. And we might have to do it repeatedly to be aligned with continuous changes in the remote.
Where possible merge conflict could occur?
I am speculating even in the above scenario, trying to rebase would result in us resolving some changes manually.
and In case we happen to resolve any conflicts manually, there are possibilities of
- introducing/removing xml tags at wrong places
- due to the long floating point numbers, it also involves paying too much attention to those details along with also much context switching
I see! But in this specific case, I guess that the only possible sources of conflicts are related to manual modifications in the urdf
. I suspect that block additions (like https://github.com/dic-iit/icub-models/blob/20d034c547aae832c7f3db3c1f53398dc10fac76/iCub/robots/iCubGazeboV3/model.urdf#L1678-L1686) should be easy to handle by git
. For the all modifications you mentioned, we can simply use the remote
ones, right?
In any case, @GiulioRomualdi have you tried to do the rebase locally?
In any case, @GiulioRomualdi have you tried to do the rebase locally?
yes, we cannot rebase as it is. if we do a git rebase origin/devel
we lose all the modifications related to the simplified contact shape for the feet.
This
- <origin xyz="0.010700000000000012 -0.06475000000001183 0.9464469999999995" rpy="0 0 -1.5707963267948966"/>
+ <origin xyz="0.0 0.0 0.003" rpy="0.0 0.0 0.0"/>
<geometry>
- <mesh filename="package://iCub/meshes/simmechanics/sim_icub3_l_foot_rear_prt.stl" scale="0.001 0.001 0.001"/>
+ <box size="0.117 0.1 0.006"/>
Edit: I'm a bit confused :confused: Could you tell me which are the lines required to have whole-body dynamics running?
Edit: I'm a bit confused :confused:. Could you tell me which are the lines required to have whole-body dynamics running?
Well @GiulioRomualdi, you may check the history of the commits:
yes, we cannot rebase as it is. if we do a
git rebase origin/devel
we lose all the modifications related to the simplified contact shape for the feet.
If I am not wrong, that feature got merged into icub-models-generator
(https://github.com/robotology/icub-models-generator/pull/165) and arrived to devel
with https://github.com/robotology/icub-models/commit/f95aa8759ed1d9bf8fb4b32d908b549573aa658c :thinking:
If I am not wrong, that feature got merged into icub-models-generator (robotology/icub-models-generator#165) and arrived to devel with robotology@f95aa87 thinking
my bad, I pointed @GiulioRomualdi towards the master
branch. While the changes are being merged into devel
. I confirm rebasing against devel
does not result in any conflicts.
Could you tell me which are the lines required to have whole-body dynamics running?
The lines with + are required.
The running of whole-body-dynamics is independent of the changes in these lines. These simplified collision geometries are useful to have better contacts at the feet.
I'm trying to rebase on my PC. Unfortunately, I'm not able to run whole-body dynamics because of https://github.com/robotology/whole-body-estimators/issues/91
I'm trying to rebase on my PC. Unfortunately, I'm not able to run whole-body dynamics because of robotology/whole-body-estimators#91
Is this problem solved?
I suppose, yes.
Yes I rebased the model locally on my pc. How shall we proceed? Do we open a PR from origin devel to this fork?
Yes I rebased the model locally on my pc. How shall we proceed? Do we open a PR from origin devel to this fork?
I guess we can start aligning this fork with your local version. Then, I guess that the file additions can be merged directly. For the modifications to the URDF we should open a PR on icub-models-generator
to avoid losing them as soon as the URDF is regenerated.
I have rebased over the latest devel and force-pushed the branch. In the end, the only diff from the devel must be,
We can close this issue?
Before starting using the model of
iCubGazeboV3
I ran agit diff
between this model and the one stored inrobotology/icub-models
. Namelly I compared:icub3/wbd
commit of this forkrobotology/icub-models
git diff 20d034c547aae832c7f3db3c1f53398dc10fac76..3c6cd409db01c4f3883583acb45525f56a2e52c4 iCub/robots/iCubGazeboV3/model.urdf
this is the output. There seems there is a difference between some inertial and more important the direction of some axis, namely
r_hip_yaw
andr_hip_roll
. If I've to tell the truth I don't know if this modification is required. In https://github.com/robotology/icub-models-generator/pull/153 I modified some axis direction but it's strange that it has been ported on the model only nowcc @traversaro @prashanthr05 @S-Dafarra