The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
tl;dr: this is probably not something you should try to use (the standard interfaces of) MoveIt for, as it does much, much more than simple interpolation and that takes time. In addition, MoveIt (in its default configuration) was not designed for this kind of use, which is why you run into the issues you describe.
Typical approach: use any of the kinematics plugins available (KDL, Trac IK, Bio IK) to solve IK at a suitable rate and send those directly to your controller. Alternative: use the velocity control interface (if available on your controller and ROS driver) and use the Jacobian.
First: I think this isn't really a "ROS-Industrial" thing other than industrial robots being involved. It's more a motion planning and robot interfacing issue (I do understand why you tagged it with ros-industrial though).
As for an answer and possible approach: this is certainly possible, but 1) is not something that MoveIt was designed for, 2) will need a little manual work and 3) will require a good interface to the motion controller of the robot you're trying to do this with.
re: not design for: MoveIt has a predominantly pipeline based architecture, which receives a motion request (go from A to B), asks a planning plugin to come up with a joint space path (not a trajectory), checks it for collisions, converts it to a trajectory and then returns the result. There is no feedback here, and no concept of a Cartesian space (at least in how it interacts with OMPL and in the default cases, other than the start and end pose). Additionally, the (perhaps implicit) assumption is that trajectories start at 0-velocities (and accelerations, etc) and end with them. These characteristics make the default interfaces you have to MoveIt rather unsuitable for a jogging (ie: continuous motion in Cartesian space).
(there is something called trajectory replacement, but that is not a MoveIt concept per se, and will not change the way MoveIt deals with planning requests)
re: good interface to your robot: many industrial robots don't actually have an external motion interface that will allow you to do anything like this. The two brands you mention (KUKA (RSI: 250 Hz joint space position control) and UR (125 Hz joint space and Cartesian control)) are some exceptions to this, so provided you can come up with the appropriate input to those external motion interfaces, ROS controlled jogging is possible to implement.
re: implementing something like this: there are quite some older questions (and answers) about this: a good one with some background is probably #q74776. Another example is #q245390. And finally, #q69757 (note the response by one of the original authors of MoveIt: "if you already know where you want to go, and you only want to move in a straight line, then the motion planning that MoveIt does is not what you want"). This post on moveit-users discusses a similar question as well.
The typical conclusion of these questions is that trying to use the full planning pipeline of MoveIt (and its output) is probably not the best / most efficient / most performant way to go about this. Instead, IK solvers are used to compute IK for incrementally updated poses and the results are send to controllers directly (through drivers if possible).
I currently did that, but in a "not smooth" way, like: when he press a button, and until he release it, I publish once each ms on a topic that I want it to go x cm more on that axis. but dues to accelerations, the robot don't do it smoothly.
If MoveIt was still involved here, I don't think that 'ms' time scales are reasonable. Planning takes time. I also don't know of any external motion interface on KUKAs or URs that supports a kHz update rate.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
