Skip to content
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

Closed
PeterBowman opened this issue Oct 30, 2017 · 6 comments
Closed

Comments

@PeterBowman
Copy link
Member

Per #123 (comment):

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
Copy link
Member Author

PeterBowman commented Mar 16, 2018

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

controldynamics

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
Copy link
Member Author

See also #135 (focused on trajectory generation).

@PeterBowman
Copy link
Member Author

PeterBowman commented May 1, 2019

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 (#156), then translated into joint coordinates through IK (preferably using our brand new screw theory solver) and sent in batches (roboticslab-uc3m/yarp-devices#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 (roboticslab-uc3m/yarp-devices#198).

@PeterBowman
Copy link
Member Author

PeterBowman commented Jun 7, 2022

(...) 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 #193.

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

@PeterBowman
Copy link
Member Author

PeterBowman commented Feb 15, 2023

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, #190 allowed us to handle a tree structure underneath using KdlTreeSolver.

This is how an acceleration-aware control loop could look like: (#124 (comment))

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...

@PeterBowman
Copy link
Member Author

PeterBowman commented Feb 20, 2023

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

Done at e286bab, 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 😈.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant