search

ros-industrial / motoman

ROS-Industrial Motoman support (http://wiki.ros.org/motoman)
145 stars 192 forks source link

I/O Interface Development #361

Closed marip8 closed 1 year ago

marip8 commented 3 years ago

Opening this thread as a discussion point for the development of I/O interface capabilities from the ROS driver

Milestones

The tasks below are the currently planned high-level milestones for the I/O interface

Future Development

Edit: not on the original list of work, but:

gavanderhoorn commented 3 years ago

@marip8 wrote:

Add support for multi-group I/O reading/writing

what is this exactly @marip8 ?

Reading/writing bytes and words, or getting everything to work in both the single and multi-motion group code paths?

marip8 commented 3 years ago

I meant I/O support for bytes/strings/etc. I just changed the wording above

gavanderhoorn commented 3 years ago

Ok.

Suggestion: split this into (at least) two items, as reading/writing bytes is already supported by/through MotoROS (see also REP-I4: Assigned Message Identifiers for the Simple Message Protocol - Assigned Message Identifiers - Vendor Specific Messages - Motoman), while variables, strings and others like that would probably need the ethernet server.

cjue commented 3 years ago

Suggestion: split this into (at least) two items, as reading/writing bytes is already supported by/through MotoROS

Yes, just adding read/write byte/word support would be helpful. IMHO having read/write_byte/word_io services would already save time and complexity for simple applications.

gavanderhoorn commented 3 years ago

While convenience is why we're adding them here, I'm going to repeat my advice (which I always give when talking about ROS, robot drivers and IO): consider using a proper fieldbus for industrial deployments. Having to add IO support to each and every robot driver doesn't scale very well, and will most likely use custom implementations of protocols which do not have the same level of support, integration nor testing as any of the available (software defined) fieldbuses in existence.

Even a simple wrapper around a modbus/tcp client would be a good option.

Having written that: we will add services to read & write bytes, as that is already supported by MotoROS.

Reading & writing single elements (ie: single bits) is already supported now that #355 is merged.

gavanderhoorn commented 3 years ago

@steviedale: #362 would also be good to consider here.

gavanderhoorn commented 3 years ago

366 added message and success fields to the service responses.

Those could be improved to provide a better indication of the cause of a failure as part of a fix for #360 and #367.

gavanderhoorn commented 3 years ago

I've marked "provide better error messages" as completed, as we now have input verification on the MotoROS side and error reporting on the motoman_driver.

gavanderhoorn commented 2 years ago

WIP PR for "Group IO" support: #435.

gavanderhoorn commented 2 years ago

WIP PR for "M Register" support: #439.

gavanderhoorn commented 2 years ago

438 (and the related PRs #435, #436 and #439) made it clear that including the MotoROS result (sub) code as part of the service response would actually be really nice. Right now we only include a human-readable error message, which is good, but doesn't work as well when trying to implement some automated recovery behaviour.

Adding a field to a message cannot be done in a bw-compatible way though (as in: the MD5 will change, even if the field is not a required field, or could be ignored), so changing the message definitions will require users to rebuild the driver.

(there would be no changes required to call sites though, as the new field(s) are additions)

gavanderhoorn commented 2 years ago

Just merged #435 and updated the OP.

Keeping this open to track status of "add MotoROS result (sub) code to service response".

gavanderhoorn commented 1 year ago

I'm going to close this as I believe we've implemented what we initially set out to do.

The two open (sub)tasks have either been implemented in MotoROS2 or we're not going to implement them (we won't be using HSES here).