The JTCartesianController of robot_mechanism_controllers (trunk, as of r54402), computes the nullspace projector using the damped least squares (DLS) inverse, instead of a regular least squares (LS) pseudoinverse.
It's OK to use a DLS for the differential IK part Jinv * x_dot, but not for computing the projector. The thing with the DLS inverse is that it does not satisfy all properties of a generalized inverse, in particular J * Jinv_dls * J != J, the result being the secondary task interfering with the primary one (if their goals are conflicting).
I guess if damping is low, you can't visually see the tasks fighting each other (I'm not a user of this controller, so I haven't tried it out), and the qualitative result is OK. Still, the issue is there, and it deserves a heads-up.
You're right that the DLS inverse doesn't do the correct thing here. I'm going to leave it in place for now because in practice it works relatively well.
The JTCartesianController of robot_mechanism_controllers (trunk, as of r54402), computes the nullspace projector using the damped least squares (DLS) inverse, instead of a regular least squares (LS) pseudoinverse.
It's OK to use a DLS for the differential IK part Jinv * x_dot, but not for computing the projector. The thing with the DLS inverse is that it does not satisfy all properties of a generalized inverse, in particular J * Jinv_dls * J != J, the result being the secondary task interfering with the primary one (if their goals are conflicting).
I guess if damping is low, you can't visually see the tasks fighting each other (I'm not a user of this controller, so I haven't tried it out), and the qualitative result is OK. Still, the issue is there, and it deserves a heads-up.
trac data: