Closed PeterBowman closed 1 year ago
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)
See also https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/135 (focused on trajectory generation).
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).
(...) cartesian trajectories generated in
movl
andmovv
, 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.
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...
Also, perhaps
pose
andmovi
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:
movi
twist
Otherwise, perform the numerical differentiation yourself :smiling_imp:.
Per https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/123#issuecomment-340269259:
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).