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

How can I use ROS with my delta robot?

asked 2020-01-14 02:52:45 -0500

whitvma gravatar image

The igus delta robot is requiring ROS compatibility for some upcoming projects, and we would like to know if this is possible? Its drives are controlled by our own D1 dryves which communicate via CANopen and modbus TCP using their own IP address. The system usually works under a Siemens 1200 PLC.

Is this possible? what is needed to progress and utilise ROS for this delta robot?

Thanks in advance

edit retag flag offensive close merge delete


If you could provide some more information on how exactly you'd like to integrate or control the robot, we could give better answers.

gvdhoorn gravatar image gvdhoorn  ( 2020-01-14 10:59:52 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2020-01-14 10:53:46 -0500

gvdhoorn gravatar image

updated 2020-01-15 03:02:36 -0500

The system usually works under a Siemens 1200 PLC.

There are a few possible ways in which you could provide ROS integration of your robot. How tight you want to make the integration is up to you.

I'm going to assume here you want to remove the Siemens PLC, as you wrote "usually works", which implies you don't want to do that in case ROS is used (it would also be possible though, so please clarify it you did want to keep the PLC around). Note also that I'm only talking about the motion interface here. Nothing else.

Package suggestions and message links are from ROS 1. Some have a ROS 2 equivalent, but some don't, hence the ROS 1 links.

With no PLC, I would say the following would be needed:

  1. a driver to interface with the actuators
  2. an FK/IK solver
  3. an interface to control the robot over topics/services/actions

For 1, you could see whether ros_canopen suffices (but there are other packages that wrap CANopen access for ROS). ros_canopen supports ros_control, which probably makes writing (custom) controllers for your delta quite a bit easier than starting from scratch.

For 2, you'd probably have to write something yourself, as URDF does not support modelling parallel kinematics (actually, the limitation is in KDL, which was/is the default FK/IK solver, but because of that URDF never got support for it). This means you cannot re-use the standard robot_state_publisher nor any of the available IK solvers which target serial manipulators. You probably already have FK/IK code, so this would come down to wrapping it in the correct plugin interface.

For 3, you'd also need to write something yourself. I'm mainly thinking about an actionlib interface which accepts (for instance) Cartesian poses defined in the robot's base frame and then moves the TCP there. Most ROS robot drivers target serial kinematics and would expose a FollowJointTrajectory action server, which accepts goals which contain a JointTrajectory. But as the name implies, that message encodes a series of setpoints in joint space, which is not how one would typically control a delta robot (at least not at this level of abstraction).

To make it "easy" to control your delta via ROS, I would suggest to write a ros_control controller that accepts a custom actionlib goal which contains at least a geometry_msgs/PoseStamped (but perhaps also some additional fields). This would allow users to submit a target pose and have the controller+driver move the robot to that pose.

State output (ie: Cartesian pose and perhaps even also joint space poses of the three actuators) could be published using a different component, but still using ros_control (compare the joint_state_controller: this isn't actually a controller, but a component that reads sensor data from the underlying hw and publishes it as sensor_msgs/JointState msgs).

If you did want to use the Siemens PLC (and that could be advantageous: let it do low-level control, not ... (more)

edit flag offensive delete link more


Good morning

thank you very much for your quick response. My colleague's focus is to remove the PLC altogether in order to reduce programming difficulties and commissioning time. They are familiar with ROS and wish to not invest in a PLC for this single project, but use ROS for the entire motion programming of the delta robot. Do you think we could benefit from using the igus drives alongside the ROS too?

I will present them with the above and hopefully make some progress for them.

whitvma gravatar image whitvma  ( 2020-01-15 01:55:21 -0500 )edit

You don't need to keep linking your drives. Once is sufficient.

gvdhoorn gravatar image gvdhoorn  ( 2020-01-15 02:31:38 -0500 )edit

My colleague's focus is to remove the PLC altogether in order to reduce programming difficulties and commissioning time. They are familiar with ROS and wish to not invest in a PLC for this single project, but use ROS for the entire motion programming of the delta robot.

They may be familiar with ROS, but keeping the PLC in the loop could be advantageous. I would not dismiss that option too easily. If a Cartesian control interface to the robot is the end goal (for instance), then the PLC could do almost everything for you, and your ROS driver would only consist of a way to communicate those Cartesian poses to the PLC. You'd also get Cartesian state back from the PLC.

The PLC would essentially be responsible for executing Cartesian trajectories, and would take care of everything needed to do that.

Compare this to the approach I described ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2020-01-15 02:34:26 -0500 )edit

, .. FK/IK, trajectory generation, etc, etc). Joint space control of a delta is typically not desirable, as the kinematic configuration comes with quite some requirements and constraints for any control to result in meaningful (and feasible) motion (but you should already be aware of this).

I would recommend to take a good look at what the PLC can do and how to integrate that with ROS, as I believe it could save you quite some time.

Perhaps important to mention is that ROS (or at least: ROS 1) should not be considered a replacement of traditional (low-level) motion control systems, nor as an equivalent of systems such as Simulink or Labview. It was not designed for that sort of use. Component granularity is typically much higher (ie: coarse system decomposition), with real-time boundaries and requirements not crossing nodes for instance.

If you have a system capable of the hard real-time ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2020-01-15 02:38:05 -0500 )edit

answered 2021-06-03 03:03:44 -0500

edit flag offensive delete link more

Question Tools



Asked: 2020-01-14 02:52:45 -0500

Seen: 1,204 times

Last updated: Jan 15 '20