Re: [PlayerStage-Gazebo] Why do Sensors have to be attached to a body?

[Nate K. <nk...@us...>]

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
>
>