ros-industrial / motoman

ROS-Industrial Motoman support (http://wiki.ros.org/motoman)
145 stars 192 forks source link

Unable to move more than one controllers at the same time #442

Closed akashjinandra closed 2 years ago

akashjinandra commented 2 years ago

Hello All,

I have a YRC1000 with a 6 axis robot arm, that is on a track(set up as an external axis) . I have a controllers.yaml file with 2 controllers, one for the arm and one for the track. I have 3 moveit groups, one with just the robot, one with just the track and one with both the robot and the track. When using both the singular controller groups such as only robot and only gripper I am able to move the robot through moveit. However with the moveit group with both controllers, only one controller moves(either the robot or the track) and then the other controller times out.

I have also looked at the joint trajectory/goal topic and both are being commanded.

I have tested the concept of using 2 different controllers with one moveit group in simulation and it has worked without any issues.

I am using ROS melodic with the latest moto ros and kinetic branch of this repo. I also tried this branch: https://github.com/ros-industrial/motoman/pull/259

And followed these instructions:
http://wiki.ros.org/motoman_driver/Tutorials/Creating%20a%20Dual-Arm%20System

Also using this launch file: https://github.com/ros-industrial/motoman/blob/kinetic-devel/motoman_driver/launch/robot_multigroup_interface_streaming_yrc1000.launch

akashjinandra commented 2 years ago

Updated Errors from terminal:

[ INFO] [1639641492.462853818]: Execution request received [ INFO] [1639641495.349610460]: Controller 'gp200r/gp200r_b1_controller' successfully finished

[ERROR] [1639641503.605817681]: Controller is taking too long to execute trajectory (the expected upper bound for the trajectory execution was 11.131715 seconds). Stopping trajectory. [ INFO] [1639641503.605871035]: Cancelling execution for gp200r/gp200r_r1_controller [ INFO] [1639641503.605966982]: Completed trajectory execution with status TIMED_OUT ... [ INFO] [1639641503.606055999]: Execution completed: TIMED_OUT [ INFO] [1639641503.606532460]: Controller 'gp200r/gp200r_r1_controller' successfully finished [ INFO] [1639641503.802789415]: ABORTED: Timeout reached

As mentioned in the earlier message, the b1 controller is the track and the r1 controller is the robot.

akashjinandra commented 2 years ago

Hello, I figured out the solution to my issue, so in the controllers.yaml file you need to have all the individual controllers, like R1, B1, for each individual group on the robot controller, in my case, one for the robot, one for the track. What I was missing was one extra controller that controlled ALL the axes. See here: https://github.com/Danfoa/motoman/blob/kinetic-devel/motoman_sda10f_moveit_config/config/controllers.yaml

I missed that step because in simulation it wasn't necessary(meaning you can just keep all controllers separate.. i.e. one for track and one for robot), but I see now that on the real robot/controller, it can't take 2 separate controller requests at the same time, so that's why there needs to be one controller with all the axes within it.

gavanderhoorn commented 2 years ago

Good to hear you figured it out.

It's indeed not supported right now to move two different groups asynchronously (or: at the same time with two different goals) as you were trying to do.

MoveIt will try to do that if you only give it two groups -- one with the joints of the robot and one with the track joint -- and then create a group which contains those groups.

As you found out, the correct way to configure it is to create a third group which is comprised of all the joints that need to move simultaneously: so robot joints + track joint.

I missed that step because in simulation it wasn't necessary

I'm not sure which "simulation" you refer to, but in general without verifying simulation works as whatever real HW you're planning on using, it's not wise to rely on outcomes of simulations.

I see now that on the real robot/controller, it can't take 2 separate controller requests at the same time, so that's why there needs to be one controller with all the axes within it.

exactly.

For future issues: please always specify what kind of "controller" you refer to.

It's an ambiguous name to use otherwise (Yaskawa controller, MoveIt 'controller' (which isn't really a controller), ros_control controller, etc).

gavanderhoorn commented 2 years ago

As this was solved by correcting the configuration, I'm going to close the issue.

Not to say that things wrt multi-group motion can't be improved, but we already have issues tracking those enhancement requests.

akashjinandra commented 2 years ago

Thanks for your input. When I said simulation, I meant with normal ros control(gazebo/fake joint ros control) and moveit. You can specify in the controllers.yaml file one controller for the track(b1) and another for the robot(r1), and have the corresponding ROS controllers that are of the follow joint trajectory type. At this point if you have one moveit group that has both the track and the robot, it is able to do coordinated motion. This is without having to have an extra controller listed in the controllers.yaml that includes both the robot and track joints. But I'm glad I understand how to do this now for Yaskawa controllers.

gavanderhoorn commented 2 years ago

When I said simulation, I meant with normal ros control(gazebo/fake joint ros control) and moveit.

ah, ok.

At this point if you have one moveit group that has both the track and the robot, it is able to do coordinated motion

So the reason that works is because everything is completely virtual, and you actually don't have synchronous motion with that setup. Coordinated in a way perhaps, but not synchronised. MoveIt just happens to submit the goals to the individual groups really close together (in time).

In practice you probably won't notice that, due to the kind of application you're working on, but that's really different from what the yaskawa controller does (or actually: motoman_driver).