Torque and Velocity feedback about gazebo-yarp-plugins HOT 24 CLOSED

Yes we are using these ports. Before adding springs no more :)

from gazebo-yarp-plugins.

Well... yes and no.
The teoretically correct way is to use the getXXX functions, yet they are intended to be used once in a while because they generate more traffic, and may not respond as quickly as we want.
Since there was the need of having those data at the same rate as positions we decided to go for a broadcast policy as the positions.

The correct procedure is (solution 1) to create a specific device doing this job. I did this in the real robot an I started to build those devices (one for velocity and one fot torque) also for the simulator but I haven't finished yet.

Another approach we discuss recently with Enrico and Lorenzo was (solution 2) to expand the state of the controlBoard to include also those data and do not have an avoidable raise in devices number, where each one has to be compiled and configured, plus will result in an high number of ports and connections and so on.

We will probably go for solution 2, because it is more general, could be used also for icub, less stuff to enable and configure and, if I found a way to be back-compatible, also transparent and current users will get more stuff for free.

I'll think how to go on hopefully in the next days.
So I agree that having solution 1 right now will make things more 'clean' and more similar to the robot, but I believe that as long as the user sees the same ports and same interfaces, even if the implementation is not the ideal one things will just work as well.

I'd avoid putting to much effort in cleaning something that we will probably throw away soon anyway

P.S.
By the way, yes, controlboardwrapper wraps those functions both in the real robot and in the simulator. I don't know if they are then actually implemented in the simulator...

@EnricoMingo : what do you mean with "Before adding springs no more "?

from gazebo-yarp-plugins.

Ok, perfect we'll wait. As temporary solution I just removed the hard coding of coman name in current solution ( TorqueAndSpeedPublisher ) in commit e818e44 .

from gazebo-yarp-plugins.

Do you keep the robot name?
Il giorno 24/dic/2013 11:06, "Silvio Traversaro" [email protected]
ha scritto:

Ok, perfect we'll wait. As temporary solution I just removed the hard
coding of coman name in current solution ( TorqueAndSpeedPublisher ) in
commit e818e44e818e44.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-31166104
.

from gazebo-yarp-plugins.

Yes, it is extracted by the name parameter in the WRAPPER group.

from gazebo-yarp-plugins.

Sounds good!

Silvio Traversaro [email protected] Ha scritto:

Yes, it is extracted by the name parameter in the WRAPPER group.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-31167138.

from gazebo-yarp-plugins.

By the way I noticed my solution was unnecessary complex, it is ok to just use the WRAPPER name, a cleaner solution is in commit 841bf2f .

from gazebo-yarp-plugins.

Perfect, thx!
Il giorno 24/dic/2013 11:43, "Silvio Traversaro" [email protected]
ha scritto:

Yes, it is extracted by the name parameter in the WRAPPER group.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-31167138
.

from gazebo-yarp-plugins.

We should add the possibility to specify the thread rate at configuration time for speed and torque ports

from gazebo-yarp-plugins.

getTorques is implemented as well as getEncoderSpeeds.
How is the status of things? I would love to remove that RateThread from inside the ControlBoardDriver.. which by the way could be possible even with the current solution of writing to ports (just put it into the onUpdate)
In the current situation, what happens when you use the libgazebo_yarp_clock.so system plugin is, the RateThread from the ControlBoardDriver runs when the OnUpdate of the plugin is called, which should be the same as the OnUpdate from the ControlBoard (that is, WorldUpdateBegin) ....

from gazebo-yarp-plugins.

Today we noticed that practically nobody was using this ports (perhaps @jeljaik is using them in some simulink block?) and we agreed to removed them (removal is in PR #75 ) .
@barbalberto how things have evolved from past december?

from gazebo-yarp-plugins.

I suggest to remove them once we know that they are totally equivalent to the information that can be retrieved with other function calls (perhaps getTorques or getVelocities).
Francesco

Francesco Nori
Istituto Italiano di Tecnologia
Email: [email protected]:[email protected]

Web: people.liralab.it/ironhttp://people.liralab.it/iron

On 26/mar/2014, at 22:04, "Silvio Traversaro" <[email protected]mailto:[email protected]> wrote:

Today we noticed that practically nobody was using this ports (perhaps @jeljaikhttps://github.com/jeljaik is using them in some simulink block?) and we agreed to removed them.
@barbalbertohttps://github.com/barbalberto how things have evolved from past december?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-38739441.

from gazebo-yarp-plugins.

@traversaro from my side and given our current situation I believe they could be removed since we tested that getEstimates() retrieves the same joint torques as read from the simulator. Nevertheless, these ports proved very useful for debugging the same estimates when the robot was in different configurations, say "impaled" or on the ground. These two cases are addressed in the Simulink blocks but we haven't added additional external contacts and it's my guess that they might turn useful again when this will be the case.

from gazebo-yarp-plugins.

I talked to @barbalberto and got some additional insight on how to properly implement the speed and torque streaming on the simulator.

I was not aware of the fact that the COMAN robotInterface is providing torque and speed streaming feedback as IAnalogSensor devices, in particular in comanVelocityObserver and comanJointTorqueSensor.

To provide software compatibility with the real robot we then have to open this ports (*/analog:o/speed , */analog:o/speed/rpc and so on).

Currently we mix implementation of the controlboard device with a quick hack to open this ports instead of properly creating a yarp device.
In my idea the clean way of implementing this behaviour is to create two new Gazebo ModelPlugins that implement the joint velocity and joint torque sensors as IAnalogSensor devices, GazeboYarpForceTorque & GazeboYarpForceTorqueDriver can be easily used as an example on how to deal with the analog device wrapper.
The only difference between this two plugins will be the line of code in which we call the function to get velocity/torque from gazebo, so it could make sense to share the code, or eventually have only one pluigin (JointQuantitiesSensor? JointQuantitiesPublisher?) in which the output quantity can be specified as a configuration parameter.

Until we have a different way of publishing this information I guess we have to stick with the TorqueAndSpeedPublisher thread, because compatibility with real robots (in this case COMAN) is a primary concern for gazebo_yarp_plugins (correct me if I am wrong).

from gazebo-yarp-plugins.

doesn't implementing ITorqueControl and IEncoders already ensure the right ports are opened?

from gazebo-yarp-plugins.

No, ports are associated to device, not interface

from gazebo-yarp-plugins.

I have done a sketch of a new joint generic sensors plugin (can broadcast position, speeds or torques) in https://github.com/robotology/gazebo_yarp_plugins/tree/jointgenericsensors. It should work in properly emulating comanVelocityObserver and comanJointTorqueSensor. There are some still issue in port names and in duplication of information among different configuration file, that could be addressed by using the inclusion feature of yarp configuration files (http://wiki.icub.org/yarpdoc/yarp_config_files.html#yarp_config_file_nesting).

from gazebo-yarp-plugins.

This could be interesting also to provide a simulation of passive compliance in future...what about input to this joint? Position, impedance and torque interfaces?

Inviato da iPad

Il giorno 31/mar/2014, alle ore 11:33, "Silvio Traversaro" <[email protected]mailto:[email protected]> ha scritto:

I have done a sketch of a new joint generic sensors plugin (can broadcast position, speeds or torques) in https://github.com/robotology/gazebo_yarp_plugins/tree/jointgenericsensors. It should work in properly emulating comanVelocityObserver and comanJointTorqueSensor. There are some still issue in port names and in duplication of information among different configuration file, that could be addressed by using the inclusion feature of yarp configuration files (http://wiki.icub.org/yarpdoc/yarp_config_files.html#yarp_config_file_nesting).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-39069694.

from gazebo-yarp-plugins.

What do you mean by input to this joint?

from gazebo-yarp-plugins.

Controllo inputs.
Il 01/apr/2014 13:43 "Silvio Traversaro" [email protected] ha
scritto:

What do you mean by input to this joint?

Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-39195896
.

from gazebo-yarp-plugins.

This plugin is just for emulating sensors, not actuators. Are you in lab?

from gazebo-yarp-plugins.

No sorry. I guess sensors located in actuators right?
Il 01/apr/2014 15:10 "Silvio Traversaro" [email protected] ha
scritto:

This plugin is just for emulating sensors, not actuators. Are you in lab?

Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-39202858
.

from gazebo-yarp-plugins.

Actually on joints, as currently in gazebo we do not have a distinction between motor joints and "joint" joints.

from gazebo-yarp-plugins.

With the addiction of proper velocity and torque sensors in coman model ( EnricoMingo/iit-coman-ros-pkg@8d68070 ) I guess we can finally close this issue.

from gazebo-yarp-plugins.