Integration of 6-axis manipulator and 2-axis positioner (external axes)

ROS-Industrial
1

I am currently working on setting up a 6-axis welding robot with a 2-axis positioner for wire and arc additive manufacturing (WAAM). What we are attempting is very similar to what @VictorLamoine describes here: Path planning with external axis

So what we would need to do is to integrate the manipulator and positioner w.r.t. kinematics and planning including collision avoidance so that the planner can account for simultaneous motion of both the manipulator and positioner. I am assuming that Descartes might be able to plan trajectories for both groups simultaneously including collision avoidance.

I am not sure if there are already packages available for this type of setup (manipulator and 2-axis positioner) and could not find much in public repositories. Therefore, I have started to develop support and moveit_config packages for our WAAM system based on the assumption that our manipulator-positioner setup would be very similar to a two-arm system. The design of the manipulator-positioner support package is therefore roughly modeled after the Motoman SDA10f support package. The moveit_config package was created using the moveit setup assistant and this tutorial: http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot.

The packages can be found here:


They depend on the motoman_ma2010_support and motoman_motopos_d500_support packages, which can be found in this fork of the ros-industrial/motoman repo for the time being: https://github.com/Adamsua-lab/motoman.

I am now wondering if this is the correct approach to achieve the integration of manipulator and positioner.
I am posting this here and not in ROS Answers as I can imagine that using a manipulator together with a 2-axis positioner is found frequently in the industry and is therefore of general interest. I am also hoping that my attempt and struggles to make this work (see below) might help further the discussion on this subject.

I have tested the moveit_config package using moveit_planning_execution.launch sim:=true. But there seems to be an issue with the service /get_planning_scene. The following error messages are thrown:

[ INFO] [1550623893.876476244]: waitForService: Service [/get_planning_scene] has not been advertised, waiting...
[ WARN] [1550623897.538627753]: Waiting for ma2010_d500/arm_controller/joint_trajectory_action to come up
[ INFO] [1550623898.898565207]: Failed to call service get_planning_scene, have you launched move_group? at /tmp/binarydeb/ros-kinetic-moveit-ros-planning-0.9.15/planning_scene_monitor/src/planning_scene_monitor.cpp:498

move_group is indeed running but /get_planning_scene seems to be stuck for some reason. The service is actually listed when running rosservice list | grep /get_planning_scene.

When I instead launch demo.launch, I can plan and execute manipulator pose goals successfully.

I have a slight suspicion that there is something wrong with the controller-setup or something related to it as the demo.launch and moveit_planning_execution.launch files launch different controllers.

I am getting essentially the same behaviour as described above when running the same two launch-scripts of the motoman_sda10f_moveit_config package.

Has anyone encountered an error like this before and would know how to solve it?

2

I think you indeed miss the controllers, see https://github.com/ros-industrial-consortium/bezier_examples/issues/2 for a similar issue.

1 Like
3

The controller_list is included in config/controllers.yaml of the moveit_config package and contains 3 controllers. One for all joints (arm and positioner) and two for the arm and positioner individually. This is the same approach as found in the dual arm motoman_sda10f_moveit_config package. The latter two controllers have non-empty names and that seems to be a problem based on the issue that you are referencing. If I, however, remove the last two controllers, so that only the unnamed remains I get the following error when I try to execute a planned trajectory (in simulation):

[ERROR] [1550792465.767458570]: Joint trajectory action failing on invalid joints
[ WARN] [1550792465.767995973]: Controller  failed with error code INVALID_JOINTS
[ WARN] [1550792465.768094358]: Controller handle  reports status FAILED

I do not have experience with multi-group systems in ROSi and could not find much except for existing multi-arm systems to go from. According to this tutorial, “A non-empty “name” parameter may be required if multiple robots are being controlled, to provide separate namespaces.” Naming the controllers is, however, apparently an issue as stated here: https://github.com/ros-industrial-consortium/bezier_examples/issues/2. Could a possible solution be to push the FollowJointTrajectory server down into a namespace (e.g. remap it)? And would I have to spawn two FollowJointTrajectory servers, for arm and positioner?

4

Dear Thomas (@tdl-ua),

as a general remark as you posted a question seeking for “Answers” on “ROS Discourse”.

Please read the support guidelines,
https://wiki.ros.org/Support
questions should be directed to https://answers.ros.org
not to the discussion forum.

Please also do not double post things, especially without cross references as that will potentially cause multiple people
to take time to answer your same question in the different forums without knowing that someone else has already take the time.

Thank you

Thilo

5

In this case I suggested to post here on ROS Discourse, as in a private email, it appeared that the topic that @tdl-ua is seeking support on is more a discussion topic (as in: is it even possible, what are the potential (dis)advantages of the different approaches) than a Q&A which actually has a single “best” answer.

In general though @ThiloZimmermann I agree with you.

1 Like
6

Hi @gavanderhoorn and @ThiloZimmermann,

I contemplated posting this on ROS Answers because there is an immediate issue I am facing with this and a direct question to which there might be a direct answer. However, integrating a manipulator with a positioner (or more broadly multi-group systems) w.r.t., configuration, kinematics and path planning seem to be discussed in general terms based on the replies to Victor’s post referenced earlier. Therefore, once it is clear whether my approach above is the way to go and my immediate issue mentioned above has been resolved, a further and broader discussion of general interest might also be necessary on collision avoidance and path planning (e.g., can Descartes do this? If not, how can it be done?). I’ve kind of tried to bring this point across in my initial post but did it rather poorly.

Long story short, I thought that what I am trying to do here could help keeping this whole discussion about kinematics and planning of external axes going.

If you prefer this to be posted on ROS Answers, I can of course do so.

1 Like
7

no, I agree with @gavanderhoorn that this is a rather a discussion than a simple question-answer thing.

Hopefully the discussion here also goes back to your initial topic of Integration of 6-axis manipulator and 2-axis positioner (external axes) & we can stop this meta-discussion on whether to post it here or there :slight_smile:

pardon - culpa mea

1 Like
8

@tdl-ua: can you describe the configuration of the Yaskawa controller? How are all the axes configured there? Two groups (one for the 6 axes of the robot, the turntable in another)?

If this is setup as a multi-group system, then you need to configure motoman_driver for that. I can’t be certain that you’ve done that from the description you’ve given here and the packages that you’ve made available.

Just to make sure: refer to this tutorial for an example configuration file (note: the title says “dual arm system”, but the idea is the same for any multi-motion group setup).

Do note that there are (still) some issues with such setups. Be sure to check the ros-industrial/motoman issue tracker.

9

@gavanderhoorn: both manipulator and positioner are integrated with a DX200 controller. Here is Eric Marcil’s answer to a similar question:

Yes, the same controller will support both the robot and the station. Each one is considered a control group.

So any example combining two robots is essentially the same as combining a robot with a station. The only difference is that the station has less joints.

If you look in the simple message structure there is a field for groupNo. For your system:

0 = robot
1 = station

If I remember correctly, there are two approaches.

You can send multiple messages for each group using SmBodyJointTrajPtFull
Or you can send a single message with multiple group info using SmBodyJointTrajPtFullEx

I believe that the second one is usually recommended if you are trying to coordinate the motion between both groups.

So I think our system is in deed setup as a multi-group system. It has actually not been delivered yet but we should have it up and running some time in March. So far, I have been running moveit_planning_execution.launch sim:=true to simulate the robot and that is when I’ve run into the above errors. So the question would also be whether the industrial robot simulator has multi-group capabilities since simulating the robot prior to execution is also required.

I have not configured the motoman_driver but will look into that next.

10

I should probably have noticed this earlier, but:

This made me believe you were already working with real hardware, which is not the case.

The fact that you’re only simulating leads to a very different diagnostic approach.

This is the only question at the moment really.

industrial_robot_simulator does not have multi-group support (or at least, the v1 version doesn’t). And: even if it had, none of the configuration files in the packages would have told it what those groups would be. Only the MoveIt side has information on joints in groups (from the .srdf) and those are not used by anything else.

This is actually the cause of the issues here: no matter how you configure the MoveIt side, there are never two Action servers with the current industrial_robot_client, so this is not going to work.

What you could do is start two instances of industrial_robot_simulator, each with their own set of joints, in two different namespaces (one for each group). That would be similar to how motoman_driver would expose the two groups. If you have that setup, you can start working on the MoveIt side.

Without real hardware there is no need. Only motoman_driver uses that configuration.

Could you please – in case of parallel requests for support through different channels – always present/include pertinent information in posts like yours?

11

@tdl-ua: please see Adamsua-lab/motoman_ma2010_d500_waam_moveit_config#1, which is an example of how your setup could be approximated using the industrial_robot_client.

It’s not exactly how it would be with motoman_driver, but close enough to give you an idea.

Note: I’ve also changed your MoveIt configuration to use chains for the two groups and used trac_ik instead of KDL (with Distance solve type).

If/when you have your real hw, we can revisit this.

Note: this only gets you to the actual problem / challenge: planning for the combined scene (or at least: with kinematics involved).

12

Thank you very much for the PR, @gavanderhoorn. I’ve changed moveit_planning_execution.launch and related scripts to launch two namespaced instances of industrial_robot_simulator when argument sim is set to true. I had tried to “push down” the simulator and joint_trajectory_action server instances individually using ROS_NAMESPACE before without success. Your approach using groups seems to work without issues.

I can now successfully plan and execute pose goals for the manipulator and positioner individually in rviz. This should solve the initial issue I described for simulation. Once our system is ready to use, I will carry out the same tests on the physical robot.

Note: this only gets you to the actual problem / challenge: planning for the combined scene (or at least: with kinematics involved).

The end goal for our application of metal additive manufacturing (and I am assuming for many others using the manipulator/positioner combination for various purposes) would be to plan paths not only based on getting from point A to B whilst avoiding collision but planning manipulator and positioner (and thus workpiece) pose trajectories from tool paths that are generated from CAD-2-path tools. Such tools (e.g., slicers such as the ros_additive_manufacturing package) generate tool paths with many via points based on the workpiece geometry. This response by @gavanderhoorn to a post on ROS Answers explains the difference and challenges involved very well IMO: Planning complex plans using multiple waypoints with MoveIt. Based on that post and my preliminary testing when only considering the manipulator for planning, Descartes seems to be a suitable alternative but also MoveIt! has some capabilities for planning Cartesian paths with waypoints: move_group tutorial: cartesian paths.

I think the challenge as far as I can tell now is the combined planning of workpiece and manipulator trajectories with collision avoidance and then also the synchronization of end-effector commands (e.g., welding torch on/off).

Any ideas for avenues to go down or suggestions of tools that can be used or adapted to ultimately achieve this final objective would be much appreciated.

Could you please – in case of parallel requests for support through different channels – always present/include pertinent information in posts like yours?

For sure, will do that in the future. This particular reply form Eric was part of an email exchange with me a few months ago where I tried to get a sense of the general Yaskawa system capabilities related to ROS.

13

I’ve left a comment on my PR that I believe is important.

You may have done it on purpose (as you have no hw yet), but your controllers.yaml as it is right now will not work correctly when trying to execute trajectories for the two groups separately.

I would take a look at Jmeyer1292/hybrid_planning_experiments by @Jmeyer, which builds upon the work by @Levi-Armstrong et al (trajopt_ros and tesseract).

Their presentation at ROSCon’18 last year shows what those packages can do: Optimization Motion Planning with Tesseract and TrajOpt for Industrial Applications (video, slides).

14

Hi,

Did anyone do some progress on this problematic? We will start working on this first, and maybe later on a use-case with one robot positioning the workpiece and the other welding (jigless welding).
I have in mind to apply OMPL constrained planning in order to obtain something like this: Multi-Robot Coordinated Weld with Camera - YouTube

Any input or open-source repo to start is welcome :slight_smile:

15

There are a couple external axes options here in the examples: https://github.com/ros-industrial-consortium/trajopt_ros
Perhaps @Levi-Armstrong can add a bit more detail relative to latest on hybrid planning and tesseract.

1 Like
16

In the mean time I tried to setup tesseract without success, could you have a look at this issue ?

https://github.com/Levi-Armstrong/tesseract_ros_workcell/issues/4

Maybe this one is outdated / less important https://github.com/ros-industrial-consortium/tesseract_ros/issues/121