ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Taking this a bit wider (so no necessarily a "ROS-I interface"):

Currently the robot can only be programmed via a teach pendant, using a C-like language. It can also be interfaced via MODBUS, so I can write a program which accepts something from the MODBUS (positions / coordinates etc) and move the robot arm accordingly.

that would be something that could work. Given proper buffering and blending of motions this could be a viable first approach.

There might be other communication methods, but the vendor is hiding them from us (for business reason I suppose). If needed, I could ask them to make these available.

Depending on your actual use-case / application it might be worth it to ask them.

Taking this a bit wider (so no necessarily a "ROS-I interface"):

Currently the robot can only be programmed via a teach pendant, using a C-like language. It can also be interfaced via MODBUS, so I can write a program which accepts something from the MODBUS (positions / coordinates etc) and move the robot arm accordingly.

that would be something that could work. Given proper buffering and blending of motions this could be a viable first approach.

If you'd like to reuse something like industrial_robot_client you could take a look at any of the server-side (ie: controller) programs in abb_driver or fanuc_driver. They're no longer being developed (as better interfaces are now available), but it should give you an idea.

There might be other communication methods, but the vendor is hiding them from us (for business reason I suppose). If needed, I could ask them to make these available.

Depending on your actual use-case / application it might be worth it to ask them.

Taking this a bit wider (so no not necessarily a "ROS-I interface"):

Currently the robot can only be programmed via a teach pendant, using a C-like language. It can also be interfaced via MODBUS, so I can write a program which accepts something from the MODBUS (positions / coordinates etc) and move the robot arm accordingly.

that would be something that could work. Given proper buffering and blending of motions this could be a viable first approach.

If you'd like to reuse something like industrial_robot_client you could take a look at any of the server-side (ie: controller) programs in abb_driver or fanuc_driver. They're no longer being developed (as better interfaces are now available), but it should give you an idea.

There might be other communication methods, but the vendor is hiding them from us (for business reason I suppose). If needed, I could ask them to make these available.

Depending on your actual use-case / application it might be worth it to ask them.