blob: 17d36994e4e9750d5a37074f009defc5b87ef827 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
<!--//$Id$ -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>DDS4CCM Tutorial Shapes - General</title>
</head>
<body>
<table width="100%" border="0">
<tr>
<td align="left"></td>
<td align="center"><img width="4%" height="5%" src="./images/images.png"/></td>
<td align="right"><a href="./idl.html">Next</a></td>
</tr>
</table>
<hr />
<h1>General</h1>
<p>
This tutorial explains how to use a DDS4CCM connector in
combination with a CCM component.<br/>
</p>
<h2>System</h2>
<p>
The system consists of three components:
<ul>
<li>A sender component</li>
<li>A receiver component</li>
<li>A controller component</li>
</ul>
In this tutorial RTI DDS is used to transfer data from the sender to the receiver.
Therefor both the sender and receiver are using a DDS4CCM connector.<br/>
The data consists of a struct with the following members:
<ul>
<li>color : represents the color of the shape.</li>
<li>x : represents the location on the x-axis.</li>
<li>y : represents the location on the y-axis</li>
<li>shapesize : represents the size of the shape.</li>
</ul>
The controller controls the location and size of the registered shape.<br/>
The only thing the sender does is registering a shape with DDS and transferring
the data received from the controller to DDS.<br/>
The receiver listens to DDS and receives the updates regarding the shapes data.
</p>
<img width="60%" height="40%" src="./images/system.png" />
<p><i><b>to-be-replaced</b></i></p>
<p>
This tutorial runs in conjuntion with the RTI shapes demo
(see <a href="./rti_shapes.html">this page<a/> how to run the
RTI shapes demo).
</p>
<h2>Directory structure</h2>
<p>
The following convention is used:
<ul>
<li>|--<b>*_asm</b>
: Directory contains an assembly.
</li>
<li> |--<b>ports</b>
: Directory contains common IDL code for the assembly.
</li>
<li> |--<b>*_comp</b>
: Directory contains an component.
</li>
<li> |--
<b>ports</b>
: Directory contains common IDL code for the component.
</li>
<li> |--
<b>src</b>
: Directory contains the IDL and *_exec-files for the component.
</li>
</ul>
</p>
<h2>File naming convention</h2>
<p>
The following convention is used:
<ul>
<li><b>*_defn.idl</b> - These files will contain definitions,
like enumerations, constants and so on<br/>
Typically located in *_asm/ports.
</li>
<li><b>*_msg.idl</b> - These files will contain the messages (data structure)
send by DDS.<br/>
Typically located in *_asm/ports.
</li>
<li><b>*_conn.idl</b> - These files will contain the connector
declarations.<br/>
Typically located in *_asm/ports.
</li>
<li><b>*_obj.idl</b> - These files will contain the interfaces between
components.<br/>
Typically located in *_asm/*_comp/ports.
</li>
<li><b>*_comp.idl</b> - These files will contain the component declaration.<br/>
Typically located in *_asm/*_comp/src.
</li>
</ul>
</p>
<h2>Additional conventions</h2>
<p>
<ul>
<li>MPC files are located in the same directory as the IDL and executor
files.
</li>
<li>Files that were generated by the TOA IDL compiler or the RTI DDS gen
compiler should be located in a subdirectory. In this tutorial the name
of this subdirectory is "GeneratedCode".
</li>
</u>
</p>
<hr />
<table width="100%" border="0">
<tr>
<td align="left"></td>
<td align="center"><img width="4%" height="5%" src="./images/images.png"/></td>
<td align="right"><a href="./idl.html">Next</a></td>
</tr>
</table>
</body>
|
