# ABB Plan with external (revolute) axis

Hi everyone,

Some background: I am quite fresh with ROS. The setup i am using includes ROS (kinetic), an ABB arm, ROS-I along with the abb_driver. Moveit for the motion planning, kinematics etc. Setup with just the arm is working as it is supposed to. The goal now is to control an external axis which is rotating.

As stated in the abb_driver wiki the driver supports up to 4 integrated external linear axis. But in this case the external axis is set in front of the robot on top of a fixed base.

As far as the message part goes, with a quick inspection I saw that a conversion from mm to m and vice-versa is happening at the RAPID side. From ROS side the information for the external axis seems to be incorporated into the joint_message - joint_data system. For the RAPID side, is it as simple as using conversion from degree2rad instead of mm2m in order to support a revolute joint?

Main question: If the message structure for the supported linear axis is possible to be used with a revolute joint, what is the correct way to add the external axis assembly in the URDF and Moveit?

Current idea:

• Add a world frame in the urdf.
• Add both the arm's and positioner's first links as children of the world frame (This will create a branch in the kinematic chain.).
• Place positioner_base in front of the robot with a fixed joint and attach the second link to the positioner_base with a revolute joint.
• Define a new positioner planning group.
• Define a new controller for that group.

I have tried this approach for now and set it up with MSA but as soon as I add the new joint in the joint_names.yaml and execute the plan i get the error:

[ERROR] [1550352562.186055092]: Joint trajectory action failing on invalid joints


Moreover, IK solver does not like it if I create a planning_group that includes both "manipulator" and "positioner" as subgroups therefore i cannot incorporate them under the same planning_group. Currently i am using the TracIK kinematics plugin and it supports only chains.

If I create the second controller and name both of them accordingly: "manipulator", "positioner". I get the following error:

[ WARN] [1550403869.172061404]: Waiting for manipulator/joint_trajectory_action to come up
[ERROR] [1550403875.172279892]: Action client not connected: manipulator/joint_trajectory_action


Searching other posts for solutions i added two groups (inside robot_interface.launch) in order to define two namespaces (i think at least) to start their own instance of joint_trajectory_action but i still get the error.

Last, if I remove joint_7 (external axis) from the controller_joint_names I can normally plan for the arm but I also get this:

[ WARN] [1550419157.365318143]: The complete state of the robot is not yet known.  Missing joint_7


I am confused at this point since adding a second group which is also trying to connect to the same IP does not seem right (since the external axis is integrated in the abb controller). But ...

edit retag close merge delete

This is all possible, and should not be that difficult to setup.

If you haven't figured it out or someone hasn't responded earlier, I'll post something tomorrow.

( 2019-02-17 11:11:11 -0500 )edit

Nice these are good news, and thanks for the fast response. If I figure it out in the meantime I will update the post.

( 2019-02-17 11:18:03 -0500 )edit

An update on "Edit 2": Route No.2 is no longer an option since I do not have multimove option on the real IRC5 controller.

( 2019-02-21 08:19:59 -0500 )edit

Sort by » oldest newest most voted

Maybe I missed something somewhere but I could not find a straightforward solution to fit my needs.

The problem boiled down to the following:

In this case the relation between the ABB and ROS controllers-planning_groups is 1 to 2. There is one connection to the ABB driver (motion/state server). In Moveit I have two groups, in two namespaces, namely manipulator and positioner. Since I could use only one instance of the motion_download_interface I could control only one out of the two groups.

This is is definitely a workaround and NOT a solution, but I made it work like this..:

• I created a third planning group named "both".
• Added a third controller named "both" which includes all the 7 joints (arm:6 + positioner:1)
• robot_state and motion_download_interface nodes are included in the "both" group under the same namespace.
• All 3 namespaces (groups) include a joint_trajectory_action.
• Created the following nodes:
• joint_state_splitter: responsible to split the 7 joints list that returns from the ABB controller (to the /both namespace) into 6 and 1 and publish these lists to the respected /joint_states topics
• feedback_state_splitter: does the same as the above splitter for the feedback state positions.
• trajectory_merger: when an individual plan is made (either for the manipulator or the positioner) this node listens to it, and is also subscribed to the state of the second group from where it takes the static position. It always creates a trajectory which includes 7 joints with 7 positions for each point and submits the edited trajectory to the /both/joint_trajectory_action.
• In order for this to work, the trajectory_merger is doing some manipulation of the controller_list paremeter. Each time a plan is requested, the node sets the appropriate joint names to "both" controller and when the publish is complete it resets the parameter to the original value.

Since I consider all the above a quite dirty manipulation. I would like at least to suggest what in my mind sounds like a clean-solution:

• If multimove is an available option then a very clean 1-1 structure can be made for each group. This sums to two motion tasks in the RAPID side and the positioner is considered as separate unit (not integrated but 1-1 relation with ROS).
• If I could use an IK solver that could work with "tree" chain, meaning, one fixed joint and one branch for the arm plus one branch for the positioner, then probably moveit can plan for one group that includes both. Like that, there is again 1-1 to relation between ABB and ROS controllers. Probably a setup like this can plan for a simultaneous movement aswell?

Nonetheless, this is for now. In case there is suggested way to make this concept work, I am interested to hear it!

more