You have a lot of great ideas, I kind of disagree in some points.
I think that we should stick to xode specification as much as we can. I'm s=
we can send an email to the people is doing it (I think should be quite op=
to proposals) and share our concerns or needs.
Gazebo have a wheel body, if we can define a wheel as "wheel" we can genera=
code that take advantage of that body. I don't know how to better merge thi=
with xode specification.
I agree with you, every gazebo's specific tag will begin with "gz_", every=
gazebo interface tag will have the pattern: "gz_name_iface"
I also like your general info tag idea.=20
But I won't put there the position and rotation information. The xode=20
specification have already tags to do that, so we can use the standar=20
<transform> tag. In fact we can use that tag for the sonar location also. =
This way we don't need the "position and rotation just in case" solution.
Also, the battery tag should go out of the general information and go toget=
with the gz_battery_iface info IMHO.
I'd add a description tag to every file, we can extract documentation from=
there, and surely a GUI can take advantage of that.
So we have something like this (using your file):
=C2=A0 =C2=A0 <group> =C2=A0 <!-- General info -->
=C2=A0 =C2=A0 =C2=A0 <ext ename=3D"gz_model_info">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <model name=3D"Pioneer2AT"=20
description=3D"Pioneer 2AT from ActivMedia, mobile all-terrain four wheele=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <author name=3D"Andrew Howard" />
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <author name=3D"Nate Koenig" />
=C2=A0 =C2=A0 =C2=A0 </ext>
=C2=A0 =C2=A0 </group>
I also like your organization, far better than mine using the group tags to=
group similar information
I don't like the type and from ideas. The main idea behind the XML file is =
able to make a model definition _entirely_ inside the XML file so the "from=
attribute is useless as won't be such a function but the parser will know=20
what to do with each interface.=20
Because of that the "type" attribute is also useless, we already know that =
gz_position_iface interface will always work with gz_position.
Regarding interfaces, I open every model that has the interface (example=20
sonar). I read the code and took notes about how differently models use=20
interfaces, then come up with a general solution. Sonars are easy, every=20
gazebo model works more or less the same regarding to them. The most=20
difficult interface will be gz_position_iface. About others interfaces, I'l=
send comments on them in next emails :P
<position x=3D"-0.40" y=3D"0.17" z=3D"0.23" />
=C2=A0 =C2=A0 <rotation>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <euler x=3D"0" y=3D"90" z=3D"0" a=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </rotation>
<position x=3D"-0.45" y=3D"0.2" z=3D"0.23" />
<euler x=3D"0" y=3D"120" z=3D"0" aformat=3D"degrees" />
The transform tag make it a bit long (imagine 48 sonars!) but it will be=20
consistent with the xode definition. Also, when we move from manual editing=
to GUI based, we will not concerned about it.
What do you think?
Cameras should go inside the XML as everything else, we must decide how we =
best define them. I'll take a look to battery and cameras next, I'll take=20
your current specification as base.
As for the obscure numbers I'm also worried about it, but I don't know any=
=46riday 24 March 2006 04:37=E3=80=81Konstantinos Dalamagkidis =E3=81=95=E3=
> Hi again,
> I took a look at the specification of the XODE (from
> http://tanksoftware.com/xode/1.0r23/xode.txt) and I have the following
> The joint definition seems incomplete, the axis should also have a
> vector of rotation, like the anchor has a vector of position. It is also
> a little awkward the way it's defined but that's only my opinion.
> There is the facility for wheels using the cylinder body/geom.
> Is this specification something that gazebo needs/wants to follow and
> follow strictly?
> Based on Jordi's submissions so far and on the Pioneer model, I made an
> xml file that illustrates some of my suggestions, namely:
> It would be good to use consistent positioning tags even when it is not
> currently needed (e.g. roll, pitch for sonars). Maybe someone will need
> it in the future and it (probably) reduces the amount of coding necessary.
> I put a group that contains general model info as well as the defaults
> for attributes that can be set in the world file. I didn't put the id
> attribute because it makes sense for it to be mandatory to be defined
> explicitly. This group will also help in the generation of more complete
> The next group contains information on the interfaces. Each interface
> has a minimum of a "provides" tag with an attribute corresponding to the
> data type of the information returned by the interface (type) and the
> function that is used to get the information (from).
> Then we have a space tag where all the real ODE stuff go. I hope I
> understood correctly the need for a body AND a geom for every part of
> the model. I don't like them having the same name as I put in the
> example but at least it is simpler that way.
> Questions to the public:
> Should the cameras get inside the model or remain outside? Editing the
> model now is a lot easier so it does make some sense to incorporate them
> inside the model definition.
> The file seems riddled with obscure numbers, especially when it comes to
> the positioning of elements. As Jordi asked before, is there a way to
> improve on that or can we leave it as is?
> Does anyone has in mind a model or a situation were the scheme Jordi and
> I are proposing might not work or lack something?
> Hope I helped a little
> http://www.freemail.gr - =CE=B4=CF=89=CF=81=CE=B5=CE=AC=CE=BD =CF=85=CF=
> http://www.freemail.gr - free email service for the Greek-speaking.