You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main purpose of this effort is to combine the advantages of [ROS](http://wiki.ros.org/) and Model-Driven-Engineering techniques. This repository holds a family of metamodels defined as Ecore models and their corresponding Xtext-based DSLs (Domain Specific Language) implementation.
5
+
The main purpose of this effort is to combine the advantages of [ROS](http://wiki.ros.org/) and Model-Driven-Engineering techniques. This repository holds a family of metamodels defined as Ecore models and their corresponding Xtext-based DSLs (Domain Specific Language) implementation.
6
6
The resulted models allow the description of ROS and ROS2 concepts and properties, like packages, artifacts, nodes, interfaces types, parameters... Moreover a complete system as composition of ROS components can be also modelled.
7
7
8
8
The models have associated tools, the following are some examples:
@@ -58,7 +58,7 @@ Publications:
58
58
- Combine components to form a ROS System
59
59
- [Create manually a new RosSystem description](docu/RosSystemModelDescription.md)
60
60
- [Visualize a system using PlantUML](docu/PlantUML.md)
Copy file name to clipboardExpand all lines: docu/Example_PubSub.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Tutorial: How to create a simple Publisher-Subscriber example.
2
2
3
-
In this tutorial we just want to show how the models can be used to define ROS nodes.
3
+
In this tutorial we just want to show how the models can be used to define ROS nodes.
4
4
For this we will see how two simple nodes can be defined, one that acts as a publisher of a "Hello World!" message and another that receives it as a subscriber.
5
5
6
6
This tutorial is fictitious, it is not based on any existing ROS node. The ROS example is reflected in the models of the example [pub_sub_ros2](https://github.com/ipa-nhg/ros-model-examples/tree/main/pub_sub_ros2).
@@ -24,7 +24,7 @@ publisher_package:
24
24
25
25
```
26
26
27
-
Then we need the artifact, a runnable to execute the node. As every YAML format file we have to add identantion to the secon line. Then pressing the keys "Ctrl"+Space bar the menu will suggest us as an option the text "artifacts:". We select it and go to the next line.
27
+
Then we need the artifact, a runnable to execute the node. As every YAML format file we have to add identantion to the secon line. Then pressing the keys "Ctrl"+Space bar the menu will suggest us as an option the text "artifacts:". We select it and go to the next line.
28
28
29
29
In the third line we must add a douple identation, we will create an object under artifacts. The next object will be a name for the artifact, for example "pub_artifact":
30
30
@@ -42,7 +42,7 @@ publisher:
42
42
pub_artifact:
43
43
node: pub_node
44
44
```
45
-
Now that we have the node, we can define the interfaces that offers this node as inputs and output to connect to it. In our case we want to create a publisher, which the type **String** .
45
+
Now that we have the node, we can define the interfaces that offers this node as inputs and output to connect to it. In our case we want to create a publisher, which the type **String** .
46
46
47
47
48
48
@@ -79,7 +79,7 @@ Now that we have already the components we can compose them. For that we have to
79
79
80
80
In [RosSystem description](RosSystemModelDescription.md) we explain the format of a system and the editor will support you to write the model properly.
81
81
82
-
The first that must be given is a name and then a ":" is required. In the next line you must add identation and you can press the keys "Ctrl" + Space bar for help.
82
+
The first that must be given is a name and then a ":" is required. In the next line you must add identation and you can press the keys "Ctrl" + Space bar for help.
83
83
Then we will define the nodes that compose the system. Here under "from" we will link our previously created nodes, the grammar for the references is **PackageName.NodeName**.
84
84
85
85
@@ -131,4 +131,4 @@ my_system:
131
131
-[ HelloWorldPublisher, HelloWorldSubscriber]
132
132
```
133
133
134
-
With this very basic example we hope you have understood how the models can be used and what kind of attributes they allow to represent.
134
+
With this very basic example we hope you have understood how the models can be used and what kind of attributes they allow to represent.
Copy file name to clipboardExpand all lines: docu/Example_Turtlesim.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -62,7 +62,7 @@ Now that we have already the components we can compose them. For that we have to
62
62
63
63
In [RosSystem description](RosSystemModelDescription.md) we explain the format of a system and the editor will support you to write the model properly.
64
64
65
-
The first that must be given is a name and then a ":" is required. In the next line you must add identation and you can press the keys "Ctrl" + Space bar for help.
65
+
The first that must be given is a name and then a ":" is required. In the next line you must add identation and you can press the keys "Ctrl" + Space bar for help.
66
66
Firstly, we will add the 2 nodes that compose our system.
Copy file name to clipboardExpand all lines: docu/ParametersAPI.md
+6-7Lines changed: 6 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,15 +3,15 @@
3
3
The types of parameters supported by the ROS tooling are the following:
4
4
5
5
* Boolean (true or false)
6
-
* Integer
6
+
* Integer
7
7
* Double
8
8
* String
9
9
* Base64
10
-
* List
10
+
* List
11
11
* Array
12
12
* Struct
13
13
14
-
and their description is allowed at ROS and ROSSystem model level.
14
+
and their description is allowed at ROS and ROSSystem model level.
15
15
16
16
For the complete definition of parameters the user has to open the ROS model editor, where the language format is the following:
17
17
```
@@ -25,9 +25,9 @@ For example (for a .ros2 file):
25
25
26
26
```
27
27
test_parameters:
28
-
artifacts:
28
+
artifacts:
29
29
test_parameters:
30
-
node: params_example
30
+
node: params_example
31
31
parameters:
32
32
string_test:
33
33
type: String
@@ -78,8 +78,7 @@ test:
78
78
value: ["hello", "hola", "hallo"]
79
79
- test_st: "test_parameters::struct_test"
80
80
value: [
81
-
hello: 1
81
+
hello: 1
82
82
what: "test"]
83
83
```
84
84
The model definition of parameters is also consider for the autogeneration of launch files and the component interfaces. Complementarily, and because of the complexity of the format, the .ros, the .componentinterface and the .rossystem language validators contain rules to check that the value given to the parameter has the correct type and also help messages that together with the auto-complete function (Ctrl+Space) facilitate to the user the creation of parameters.
Copy file name to clipboardExpand all lines: docu/RosModelDescription.md
+23-23Lines changed: 23 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,22 +14,22 @@ my_awesome_pkg: #Name of the package
14
14
**artifacts:**
15
15
awesome: # Name of the artifact (as it is named in the CMakeLists)
16
16
**node:** awesome_node # Name of the node
17
-
**publishers:** # (Optional) List of publishers
17
+
**publishers:** # (Optional) List of publishers
18
18
awesome_pub:
19
19
**type:** "std_msgs/msg/Bool"
20
-
**subscribers:** # (Optional) List of subscribers
20
+
**subscribers:** # (Optional) List of subscribers
21
21
awesome_sub:
22
22
**type:** "std_msgs/msg/Bool"
23
-
**serviceclients:** # (Optional) List of service clients
23
+
**serviceclients:** # (Optional) List of service clients
24
24
awesome_client:
25
25
**type:** "std_srvs/srv/Empty"
26
-
**serviceservers:** # (Optional) List of service servers
26
+
**serviceservers:** # (Optional) List of service servers
27
27
awesome_server:
28
28
**type:** "std_srvs/srv/Empty"
29
-
**actionclients:** # (Optional) List of action clients
29
+
**actionclients:** # (Optional) List of action clients
30
30
awesome_action:
31
31
**type:** "control_msgs/action/JointTrajectory"
32
-
**actionservers:** # (Optional) List of action servers
32
+
**actionservers:** # (Optional) List of action servers
33
33
awesome_action:
34
34
**type:** "control_msgs/action/JointTrajectory"
35
35
**parameters:** # (Optional) List of parameters
@@ -39,7 +39,7 @@ my_awesome_pkg: #Name of the package
39
39
```
40
40
41
41
42
-
The format is based the YAML file format. All the words marked in the template with '**' are keywords that compose the model, they can't be modified.
42
+
The format is based the YAML file format. All the words marked in the template with '**' are keywords that compose the model, they can't be modified.
43
43
44
44
45
45
See the following model exmaple for the known teleop ROS package:
@@ -54,7 +54,7 @@ teleop:
54
54
type: "geometry_msgs/msg/Twist"
55
55
subscribers:
56
56
joy:
57
-
type:"sensor_msgs/msg/Joy"
57
+
type:"sensor_msgs/msg/Joy"
58
58
```
59
59
60
60
## ROS 2
@@ -69,67 +69,67 @@ my_awesome_pkg:
69
69
**publishers:**
70
70
awesome_pub:
71
71
**type:** "std_msgs/msg/Bool"
72
-
**qos:**
72
+
**qos:**
73
73
**depth:** 10
74
74
**durability:** volatile
75
75
**history:** keep_all
76
76
**profile:** default_qos
77
-
**reliability:** best_effort
77
+
**reliability:** best_effort
78
78
**subscribers:**
79
79
awesome_sub:
80
80
**type:** "std_msgs/msg/Bool"
81
-
**qos:**
81
+
**qos:**
82
82
**depth:** 10
83
83
**durability:** transient_local
84
84
**history:** keep_last
85
85
**profile:** sensor_qos
86
-
**reliability:** reliable
86
+
**reliability:** reliable
87
87
**serviceclients:**
88
88
awesome_client:
89
89
**type:** "std_srvs/srv/Empty"
90
-
**qos:**
90
+
**qos:**
91
91
**depth:** 10
92
92
**durability:** volatile
93
93
**history:** keep_all
94
94
**profile:** services_qos
95
-
**reliability:** best_effort
95
+
**reliability:** best_effort
96
96
**serviceservers:**
97
97
awesome_server:
98
98
**type:** "std_srvs/srv/Empty"
99
-
**qos:**
99
+
**qos:**
100
100
**depth:** 10
101
101
**durability:** volatile
102
102
**history:** keep_all
103
103
**profile:** services_qos
104
-
**reliability:** best_effort
104
+
**reliability:** best_effort
105
105
**actionclients:**
106
106
awesome_action:
107
107
**type:** "control_msgs/action/JointTrajectory"
108
-
**qos:**
108
+
**qos:**
109
109
**depth:** 10
110
110
**durability:** volatile
111
111
**history:** keep_all
112
112
**profile:** default_qos
113
-
**reliability:** best_effort
113
+
**reliability:** best_effort
114
114
**actionservers:**
115
115
awesome_action:
116
116
**type:** "control_msgs/action/JointTrajectory"
117
-
**qos:**
117
+
**qos:**
118
118
**depth:** 10
119
119
**durability:** volatile
120
120
**history:** keep_all
121
121
**profile:** default_qos
122
-
**reliability:** best_effort
122
+
**reliability:** best_effort
123
123
**parameters:**
124
124
awesome_param:
125
125
**type:** String
126
126
**default:** "Hello"
127
-
**qos:**
127
+
**qos:**
128
128
**depth:** 10
129
129
**durability:** volatile
130
130
**history:** keep_all
131
131
**profile:** parameter_qos
132
-
**reliability:** best_effort
132
+
**reliability:** best_effort
133
133
```
134
134
135
135
The only remarkable difference with the ROS 1 model is that the quality of service can be defined for all the different interfaces. The quality of service atrributes are optional and they allow the following options:
@@ -141,7 +141,7 @@ The only remarkable difference with the ROS 1 model is that the quality of servi
Copy file name to clipboardExpand all lines: docu/RosSystemModelDescription.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,7 +39,7 @@ Below we analyze each part that makes up the system and how it is formed:
39
39
- from: reference to the instantiated node description. It is given by the name of the package that contains it and the name of the original node.
40
40
- interfaces: list of all the interfaces of the node. Here it is not mandatory to list of the interfaces (again) as they are already on the .ros2 file. Only the renamed interfaces must be added, as well as, interfaces that will form a connection with other components. A referenced interface is given by: **NewName: Type -> ref_artifact_name::ref_interface_name** where `ref_artifact_name` and `ref_artifact_name` come from the ros2 file. And the Type can be pub, sub, sc, ss, ac, or as.
41
41
- parameters: it is used to pass a value to a parameter. Every parameter shall have a name (my_param) in the example, and the reference to an existing parameter, given by 'artifact_name::param_name' frpm a .ros2 file. Then under value, a new value can be given to the parameter.
42
-
42
+
43
43
- (Optional) Connections: describe the connections between the nodes. They are given by `[name_of_the_output, name_of_the_input]` the outputs and inputs musst be previously created, they musst have the same communication pattern (topic, service or action) and the same type of communication object (for example std_msgs/String). Otherwise, the validator will give an error.
44
44
45
45
The Editor of the models contains validators and the auto-complete function, which can be called with the combination of the keys `Ctrl` and space bar.
0 commit comments