search

RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.36k stars 1.27k forks source link

Need better documentation for torque values on LCM systems #13374

Open sammy-tri opened 4 years ago

sammy-tri commented 4 years ago

Some systems which send/receive LCM messages (e.g. IiwaStatusSender, JacoStatusSender) have input/outputs for "torque" which have little to no documentation, and varying conventions based on the model of robot in use.

For example, consider a situation where an arm is reaching well outside it's center of gravity, such that joint[1] has a significant positive position value. A force is applied to the end effector which should push that joint the the positive direction.

Robot model Position Torque External Torque
Real iiwa positive positive positive
Sim iiwa positive negative positive
Real Jaco positive negative negative

"real iiwa" makes sense if what we're representing is a description of the world from the perspective of that joint, all of the directions should have the same sign. "simulated iiwa" makes sense once you realize that value we're using for "torque measured" is the value we're sending to the actuation input port on the plant, and the sign would thus be inverted vs. the real iiwa (it's wrong, as a simulation of the iiwa, so we should fix that). The external force also makes sense, since in the sim it's populated by the value from the contact force output port in the MBP (and the sum of the contact force in that simulation should be to push the joint in a more positive direction).

The Jaco (and Panda, though drake doesn't have LCM systems for that yet, only messages) seem to be reporting the actuation effort as "joint torque" (like our existing iiwa simulation) and then reporting the external torque as the portion of the actuator effort not related to gravity compensation (Kinova calls this API "GetAngularForceGravityFree" which I guess makes sense here).

The Jaco sim doesn't send torques yet, so at least it's not wrong yet.

We should document the LCM systems so that we know what values should be used. I'm curious if anyone things we should also have the LCM senders/receivers convert values internally to allow for a common representation in drake, or just pass through the vendor's convention.

EricCousineau-TRI commented 9 months ago

Note that we have some additional data + discussion on the Anzu issue (4759) side of things.