Closed jjyyxx closed 1 month ago
prefix
for attach in the future.I can't reproduce 3 (I tried with custom numeric data and it works fine), could you please send a minimal example?
@quagla Once again, with replicate
😂 With one level of replicate
, the output model contains a lot of (seems combinatory?) numeric
s. With another nested level of replicate
(uncomment below), MjSpec
breaks internally with Error: repeated name 'a00' in numeric
parent.xml
<mujoco>
<asset>
<model name="child" file="child.xml" />
</asset>
<worldbody>
<attach model="child" body="child" />
<replicate count="12">
<!-- <replicate count="12"> -->
<body />
<!-- </replicate> -->
</replicate>
</worldbody>
</mujoco>
child.xml
<mujoco>
<custom>
<numeric name="a" data="1"/>
</custom>
<worldbody>
<body name="child" />
</worldbody>
</mujoco>
@quagla Thanks for the quick fix! But,
- Should be solved by using a prefix, could you please confirm? It's likely that we will require a prefix for attach in the future.
I could not confirm this workaround, because applying prefix when attaching a child model containing actuator with class leads to yet another segfault (in mjXWriter::OneActuator
). 😂
a.xml
<mujoco>
<asset>
<model name="b" file="b.xml" />
</asset>
<worldbody>
<attach model="b" body="b" prefix="b" />
</worldbody>
</mujoco>
b.xml
<mujoco>
<default>
<default class="b"/>
</default>
<worldbody>
<body name="b">
<geom type="box" size="0.1 0.1 0.1"/>
<joint name="b"/>
</body>
</worldbody>
<actuator>
<position joint="b" class="b"/>
</actuator>
</mujoco>
Besides,
This is known and part of conflicting compiler options in general. We are working to keep track of attached options.
I found that, currently, in order for an attached model (with assets) to work with MjSpec, the parent and child XML must be in the same level of directory. Otherwise, path inconsistency either prevents MjSpec.compile
before to_xml
, or produces a model with wrong relative path. I understand that completely resolving this issue may require some major changes, but this indeed complicates our model management (we would like to put thirdparty child models in a sub-directory, but currently could not.)
Besides,
This is known and part of conflicting compiler options in general. We are working to keep track of attached options.
I found that, currently, in order for an attached model (with assets) to work with MjSpec, the parent and child XML must be in the same level of directory. Otherwise, path inconsistency either prevents
MjSpec.compile
beforeto_xml
, or produces a model with wrong relative path. I understand that completely resolving this issue may require some major changes, but this indeed complicates our model management (we would like to put thirdparty child models in a sub-directory, but currently could not.)
Yes, I know. I have a solution partially implemented but it's not ready to be submitted yet. Maybe in a week's time.
@quagla Thanks for the quick fix! But,
- Should be solved by using a prefix, could you please confirm? It's likely that we will require a prefix for attach in the future.
I could not confirm this workaround, because applying prefix when attaching a child model containing actuator with class leads to yet another segfault (in
mjXWriter::OneActuator
). 😂a.xml
<mujoco> <asset> <model name="b" file="b.xml" /> </asset> <worldbody> <attach model="b" body="b" prefix="b" /> </worldbody> </mujoco>
b.xml
<mujoco> <default> <default class="b"/> </default> <worldbody> <body name="b"> <geom type="box" size="0.1 0.1 0.1"/> <joint name="b"/> </body> </worldbody> <actuator> <position joint="b" class="b"/> </actuator> </mujoco>
That's very useful, thanks!
Intro
I am a graduate student at HKU, I use MuJoCo for my research on robotic manipulation. This issue is a follow-up of comment https://github.com/google-deepmind/mujoco/issues/2150#issuecomment-2426708998
My setup
MuJoCo 3.2.4
What's happening? What did you expect?
meshdir
would be overwritten, breaking either parent or child<custom>
tags.Steps for reproduction
Run snippet below
Minimal model for reproduction
parent.xml
child/child.xml
Code required for reproduction
Confirmations