docs: improve signals page #200
Conversation
This reverts commit 0e9e63c.
| @@ -16,15 +16,16 @@ Often, the message topic and message type is hardcoded within the implementation | |||
| difficult to rearrange the network topology of ROS nodes without modifying and recompiling the node implementation | |||
| itself. | |||
|
|
|||
| <!-- TODO: we now support all message types and not just standardized --> | |||
There was a problem hiding this comment.
I don't like this part a lot anymore since we now support any message type so especially the sentence right after this, line 20, is not really correct anymore. At this point, signals are just ROS 2 publishers and subscribers that take their topic name from a parameter
| library for Cartesian and joint state classes in C++ and Python. | ||
|
|
||
| <!-- TODO: all other state rep types too --> |
There was a problem hiding this comment.
To be done in a followup PR
|
|
||
| When developing an AICA component, signals are automatically converted to and from the corresponding data object. | ||
| writing it back into a message can involve a fair amount of boilerplate code. When developing an AICA component, signals | ||
| are usually automatically converted to and from the corresponding data object. | ||
|
|
||
| ## Basic signal types |
There was a problem hiding this comment.
Also in a follow up PR, I want to provide a table that explains what these message types are mapped to, e.g. double -> Float64
There was a problem hiding this comment.
One of my concerns reading this is that we say:
Additionally, ROS 2 messages are data packets, not data objects. Parsing data from a message, manipulating it and writing it back into a message can involve a fair amount of boilerplate code. When developing an AICA component, signals are usually automatically converted to and from the corresponding data object.
but I don't find it accurate. ROS messages are structs after all. This also feels like we are deviating from ROS language a bit (which we eventually have to but we should make a clear connection first).
I would personally prefer/suggest something more along the lines of
ROS 2 messages are lean data structures with no additional functionality other than storing data. Therefore, parsing data from a message, manipulating it and writing it back into a message can involve a fair amount of boilerplate code. Conversely, the AICA System will typically convert these message structures to and from objects that encapsulate a lot more functionality for manipulating, transforming, and in general operating on their contents.
There was a problem hiding this comment.
some concerns/comments.
Also, we say
ROS 2 topics are messages ...
which is not accurate. We could lightly edit by saying
ROS 2 messages flow through namespaced topics that publishers and subscribers can refer to ...
or something like that. I mention it in another comment, but I think we are deviating a bit from ROS language but that might not make much sense to ROS users (it might not affect newcomers, but it would still not portray the actual structure)
| @@ -16,15 +16,16 @@ Often, the message topic and message type is hardcoded within the implementation | |||
| difficult to rearrange the network topology of ROS nodes without modifying and recompiling the node implementation | |||
| itself. | |||
|
|
|||
| <!-- TODO: we now support all message types and not just standardized --> | |||
|
|
||
| When developing an AICA component, signals are automatically converted to and from the corresponding data object. | ||
| writing it back into a message can involve a fair amount of boilerplate code. When developing an AICA component, signals | ||
| are usually automatically converted to and from the corresponding data object. | ||
|
|
||
| ## Basic signal types |
There was a problem hiding this comment.
One of my concerns reading this is that we say:
Additionally, ROS 2 messages are data packets, not data objects. Parsing data from a message, manipulating it and writing it back into a message can involve a fair amount of boilerplate code. When developing an AICA component, signals are usually automatically converted to and from the corresponding data object.
but I don't find it accurate. ROS messages are structs after all. This also feels like we are deviating from ROS language a bit (which we eventually have to but we should make a clear connection first).
I would personally prefer/suggest something more along the lines of
ROS 2 messages are lean data structures with no additional functionality other than storing data. Therefore, parsing data from a message, manipulating it and writing it back into a message can involve a fair amount of boilerplate code. Conversely, the AICA System will typically convert these message structures to and from objects that encapsulate a lot more functionality for manipulating, transforming, and in general operating on their contents.
|
|
||
| However, any ROS 2 message can be implemented as a signal using the `custom` signal type. As long as the custom type | ||
| between two connected components has the same name, the application will be valid. | ||
| However, any ROS 2 message type can be implemented as a signal in an AICA application. The syntax for doing this is |
There was a problem hiding this comment.
We say publishers/subscribers are signals, but here it feels like we now identify them with messages too. I see where we are going with this, but I think it's a bit inconsistent in its use.
ROS uses the following:
|
Description
This PR makes a few updates to the signals page in the docs.
Review guidelines
Estimated Time of Review: 5 minutes
Checklist before merging: