From 0e9e63cf1bc3a718472c00574163e87bda24c841 Mon Sep 17 00:00:00 2001 From: Dominic Reber Date: Thu, 19 Dec 2024 07:22:21 +0100 Subject: [PATCH 1/3] feat: remove clproto message type --- .../custom-components/02-custom-component.md | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/docs/docs/reference/custom-components/02-custom-component.md b/docs/docs/reference/custom-components/02-custom-component.md index ea80627e..f259deca 100644 --- a/docs/docs/reference/custom-components/02-custom-component.md +++ b/docs/docs/reference/custom-components/02-custom-component.md @@ -495,19 +495,11 @@ The following example adds two outputs: one as a floating point number and one a -:::note - -When using the `EncodedState` type for an output, the specific underlying state type must also be defined using the -`MessageType` enumeration in the `clproto` library. - -::: - ```python title="custom_component.py" from std_msgs.msg import Float64 from modulo_core.encoded_state import EncodedState -from clproto import MessageType from state_representation import CartesianPose ``` @@ -521,9 +513,7 @@ from state_representation import CartesianPose # bind the attribute to an output using the attribute name and message type self.add_output("number", "_output_number", Float64) - - # for encoded states, further define the expected state type when binding the output - self.add_output("pose", "_output_pose", EncodedState, MessageType.CARTESIAN_POSE_MESSAGE) + self.add_output("pose", "_output_pose", EncodedState) ``` From debe9f5e35ebb423639e43f9d359a6b4b705ee41 Mon Sep 17 00:00:00 2001 From: Dominic Reber Date: Fri, 20 Dec 2024 10:11:38 +0100 Subject: [PATCH 2/3] docs: improve signals page --- .../concepts/05-building-blocks/01-signals.md | 29 ++++++++++--------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/docs/docs/concepts/05-building-blocks/01-signals.md b/docs/docs/concepts/05-building-blocks/01-signals.md index 380364d5..a7bd9947 100644 --- a/docs/docs/concepts/05-building-blocks/01-signals.md +++ b/docs/docs/concepts/05-building-blocks/01-signals.md @@ -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. + Signals then are ROS 2 publishers and subscribers with dynamically assigned topics and standardized message types. This makes it easy to reconfigure the signal connections between different components and controllers in the application graph without modifying or recompiling any source code. By using standard message types, the signal compatibility -between components and controllers is also simplified. +between components and controllers is also simplified. When components and controllers are connected by a signal in an +application graph, the application interpreter will try to assert that the signals have a matching type. 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 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 @@ -74,24 +75,26 @@ The following state variables can be exchanged as signals: AICA state signals are built on the -open-source [`state_representation`](https://aica-technology.github.io/control-libraries/versions/v7.1.0/md__github_workspace_source_state_representation__r_e_a_d_m_e.html) +open-source [`state_representation`](https://aica-technology.github.io/control-libraries/versions/9.0.1/md__2github_2workspace_2source_2state__representation_2_r_e_a_d_m_e.html) library for Cartesian and joint state classes in C++ and Python. + + ::: ## Custom messages -The standard primitive and state message types are generally enough to cover the majority of messaging needs in -an AICA application. Having a reduced message definition set is important to maximizing the modularity and compatibility -of components. When components are connected by a signal in an application graph, the application interpreter will try -to assert that the signals have a matching type. +The set of basic and state signal types is generally enough to cover the majority of messaging needs in an AICA +application. Having a reduced message definition set is important to maximizing the modularity and compatibility +of components. -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 +corresponding to basic and state signals with the downside that any conversion from the data packet to a data object and +back is not automatic. :::tip -The AICA component library includes signal translator components for commonly used ROS messages (namely `std_msgs` -and `geometry_msgs`) for AICA components to communicate with traditional ROS nodes in an external process. +The AICA component library includes signal translator components for commonly used ROS messages, namely +`sensor_msgs/JointState`, `geometry_msgs/PoseStamped`, `geometry_msgs/TwistStamped` and `geometry_msgs/WrenchStamped`. ::: From eeddcb14f966395ca84599116b61c625aaa8d987 Mon Sep 17 00:00:00 2001 From: Dominic Reber Date: Fri, 20 Dec 2024 10:13:46 +0100 Subject: [PATCH 3/3] Revert "feat: remove clproto message type" This reverts commit 0e9e63cf1bc3a718472c00574163e87bda24c841. --- .../custom-components/02-custom-component.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/docs/docs/reference/custom-components/02-custom-component.md b/docs/docs/reference/custom-components/02-custom-component.md index f259deca..ea80627e 100644 --- a/docs/docs/reference/custom-components/02-custom-component.md +++ b/docs/docs/reference/custom-components/02-custom-component.md @@ -495,11 +495,19 @@ The following example adds two outputs: one as a floating point number and one a +:::note + +When using the `EncodedState` type for an output, the specific underlying state type must also be defined using the +`MessageType` enumeration in the `clproto` library. + +::: + ```python title="custom_component.py" from std_msgs.msg import Float64 from modulo_core.encoded_state import EncodedState +from clproto import MessageType from state_representation import CartesianPose ``` @@ -513,7 +521,9 @@ from state_representation import CartesianPose # bind the attribute to an output using the attribute name and message type self.add_output("number", "_output_number", Float64) - self.add_output("pose", "_output_pose", EncodedState) + + # for encoded states, further define the expected state type when binding the output + self.add_output("pose", "_output_pose", EncodedState, MessageType.CARTESIAN_POSE_MESSAGE) ```