From: Jordi <mu...@gm...> - 2006-03-23 20:39:47
|
Definition <ext ename="gazebo_interface"> <supports>string</supports> </ext> Example (this is not a complete xode file, just and ilustration) <?xml version="1.0" encoding="UTF-8"?> <xode version="1.0r23" name="truck" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://tanksoftware.com/xode/1.0r23/xode.xsd"> <world> <space> <ext ename="gazebo_interface"> <supports>position</supports> <supports>sonar</supports> <supports>power</supports> </ext> </space> </world> </xode> The gazebo_interface extension instruct the model what interfaces it has to provide, update and read data from. It is defined under the <space> tag because is model wide information (don't belongs to any specific body or geometry) Definning the gazebo interfaces under this gazebo_interface tags will allow the model allocate, initialize and later on, destroy and deallocate the interfaces. But the model won't do anything interesting with this interfaces. Each interface have its own extension to control how the model manage it. Comments? |
From: Konstantinos D. <da...@fr...> - 2006-03-23 21:33:57
|
Why not put the interface info here rather than separate? I was thinking something along the lines of <?xml version="1.0" encoding="UTF-8"?> <xode version="1.0r23" name="truck" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://tanksoftware.com/xode/1.0r23/xode.xsd"> <world> <space> <ext ename="gz_sonar_iface"> <sonar range="5.0" x="-0.40" y="0.17" z="0.23" dir="90" /> <sonar range="5.0" x="-0.45" y="0.17" z="0.23" dir="120" /> <sonar range="5.0" x="-0.50" y="0.17" z="0.23" dir="150" /> ... </ext> <ext ename="gz_camera_iface"> <camera x="-0.40" y="0.17" z="1.23" r="0" p="0" y="10" /> <camera x="-0.40" y="0.17" z="1.23" r="0" p="0" y="10" /> </ext> <ext ename="gz_power_iface"> whatever </ext> <ext ename="gz_position_iface"> whatever </ext> </space> </world> </xode> I also think we could agree on degrees or radians (probably degrees since that is what is currently used anyway). I don't think anyone has a problem converting back and forth when needed. That way there are less stuff to parse and check. Jordi wrote: >Definition > <ext ename="gazebo_interface"> > <supports>string</supports> > </ext> > > > > >Example >(this is not a complete xode file, just and ilustration) > ><?xml version="1.0" encoding="UTF-8"?> ><xode version="1.0r23" name="truck" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >xsi:noNamespaceSchemaLocation="http://tanksoftware.com/xode/1.0r23/xode.xsd"> > ><world> > > <space> > <ext ename="gazebo_interface"> > <supports>position</supports> > <supports>sonar</supports> > <supports>power</supports> > </ext> > > </space> ></world> ></xode> > > > >The gazebo_interface extension instruct the model what interfaces it has to >provide, update and read data from. >It is defined under the <space> tag because is model wide information (don't >belongs to any specific body or geometry) >Definning the gazebo interfaces under this gazebo_interface tags will allow >the model allocate, initialize and later on, destroy and deallocate the >interfaces. >But the model won't do anything interesting with this interfaces. >Each interface have its own extension to control how the model manage it. > > >Comments? > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Playerstage-gazebo mailing list >Pla...@li... >https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > ____________________________________________________________________ http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ. http://www.freemail.gr - free email service for the Greek-speaking. |
From: Jordi <mu...@gm...> - 2006-03-23 22:34:11
|
You are right, we can do it in one step. I have some issues thought. =2D I'd change the names from gz_sonar_iface to gazebo_sonar_iface or other= wise=20 every gazebo_meaningfull_name should be change to gz_meaningfull_name (in t= he=20 shake of consistence) =2DSonar sensors (and I guess that camera sensors are the same) needs to be= =20 attached to a body. So the name of the body should be provided some way. Th= at=20 was the reason I previously put sonar sensor inside a body declaration. You= r=20 solution is far more ellegant (if you solve the body name issue)=20 =2DIt seems that you prefer attributes in a tag to several subtags. I have = no=20 special preference, your scheme seems good and easy to read, so let's go fo= r=20 attributes as much as we can (also for consistence) =2D- Jordi Polo > Why not put the interface info here rather than separate? I was thinking > something along the lines of > > <?xml version=3D"1.0" encoding=3D"UTF-8"?> > <xode version=3D"1.0r23" name=3D"truck" > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:noNamespaceSchemaLocation=3D"http://tanksoftware.com/xode/1.0r23/xode= =2Exsd >"> > > <world> > <space> > <ext ename=3D"gz_sonar_iface"> > <sonar range=3D"5.0" x=3D"-0.40" y=3D"0.17" z=3D"0.23" dir=3D"90" /> > <sonar range=3D"5.0" x=3D"-0.45" y=3D"0.17" z=3D"0.23" dir=3D"120" /> > <sonar range=3D"5.0" x=3D"-0.50" y=3D"0.17" z=3D"0.23" dir=3D"150" /> > ... > </ext> > <ext ename=3D"gz_camera_iface"> > <camera x=3D"-0.40" y=3D"0.17" z=3D"1.23" r=3D"0" p=3D"0" y=3D"10" /> > <camera x=3D"-0.40" y=3D"0.17" z=3D"1.23" r=3D"0" p=3D"0" y=3D"10" /> > </ext> > <ext ename=3D"gz_power_iface"> > whatever > </ext> > <ext ename=3D"gz_position_iface"> > whatever > </ext> > </space> > </world> > </xode> > > I also think we could agree on degrees or radians (probably degrees > since that is what is currently used anyway). I don't think anyone has a > problem converting back and forth when needed. > That way there are less stuff to parse and check. > > Jordi wrote: > >Definition > > <ext ename=3D"gazebo_interface"> > > <supports>string</supports> > > </ext> > > > > > > > > > >Example > >(this is not a complete xode file, just and ilustration) > > > ><?xml version=3D"1.0" encoding=3D"UTF-8"?> > ><xode version=3D"1.0r23" name=3D"truck" > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > >xsi:noNamespaceSchemaLocation=3D"http://tanksoftware.com/xode/1.0r23/xod= e.xs > >d"> > > > ><world> > > > > <space> > > <ext ename=3D"gazebo_interface"> > > <supports>position</supports> > > <supports>sonar</supports> > > <supports>power</supports> > > </ext> > > > > </space> > ></world> > ></xode> > > > > > > > >The gazebo_interface extension instruct the model what interfaces it has > > to provide, update and read data from. > >It is defined under the <space> tag because is model wide information > > (don't belongs to any specific body or geometry) > >Definning the gazebo interfaces under this gazebo_interface tags will > > allow the model allocate, initialize and later on, destroy and dealloca= te > > the interfaces. > >But the model won't do anything interesting with this interfaces. > >Each interface have its own extension to control how the model manage it. > > > > > >Comments? > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by xPML, a groundbreaking scripting > > language that extends applications into web and mobile media. Attend the > > live webcast and join the prime developer group breaking into this new > > coding territory! > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > > _______________________________________________ > >Playerstage-gazebo mailing list > >Pla...@li... > >https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > ____________________________________________________________________ > http://www.freemail.gr - =E4=F9=F1=E5=DC=ED =F5=F0=E7=F1=E5=F3=DF=E1 =E7= =EB=E5=EA=F4=F1=EF=ED=E9=EA=EF=FD =F4=E1=F7=F5=E4=F1=EF=EC=E5=DF=EF=F5. > http://www.freemail.gr - free email service for the Greek-speaking. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Playerstage-gazebo mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo |
From: Konstantinos D. <da...@fr...> - 2006-03-23 23:00:54
|
Jordi wrote: >You are right, we can do it in one step. > >I have some issues thought. >- I'd change the names from gz_sonar_iface to gazebo_sonar_iface or otherwise >every gazebo_meaningfull_name should be change to gz_meaningfull_name (in the >shake of consistence) > > > I think in the API we have gz_data, gz_joint and stuff like that. Using just gz also makes for shorter names. But as I said in the first email it doesn't really matter all that much as long as it is the same everywhere. >-Sonar sensors (and I guess that camera sensors are the same) needs to be >attached to a body. So the name of the body should be provided some way. That >was the reason I previously put sonar sensor inside a body declaration. Your >solution is far more ellegant (if you solve the body name issue) > > > Could be a tag like <sonar location="chassis" ..... or it could be relative to the entire model and not a specific part of it (I think currently at least for the cameras it is relative to the entire model) >-It seems that you prefer attributes in a tag to several subtags. I have no >special preference, your scheme seems good and easy to read, so let's go for >attributes as much as we can (also for consistence) > > Well maybe getting it all attributes could make some tags very long. We could use something in between, like keeping the positioning info (which is used a lot) separate as subtags. Like this <ext ename="gz_sonar_iface"> <sonar location="chassis" range="5.0"> <xyz x="-0.40" y="0.17" z="0.23" /> <rpy r="0" p="0" y="90" /> </sonar> <sonar location="chassis" range="5.0"> <xyz x="-0.45" y="0.17" z="0.23" /> <rpy r="0" p="0" y="120" /> </sonar> </ext> Anyway don't trust me though with decisions like that, I'm neither a computer scientist nor a programmer :) Let me know what you think dalai ____________________________________________________________________ http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ. http://www.freemail.gr - free email service for the Greek-speaking. |
From: Konstantinos D. <da...@fr...> - 2006-03-24 03:37:21
Attachments:
pioneer.xode
dalai.vcf
|
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 observations: 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 documentation. 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 dalai ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. |
From: Jordi <mu...@gm...> - 2006-03-24 22:32:25
|
Great work! 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= ure=20 we can send an email to the people is doing it (I think should be quite op= en=20 to proposals) and share our concerns or needs. Gazebo have a wheel body, if we can define a wheel as "wheel" we can genera= te=20 code that take advantage of that body. I don't know how to better merge thi= s=20 with xode specification. I agree with you, every gazebo's specific tag will begin with "gz_", every= =20 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. = =20 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= her=20 with the gz_battery_iface info IMHO. I'd add a description tag to every file, we can extract documentation from= =20 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= d=20 robot"/> =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= =20 group similar information About interfaces I don't like the type and from ideas. The main idea behind the XML file is = be=20 able to make a model definition _entirely_ inside the XML file so the "from= "=20 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 = the=20 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= l=20 send comments on them in next emails :P <ext ename=3D"gz_sonar_iface"> <provides location=3D"chassis"> <sonar range=3D"5.0"> <transform> <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= format=3D"degrees" /> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </rotation> </transform> </sonar> <sonar range=3D"5.0"> <transform> <position x=3D"-0.45" y=3D"0.2" z=3D"0.23" /> <rotation> <euler x=3D"0" y=3D"120" z=3D"0" aformat=3D"degrees" /> </rotation> </transform> </sonar> </ext> 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= =20 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 = can=20 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= =20 easy solution. Comments wellcome! =46riday 24 March 2006 04:37=E3=80=81Konstantinos Dalamagkidis =E3=81=95=E3= =82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F: > 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 > observations: > 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 > documentation. > 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 > > dalai > > > ____________________________________________________________________ > http://www.freemail.gr - =CE=B4=CF=89=CF=81=CE=B5=CE=AC=CE=BD =CF=85=CF= =80=CE=B7=CF=81=CE=B5=CF=83=CE=AF=CE=B1 =CE=B7=CE=BB=CE=B5=CE=BA=CF=84=CF= =81=CE=BF=CE=BD=CE=B9=CE=BA=CE=BF=CF=8D =CF=84=CE=B1=CF=87=CF=85=CE=B4=CF= =81=CE=BF=CE=BC=CE=B5=CE=AF=CE=BF=CF=85. > http://www.freemail.gr - free email service for the Greek-speaking. |
From: Konstantinos D. <da...@fr...> - 2006-03-24 23:15:41
Attachments:
dalai.vcf
|
Jordi wrote: > Gazebo have a wheel body, if we can define a wheel as "wheel" we can generate > code that take advantage of that body. I don't know how to better merge this > with xode specification. > > Taking a look at the WheelGeom.cc and SphereGeom.cc, from what I can understand the "wheel" is the same as a sphere ode geom with different opengl code to render it. Since gazebo is internally using an ODE body maybe we could define it as an ODE body (xode compliant) - perhaps putting an extra tag that it is a wheel for the rendering part. I'm not sure how the collision detection works with it. > 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. > But I won't put there the position and rotation information. The xode > specification have already tags to do that, so we can use the standar > <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. > That wasn't the position and rotation of the model per se but the default values in case they are not defined in the world file. I guess we could use the transformation tag there too for consistency. > Also, the battery tag should go out of the general information and go together > with the gz_battery_iface info IMHO. > That battery tag was also about the default values. I don't know if there is a need for a separate section for the model parameters and their defaults. > 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): > > <group> <!-- General info --> > <ext ename="gz_model_info"> > <model name="Pioneer2AT" > description="Pioneer 2AT from ActivMedia, mobile all-terrain four wheeled > robot"/> > <author name="Andrew Howard" /> > <author name="Nate Koenig" /> > </ext> > </group> > > > I also like your organization, far better than mine using the group tags to > group similar information > > > About interfaces > I don't like the type and from ideas. The main idea behind the XML file is be > 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 > what to do with each interface. > Because of that the "type" attribute is also useless, we already know that the > gz_position_iface interface will always work with gz_position. > To be honest I was wondering today why I proposed that yesterday. I guess I was thinking about the ability to build custom interfaces. You are right though, the gz_position_iface and any other interface should always behave the same way and return the same info. > Regarding interfaces, I open every model that has the interface (example > sonar). I read the code and took notes about how differently models use > interfaces, then come up with a general solution. Sonars are easy, every > gazebo model works more or less the same regarding to them. The most > difficult interface will be gz_position_iface. About others interfaces, I'll > send comments on them in next emails :P > > <ext ename="gz_sonar_iface"> > <provides location="chassis"> > <sonar range="5.0"> > <transform> > <position x="-0.40" y="0.17" z="0.23" /> > <rotation> > <euler x="0" y="90" z="0" aformat="degrees" /> > </rotation> > </transform> > </sonar> > <sonar range="5.0"> > <transform> > <position x="-0.45" y="0.2" z="0.23" /> > <rotation> > <euler x="0" y="120" z="0" aformat="degrees" /> > </rotation> > </transform> > </sonar> > </ext> > > > The transform tag make it a bit long (imagine 48 sonars!) but it will be > 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? > I agree. They take 50 lines of code anyway now. > Cameras should go inside the XML as everything else, we must decide how we can > best define them. I'll take a look to battery and cameras next, I'll take > your current specification as base. > I was asking that because cameras now are completely different models with their own interfaces and parameters and stuff. ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. |
From: Jordi <mu...@gm...> - 2006-03-25 13:24:13
|
> > Gazebo have a wheel body, if we can define a wheel as "wheel" we can > > generate code that take advantage of that body. I don't know how to > > better merge this with xode specification. > > Taking a look at the WheelGeom.cc and SphereGeom.cc, from what I can > understand the "wheel" is the same as a sphere ode geom with different > opengl code to render it. Since gazebo is internally using an ODE body > maybe we could define it as an ODE body (xode compliant) - perhaps > putting an extra tag that it is a wheel for the rendering part. I'm not > sure how the collision detection works with it. > 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 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. > > But I won't put there the position and rotation information. The xode > > specification have already tags to do that, so we can use the standar > > <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. > > That wasn't the position and rotation of the model per se but the > default values in case they are not defined in the world file. I guess > we could use the transformation tag there too for consistency. > > > Also, the battery tag should go out of the general information and go > > together with the gz_battery_iface info IMHO. > > That battery tag was also about the default values. I don't know if > there is a need for a separate section for the model parameters and > their defaults. 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. > > Cameras should go inside the XML as everything else, we must decide how > > we can best define them. I'll take a look to battery and cameras next, > > I'll take your current specification as base. > > I was asking that because cameras now are completely different models > with their own interfaces and parameters and stuff. > Then we can just define the camera's model in their own XML. The world file will be use to join together the camera model with the robot model. I'll take a look to this tomorrow. -- Jordi Polo |
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. |
From: Jordi <mu...@gm...> - 2006-03-27 19:12:05
|
> 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. You are right, surely nobody has such a strong need for wheels or ODE would add support for them. You have mistyped the first <sphere radius="0.2" /> isn't it? gz_appearance for color information and the like is OK for me. I have some issues against your <wheel track_width="0.05" /> tag. But instead of talk about it, I'd like to know if there's any reason not to use cylinders as wheels, we have right there the extra parameter needed by wheels (in cylinders is called length). If we use cylinders, we can just use standar xode. <cylinder radius="0.2" length="0.05" /> BTW, Anybody knows about the future of ODE development? It seems like we have been using 0.5 version for ages. Maybe they are planning wheels. > > > 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. What I meant is that we don't need to say : "hey! here we have a default" In XML you proposed in this same email, you have the wheel geometry (that up to now can't be overwritten by the world file) and you also put the colour info. This information can be overwritten but no special distintion is needed. We can somewhat merge the information of the world file and the model file, so the world file always overwrite the model file's values. This way, any parameter of a model can be changed by the world file in the future and we don't need to touch the model files. maybe we need your proposed "gz_model_parameters" anyway if there is a lot of model-wide miscellaneous information. > > 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. I agree with the idea of a CVS branch. Maybe someday Nate will give us write access to the CVS. Otherwise when I start redefine current models I'll start a CVS somewhere else. I think is too early for a spec document, there is still a lot of issues we must decide. I think that for that document a format similar to the xode document is the best choice, anyway users will need to read both. > xgazebo sounds like an X application, gazeboXML would be my choice. > gazeboEX - "Gazebo Extension to XODE" ? gazeboEX sounds like a really killer application!! wooah People will be deceived when they know what is it all about :P |
From: Konstantinos D. <da...@fr...> - 2006-03-27 20:18:52
Attachments:
dalai.vcf
|
> > You are right, surely nobody has such a strong need for wheels or ODE would > add support for them. > You have mistyped the first <sphere radius="0.2" /> isn't it? > Actually the XODE spec talks about bodies and geoms separately. It seems that you have to define both despite the fact that most likely they are going to be the same. I might be wrong on this I haven't studied the spec or ODE all that much. > gz_appearance for color information and the like is OK for me. > > I have some issues against your <wheel track_width="0.05" /> tag. But instead > of talk about it, I'd like to know if there's any reason not to use cylinders > as wheels, we have right there the extra parameter needed by wheels (in > cylinders is called length). If we use cylinders, we can just use standar > xode. > <cylinder > radius="0.2" > length="0.05" > /> > Even if we used the cylinder it might still be useful to have a wheel tag for rendering - for example to put a different color on the tire than the rest of the wheel or to make it more fancy looking. > BTW, Anybody knows about the future of ODE development? It seems like we have > been using 0.5 version for ages. Maybe they are planning wheels. > The number of products using ODE is fairly large and a lot of them are racing simulators. I suspect a need for special wheel bodies is not great. Furthermore when physics and collision detection are concerned cylinders and spheres are probably adequate - rendering being a different issue. > What I meant is that we don't need to say : "hey! here we have a default" > In XML you proposed in this same email, you have the wheel geometry (that up > to now can't be overwritten by the world file) and you also put the colour > info. This information can be overwritten but no special distintion is > needed. > We can somewhat merge the information of the world file and the model file, so > the world file always overwrite the model file's values. > This way, any parameter of a model can be changed by the world file in the > future and we don't need to touch the model files. > > maybe we need your proposed "gz_model_parameters" anyway if there is a lot of > model-wide miscellaneous information. > That's a good idea. I was thinking of limiting the overriding to the few parameters currently available. Of course that will probably mean modifications to the world file parser too. > I agree with the idea of a CVS branch. Maybe someday Nate will give us write > access to the CVS. Otherwise when I start redefine current models I'll start > a CVS somewhere else. > I think is too early for a spec document, there is still a lot of issues we > must decide. I think that for that document a format similar to the xode > document is the best choice, anyway users will need to read both. > I was thinking of starting to write one in a wiki like form (pbwiki.com or writeboard.com). At first we can just collect the stuff that we more or less agree on. I'm not taking about detailed descriptions but the structure. Then we try to force one by one the models currently available on that structure and make adjustments where needed. Later we add descriptions maybe a couple of simple examples and we get something like the xode one. This way we have revisions, anyone in the list that want can go directly and see (perhaps even modify it) and we don't fill people's mailboxes. > gazeboEX sounds like a really killer application!! wooah People will be > deceived when they know what is it all about :P > How about gazeboRMAX (gazebo Robotic Modeling Additions to XODE) :D With some good advertising and a cool logo we can make a fortune I tell you !!!! ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. |
From: Jordi <mu...@gm...> - 2006-03-27 23:19:09
|
> Actually the XODE spec talks about bodies and geoms separately. It seems > that you have to define both despite the fact that most likely they are > going to be the same. I might be wrong on this I haven't studied the > spec or ODE all that much. I understood that geom belongs to body (to his closest ancestor) so there's= no=20 need to define both. > > gz_appearance for color information and the like is OK for me. > > > > I have some issues against your <wheel track_width=3D"0.05" /> tag. But > > instead of talk about it, I'd like to know if there's any reason not to > > use cylinders as wheels, we have right there the extra parameter needed > > by wheels (in cylinders is called length). If we use cylinders, we can > > just use standar xode. > > <cylinder > > radius=3D"0.2" > > length=3D"0.05" > > /> > > Even if we used the cylinder it might still be useful to have a wheel > tag for rendering - for example to put a different color on the tire > than the rest of the wheel or to make it more fancy looking. Ok, I think that I got it. Maybe we use a game engine or maybe we use Ogre3D, in both cases we'll have= a=20 format for 3D objects meshes (meshes can be pretty complex, not only the=20 triangles are defined, but colours, textures, animation ...). For instance = in=20 Ogre3D we have the .mesh files (I assume .mesh now, but anything is ok). In= =20 the future, gazebo will use this files to render the models. =20 What we can do here is inside gz_appearance have something like: <mesh name=3D"wheel" location=3D"wheel.mesh" > <scale x=3D"2" y=3D"1" z=3D"0.1" /> </mesh> Along with the color and skin atributes, we can change the apparency of any= =20 object. So with less bodies we can make more complex models. This attribute= =20 also can be made available for the world files. In this example, the standard wheel mesh will be scaled so is double size i= n=20 the x axis, ten times smaller in the z axis and equal in y axis. This change depends on the change of the rendering subsystem of gazebo.=20 > > maybe we need your proposed "gz_model_parameters" anyway if there is a > > lot of model-wide miscellaneous information. > > That's a good idea. I was thinking of limiting the overriding to the few > parameters currently available. Of course that will probably mean > modifications to the world file parser too. =46rom one of my first emails, we can use this: <ext ename=3D"gazebo_attribute"> <attribute name=3D"id"\> <attribute name=3D"xyz" default=3D""\> <attribute name=3D"rpy" \> <attribute name=3D"size" default=3D"1.0"\> </ext> So we know what parameters can be overwritten by the world file in this mod= el. > > I was thinking of starting to write one in a wiki like form (pbwiki.com > or writeboard.com). At first we can just collect the stuff that we more > or less agree on. I'm not taking about detailed descriptions but the > structure. Then we try to force one by one the models currently > available on that structure and make adjustments where needed. Later we > add descriptions maybe a couple of simple examples and we get something > like the xode one. This way we have revisions, anyone in the list that > want can go directly and see (perhaps even modify it) and we don't fill > people's mailboxes. outstanding idea! I've just made an empty one: http://gazeboxml.pbwiki.com/ We can change the name if you like. Tomorrow I'll take everything I have around (mails and other things) and p= ut=20 it online there.=20 > > > gazeboEX sounds like a really killer application!! wooah People will be > > deceived when they know what is it all about :P > > How about gazeboRMAX (gazebo Robotic Modeling Additions to XODE) :D > With some good advertising and a cool logo we can make a fortune I tell > you !!!! > You have something! Really! Have you ever thought about working in a marketing agency. I think= =20 that you'd be very valuable there=20 You are the best suited to decide the name of the project. =2D- Jordi |
From: Konstantinos D. <da...@fr...> - 2006-03-28 03:30:04
|
hi, > I understood that geom belongs to body (to his closest ancestor) so there's no > need to define both. > What I got was that <body> is for the rigid body and <geom> is for the collision detection, so although the geom may belong to a body it might be different eg. a rectangular body with a sphere geom. >>> maybe we need your proposed "gz_model_parameters" anyway if there is a >>> lot of model-wide miscellaneous information. >>> >> That's a good idea. I was thinking of limiting the overriding to the few >> parameters currently available. Of course that will probably mean >> modifications to the world file parser too. >> > > From one of my first emails, we can use this: > > <ext ename="gazebo_attribute"> > <attribute name="id"\> > <attribute name="xyz" default=""\> > <attribute name="rpy" \> > <attribute name="size" default="1.0"\> > </ext> > > So we know what parameters can be overwritten by the world file in this model. > > I liked your other suggestion better where everything can be overridden in the world file. This way there is no need for extra tagging in the model file. > outstanding idea! > I've just made an empty one: http://gazeboxml.pbwiki.com/ > We can change the name if you like. > Tomorrow I'll take everything I have around (mails and other things) and put > it online there. > ok I saw that we can't put more than 3 comments on each page, but we can make a discussion/notes page for that. I was also thinking if we should name the interfaces after the ones used in player e.g. gz_position3d instead of gz_position but I guess we can have this conversation in pbwiki. >>> gazeboEX sounds like a really killer application!! wooah People will be >>> deceived when they know what is it all about :P >>> >> How about gazeboRMAX (gazebo Robotic Modeling Additions to XODE) :D >> With some good advertising and a cool logo we can make a fortune I tell >> you !!!! >> > > You have something! > Really! Have you ever thought about working in a marketing agency. I think > that you'd be very valuable there > You are the best suited to decide the name of the project. > ok since it is still under work we will need an internal name (all the software giants have them). How about Project XG-1: Atlas (because it will hold the "world" information)? Then when it is near completion we can coin a marketing name. I'd also recommend we sell the first version cheap (say $59.99) but incorporate some bugs. Then we can charge ($29.99) for each service pack and ($299.99) for version 1.5 After that the path to world domination is open. *mad laughter goes here* Sorry it's this darn SRMD again (http://project-apollo.net/mos/index.html). -dalai ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. |