On Jan 10, 2008 12:00 AM, Benjamin Kloster <email@example.com
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.
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.
Playerstage-gazebo mailing list