motoman
motoman copied to clipboard
ros-industrial
I/O Interface Development
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
- [x] Add I/O communication into joint trajectory streamer node (done: #355)
- [x] Port I/O communication into stand-alone node (done: #365)
- [x] Incorporate better error feedback for incorrect I/O addresses per #360 (started with #366 and #371 (and #369))
- [x] Add support for reading/writing bytes (#435)
Future Development
- [ ] Implement I/O solution for ROS 2 driver
- [ ] Leverage high-speed ethernet server for I/O communication with complex types (i.e. strings, etc.) and other teach pendant functionality
Edit: not on the original list of work, but:
- [x] Add support for reading/writing M-registers (#439)
@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?
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.
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.
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.
#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.
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.
#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)
Just merged #435 and updated the OP.
Keeping this open to track status of "add MotoROS result (sub) code to service response".
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).