From: Konstantinos D. <da...@fr...> - 2006-03-25 18:34:54
|
Jordi wrote: > You are right, now the wheel body is just a sphere body with wheel rendering. > I think that we should use the wheel body because in the future can be change > to a better approximation to a wheel, have special parameters, etc. It's too > much for the XML to also define how the bodies are. > > I think the body dynamics are (most likely) going to continue be ODE objects and therefore should be defined as ODE objects in the XML. It seems to me that the WheelGeom was created because of the need for a SphereGeom that could take a second parameter (the track width) to be used in rendering. So something like the following xml would make sense to me. <body name="wheel"> <sphere radius="0.2" /> <mass> <adjust total="1" /> </mass> <geom name="wheel"> <sphere radius="0.2" /> </geom> <transform scale="1"> <position x="0.25" y="0.1" z="0" /> <rotation> <euler x="0" y="90" z="0" aformat="degrees" /> </rotation> </transform> <ext ename="gz_appearance"> <wheel track_width="0.05" /> <color r="0.0" g="0.0" b="0.0" /> </ext> </body> This way all the gazebo specific stuff go under one tag (gz_appearance) and the whole <space> section is almost ODE-only. I'm assuming of course that if there was really a need for the definition of a new ODE geometry for wheels, it would have been done by now. Even if later a better approximation for the wheel with more parameters is used, there is going to be a GUI for editing it that could automatically change the bodies with wheel tags to the new geoms (be it cylinder or anything else) and the extra info can still go in the gz_appearance. > Maybe we can just define parameters. Any parameter that can be overwritten by > the world file is a model default. Any other parameter is just a model > constant. > > I guess after the gz_model_info group we could have a gz_model_parameters group. > When we have a stable XML specification, I'll write the parser and ask Nate to > delete the current C code in favour of the new XML models. > That will be gazebo XML V 1.0 > > For V1.0 we can just define current models in XML (complex enought issue) > Post V1.0 we can focus on improving models > > > We can define gazebo XML without the battery interface for now. > V1.0 won't have battery interface, so we'll delete a current gazebo feature > that it is not working anyway (I doubt anybody is using it in the current > state anyway). > In the post- V1.0 days we can come back to the complex battery interface > issues. > Maybe it will be a good idea to have a gazeboxml branch for a while in parallel with the current version. That way removing features or breaking stuff will surely not affect anyone (think of people using customized models now). Probably it is also a good time to start preparing a spec document, that will help with the redefinition of the current models in XML and of course later as a guide for users that want to define their own models. I could help with the document and the redefinition of the models if you want. > Any good name for gazebo XML specification (xgazebo? gazeboXML?) ? xgazebo sounds like an X application, gazeboXML would be my choice. gazeboEX - "Gazebo Extension to XODE" ? cheers dalai ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. |