From: Benjamin K. <ben...@gm...> - 2008-01-09 15:00:56
|
Hello, I am trying to write a force / torque sensor for joints. My idea is to have the name of the joint passed to the sensor in its XML tag. But then I run into a problem: To get the actual joint object in the sensor's constructor, I need to call the method GetJoint(jointName) of the _Model_. But the sensor doesn't know the model, it just knows the body it is attached to. I have thought of two solutions: 1. Get the parent of the body and test if it is of the type "Model". If not, get the parent of the parent, and so on until I have found the Model and can call GetJoint. I have to do this recursively to catch the case where the sensor is attached to a body that is attached to another body that is attached to the model. 2. Change the Sensor superclass so it isn't attached to a body, but to a model or even an entity (which would allow it to be attached directly to the joint). This would involve moving the LoadSensor part of Body to the Model class (or Entity). I think Model would be the best home for it. Personally, I like the idea of attaching sensors to models rather than bodies better. The first solution would probably work, but I can think of several sensors that don't have a physical shape and therefore don't have an obvious body to be attached to. Battery charge, ground truth and yes, force sensors for joints. The major disadvantage would be that without further changes it would be cumbersome to get hold of a sub-body (i.e. a body that is attached to a body that is attached to the model) from within a sensor. So my question is, would there be any serious impact besides having to change the existing sensors (i.e. Ray- and Camera-Sensor)? If no, I would like to implement the second solution. If there are objections, I will go the first route. Regards, Ben -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10 |
From: Jordi <mu...@gm...> - 2008-01-09 16:22:04
|
The problem is that some sensors will need to be positionated, and will nee= d to be moved in the simulation. For instance cameras. In that cases it makes very sense to put them in a Body, ie. the entity that can be placed and hav= e joints attached. On the other hand, it is true that a lot of sensors have more sense just being in the Model. Umm... I'd say that sensors can inherit Body instead of Entity, so they bot= h have a bodyId, are placeable, can be attached with joints and are potential direct children of Models. I think that is the minimal change and powerful enough for all the sensors. Anyway, what are the main kind of sensors out there? - cameras - lasers - microphones - bumpers (or other more sophisticated contact sensors) - force sensors - gyroscopes /velocimetres ... - truth - battery charge - temperature (contact or non-contact method) For any of these, I think that a sensor inheriting Body can be enough. What do you think? On Jan 10, 2008 12:00 AM, Benjamin Kloster <ben...@gm...> wrote: > Hello, > I am trying to write a force / torque sensor for joints. My idea is to > have the name of the joint passed to the sensor in its XML tag. But then = I > run into a problem: To get the actual joint object in the sensor's > constructor, I need to call the method GetJoint(jointName) of the _Model_= . > But the sensor doesn't know the model, it just knows the body it is attac= hed > to. I have thought of two solutions: > > 1. Get the parent of the body and test if it is of the type "Model". If > not, get the parent of the parent, and so on until I have found the Model > and can call GetJoint. I have to do this recursively to catch the case wh= ere > the sensor is attached to a body that is attached to another body that is > attached to the model. > > 2. Change the Sensor superclass so it isn't attached to a body, but to a > model or even an entity (which would allow it to be attached directly to = the > joint). This would involve moving the LoadSensor part of Body to the Mode= l > class (or Entity). I think Model would be the best home for it. > > Personally, I like the idea of attaching sensors to models rather than > bodies better. The first solution would probably work, but I can think of > several sensors that don't have a physical shape and therefore don't have= an > obvious body to be attached to. Battery charge, ground truth and yes, for= ce > sensors for joints. > > The major disadvantage would be that without further changes it would be > cumbersome to get hold of a sub-body (i.e. a body that is attached to a > body that is attached to the model) from within a sensor. > > So my question is, would there be any serious impact besides having to > change the existing sensors (i.e. Ray- and Camera-Sensor)? If no, I would > like to implement the second solution. If there are objections, I will go > the first route. > > Regards, > Ben > -- > Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=3D10 > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl= ace > _______________________________________________ > Playerstage-gazebo mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > --=20 Jordi Polo Carres Natural language processing laboratory NAIST http://www.bahasara.org |
From: Nate K. <nk...@us...> - 2008-01-11 16:45:20
|
The Sensor class inherits from Entity, and that is the way it should stay. A Sensor is not a type of Body. Also, a sensor must be attached to a body. This is the mechanism that allows the sensor to move properly. A body can not be nested within another body. Therefore, a body's parent must always be a Model. Given this, I suggest option number 1. -nate On Jan 9, 2008 8:22 AM, Jordi <mu...@gm...> wrote: > > The problem is that some sensors will need to be positionated, and will n= eed > to be moved in the simulation. For instance cameras. In that cases it mak= es > very sense to put them in a Body, ie. the entity that can be placed and h= ave > joints attached. > > On the other hand, it is true that a lot of sensors have more sense just > being in the Model. > > Umm... I'd say that sensors can inherit Body instead of Entity, so they b= oth > have a bodyId, are placeable, can be attached with joints and are potenti= al > direct children of Models. I think that is the minimal change and powerfu= l > enough for all the sensors. > > Anyway, what are the main kind of sensors out there? > > - cameras > - lasers > - microphones > - bumpers (or other more sophisticated contact sensors) > - force sensors > - gyroscopes /velocimetres ... > - truth > - battery charge > - temperature (contact or non-contact method) > > > For any of these, I think that a sensor inheriting Body can be enough. > > What do you think? > > > > > On Jan 10, 2008 12:00 AM, Benjamin Kloster <ben...@gm...> wrote: > > Hello, > > I am trying to write a force / torque sensor for joints. My idea is to > have the name of the joint passed to the sensor in its XML tag. But then = I > run into a problem: To get the actual joint object in the sensor's > constructor, I need to call the method GetJoint(jointName) of the _Model_= . > But the sensor doesn't know the model, it just knows the body it is attac= hed > to. I have thought of two solutions: > > > > 1. Get the parent of the body and test if it is of the type "Model". If > not, get the parent of the parent, and so on until I have found the Model > and can call GetJoint. I have to do this recursively to catch the case wh= ere > the sensor is attached to a body that is attached to another body that is > attached to the model. > > > > 2. Change the Sensor superclass so it isn't attached to a body, but to = a > model or even an entity (which would allow it to be attached directly to = the > joint). This would involve moving the LoadSensor part of Body to the Mode= l > class (or Entity). I think Model would be the best home for it. > > > > Personally, I like the idea of attaching sensors to models rather than > bodies better. The first solution would probably work, but I can think of > several sensors that don't have a physical shape and therefore don't have= an > obvious body to be attached to. Battery charge, ground truth and yes, for= ce > sensors for joints. > > > > The major disadvantage would be that without further changes it would b= e > cumbersome to get hold of a sub-body (i.e. a body that is attached to a b= ody > that is attached to the model) from within a sensor. > > > > So my question is, would there be any serious impact besides having to > change the existing sensors ( i.e. Ray- and Camera-Sensor)? If no, I woul= d > like to implement the second solution. If there are objections, I will go > the first route. > > > > Regards, > > Ben > > -- > > Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? > > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=3D10 > > > > -----------------------------------------------------------------------= -- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl= ace > > _______________________________________________ > > Playerstage-gazebo mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > > > -- > Jordi Polo Carres > Natural language processing laboratory > NAIST > http://www.bahasara.org > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl= ace > > _______________________________________________ > Playerstage-gazebo mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > |
From: Benjamin K. <ben...@gm...> - 2008-01-17 14:05:58
|
Hello again, well, I saw that Body can be parented to an Entity and jumped to the conclusion that it can therefore be parented to all subclasses of Entity. The hint that bodies can't be nested simplified things, thanks. Now I have general questions regarding creating sensors and especially sending a sensor in to contribute to Gazebo: >From the examples (camera and ray sensors) it looks like sensors have three parts: 1. The code in server/sensors/FancySensor 2. A controller in server/sensors/FancyController to publish the sensor data 3. An interface definition in libgazebo/gazebo.h Are there any other places where something needs to be done to create a functional sensor? Second Question: In the JointForceSensor class (part 1, if you will) I use the dJointFeedback struct of ODE. Since it is planned to make the physics engine replaceable, should I create a wrapper for the data structure or just check whether ODE is available and if not, throw an error? Ben -------- Original-Nachricht -------- > Datum: Fri, 11 Jan 2008 08:45:20 -0800 > Von: "Nate Koenig" <nk...@us...> > An: "Gazebo developers" <pla...@li...> > Betreff: Re: [PlayerStage-Gazebo] Why do Sensors have to be attached to a body? > The Sensor class inherits from Entity, and that is the way it should > stay. A Sensor is not a type of Body. > > Also, a sensor must be attached to a body. This is the mechanism that > allows the sensor to move properly. > > A body can not be nested within another body. Therefore, a body's > parent must always be a Model. > > Given this, I suggest option number 1. > > -nate > > On Jan 9, 2008 8:22 AM, Jordi <mu...@gm...> wrote: > > > > The problem is that some sensors will need to be positionated, and will > need > > to be moved in the simulation. For instance cameras. In that cases it > makes > > very sense to put them in a Body, ie. the entity that can be placed and > have > > joints attached. > > > > On the other hand, it is true that a lot of sensors have more sense just > > being in the Model. > > > > Umm... I'd say that sensors can inherit Body instead of Entity, so they > both > > have a bodyId, are placeable, can be attached with joints and are > potential > > direct children of Models. I think that is the minimal change and > powerful > > enough for all the sensors. > > > > Anyway, what are the main kind of sensors out there? > > > > - cameras > > - lasers > > - microphones > > - bumpers (or other more sophisticated contact sensors) > > - force sensors > > - gyroscopes /velocimetres ... > > - truth > > - battery charge > > - temperature (contact or non-contact method) > > > > > > For any of these, I think that a sensor inheriting Body can be enough. > > > > What do you think? > > > > > > > > > > On Jan 10, 2008 12:00 AM, Benjamin Kloster <ben...@gm...> wrote: > > > Hello, > > > I am trying to write a force / torque sensor for joints. My idea is to > > have the name of the joint passed to the sensor in its XML tag. But then > I > > run into a problem: To get the actual joint object in the sensor's > > constructor, I need to call the method GetJoint(jointName) of the > _Model_. > > But the sensor doesn't know the model, it just knows the body it is > attached > > to. I have thought of two solutions: > > > > > > 1. Get the parent of the body and test if it is of the type "Model". > If > > not, get the parent of the parent, and so on until I have found the > Model > > and can call GetJoint. I have to do this recursively to catch the case > where > > the sensor is attached to a body that is attached to another body that > is > > attached to the model. > > > > > > 2. Change the Sensor superclass so it isn't attached to a body, but to > a > > model or even an entity (which would allow it to be attached directly to > the > > joint). This would involve moving the LoadSensor part of Body to the > Model > > class (or Entity). I think Model would be the best home for it. > > > > > > Personally, I like the idea of attaching sensors to models rather than > > bodies better. The first solution would probably work, but I can think > of > > several sensors that don't have a physical shape and therefore don't > have an > > obvious body to be attached to. Battery charge, ground truth and yes, > force > > sensors for joints. > > > > > > The major disadvantage would be that without further changes it would > be > > cumbersome to get hold of a sub-body (i.e. a body that is attached to a > body > > that is attached to the model) from within a sensor. > > > > > > So my question is, would there be any serious impact besides having to > > change the existing sensors ( i.e. Ray- and Camera-Sensor)? If no, I > would > > like to implement the second solution. If there are objections, I will > go > > the first route. > > > > > > Regards, > > > Ben > > > -- > > > Psssst! Schon vom neuen GMX MultiMessenger gehört? > > > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10 > > > > > > > ------------------------------------------------------------------------- > > > Check out the new SourceForge.net Marketplace. > > > It's the best place to buy or sell services for > > > just about anything Open Source. > > > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > _______________________________________________ > > > Playerstage-gazebo mailing list > > > Pla...@li... > > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > > > > > > > > -- > > Jordi Polo Carres > > Natural language processing laboratory > > NAIST > > http://www.bahasara.org > > > > > ------------------------------------------------------------------------- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > > _______________________________________________ > > Playerstage-gazebo mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Playerstage-gazebo mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail |
From: Nate K. <nk...@us...> - 2008-01-24 20:35:36
|
> >From the examples (camera and ray sensors) it looks like sensors have th= ree parts: > 1. The code in server/sensors/FancySensor > 2. A controller in server/sensors/FancyController to publish the sensor d= ata > 3. An interface definition in libgazebo/gazebo.h > Are there any other places where something needs to be done to create a f= unctional sensor? Those should be the only places where you have to add code. > Second Question: In the JointForceSensor class (part 1, if you will) I us= e the dJointFeedback struct of ODE. Since it is planned to make the physics= engine replaceable, should I create a wrapper for the data structure or ju= st check whether ODE is available and if not, throw an error? At this stage in the game you don't have to worry about wrapping up the ODE stuff. The ultimate goal was to make the physics engine replaceable, but this hasn't happened yet and will not happen for a good while. You can just use the ODE structure directly. -nate > -------- Original-Nachricht -------- > > Datum: Fri, 11 Jan 2008 08:45:20 -0800 > > Von: "Nate Koenig" <nk...@us...> > > An: "Gazebo developers" <pla...@li...> > > Betreff: Re: [PlayerStage-Gazebo] Why do Sensors have to be attached to= a body? > > > > The Sensor class inherits from Entity, and that is the way it should > > stay. A Sensor is not a type of Body. > > > > Also, a sensor must be attached to a body. This is the mechanism that > > allows the sensor to move properly. > > > > A body can not be nested within another body. Therefore, a body's > > parent must always be a Model. > > > > Given this, I suggest option number 1. > > > > -nate > > > > On Jan 9, 2008 8:22 AM, Jordi <mu...@gm...> wrote: > > > > > > The problem is that some sensors will need to be positionated, and wi= ll > > need > > > to be moved in the simulation. For instance cameras. In that cases it > > makes > > > very sense to put them in a Body, ie. the entity that can be placed a= nd > > have > > > joints attached. > > > > > > On the other hand, it is true that a lot of sensors have more sense j= ust > > > being in the Model. > > > > > > Umm... I'd say that sensors can inherit Body instead of Entity, so th= ey > > both > > > have a bodyId, are placeable, can be attached with joints and are > > potential > > > direct children of Models. I think that is the minimal change and > > powerful > > > enough for all the sensors. > > > > > > Anyway, what are the main kind of sensors out there? > > > > > > - cameras > > > - lasers > > > - microphones > > > - bumpers (or other more sophisticated contact sensors) > > > - force sensors > > > - gyroscopes /velocimetres ... > > > - truth > > > - battery charge > > > - temperature (contact or non-contact method) > > > > > > > > > For any of these, I think that a sensor inheriting Body can be enough= . > > > > > > What do you think? > > > > > > > > > > > > > > > On Jan 10, 2008 12:00 AM, Benjamin Kloster <ben...@gm...> wrot= e: > > > > Hello, > > > > I am trying to write a force / torque sensor for joints. My idea is= to > > > have the name of the joint passed to the sensor in its XML tag. But t= hen > > I > > > run into a problem: To get the actual joint object in the sensor's > > > constructor, I need to call the method GetJoint(jointName) of the > > _Model_. > > > But the sensor doesn't know the model, it just knows the body it is > > attached > > > to. I have thought of two solutions: > > > > > > > > 1. Get the parent of the body and test if it is of the type "Model"= . > > If > > > not, get the parent of the parent, and so on until I have found the > > Model > > > and can call GetJoint. I have to do this recursively to catch the cas= e > > where > > > the sensor is attached to a body that is attached to another body tha= t > > is > > > attached to the model. > > > > > > > > 2. Change the Sensor superclass so it isn't attached to a body, but= to > > a > > > model or even an entity (which would allow it to be attached directly= to > > the > > > joint). This would involve moving the LoadSensor part of Body to the > > Model > > > class (or Entity). I think Model would be the best home for it. > > > > > > > > Personally, I like the idea of attaching sensors to models rather t= han > > > bodies better. The first solution would probably work, but I can thin= k > > of > > > several sensors that don't have a physical shape and therefore don't > > have an > > > obvious body to be attached to. Battery charge, ground truth and yes, > > force > > > sensors for joints. > > > > > > > > The major disadvantage would be that without further changes it wou= ld > > be > > > cumbersome to get hold of a sub-body (i.e. a body that is attached to= a > > body > > > that is attached to the model) from within a sensor. > > > > > > > > So my question is, would there be any serious impact besides having= to > > > change the existing sensors ( i.e. Ray- and Camera-Sensor)? If no, I > > would > > > like to implement the second solution. If there are objections, I wil= l > > go > > > the first route. > > > > > > > > Regards, > > > > Ben > > > > -- > > > > Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? > > > > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did= =3D10 > > > > > > > > > > -----------------------------------------------------------------------= -- > > > > Check out the new SourceForge.net Marketplace. > > > > It's the best place to buy or sell services for > > > > just about anything Open Source. > > > > > > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/market= place > > > > _______________________________________________ > > > > Playerstage-gazebo mailing list > > > > Pla...@li... > > > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > > > > > > > > > > > > > -- > > > Jordi Polo Carres > > > Natural language processing laboratory > > > NAIST > > > http://www.bahasara.org > > > > > > > > -----------------------------------------------------------------------= -- > > > Check out the new SourceForge.net Marketplace. > > > It's the best place to buy or sell services for > > > just about anything Open Source. > > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/market= place > > > > > > _______________________________________________ > > > Playerstage-gazebo mailing list > > > Pla...@li... > > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > > > > > > > -----------------------------------------------------------------------= -- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/market= place > > _______________________________________________ > > Playerstage-gazebo mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > -- > GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. > Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > Playerstage-gazebo mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > |
From: Jordi <mu...@gm...> - 2008-01-25 15:40:28
|
Anyway, it seems that we are going to use PAL as physics middleware. And I don't know if those will work with the ODE engine but they have these sensors mentioned between the features: Sensors - Contact - Compass (Angular position) - GPS (Global Positioning System - Position) - Gyroscope (Angular velocity) - Inclinometer (Angular position) - PSD (Position Sensitive Device - Ray casting) - Velocimeter (Linear velocity) - Transponder (Distance between two objects) Maybe your code can added to PAL + Gazebo sensor interface. On Jan 25, 2008 5:35 AM, Nate Koenig <nk...@us...> wrote: > > >From the examples (camera and ray sensors) it looks like sensors have > three parts: > > 1. The code in server/sensors/FancySensor > > 2. A controller in server/sensors/FancyController to publish the sensor > data > > 3. An interface definition in libgazebo/gazebo.h > > Are there any other places where something needs to be done to create a > functional sensor? > > Those should be the only places where you have to add code. > > > Second Question: In the JointForceSensor class (part 1, if you will) I > use the dJointFeedback struct of ODE. Since it is planned to make the > physics engine replaceable, should I create a wrapper for the data struct= ure > or just check whether ODE is available and if not, throw an error? > > At this stage in the game you don't have to worry about wrapping up > the ODE stuff. The ultimate goal was to make the physics engine > replaceable, but this hasn't happened yet and will not happen for a > good while. You can just use the ODE structure directly. > > -nate > > > -------- Original-Nachricht -------- > > > Datum: Fri, 11 Jan 2008 08:45:20 -0800 > > > Von: "Nate Koenig" <nk...@us...> > > > An: "Gazebo developers" <pla...@li...> > > > Betreff: Re: [PlayerStage-Gazebo] Why do Sensors have to be attached > to a body? > > > > > > > The Sensor class inherits from Entity, and that is the way it should > > > stay. A Sensor is not a type of Body. > > > > > > Also, a sensor must be attached to a body. This is the mechanism that > > > allows the sensor to move properly. > > > > > > A body can not be nested within another body. Therefore, a body's > > > parent must always be a Model. > > > > > > Given this, I suggest option number 1. > > > > > > -nate > > > > > > On Jan 9, 2008 8:22 AM, Jordi <mu...@gm...> wrote: > > > > > > > > The problem is that some sensors will need to be positionated, and > will > > > need > > > > to be moved in the simulation. For instance cameras. In that cases > it > > > makes > > > > very sense to put them in a Body, ie. the entity that can be placed > and > > > have > > > > joints attached. > > > > > > > > On the other hand, it is true that a lot of sensors have more sense > just > > > > being in the Model. > > > > > > > > Umm... I'd say that sensors can inherit Body instead of Entity, so > they > > > both > > > > have a bodyId, are placeable, can be attached with joints and are > > > potential > > > > direct children of Models. I think that is the minimal change and > > > powerful > > > > enough for all the sensors. > > > > > > > > Anyway, what are the main kind of sensors out there? > > > > > > > > - cameras > > > > - lasers > > > > - microphones > > > > - bumpers (or other more sophisticated contact sensors) > > > > - force sensors > > > > - gyroscopes /velocimetres ... > > > > - truth > > > > - battery charge > > > > - temperature (contact or non-contact method) > > > > > > > > > > > > For any of these, I think that a sensor inheriting Body can be > enough. > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > > > On Jan 10, 2008 12:00 AM, Benjamin Kloster <ben...@gm...> > wrote: > > > > > Hello, > > > > > I am trying to write a force / torque sensor for joints. My idea > is to > > > > have the name of the joint passed to the sensor in its XML tag. But > then > > > I > > > > run into a problem: To get the actual joint object in the sensor's > > > > constructor, I need to call the method GetJoint(jointName) of the > > > _Model_. > > > > But the sensor doesn't know the model, it just knows the body it is > > > attached > > > > to. I have thought of two solutions: > > > > > > > > > > 1. Get the parent of the body and test if it is of the type > "Model". > > > If > > > > not, get the parent of the parent, and so on until I have found the > > > Model > > > > and can call GetJoint. I have to do this recursively to catch the > case > > > where > > > > the sensor is attached to a body that is attached to another body > that > > > is > > > > attached to the model. > > > > > > > > > > 2. Change the Sensor superclass so it isn't attached to a body, > but to > > > a > > > > model or even an entity (which would allow it to be attached > directly to > > > the > > > > joint). This would involve moving the LoadSensor part of Body to th= e > > > Model > > > > class (or Entity). I think Model would be the best home for it. > > > > > > > > > > Personally, I like the idea of attaching sensors to models rather > than > > > > bodies better. The first solution would probably work, but I can > think > > > of > > > > several sensors that don't have a physical shape and therefore don'= t > > > have an > > > > obvious body to be attached to. Battery charge, ground truth and > yes, > > > force > > > > sensors for joints. > > > > > > > > > > The major disadvantage would be that without further changes it > would > > > be > > > > cumbersome to get hold of a sub-body (i.e. a body that is attached > to a > > > body > > > > that is attached to the model) from within a sensor. > > > > > > > > > > So my question is, would there be any serious impact besides > having to > > > > change the existing sensors ( i.e. Ray- and Camera-Sensor)? If no, = I > > > would > > > > like to implement the second solution. If there are objections, I > will > > > go > > > > the first route. > > > > > > > > > > Regards, > > > > > Ben > > > > > -- > > > > > Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? > > > > > Der kann`s mit allen: > http://www.gmx.net/de/go/multimessenger?did=3D10 > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > Check out the new SourceForge.net Marketplace. > > > > > It's the best place to buy or sell services for > > > > > just about anything Open Source. > > > > > > > > > > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl= ace > > > > > _______________________________________________ > > > > > Playerstage-gazebo mailing list > > > > > Pla...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > > > > > > > > > > > > > > > > > > -- > > > > Jordi Polo Carres > > > > Natural language processing laboratory > > > > NAIST > > > > http://www.bahasara.org > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > Check out the new SourceForge.net Marketplace. > > > > It's the best place to buy or sell services for > > > > just about anything Open Source. > > > > > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl= ace > > > > > > > > _______________________________________________ > > > > Playerstage-gazebo mailing list > > > > Pla...@li... > > > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > Check out the new SourceForge.net Marketplace. > > > It's the best place to buy or sell services for > > > just about anything Open Source. > > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl= ace > > > _______________________________________________ > > > Playerstage-gazebo mailing list > > > Pla...@li... > > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > -- > > GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. > > Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > _______________________________________________ > > Playerstage-gazebo mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Playerstage-gazebo mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo > --=20 Jordi Polo Carres Natural language processing laboratory NAIST http://www.bahasara.org |