|
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