Revision history [back]

After edit:

Ok, so essentially you want to implement a new server application (in the terminology of ROS-Industrial) that accepts incoming simple_message messages, deserialises and then processes them. You want to do this for both a simulated version of your controller, as well as for your B&R controller.

In general, as long as you don't have too specialised requirements for the interaction with a remote controller, the nodes in the industrial_robot_client pkg can be used as the client side of a ROS-Industrial 'bridge' (if you will). The generic robot_state, motion_streaming_interface and joint_trajectory_action nodes implement this bridge. For instance: they accept JointTrajectory messages, convert those into Simple Message JointTrajPt messages and send them to your server application running on your controller (or wherever you want really, it's just a TCP/IP connection most of the time).

The 'only' thing you need to do, is to implement a server that is capable of 'understanding' those Simple Message messages. In the case of an industrial robot controller this typically involves programming a special application to run on the industrial controller. That application deserialises the incoming Simple Message messages and then gets the controller to perform the appropriate motions. For a number of vendors, we already have these server applications and you only need to install those on your robot controller.

More often than not, those server applications are written in controller specific languages, not C or C++. In your specific case (with Matlab action as a middle-man) you have a few options:

1. Implement the whole Simple Message protocol (de)serialisation and TCP/IP connection management in Matlab script, or
2. Wrap the existing simple_message library inside a Simulink S-Function. Simple Message is just C++, and should be reasonably easy to port to Windows (if needed). The existing code will handle the connection and (de)serialisation for you, all you need to do is provide a few callbacks which will be called when a message is received.

If I understand you correctly, Matlab will then communicate with your B&R controller, but that is a separate problem.

Obviously, if you want to run the Simple Message server application directly on your B&R controller (without Matlab in the middle), you would have to write something that can run on that controller.

After edit:

Ok, so essentially you want to implement a new server application (in the terminology of ROS-Industrial) that accepts incoming simple_message messages, deserialises and then processes them. You want to do this for both a simulated version of your controller, as well as for your B&R controller.

In general, as long as you don't have too specialised requirements for the interaction with a remote controller, the nodes in the industrial_robot_client pkg can be used as the client side of a ROS-Industrial 'bridge' (if you will). The generic robot_state, motion_streaming_interface and joint_trajectory_action nodes implement this bridge. For instance: they accept JointTrajectory messages, convert those into Simple Message JointTrajPt messages and send them to your server application running on your controller (or wherever you want really, it's just a TCP/IP connection most of the time).

The 'only' thing you need to do, is to implement a server that is capable of 'understanding' those Simple Message messages. In the case of an industrial robot controller this typically involves programming a special application to run on the industrial controller. That application deserialises the incoming Simple Message messages and then gets the controller to perform the appropriate motions. For a number of vendors, we already have these server applications and you only need to install those on your robot controller.

More often than not, those server applications are written in controller specific languages, not C or C++. In your specific case (with Matlab action as a middle-man) you have a few options:

1. Implement the whole Simple Message protocol (de)serialisation and TCP/IP connection management in Matlab script, or
2. Wrap the existing simple_message library inside a Simulink S-Function. Simple Message is just C++, and should be reasonably easy to port to Windows (if needed). The existing code will handle the connection and (de)serialisation for you, all you need to do is provide a few callbacks which will be called when a message is received.

If I understand you correctly, Matlab will then communicate with your B&R controller, but that is a separate problem.

Obviously, if you want to run the Simple Message server application directly on your B&R controller (without Matlab in the middle), you would have to write something that can run on that controller.

After edit:

Ok, so essentially you want to implement a new server application (in the terminology of ROS-Industrial) that accepts incoming simple_message messages, deserialises and then processes them. You want to do this for both a simulated version of your controller, as well as for your B&R controller.

In general, as long as you don't have too specialised requirements for the interaction with a remote controller, the nodes in the industrial_robot_client pkg can be used as the client side of a ROS-Industrial 'bridge' (if you will). The generic robot_state, motion_streaming_interface and joint_trajectory_action nodes implement this bridge. For instance: they accept JointTrajectory messages, convert those into Simple Message JointTrajPt messages and send them to your server application running on your controller (or wherever you want really, it's just a TCP/IP connection most of the time).

The 'only' thing you need to do, is to implement a server that is capable of 'understanding' those Simple Message messages. In the case of an industrial robot controller this typically involves programming a special application to run on the industrial controller. That application deserialises the incoming Simple Message messages and then gets the controller to perform the appropriate motions. For a number of vendors, we already have these server applications and you only need to install those on your robot controller.

More often than not, those server applications are written in controller specific languages, not C or C++. In your specific case (with Matlab action as a middle-man) you have a few options:

1. Implement the whole Simple Message protocol (de)serialisation and TCP/IP connection management in Matlab script, or
2. Wrap the existing simple_message library inside a Simulink S-Function. Simple Message is just C++, and should be reasonably easy to port to Windows (if needed). The existing code will handle the connection and (de)serialisation for you, all you need to do is provide a few callbacks which will be called when a message is received.

If I understand you correctly, Matlab will then communicate with your B&R controller, but that is a separate problem.

Obviously, if you want to run the Simple Message server application directly on your B&R controller (without Matlab in the middle), you would have to write something that can run on that controller.controller. If you are in the fortunate situation where you controller can run C/C++ applications, you can reuse the existing simple_message library again. You would then not need to write the protocol (de)serialiser from scratch.

As soon as you have created your server, the generic clients can bridge between ROS and your motion controller. Now write a URDF, create a MoveIt configuration package and you can start using MoveIt to plan motions.

After edit:

Ok, so essentially you want to implement a new server application (in the terminology of ROS-Industrial) that accepts incoming simple_message messages, deserialises and then processes them. You want to do this for both a simulated version of your controller, as well as for your B&R controller. From a ROS-Industrial perspective, what you're trying to do is implementing a driver for a specific (industrial) controller.

In general, as long as you don't have too specialised requirements for the interaction with a remote controller, the nodes in the industrial_robot_client pkg can be used as the client side of a ROS-Industrial 'bridge' (if you will). The generic robot_state, motion_streaming_interface and joint_trajectory_action nodes implement this bridge. For instance: they accept JointTrajectory messages, convert those into Simple Message JointTrajPt messages and send them to your server application running on your controller (or wherever you want really, it's just a TCP/IP connection most of the time).

The 'only' thing you need to do, is to implement a server that is capable of 'understanding' those Simple Message messages. In the case of an industrial robot controller this typically involves programming a special application to run on the industrial controller. That application deserialises the incoming Simple Message messages and then gets the controller to perform the appropriate motions. For a number of vendors, we already have these server applications and you only need to install those on your robot controller.

More often than not, those server applications are written in controller specific languages, not C or C++. In your specific case (with Matlab action as a middle-man) you have a few options:

1. Implement the whole Simple Message protocol (de)serialisation and TCP/IP connection management in Matlab script, or
2. Wrap the existing simple_message library inside a Simulink S-Function. Simple Message is just C++, and should be reasonably easy to port to Windows (if needed). The existing code will handle the connection and (de)serialisation for you, all you need to do is provide a few callbacks which will be called when a message is received.

If I understand you correctly, Matlab will then communicate with your B&R controller, but that is a separate problem.

Obviously, if you want to run the Simple Message server application directly on your B&R controller (without Matlab in the middle), you would have to write something that can run on that controller. If you are in the fortunate situation where you controller can run C/C++ applications, you can reuse the existing simple_message library again. You would then not need to write the protocol (de)serialiser from scratch.scratch. Again, see the industrial_robot_client page for more information.

As soon as you have created your server, the generic clients can bridge between ROS and your motion controller. Now write a URDF, create a MoveIt configuration package and you can start using MoveIt to plan motions.

After edit:

Ok, so essentially you want to implement a new server application (in the terminology of ROS-Industrial) that accepts incoming simple_message messages, deserialises and then processes them. You want to do this for both a simulated version of your controller, as well as for your B&R controller. From a ROS-Industrial perspective, what you're trying to do is implementing a driver for a specific (industrial) controller.

In general, as long as you don't have too specialised requirements for the interaction with a remote controller, the nodes in the industrial_robot_client pkg can be used as the client side of a ROS-Industrial 'bridge' (if you will). The generic robot_state, motion_streaming_interface and joint_trajectory_action nodes implement this bridge. For instance: they accept JointTrajectory messages, convert those into Simple Message JointTrajPt messages and send them to your server application running on your controller (or wherever you want really, it's just a TCP/IP connection most of the time).

The 'only' thing you need to do, is to implement a server that is capable of 'understanding' those Simple Message messages. In the case of an industrial robot controller this typically involves programming a special application to run on the industrial controller. That application deserialises the incoming Simple Message messages and then gets the controller to perform the appropriate motions. For a number of vendors, we already have these server applications and you only need to install those on your robot controller.

More often than not, those server applications are written in controller specific languages, not C or C++. In your specific case (with Matlab action as a middle-man) you have a few options:

1. Implement the whole Simple Message protocol (de)serialisation and TCP/IP connection management in Matlab script, or
2. Wrap the existing simple_message library inside a Simulink S-Function. Simple Message is just C++, and should be reasonably easy to port to Windows (if needed). The existing code will handle the connection and (de)serialisation for you, all you need to do is provide a few callbacks which will be called when a message is received.

If I understand you correctly, Matlab will then communicate with your B&R controller, but that is a separate problem.

Obviously, if you want to run the Simple Message server application directly on your B&R controller (without Matlab in the middle), you would have to write something that can run on that controller. If you are in the fortunate situation where you controller can run C/C++ applications, you can reuse the existing simple_message library again. You would then not need to write the protocol (de)serialiser from scratch. Again, see the industrial_robot_client page for more information.

As soon as you have created your server, the generic clients can bridge between ROS and your motion controller. Now write a URDF, create a MoveIt configuration package and you can start using MoveIt to plan motions.

After edit:

Ok, so essentially you want to implement a new server application (in the terminology of ROS-Industrial) that accepts incoming simple_message messages, deserialises and then processes them. You want to do this for both a simulated version of your controller, as well as for your B&R controller. From a ROS-Industrial perspective, what you're trying to do is implementing a driver for a specific (industrial) controller.

In general, as long as you don't have too specialised requirements for the interaction with a remote controller, the nodes in the industrial_robot_client pkg can be used as the client side of a ROS-Industrial 'bridge' (if you will). The generic robot_state, motion_streaming_interface and joint_trajectory_action nodes implement this bridge. For instance: they accept JointTrajectory messages, convert those into Simple Message JointTrajPt messages and send them to your server application running on your controller (or wherever you want really, it's just a TCP/IP connection most of the time).

The 'only' thing you need to do, is to implement a server that is capable of 'understanding' those Simple Message messages. In the case of an industrial robot controller this typically involves programming a special application to run on the industrial controller. That application deserialises the incoming Simple Message messages and then gets the controller to perform the appropriate motions. For a number of vendors, we already have these server applications and you only need to install those on your robot controller.

More often than not, those server applications are written in controller specific languages, not C or C++. In your specific case (with Matlab action as a middle-man) you have a few options:

1. Implement the whole Simple Message protocol (de)serialisation and TCP/IP connection management in Matlab script, or
2. Wrap the existing simple_message library inside a Simulink S-Function. Simple Message is just C++, and should be reasonably easy to port to Windows (if needed). The existing code will handle the connection and (de)serialisation for you, all you need to do is provide a few callbacks which will be called when a message is received.

If I understand you correctly, Matlab will then communicate with your B&R controller, but that is a separate problem.

Obviously, if you want to run the Simple Message server application directly on your B&R controller (without Matlab in the middle), you would have to write something that can run on that controller. If you are in the fortunate situation where you controller can run C/C++ applications, you can reuse the existing simple_message library again. You would then not need to write the protocol (de)serialiser from scratch. Again, see the industrial_robot_client page for more information.

As soon as you have created your server, the generic clients can bridge between ROS and your motion controller. Now write a URDF, create a MoveIt configuration package and you can start using MoveIt to plan motions.

Edit 2: to get the industrial_robot_client nodes to send you any traffic for testing, you could use the test_move.py script in the ur_driver package. Make sure to start the joint_trajectory_action and motion_streaming_interface from industrial_robot_client first though.

After edit:

Ok, so essentially you want to implement a new server application (in the terminology of ROS-Industrial) that accepts incoming simple_message messages, deserialises and then processes them. You want to do this for both a simulated version of your controller, as well as for your B&R controller. From a ROS-Industrial perspective, what you're trying to do is implementing a driver for a specific (industrial) controller.

In general, as long as you don't have too specialised requirements for the interaction with a remote controller, the nodes in the industrial_robot_client pkg can be used as the client side of a ROS-Industrial 'bridge' (if you will). The generic robot_state, motion_streaming_interface and joint_trajectory_action nodes implement this bridge. For instance: they accept JointTrajectory messages, convert those into Simple Message JointTrajPt messages and send them to your server application running on your controller (or wherever you want really, it's just a TCP/IP connection most of the time).

The 'only' thing you need to do, is to implement a server that is capable of 'understanding' those Simple Message messages. In the case of an industrial robot controller this typically involves programming a special application to run on the industrial controller. That application deserialises the incoming Simple Message messages and then gets the controller to perform the appropriate motions. For a number of vendors, we already have these server applications and you only need to install those on your robot controller.

More often than not, those server applications are written in controller specific languages, not C or C++. In your specific case (with Matlab action as a middle-man) you have a few options:

1. Implement the whole Simple Message protocol (de)serialisation and TCP/IP connection management in Matlab script, or
2. Wrap the existing simple_message library inside a Simulink S-Function. Simple Message is just C++, and should be reasonably easy to port to Windows (if needed). The existing code will handle the connection and (de)serialisation for you, all you need to do is provide a few callbacks which will be called when a message is received.

If I understand you correctly, Matlab will then communicate with your B&R controller, but that is a separate problem.

Obviously, if you want to run the Simple Message server application directly on your B&R controller (without Matlab in the middle), you would have to write something that can run on that controller. If you are in the fortunate situation where you controller can run C/C++ applications, you can reuse the existing simple_message library again. You would then not need to write the protocol (de)serialiser from scratch. Again, see the industrial_robot_client page for more information.

As soon as you have created your server, the generic clients can bridge between ROS and your motion controller. Now write a URDF, create a MoveIt configuration package and you can start using MoveIt to plan motions.

Edit 2: to get the industrial_robot_client nodes to send you any traffic for testing, you could use the test_move.py script in the ur_driver package. Make sure to start the joint_trajectory_action and motion_streaming_interface from industrial_robot_client first though. though, and update the list of joint names.

See industrial_robot_client/launch/robot_interface_streaming.launch for an example launch file.