Future of BasicCartesianControl and outlines for creating new controllers

[PeterBowman]

Per https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/123#issuecomment-340269259:

PS: BTW, I cannot find the issue, but you asked the purpose/extent of BasicCartesianController. I guess it could be renamed to something like OneLimbCartesianController to express it should be capable of anything that requires a single limb (i.e. anything except walking with two legs, or whole-body motion control).

I always associated the basic component in the name as a reference to the RMRC scheme pictured at doc/fig/kinematics-dynamics.png. In fact, there are surely more convolute and advanced forms of cartesian control, let me cite chapters 9 to 11 of J. Craig, Introduction to Robotics. Mechanics and Control., 3rd edition.

I'm not sure about the restriction of using this controller solely with single limbs. If launched with the appropriate solver, I guess it could handle tree structures (KDL::Tree), too. On the other side, docs got more restrictive in the way input parameters are defined, hence the interface itself force single-frame results (assuming I'm right that tree solvers involve a 6-element twist per leaf tip).

[PeterBowman]

This is how an acceleration-aware control loop could look like:

B. Siciliano, lecture on Industrial Robotics: Differential Kinematics, Master's course in Robotics and Intelligent Systems, Università di Napoli Federico II (PDF, more)

Further reading: F. Caccavale, S. Chiaverini and B. Siciliano, "Second-order kinematic control of robot manipulators with Jacobian damped least-squares inverse: theory and experiments," in IEEE/ASME Transactions on Mechatronics, vol. 2, no. 3, pp. 188-194, Sept. 1997, doi: 10.1109/3516.622971. (IEEE Xplore, ResearchGate)

[PeterBowman]

See also https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/135 (focused on trajectory generation).

[PeterBowman]

I am thinking now about a PositionCartesianControl or similar. A few cartesian commands could be reimplemented so that position targets are sent to the joint controller, instead of velocities. For instance, cartesian trajectories generated in movl and movv, currently velocity-driven in the joint space via RMRC, might be computed offline (https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/156), then translated into joint coordinates through IK (preferably using our brand new screw theory solver) and sent in batches (https://github.com/roboticslab-uc3m/yarp-devices/issues/208). Also, perhaps pose and movi could be merged into one single command - the position-based implementation would enable the new external reference position mode on the iPOS side (https://github.com/roboticslab-uc3m/yarp-devices/issues/198).

[PeterBowman]

(...) cartesian trajectories generated in movl and movv, currently velocity-driven in the joint space via RMRC, might be (...) translated into joint coordinates through IK (preferably using our brand new screw theory solver)...

See https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/193.

Edit: we can actually trick the robot to interpret velocity commands as position via CSV: https://github.com/roboticslab-uc3m/yarp-devices/issues/221.

[PeterBowman]

I'm not sure about the restriction of using this controller solely with single limbs. If launched with the appropriate solver, I guess it could handle tree structures (KDL::Tree), too.

In fact, https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/190 allowed us to handle a tree structure underneath using KdlTreeSolver.

This is how an acceleration-aware control loop could look like: (https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/124#issuecomment-373703327)

This is very nice, but not practical since we don't work with offline trajectories that much. Perhaps @imontesino would like to take a look at this in the context of IIWA's control loops (unless already using something similar).

With the introduction of CSV (https://github.com/roboticslab-uc3m/yarp-devices/issues/221), I no longer see the need of another cartesian controller for the time being.

However, I do see the need of a "monologue" label...

[PeterBowman]

Also, perhaps pose and movi could be merged into one single command

Done at https://github.com/roboticslab-uc3m/kinematics-dynamics/commit/e286bab06ebb1633bd7356b5caa983639cc2c23a, but this is actually a disambiguation rather than a merge:

• if you pass cartesian position inputs and want to issue joint position commands, use movi
• if you pass cartesian velocity inputs and want to issue joint velocity commands, use twist

Otherwise, perform the numerical differentiation yourself :smiling_imp:.