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:
- a driver to interface with the actuators
- an FK/IK solver
- 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)
If you could provide some more information on how exactly you'd like to integrate or control the robot, we could give better answers.