[Discourse.ros.org] [ROS-Industrial] Path planning with external axis
Victor Lamoine
|
VictorLamoine
April 13 |
We’ve been using ROS for additive manufacturing quite a lot in the last months (see ROS Additive Manufacturing (RAM)).
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!
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
gavanderhoorn
|
gavanderhoorn
April 13 |
Interesting question, and something we’ve been starting to look at here as well (not too actively yet though).
We’re not welding, but winding. Same difference, although a winding motion is potentially infinite.
Victor Lamoine
|
VictorLamoine
April 16 |
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.
Jeroen
|
JeroenDM
April 16 |
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.)
[1] https://github.com/JeroenDM/descartes_tutorials
[2] http://wiki.ros.org/descartes
[3] https://gitlab.mech.kuleuven.be/u0100037/planar_python_robotics/blob/master/example_redundant_kinematics.ipynb
[4 https://github.com/JeroenDM/descartes]
[5 https://iiw.kuleuven.be/onderzoek/acro]
Zachary Kingston
|
zkingston
April 16 |
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.
[1] http://ompl-beta.kavrakilab.org/
[2] http://ompl-beta.kavrakilab.org/constrainedPlanning.html
[3] https://vimeo.com/261052837
[4] https://bitbucket.org/ompl/ompl
Jonathan Meyer
|
Jmeyer
April 18 |
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.
Victor Lamoine
|
|
VictorLamoine
April 19 |
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.
Bas de Bruijn
|
basdebruijn
April 19 |
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.
gavanderhoorn
|
gavanderhoorn
April 19 |
VictorLamoine:
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.
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.
Yijiang Huang
|
yijiangh
April 24 |
@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!
Victor Lamoine
|
VictorLamoine
April 24 |
Video @Jmeyer wanted to show is available here: https://www.youtube.com/watch?v=EKYNZPfhyfQ
Yijiang Huang
|
yijiangh
April 24 |
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.