Publish (possibly) interesting data provided from FRI

[marcoesposito1988]

FRI provides the (estimated) external force applied on the robot, both as cartesian force/torque in the flange's reference frame, and as torque for each joint. I have many use cases where I could use this information, so I already added a realtime_publisher to lwr_hw_real in my fri_publishing branch (d1ca59150ba83b5acf9eaebfd4a032d835fe76b4).

I think there may be others interested in this information, as well in other information available through FRI (the numeric Jacobian, the mass matrix, the gravity compensation as computed by the controller).

I would like to discuss the integration of such a feature, in a way that is future-proof and compatible with other manipulators. I think the cleanest way would be to add this information to sensor_msgs/JointState, or better to create an extension of this message for manipulators with embedded force/torque sensors. I am looking at the documentation of the KUKA iiwa, and it looks like all this information is available there as well.

Maybe we can ask the ros_industrial and ros_control newsletters. What do you think?

[carlosjoserg]

I think it is good to have a publisher with robot info, like cameras do. So, the question is what to publish in this case that do not disturb and/or consume PC resources.

The effort you see in the joint_states topic is the measured torque at each joint, see here.

Then, using the joint torque and position, you can have the Jacobian until any point expressed at any frame, and estimate the Cartesian wrench there. Perhaps writing an only-read controller for that would be better, in the same line as the joint_state_controller. It can take as parameter 3 link names, the base, the tip and the frame in which you want the wrench to be expressed (optional, by default the base) for instance?

What do you mean by mass matrix? The end-effector dynamic parameters?

In general, I would prefer to invest time in having an accurate URDF model of the arm, since IMO, the less you depend on FRI values the better, since you gain control over it and can re-use stuff for other arms, not only kuka's.

[marcoesposito1988]

A read-only controller like joint_state_controller would be also viable and more portable.

But as long as we do not have a perfect URDF we could make good use of what FRI gives us. At least to have a ground truth to verify the results we get using our model. We don't have to merge it, I will keep it in a branch and start working on this "arm_state_controller".

BTW, I think I linked the wrong commit before; this 684c5315e58502c95f596058309361226901022a should look better.

[carlosjoserg]

True, it will be useful for validation

I guessed about the commit, and I got the idea, but that looked better, yes.

[marcoesposito1988]

I am working on my arm_state_controller branch, if you are interested. I will merge it with fri_publishing so that I can experiment there and compare the output of the control unit with that of my controller.

As of now it already works not bad, the difference with the control unit was 9 N (and in gravity compensation the robot started going up, so I am rebooting it.. might be that my controller is right)

[carlosjoserg]

in gravity compensation the robot started going up

Make sure that the tool you use in the script here has dyn params consistently with the real tool you have in the robot, it looks like you are trying to compensate something heavier than what is attached as end-eff.

[marcoesposito1988]

I know. The robot has nothing attached. Sometimes the calibration appears to be screwed up, it happens once in a while with our robot. We also defined a tool which is supposed to correspond to the flange, but it happens with that set as well.

Something funny is, that after the rebooting it was normal. Then after playing around with ROS it had the problem again.

[carlosjoserg]

KukaFacts

[marcoesposito1988]

It looks like today the flange is lighter. Maybe we slowed down to warp 3.

[marcoesposito1988]

BTW, I will try using the values in the URDF from the iAi of Bremen ( https://github.com/code-iai/iai_robots/blob/master/iai_kuka_lwr4_description/urdf/kuka_lwr_arm.urdf.xacro )

[carlosjoserg]

I believe it is the same as we have, since both come from ROSIE old files.

I will go for any of these:

1. http://ifatwww.et.uni-magdeburg.de/syst/about_us/people/zometa/robotmpc/index.shtml#mdl
2. http://upcommons.upc.edu/handle/2099.1/24233
3. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6907033

[marcoesposito1988]

This also looks quite interesting:

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6878124&tag=1

[carlosjoserg]

Yes, it does... confidential Kuka's parameters, I think they just wanted to challenge the community, the positive side is that at least two paper were published for that.

[marcoesposito1988]

Other food for thought:

https://github.com/orocos/orocos_kinematics_dynamics/blob/master/orocos_kdl/models/kukaLWR_DHnew.cpp

[marcoesposito1988]

The problem is that we only have a-posteriori dynamic models. Do you know any method to derive a complete description to stuff into the URDF?

[carlosjoserg]

Do you know any method to derive a complete description to stuff into the URDF?

Nope