You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ftCompensation app introduced in #191 converts the forces and torques measured by a FT sensor into joint velocities (via differential IK) to be applied on the motors, that is, F = k * dx/dt.
Why not stick to classical mechanics and Newton? Said sensor measurements could be translated into accelerations instead according to F = m * a, where the mass here is parameterized (in fact, such application would perform mass compensation). Actually, the kinematics involved are already handled under the hood by KDL and our cartesian command FORC (input: cartesian forces, output: joint torques). This makes much more sense: tell KDL that the forces measured by the FT sensors should be interpreted as external forces (as in fact they are), obtain joint torques, send command.
By using forces in this algorithm, it could be easier to implement spring-like behavior (i.e. impedance), too.
What is the point of this? As we already know, our GCMP cartesian command is severely affected by the lack of backdrivability in TEO (thanks, @jgvictores). That is, force exerted on the motor side can be easily propagated to the joint side, but not otherwise (think of a worm drive). Ideally, forces exerted by users while in GMCP mode would produce unhindered (as much as friction allows) motion and the limb would not fall on release (since gravity is compensated). In reality, it is too hard to move a joint from the joint side due to said preferred direction of propagation. Here is where FT sensors would vastly help: any force registered on the tip would be translated into joint torques via inverse dynamics and produce the desired motion.
Reminder: GMCP works the same as FORC, but assuming no external forces are present (force on the tip equals zero).
The text was updated successfully, but these errors were encountered:
Done at f5010f0. A new ICartesianControl::wrench command has been added as the streaming counterpart of forc. Note there is still some friction to be compensated on the low (joint) level: roboticslab-uc3m/yarp-devices#261.
The ftCompensation app introduced in #191 converts the forces and torques measured by a FT sensor into joint velocities (via differential IK) to be applied on the motors, that is,
F = k * dx/dt
.Why not stick to classical mechanics and Newton? Said sensor measurements could be translated into accelerations instead according to
F = m * a
, where the mass here is parameterized (in fact, such application would perform mass compensation). Actually, the kinematics involved are already handled under the hood by KDL and our cartesian command FORC (input: cartesian forces, output: joint torques). This makes much more sense: tell KDL that the forces measured by the FT sensors should be interpreted as external forces (as in fact they are), obtain joint torques, send command.By using forces in this algorithm, it could be easier to implement spring-like behavior (i.e. impedance), too.
Blockers:
What is the point of this? As we already know, our GCMP cartesian command is severely affected by the lack of backdrivability in TEO (thanks, @jgvictores). That is, force exerted on the motor side can be easily propagated to the joint side, but not otherwise (think of a worm drive). Ideally, forces exerted by users while in GMCP mode would produce unhindered (as much as friction allows) motion and the limb would not fall on release (since gravity is compensated). In reality, it is too hard to move a joint from the joint side due to said preferred direction of propagation. Here is where FT sensors would vastly help: any force registered on the tip would be translated into joint torques via inverse dynamics and produce the desired motion.
Reminder: GMCP works the same as FORC, but assuming no external forces are present (force on the tip equals zero).
The text was updated successfully, but these errors were encountered: