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
Maybe your code can added to PAL + Gazebo sensor interface.



On Jan 25, 2008 5:35 AM, Nate Koenig <nkoenig@usc.edu> 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 structure 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" <nkoenig@usc.edu>
> > An: "Gazebo developers" <playerstage-gazebo@lists.sourceforge.net>
> > 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 <mumismo@gmail.com> 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-kloster@gmx.de> 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
> > > > Playerstage-gazebo@lists.sourceforge.net
> > > > 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
> > > Playerstage-gazebo@lists.sourceforge.net
> > > 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
> > Playerstage-gazebo@lists.sourceforge.net
> > 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
> Playerstage-gazebo@lists.sourceforge.net
> 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
Playerstage-gazebo@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo



--
Jordi Polo Carres
Natural language processing laboratory
NAIST
http://www.bahasara.org