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 |