Closed arocchi closed 11 years ago
Suggestions: if it easy for you to write a python script that add the right things in the right place go for it! You will call it inside the script after the sdf conversion so it will be "transparent" to the user. What do you thing?
yes, I agree!
Alessio, you have solved this issue have you?
implemented a small python script. That was fairly quick, even if hackish. Things work now, though. Closing
Caused by some bug during conversion from urdf to sdf, the tags relative to the force_torque sensor do not show up in the final sdf (http://answers.gazebosim.org/question/4708/sensor-elements-in-urdf-disappearing-when/)
Since the community is not responding to the help request and we do not have the time and resources at the moment to fix this bug in the ros/gazebo tools, we should take action in a different way.
The actual architecture of the plugin is as follows:
1) gazebo force torque gazebo publishes on its own topic, has a joint as a parent, calls the underlying parentJoint->getWrench() function
2) gazebo force torque plugin attaches to that sensor, extends the sensor interface
3) our force forque plugin extends the gazebo force torque plugin, publishes data to the YARP interface onUpdate
Possible solutions: 1) change architecture: create a model plugin instead of a sensor plugin, call directly getWrench on desired joints. Cons: loses the ability to define the sensor location from the urdf. Changing robots means changing plugin (model plugins are expected to work like that anyway) 2) hack a small python script that just adds the offending tags to the sdf, after conversion (bypassing gzsdf bugs).