forked from eclipse-zenoh/zenoh-plugin-ros1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
DEFAULT_CONFIG.json5
187 lines (166 loc) · 8.35 KB
/
DEFAULT_CONFIG.json5
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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
////
//// This file presents the default configuration used by `zenoh-plugin-ros1` plugin.
//// The "ros1" JSON5 object below can be used as such in the "plugins" part of a config file for the zenoh router (zenohd).
////
{
plugins: {
////
//// ROS1 bridge related configuration
//// All settings are optional and are unset by default - uncomment the ones you want to set
////
ros1: {
////
//// ros_master_uri: A URI of the ROS1 Master to connect to, the defailt is http://localhost:11311/
////
// ros_master_uri: "http://localhost:11311/",
////
//// ros_hostname: A hostname to send to ROS1 Master, the default is system's hostname
////
// ros_hostname: "hostname",
////
//// ros_name: A bridge node's name for ROS1, the default is "ros1_to_zenoh_bridge"
////
// ros_name: "ros1_to_zenoh_bridge",
////
//// with_rosmaster: An option wether the bridge should run it's own rosmaster process, the default is "false"
////
// with_rosmaster: "false",
////
//// subscriber_bridging_mode: Global subscriber's topic bridging mode. Accepted values:
//// - "auto"(default) - bridge topics once they are declared locally or discovered remotely
//// - "lazy_auto" - bridge topics once they are both declared locally and discovered remotely
//// - "disabled" - never bridge topics. This setting will also suppress the topic discovery."#
// subscriber_bridging_mode: "auto",
////
//// publisher_bridging_mode: Global publisher's topic bridging mode. Accepted values:
//// - "auto"(default) - bridge topics once they are declared locally or discovered remotely
//// - "lazy_auto" - bridge topics once they are both declared locally and discovered remotely
//// - "disabled" - never bridge topics. This setting will also suppress the topic discovery."#
// publisher_bridging_mode: "auto",
////
//// service_bridging_mode: Global service's topic bridging mode. Accepted values:
//// - "auto"(default) - bridge topics once they are declared locally or discovered remotely
//// - "lazy_auto" - bridge topics once they are both declared locally and discovered remotely
//// - "disabled" - never bridge topics. This setting will also suppress the topic discovery."#
// service_bridging_mode: "auto",
////
//// client_bridging_mode: Mode of client's topic bridging. Accepted values:
//// - "auto" - bridge topics once they are discovered remotely
//// - "disabled"(default) - never bridge topics. This setting will also suppress the topic discovery.
//// NOTE: there are some pecularities on how ROS1 handles clients:
//// - ROS1 doesn't provide any client discovery mechanism
//// - ROS1 doesn't allow multiple services on the same topic
//// Due to this, client's bridging works differently compared to pub\sub bridging:
//// - lazy bridging mode is not available as there is no way to discover local ROS1 clients
//// - client bridging is disabled by default, as it may brake the local ROS1 system if it intends to have client and service interacting on the same topic
//// In order to use client bridging, you have two options:
//// - globally select auto bridging mode (with caution!) with this option
//// - bridge specific topics using 'client_topic_custom_bridging_mode' option (with a little bit less caution!)"#
// client_bridging_mode: "disabled",
////
//// subscriber_topic_custom_bridging_mode: A JSON Map describing custom bridging modes for particular topics.
//// Custom bridging mode overrides the global one.
//// Format: {"topic1":"mode", "topic2":"mode"}
//// Example: {"/my/topic1":"lazy_auto","/my/topic2":"auto"}
//// where
//// - topic: ROS1 topic name
//// - mode (auto/lazy_auto/disabled) as described above
//// The default is empty
// subscriber_topic_custom_bridging_mode: ""
////
//// publisher_topic_custom_bridging_mode: A JSON Map describing custom bridging modes for particular topics.
//// Custom bridging mode overrides the global one.
//// Format: {"topic1":"mode", "topic2":"mode"}
//// Example: {"/my/topic1":"lazy_auto","/my/topic2":"auto"}
//// where
//// - topic: ROS1 topic name
//// - mode (auto/lazy_auto/disabled) as described above
//// The default is empty
// publisher_topic_custom_bridging_mode: ""
////
//// service_topic_custom_bridging_mode: A JSON Map describing custom bridging modes for particular topics.
//// Custom bridging mode overrides the global one.
//// Format: {"topic1":"mode", "topic2":"mode"}
//// Example: {"/my/topic1":"lazy_auto","/my/topic2":"auto"}
//// where
//// - topic: ROS1 topic name
//// - mode (auto/lazy_auto/disabled) as described above
//// The default is empty
// service_topic_custom_bridging_mode: ""
////
//// client_topic_custom_bridging_mode: A JSON Map describing custom bridging modes for particular topics.
//// Custom bridging mode overrides the global one.
//// Format: {"topic1":"mode", "topic2":"mode"}
//// Example: {"/my/topic1":"auto","/my/topic2":"auto"}
//// where
//// - topic: ROS1 topic name
//// - mode (auto/disabled) as described above
//// The default is empty
// client_topic_custom_bridging_mode: ""
////
//// ros_master_polling_interval: An interval how to poll the ROS1 master for status
//// Bridge polls ROS1 master to get information on local topics, as this is the only way to keep
//// this info updated. This is the interval of this polling. The default is "100ms"
////
//// Takes a string such as 100ms, 2s, 5m
//// The string format is [0-9]+(ns|us|ms|[smhdwy])
////
// ros_master_polling_interval: "100ms",
////
//// This plugin uses Tokio (https://tokio.rs/) for asynchronous programming.
//// When running as a plugin within a Zenoh router, the plugin creates its own Runtime managing 2 pools of threads:
//// - worker threads for non-blocking tasks. Those threads are spawn at Runtime creation.
//// - blocking threads for blocking tasks (e.g. I/O). Those threads are spawn when needed.
//// For more details see https://github.com/tokio-rs/tokio/discussions/3858#discussioncomment-869878
//// When running as a standalone bridge the Zenoh Session's Runtime is used and can be configured via the
//// `ZENOH_RUNTIME` environment variable. See https://docs.rs/zenoh-runtime/latest/zenoh_runtime/enum.ZRuntime.html
////
//// work_thread_num: The number of worker thread in the asynchronous runtime will use. (default: 2)
//// Only for a plugin, no effect on a bridge.
// work_thread_num: 2,
//// max_block_thread_num: The number of blocking thread in the asynchronous runtime will use. (default: 50)
//// Only for a plugin, no effect on a bridge.
// max_block_thread_num: 50,
},
////
//// REST API configuration (active only if this part is defined)
////
// rest: {
// ////
// //// The HTTP port number (for all network interfaces).
// //// You can bind on a specific interface setting a "<local_ip>:<port>" string.
// ////
// http_port: 8000,
// },
},
////
//// zenoh related configuration (see zenoh documentation for more details)
////
////
//// id: The identifier (as hex-string) that zenoh-bridge-ros1 must use. If not set, a random UUIDv4 will be used.
//// WARNING: this id must be unique in your zenoh network.
// id: "A00001",
////
//// mode: The bridge's mode (peer or client)
////
//mode: "client",
////
//// Which endpoints to connect to. E.g. tcp/localhost:7447.
//// By configuring the endpoints, it is possible to tell zenoh which router/peer to connect to at startup.
////
connect: {
endpoints: [
// "<proto>/<ip>:<port>"
]
},
////
//// Which endpoints to listen on. E.g. tcp/localhost:7447.
//// By configuring the endpoints, it is possible to tell zenoh which are the endpoints that other routers,
//// peers, or client can use to establish a zenoh session.
////
listen: {
endpoints: [
// "<proto>/<ip>:<port>"
]
},
}