[feature_request] Add tau_grav_hat to the franka_state_controller/franka_states

[rickstaa]

For one of my projects, I was looking for an easy way to retrieve the torque that is applied by Gravity on the panda_joints. I know that I can retrieve this by using the getGravity method of the franka_hw::FrankaModelInterface, but I think it would be a significant improvement if this parameter was included in the franka_states that is published by the franka_state_controller or in a separate topic like is done with the F_ext parameter.

https:/rickstaa/franka_ros/blob/5341770c6db24cdf5acf1bd87e832cf9f60a1b5c/franka_hw/include/franka_hw/franka_model_interface.h#L122

I did not create an example pull request for this since there are several ways to implement this.

[rickstaa]

Altough, having the gravity torques show up in the franka_states message would be nice in my opinion. Merging #198 will already allow people to infer these torques.

[gollth]

Including it in the State Interface wont be an option, really, since this data is not published via the FCI and libfranka. We can only add fields into the franka_states which come directly from the robot.

Providing a topic seems possible, but I wonder how useful that would be. Most often you need this data in realtime for control, not?

What speaks against the "ros_control"-way of doing this, i.e. claiming the model interface and getting the gravity term via getGravity()?

[rickstaa]

@gollth Ah, if you're not planning to implement this in the FCI, then adding it to the franka_states indeed does not make sense.

There is nothing wrong with using the getGravity() function. I, however, thought publishing these gravity torques on a rostopic would improve user experience. By doing so, users who use the high-level franka_ros package can access this information without interacting with the franka_model_interface through C++.

[gollth]

Would definitely improve user experience but at the cost of diverging interfaces between real robot and simulation I'd say this is not worth it, especially if you can already get this information via the model interface otherwise. Feel free to reopen if new insights arise

[rickstaa]

No problem! I agree.