Closed marip8 closed 1 year 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?
I meant I/O support for bytes/strings/etc. I just changed the wording above
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.
@steviedale: #362 would also be good to consider here.
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
.
WIP PR for "Group IO" support: #435.
WIP PR for "M Register" support: #439.
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).
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: