We are now interested in working on revolution parts; the big difference is that we want to use a 2 axis positioner and combine/synchronise the movement of the position and the robot.
A typical example would be:
I want to build the green prism on the grey cylinder, the grey cylinder is attached to the positionner and can be turned around it’s axis (X / red axis on the image).
What does it take to create a trajectory to build this part accounting that:
The robot has 6 axis
The part is on a 2 axis positioner (we would be using only 1 axis for the beginning)
Moving the positioner is prioritised to minimize robot orientations changes
I’m not sure about how to do that, because the part can be moving.
In other words, I’m not sure if the path planning algorithm has to decide which orientation should the positioner take or if MoveIt has to determine the orientation of the positioner depending on the trajectory fed.
Any direction, idea, pointer would be appreciated!
Has anybody done a similar thing with ROS on industrial robots?
I would like to estimate how much time I would need to test this and get things running.
I’m currently working actively on a very similar problem, but not within ROS-I at the moment.
My goal is to plan trajectories for 6 or 7 DOF welding robots, mounted on rails, creating up to 3 additional axes.
Last year we did some experimenting [1] with the descartes [2] package of ROS-I. Because of my lacking C++ skill’s and there being no interface for highly redundant robots in MoveIt!, I started experimenting from scratch in 2D. [3]
For your problem, my initial guess (based on the approach I’m trying now) would be:
Create a kinematic chain from the workpiece to the robot tool (therefore ignoring the dynamics).
Create some kind of wrapper for the inverse kinematics of this chain that can return a sampled set of all possible solutions. The sampled space is very big, but I think it could be manageable for off-line planning. (If the ranges of the positioner are not to big. Like, smaller than 30 degrees or something, sampling at 1 degree intervals, and not to much freedom on the end-effector to keep to total solution space manageable.)
Add a custom cost function to descrates that not only minimizes joint motion, but also takes into account the priority of avoiding orientation changes. (We already experimented with adding tool orientation to the cost function, but the approach was quite hacky [4].)
Hope for the best. Descartes seems to be in active development at the moment. In the indigo version, we often encountered a lack of memory. Computation time was never really an issue when using the IKFast solver.
Feel free to contact me. I’m open to collaboration, as far as I can contribute something.
(Coincidently, we even have a Kuka robot with a two-axis positioner in our lab [5] , but I never used it.)
As stated above, the problem that you are facing is a more general instance of a constrained motion planning problem than what descartes can express. Although not immediately helpful, recently an update has been pushed to OMPL [1] that introduces generic, geometrically constrained motion planning with sampling-based motion planners [2] (you can view a highlight reel of some of the available demos here at [3]). The code is available at [4].
This new framework allows for geometric constraints to be phrased as functions of a robot’s state, f(q), which are satisfied when f(q) = 0. Your problem can be expressed as a geometric constraint on the 8-DoF system of the positioner and the end-effector. It could possibly look something like:
f(q) = SE3_Distance((desired position and normal vector on surface of the positioner), (pose of end-effector))
where SE3_Distance() is some metric in SE(3). Unfortunately, right now there is no interface through ROS to access these new features (i.e., through MoveIt! or others), but a bespoke solution is possible. It would require creating a state space for your robot and a constraint, and then running your favorite motion planner on the constrained state space (for your case, probably an asymptotically-optimal one, optimizing for minimal end-effector movement).
Feel free to let me know if you are interested in pursuing this route or if you have any trouble using OMPL.
Zach, those OMPL additions look very cool. I like the sampling augmented with a little optimization for exploration. It’s not necessarily true that something like Descartes can’t express the problem, however. Like OMPL, at it’s core it’s just a way to build and search graphs. For example, Descartes trying to move a 6DOF arm around the perimeter of a part that can turn: https://www.youtube.com/edit?o=U&video_id=EKYNZPfhyfQ
The problem is your sample space will grow out of control very quickly and so will your planning times… You might just try iterative inverse kinematics (e.g. call set from IK over and over) and see where it gets you. It’s at least quick to try.
I have lots of ideas but, frustratingly, I can’t really share too much at the moment. Even past motion planning, I’d budget a couple of weeks for debug and testing of your new motion interface.
Gijs, the problem of infinite windup might be addressable in the Descartes (or other planner) space if you specify that your start and end joint pose are the same. If your process allows the robot to get back then you could just continually duplicate that motion.
Thanks you for these very nice answers I’m happy to see that this is a topic of intereset, as many industrial robots are used with linear axis and turn tables this is a key topic to drive ROS-I into our factories.
This really doesn’t look like a feature that would be done in two days work!
I never used Descartes but I wanted to give it a look since a long time, that’s what I’ll be doing right now.
I think it would be nice that this discussion continues with the advances of everyone in the field, I’ll try what you have suggested and give it a look.
At the moment we are not starting a project or anything concrete in that direction, it is something we are studying, the main idea is to gauge the amount of work to get a simple example running, and get 3D printing running with this stuff.
This would be something interesting to figure out…
@VictorLamoine
If you plan a path as if you were planning to weld on a 2D plane then the 2D plane (and dimensions) would be the flattened cylindrical surface you’ll be welding on.
Then interpolate the rotation of the positioner with the “planned” y movement (green?) (involving PI and the radius). So put a gear ratio between the y-position and the positioner, and do not move the welding torch in the y direction. You will then get metal added concentrically with the cylinder.
Doing something similar with @gavanderhoorn example of the infinite spool winding:
depending on the winding angle, I’d see if you can interpolate the x position (along the rotarion axis) with the (winded) wire position/length. So that will be the driving (virtual) axis. Then the spool will have to generate a constant torque otherwise the wire will be too “loose” around the spool, or the wire will snap. so for 1 lenth of wire the x-position will be the width of the spool, and the next length the x-position to be reached will be zero. and repeat that.
Or maybe even simpeler, travel back and forth between the spool, forget about the wire position altogether and link the wire speed to the cartesian speed of the end effector.
I thought I’d clarify here a bit: I believe linear axes are supported quite well. I’ve got 3 setups myself that use linear axes, it’s not something that requires any really special configuration or planners (OMPL fi can cope with this just fine fi, and so can Descartes).
A turntable however is something I’m not sure about, but only because I’ve never configured such a system for use with ROS. Not necessarily because I don’t think it’s possible / supported right now.
@Jmeyer, I’m curious about how we should configure the kinematic system to make Descartes work with 6dof + turn table. I feel like this is something different to 6 dof + 1 linear track and IKFast is not supporting this, right?
Also, I think the youtube link that you shared above is not working… Would you mind fixing that? I’m looking forward to checking this demo!
Thanks @VictorLamoine ! Do we have any example code for this? If we can set up a robot model with ikfast configured, I believe descartes won’t have any difficulty working with 6dof + turntable case.
I would like to try what @yijiangh mentioned above. In other words, I want to use descartes for redundant robots, where the redundant joints are sampled/discretized. I have plenty of idea’s for the sampling part, it is with the actual implementation that I’m stuck. I’ve looked through the source code of MoveIt! and descartes but I’m not sure what the best approach is.
Add functionality to the MoveIt! IK plugin to return a certain number of possible solutions for a redundant robot. There seems to be a lot of functionality present in moveit_core/kinematics_base to work with redundant joints, but I’ve not figured out how it works yet.
Let descartes handle the sampling of the redundant joints. Use separate planning groups for the redundant and non-redundant parts of the robot. This approach seems particularly useful for external turntables.
Use a separate package for the inverse kinematics and add redundant joint sampling there. (For example opw_kinematics Only use MoveIt! for collision detection.
Some combination of the above. or other approaches I did not think of.
Approach 1. would make it available to other planners. On the other hand, you could argue that sampling is the task of the motion planner and therefore approach 2. is better. Approach 3. is somewhere in the middle.
I cannot find a lot of information on the topic using google or looking through Github issues.
Can someone help me with pointers / interesting links / insights / discussion?
@Levi-Armstrong and I are working on some demos for ROSCON that will include a slightly retooled interface to Descartes that makes it easier to express problems like this. Give me a few days and I should be able to start posting some reasonably useful stuff.
There has been progress. I can let some of the tech contributors more specifically chime in, such as @Levi-Armstrong and some of the team here in our org. I will ping a few of the team here to see if they can share their specific thoughts and how to set up such problems. I believe we have some examples out there, so stay tuned.
, but I never used it.)
I’m happy to see that this is a topic of intereset, as many industrial robots are used with linear axis and turn tables this is a key topic to drive ROS-I into our factories.
Looks awesome!