-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future of BasicCartesianControl and outlines for creating new controllers #124
Comments
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 #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 |
See #193. Edit: we can actually trick the robot to interpret velocity commands as position via CSV: roboticslab-uc3m/yarp-devices#221. |
In fact, #190 allowed us to handle a tree structure underneath using KdlTreeSolver.
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 (roboticslab-uc3m/yarp-devices#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... |
Done at e286bab, but this is actually a disambiguation rather than a merge:
Otherwise, perform the numerical differentiation yourself 😈. |
Per #123 (comment):
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).The text was updated successfully, but these errors were encountered: