|
20 | 20 | // ros_hostname: "hostname",
|
21 | 21 |
|
22 | 22 | ////
|
23 |
| - //// ros_name: A bridge node's name for ROS1, the default is "ros1_to_zenoh_bridge" |
| 23 | + //// ros_name: A bridge node's name for ROS1, the default is "ros1_to_zenoh_bridge" |
24 | 24 | ////
|
25 | 25 | // ros_name: "ros1_to_zenoh_bridge",
|
26 | 26 |
|
27 | 27 | ////
|
28 |
| - //// with_rosmaster: An option wether the bridge should run it's own rosmaster process, the default is "false" |
| 28 | + //// bridge_namespace: A bridge's namespace in terms of zenoh keys, the default is "*", the wildcard namespace. |
| 29 | + //// The generated zenoh keys will be in the form of {data_type}/{md5}/{bridge_namespace}/{topic}. |
| 30 | + //// |
| 31 | + // bridge_namespace: "*", |
| 32 | + |
| 33 | + //// |
| 34 | + //// with_rosmaster: An option wether the bridge should run it's own rosmaster process, the default is "false" |
29 | 35 | ////
|
30 | 36 | // with_rosmaster: "false",
|
31 | 37 |
|
|
59 | 65 | //// - ROS1 doesn't allow multiple services on the same topic
|
60 | 66 | //// Due to this, client's bridging works differently compared to pub\sub bridging:
|
61 | 67 | //// - lazy bridging mode is not available as there is no way to discover local ROS1 clients
|
62 |
| - //// - 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 |
| 68 | + //// - client bridging is disabled by default, as it may break the local ROS1 system if it intends to have client and service interacting on the same topic |
63 | 69 | //// In order to use client bridging, you have two options:
|
64 | 70 | //// - globally select auto bridging mode (with caution!) with this option
|
65 | 71 | //// - bridge specific topics using 'client_topic_custom_bridging_mode' option (with a little bit less caution!)"#
|
66 | 72 | // client_bridging_mode: "disabled",
|
67 | 73 |
|
68 |
| - //// |
| 74 | + //// |
69 | 75 | //// subscriber_topic_custom_bridging_mode: A JSON Map describing custom bridging modes for particular topics.
|
70 | 76 | //// Custom bridging mode overrides the global one.
|
71 | 77 | //// Format: {"topic1":"mode", "topic2":"mode"}
|
|
76 | 82 | //// The default is empty
|
77 | 83 | // subscriber_topic_custom_bridging_mode: ""
|
78 | 84 |
|
79 |
| - //// |
| 85 | + //// |
80 | 86 | //// publisher_topic_custom_bridging_mode: A JSON Map describing custom bridging modes for particular topics.
|
81 | 87 | //// Custom bridging mode overrides the global one.
|
82 | 88 | //// Format: {"topic1":"mode", "topic2":"mode"}
|
|
87 | 93 | //// The default is empty
|
88 | 94 | // publisher_topic_custom_bridging_mode: ""
|
89 | 95 |
|
90 |
| - //// |
| 96 | + //// |
91 | 97 | //// service_topic_custom_bridging_mode: A JSON Map describing custom bridging modes for particular topics.
|
92 | 98 | //// Custom bridging mode overrides the global one.
|
93 | 99 | //// Format: {"topic1":"mode", "topic2":"mode"}
|
|
98 | 104 | //// The default is empty
|
99 | 105 | // service_topic_custom_bridging_mode: ""
|
100 | 106 |
|
101 |
| - //// |
| 107 | + //// |
102 | 108 | //// client_topic_custom_bridging_mode: A JSON Map describing custom bridging modes for particular topics.
|
103 | 109 | //// Custom bridging mode overrides the global one.
|
104 | 110 | //// Format: {"topic1":"mode", "topic2":"mode"}
|
|
120 | 126 | // ros_master_polling_interval: "100ms",
|
121 | 127 |
|
122 | 128 | ////
|
123 |
| - //// This plugin uses Tokio (https://tokio.rs/) for asynchronous programming. |
| 129 | + //// This plugin uses Tokio (https://tokio.rs/) for asynchronous programming. |
124 | 130 | //// When running as a plugin within a Zenoh router, the plugin creates its own Runtime managing 2 pools of threads:
|
125 | 131 | //// - worker threads for non-blocking tasks. Those threads are spawn at Runtime creation.
|
126 | 132 | //// - blocking threads for blocking tasks (e.g. I/O). Those threads are spawn when needed.
|
127 | 133 | //// For more details see https://github.com/tokio-rs/tokio/discussions/3858#discussioncomment-869878
|
128 | 134 | //// When running as a standalone bridge the Zenoh Session's Runtime is used and can be configured via the
|
129 | 135 | //// `ZENOH_RUNTIME` environment variable. See https://docs.rs/zenoh-runtime/latest/zenoh_runtime/enum.ZRuntime.html
|
130 | 136 | ////
|
131 |
| - |
| 137 | + |
132 | 138 | //// work_thread_num: The number of worker thread in the asynchronous runtime will use. (default: 2)
|
133 | 139 | //// Only for a plugin, no effect on a bridge.
|
134 | 140 | // work_thread_num: 2,
|
135 |
| - |
| 141 | + |
136 | 142 | //// max_block_thread_num: The number of blocking thread in the asynchronous runtime will use. (default: 50)
|
137 | 143 | //// Only for a plugin, no effect on a bridge.
|
138 | 144 | // max_block_thread_num: 50,
|
|
176 | 182 |
|
177 | 183 | ////
|
178 | 184 | //// Which endpoints to listen on. E.g. tcp/localhost:7447.
|
179 |
| - //// By configuring the endpoints, it is possible to tell zenoh which are the endpoints that other routers, |
| 185 | + //// By configuring the endpoints, it is possible to tell zenoh which are the endpoints that other routers, |
180 | 186 | //// peers, or client can use to establish a zenoh session.
|
181 | 187 | ////
|
182 | 188 | listen: {
|
|
0 commit comments