Discrete I/O control

[marshallpowell97]

I am currently discussing with @Bdelspi a way to control an electric gripper through ROS and from what I can tell, there has not been any IO control implemented in this driver. I am not aware of how this is implemented in other drivers, but I would imagine it would be as simple as creating a "gripper server" in the VAL 3 code listening on a certain socket. @gavanderhoorn am I on the right track here?

[marshallpowell97]

Related: #313

[gavanderhoorn]

We don't necessarily need to use a different server task: the network decoding logic already switches based on packet id, and we have packet ids we could use for IO related functionality. That is, if we want to use simple message for this.

IIRC, Staublis have an XML-RPC server (I seem to remember SRS uses this, but I can't find any docs on it). If it does exist, does it allow access to the IO? If so, we could write a simple Python node that would wrap (a part of) the XML-RPC interface and expose ROS services (perhaps Actions) to toggle IOs, and we could publish IO state on topics.

If there is no XML-RPC (or other software-only interface), we could consider implementing support for (fi) the Motoman set of IO messages (See REP-I4 here for the IDs).

---

Reason I'm hesitant to add simple message support in staubli_val3_driver for this is because in my opinion I'd rather see people use a proper fieldbus. Something like Modbus TCP is relatively trivial to get working (on the PC side), and are typically well supported by ind robot mfgs.

At one point we did want to add generic support for IOs to simple message (see ROS-Industrial Simple Message Generic Robot IO for a candidate REP), but as it would be essentially another software defined ~fieldbus~ protocol (and not a very nice one), I decided to withdraw the REP.

It's trivial almost to wrap any protocol in a ROS node, so if you'd know of any candidate protocols we could use for this, I'd be open to suggestions. Personally I try to use things that are either free options, or already available by default on a controller.

[marshallpowell97]

Reason I'm hesitant to add simple message support in staubli_val3_driver for this is because in my opinion I'd rather see people use a proper fieldbus. Something like Modbus TCP is relatively trivial to get working (on the PC side), and are typically well supported by ind robot mfgs.

I'm perfectly fine recommending the use of a fieldbus instead. In that case, I'd like to maybe see some tools included with the driver, I.E. a modbus configuration file for the controller and some kind of sample code for the PC side. Is that something typically included with other robot drivers, or is it normally left up to the user?

[gavanderhoorn]

Is that something typically included with other robot drivers, or is it normally left up to the user?

It's not typically included with a robot driver as it's not really part of it.

A modbus configuration can be used with and without a(n industrial) robot. Additionally, there is almost no common configuration between use-cases: in the end the modbus library would be reading/writing coils. Mapping those to higher-level concepts (ie: opening/closing a gripper) is something completely defined by the application and/or integrator.

And there are many other fieldbuses and interfaces to robot controllers. Which one a user would want to use is not something that can be decided for him/her.

[gavanderhoorn]

Having written this: I would not be opposed to creating an example configuration and then linking it from the driver's readme / documentation.

Having such an example would be very useful, as it would provide a starting point for users looking to set up something similar.

If you find something is specific to Staubli controllers in such a configuration/package @marshallpowell97, we could consider hosting it in this repository. But if there isn't, it would be better not to do that.

[marshallpowell97]

If you find something is specific to Staubli controllers in such a configuration/package @marshallpowell97, we could consider hosting it in this repository. But if there isn't, it would be better not to do that.

Both of our controllers (CS8/CS9) use an XML file for the Modbus configuration. I'm not sure if the format is specific to Staubli, but I can provide an example:

`<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

` > Having such an example would be very useful, as it would provide a starting point for users looking to set up something similar. I agree.

[simonschmeisser]

+1 from me on adding/documenting modbus features. I tried implementing generic IO support but couldn't get it to work in the short amount of time I had access to a Stäubli. Only way later I discovered the Modbus/TCP interface and therefore used a ProfiNet Master Hilscher card to control the gripper.

For me it would also be interesting to have a generic interface for discrete IO. I think you @gavanderhoorn once mentioned this would need to be started with a discussion on discourse.ros.org right? Similar to the ones from reapp https://github.com/antonxy/industrial_core/blob/reapp/industrial_msgs/srv/IORead.srv

[gavanderhoorn]

To move this forward: could you perhaps put together some sort of example of what you are thinking of @marshallpowell97?

We can then decide later where to host this.

[gavanderhoorn]

For me it would also be interesting to have a generic interface for discrete IO. I think you @gavanderhoorn once mentioned this would need to be started with a discussion on discourse.ros.org right? Similar to the ones from reapp https://github.com/antonxy/industrial_core/blob/reapp/industrial_msgs/srv/IORead.srv

What I would like to see discussed a little is the ROS API itself. That's why I suggested posting on Discourse.

[marshallpowell97]

To move this forward: could you perhaps put together some sort of example of what you are thinking of @marshallpowell97?

Here is an example: IOControl.zip

modbus.xml is the configuration file for the modbus server on the controller which is configured for 2 inputs and 2 outputs (not used right now, but could potentially be useful).

IOControl.py is the python script to write to the inputs on the controller. The usage would be: python IOControl.py -i [ip address] -p [port] -o [output number] -v [value to write (true/false)]

I think this would require an "IO task" in the VAL 3 server to be monitoring the Modbus input and write that value to the correct output since it is not possible to directly link an input to and output (nor would it be desirable IMO). That would mean that the only "modifications" that the user would need to make would be linking a digital output variable to the correct physical output on the controller via the pendant.

For example, if a user wanted to use this to control the valves in the arm, they would need to:

1. Load modbus.xml onto the controller via FTP or USB and reboot
2. Link the digital output variable to valve1
3. Run IOControl.py with the correct aguments (wrapped in a ROS node? I'm not 100% what the correct implementation is here)

[gavanderhoorn]

Hm. This is not completely what I had in mind.

My experience with modbus and staublis is limited. Do I understand you correctly when I say that it's impossible to configure the server such that it will allow writing to controller outputs directly?

[marshallpowell97]

Do I understand you correctly when I say that it's impossible to configure the server such that it will allow writing to controller outputs directly?

That's correct, unfortunately. From my understanding it's a safety concern.

[marshallpowell97]

@gavanderhoorn It turns out I was wrong about this and it IS possible to link an input to an output using dioLink(). Would that make it closer to what you had in mind?

[gavanderhoorn]

If we can indeed configure modbus as you would normally do, then we could provide some reference configurations and perhaps even select a specific library / ROS package which we've verified works.

There are a few (such as wiki/modbus, just a random one). If we gather a few and test them, we should select one or two and provide known-working configurations and .launch files.