Revision history [back]

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 that I missed I am interested to hear it!

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 that I missed work, I am interested to hear it!