Wait for an EGM communication session to start...

[dyumanaditya]

Hi,
I've built abb_libegm_samples and abb_libegm in the same catkin_ws. After sourcing the setup.bat (I'm using Windows), and running rosrun abb_libegm_samples a2_pose_trajectory_node, the output is stuck to this:
Wait for an EGM communication session to start...

I've changed the remote port number of the UCdevice to 6510, 6511, 6512, 6513, 6514, which doesn't seem to make a difference.

[jontje]

EGM sessions are started by the RAPID program, so the node is probably waiting for that.

I suggest that you go back and reread the responses your previous questions in, for example, issues: ros-industrial/abb_robot_driver#10 and ros-industrial/abb_robot_driver#20.

[dyumanaditya]

Thank you for your answer @jontje, I'm sorry, I assumed that the abb_libegm_samples was a standalone package. I've incorporated abb_librws and all other dependencies (such as abb_rws_service_provider) such that I can start the RAPID programs and the EGM session by calling a service. Is this the way you would do it?

[gavanderhoorn]

This would be one way to do it, yes.

Note: with everything you've done, you're almost at the point where you've put together abb_robot_driver.

I'm still not sure why you can't use the FZI Cartesian controllers with abb_robot_driver. It would seem it would have saved you quite some time and effort.

[dyumanaditya]

The project I'm working on requires the use of ros_industrial packages and unfortunately I'm not in a position to use the FZI Cartesian controllers because it's considered 3rd party. It would be preferable, for what I'm doing, not to use ros_control and instead use RobotStudio to take care of the pose control. Do you have any suggestions for other possible alternatives?

[gavanderhoorn]

The project I'm working on requires the use of ros_industrial packages

Which packages?

I'm not in a position to use the FZI Cartesian controllers because it's considered 3rd party.

FZI is in the consortium, and in addition, the controllers they've made available have been used by others and FZI themselves in industrial settings.

I'm not claiming they're free of problems, but that same claim cannot be made of the examples you're currently using instead of abb_robot_driver.

It would be preferable, for what I'm doing, not to use ros_control and instead use RobotStudio to take care of the pose control

It sounds like you have some constraints you're not telling us, but if that's a hard requirement, why not use RAPID and program a regular application?

And pedantic, but RobotStudio is not involved. That's only a GUI.