I hope that my question is not too stupid ... but I have a hard time to understand why Jacobians computed from forward kinematics would allow a better and smoother control than using pure inverse kinematics equations when they exist.

I understand that Jacobian may map linearly cartesian coordinates to joints coordinates but why we could'nt get the same result whith small increments of inverse kinematics ?

With the example of a 3 joints robot having to reach the pose (x , y, z) from the current pose (u, v, w), if this new pose requires to increase its joints state from (q0, q1, q2) to (q0 + 10, q1 -20, q2 + 40) and if I order to my robot these joint goals computed form inverse kinematic equations with velocities (v0, v1, v2) proportional to the ordered angular motion (v0, v1 = v0 x 2, v2 = v0 x 4), why this would not provide the same result than those with jacobian control ?

Thanks for helping my understanding.


Many thanks for your detailed explanation. I understand from your reply that Jacobian is used for a large set of tasks I probably don't know. I realized that my questiion is not accurate enough. Practically, I am working on a demonstrator to get a proof of concept on microsurgery. I have designed a 4 DOF slave for which I have found FK and IK closed form equations. This slave is controlled with a custom master control for which I have also the FK equations. I applied a scaling factor from master to slave in order to convert large master motion to smaller slave motion. The scalling is applied on cartesian space. Since this is made within a loop, the motion increments are small. Each joints velocity is, at each step, ordered to be proportionnal to each joint course to get a synchronized movement. I get a decent result but not as smooth as I expected (hardware is presumed optimally tuned). It is why I consider using only velocity control with numerical jacobians, but I don't understand why it could be better than using small steps of IK with proprtionnal velocities...


Thank you for interest. The slave robot is essentially made of 3 revolute joints which rotation axis are respectively q0: around z (= gravity axis), q1 and q2 both turn around x and q3 rotates around y axis. At the output of motor q3 we have an universal joint linking to a bar which end is constrained in a second universal joint itself linked to the ground. The master control have similar structure. Right hand rule.

Here are the FK equations: ( Where p4 is the position of the center of rotation of the universal joint linked to q3 output and p2p4 the constant distance beetween p4 and the center of rotation of motor q1)

 1- first we compute position of p4:
 p4x = qx - q1 * s0 - q2 * s0 * c1 + p2p4 * (s0 * s1 + s0 * c1)
 p4y = qy + q2 * s1 + p2p4 * (c1 * s1)
 p4z = qz + q1 * c0 + q2 * c0 * c1 - p2p4 * ( s1 * c0 +* c0 * c1)

2- Compute translation and orientation of link p4 to distal pivot (which is the tool)
pE is the part of the link outside the distal pivot (pivotX, pivotY, pivotZ). 
(note that pivotZ = 0 by construction):
Ia = sqrt((pivotX - p4x)^2 + (pivotY - p4y)^2 + p4z ^2 )
Ib = IL - Ia //(Translation outside the distal pivot point)
Ibr = Ib / Ia
pEx = pivotX + (pivotX - p4x) * Ibr //(vector projection)
pEy = pivotY + (pivotY - p4y) * Ibr
pEz = -p4z * Ibr
fk.tr = Ib
## tool orientation:
alpha = atan((pEyy - p4y) / (pEz - p4z))
beta = atan((pEx - p4x) / sqrt((pEz - p4z)^2 + (pEy - p4y)^2))
//(gamma, the tool rotation is directly given by q3).

A loop read at 650 Hz the pose of the 4 DOF master control, compute the FK and if a change occurs, apply a scaling factor to the cartesian change of mastercontrol and send a new pose to the slave by adding to its IK order the cartesian change to the starting pose of the slave. Velocity orders are sent with values proportionnal to the change in joints values. Basically the slave is position controlled, velocties are used only to synchronize joints motions. This works, but the global motion is not as smooth as got when motors are individually controlled. And here (microsurgery), smoothness is very important.

  • $\begingroup$ It might be simply a control problem, rather than a matter of choosing the right IK method. Posting the controller's policy you've implemented in the loop in terms of either the equations or the meta code would help us better understand the context. $\endgroup$ – Ugo Pattacini Nov 28 '20 at 11:57
  • $\begingroup$ If you change your question I don't get notified; you should rather use comments, although I believe SE is not for discussing but rather for Q&A. I'm even more convinced that you might have a control problem unrelated to the IK method. The sample time is very tiny: how do you deal with noise that will certainly affect the small cartesian changes? What do you mean by "starting pose of the slave"? Is it the very initial one or the current pose? I guess it's the latter. Better off providing the metacode of the controller itself then, rather than the description. $\endgroup$ – Ugo Pattacini Dec 1 '20 at 17:47
  • $\begingroup$ I use industrial servomotors for which controllers are blackbox firmware. From the notice it is a PID controller with adjustable gains and 3 control modes: position, velocity and torque. They work finely in standalone but are sometime a little bit jerky with master control. I'm using it in position mode but I wonder if pure velocity control could be better for a master-slave. I call "Starting pose" the current pose of both master and slave at each new sequence (a sequence is between two clutching). $\endgroup$ – B Blmd Dec 1 '20 at 22:25
  • $\begingroup$ To be honest, I think it's quite difficult to judge what is causing the jerk as the system turns to be quite complex. Also, from the description, I didn't get all the pieces. My recommendation is to simulate the coupled system using for example MATLAB/Simulink or even some simpler tools. You could limit the simulation to a proof of concept like a couple of 2-DOF planar manipulators. Once you'll be able to reproduce the behavior in simulation, you're done! It'll be much easier to run the investigations. $\endgroup$ – Ugo Pattacini Dec 5 '20 at 14:53

Saying in general terms that with the Jacobian we can obtain smoother control and thus better movements is an overstatement if it is not referred to a specific context where one is able to analyze all the implications in depth.

In fact, we can do great things by knowing the exact IK anyway.

From a broader perspective, the Jacobian is a linear map relating the velocities of the joints with the velocity of the robot's end-effector, hence it is intimately connected to the control problem where we are asked to generate suitable velocity commands (we are dealing here with the kinematics and not with the dynamics) to achieve a goal.

With this in mind, your following definition of the Jacobian is not quite right:

I understand that Jacobian may map linearly cartesian coordinates to joints coordinates but why we could'nt get the same result whith small increments of inverse kinematics ?

That said, we need to consider other essential aspects that are more difficult to be implemented, if not impossible, with a closed-form IK:

  1. Generally, the movements we aim to perform through a controller are not only specified in the joint space but rather also in the task space. For example, we need to move linearly with the tip while staying away from the joint bounds. To this end, we ought to use the Jacobian to trade off these requirements.
  2. Nowadays, robots tend to be equipped with lots of degrees of freedom so that closed-form solutions to IK do not even exist.
  • $\begingroup$ When you have too many degrees of freedom there might still exist a closed IK solution, which also minimizes some norm of the joint angles. $\endgroup$ – fibonatic Nov 28 '20 at 10:43
  • $\begingroup$ It's true that there might exist closed IK solutions, but for DOF>=7 this generally happens for very specific cases. That said, also for DOF<7 the tendency nowadays is to use iterative algorithms in place of closed IK approaches. $\endgroup$ – Ugo Pattacini Nov 28 '20 at 11:51

My question was probably badly formulated and, finally, I think the right answer is the following:

When a master-slave system is used and when the kinematics or geometry of both systems are not similar, we need to use jacobians for master-slave control due to the intrinsic dynamic differences between master and slave joints motion. So, algebraic IK is not usefull except for reaching some specific points without master control.

Howhever, if the master control velocity is low regarding the control loop speed (= increment betwwen two frames), controlling slave by using IK (if exists) and ordering velocities proportionnal to joint courses is equivalent to using pure jacobian based control.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.