change the sing of compensation values

[elsp1991]

Dear developers,

I tried to use this software with SenseOne and Rokubi force torque sensors that have integrated IMU and I realized that compensation values had the wrong sign, resulting in the wrong wrench. After changing the sign in the compensation line everything worked as expected.

If all this makes sense to you, I think my proposed change is valid and would be nice if you accept the pull request

[diogoalmeida]

Hey,

This package has been working without issues for quite a while, with different sensors. Is it possible that the sensor frame in your robot model is wrong?

[elsp1991]

Hello,

I am visualizing all the TFs and the sensor and everything looks fine. In the attached picture you can see the red arrow pointing down is the force caused by the weight mounted to the sensor and the red arrow pointing up is the gravity acceleration. To my understanding since these two vectors always point in the other direction the need to be added and not substracted. If you can see from this visualization any error please let me know

[diogoalmeida]

What seems weird to me is that your accelerometer's readings are in the opposite direction of your F/T sensor, which doesn't seem to match Force = Mass * Acceleration. It appears that one of your sensor frames is wrong.

[traversaro]

It is also possible that the measure_direction of the sensors is not the one used by other sensors (see for example http://gazebosim.org/tutorials?tut=force_torque_sensor&cat=sensors, http://sdformat.org/spec?ver=1.8&elem=sensor#force_torque_measure_direction).

[elsp1991]

Hey @diogoalmeida,

What are you describing as Force = Mass * Acceleration is not correct because you are assuming that gravity is a real force. Gravity is actually a fictitious force and is only there to allow us to use classic mechanics in a non-inertial frame. Everything on earth is rotating with the earth so this means we are on a non-inertial frame, in the other hand and IMU is measuring acceleration in an inertial frame, for this reason all accelerometers are measuring gravity's acceleration away from the earths core and not what would be the expected (towards earth core).

Also I would like to mention that the visualization I am showing you here is from real accelerometer and FT sensor and not a simulation of gazebo.

I hope what I am saying make sense for you guys but I can confirm that every single IMU I ever used was measuring gravity the same way

[diogoalmeida]

Hey again!

I hope what I am saying make sense for you guys but I can confirm that every single IMU I ever used was measuring gravity the same way

Right! That seems sensible enough. I'll ask you to make a change then, to make this obvious in the code. Instead of the sign difference you're proposing, can you change (in line 76 of the same file you're changing in this PR)

    g.vector = gravity.linear_acceleration;

to

    g.vector = -gravity.linear_acceleration;  // IMU will measure gravity in the opposite direction from F/T sensor, check https://github.com/kth-ros-pkg/force_torque_tools/pull/18

or something equivalent? This way we'll preserve the meaning of an error between measured and expected wrench, when computing ft_compensated_eigen.

I'd also expect a similar change to be needed in https://github.com/kth-ros-pkg/force_torque_tools/blob/4affcef9d595f8ac572084dbcd5e9427daa4ef42/force_torque_sensor_calib/src/ft_calib_node.cpp#L428. Didn't you have an issue when running the calibration procedure?

[elsp1991]

Hello All,

regarding the calibration I havent used it so far and that's why there were no changes. After a quick check it failed reporting negative mass is not possible. Thats excatly what I was expecting to see.

I also modified the calibration node to work properly

[diogoalmeida]

Can you confirm that the calibration + compensation nodes are working as intended, after your changes? If yes, I am ok with merging this.

[lkotsoni]

Hi all, I checked the calibration and compensation nodes with a UR3 and a SensOne F/T sensor with integrated IMU. With the proposed changes, they both work correctly, i.e., positive mass with the calibration node and correct compensation direction with the compensation node.

[diogoalmeida]

Thank you :)