Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Mughal Ahmed
    @greenmughal_gitlab
    @pgeiem_gitlab if zenoh team adds os level channels or pipes, it would be much better.
    kydos
    @kydos
    @greenmughal_gitlab, the usual way is to compute a round-trip and then divide by two. The latency and throughput tests that we use for zenoh are included as part of the distro, look for zn_ping/pong and zn_pub/sub_thr in https://github.com/eclipse-zenoh/zenoh/tree/master/zenoh/examples/zenoh-net
    @pgeiem_gitlab zenoh has location transparency thus the fact that processes are running on the same computer is just a special case. The advantage of using zenoh, is that if at some later point you need to distribute some of those processes your application logic will remain unchanged. Additionally, with zenoh you can easily have multiple service instance and automatically load-balance across them.
    Mughal Ahmed
    @greenmughal_gitlab
    Thank you @kydos
    ryan
    @ryan:matrix.hagen.tech
    [m]
    I have quic setup on my routers and clients, it seems to be working fine, except for some malformed packets on the quic handshakes.
    ryan
    @ryan:matrix.hagen.tech
    [m]
    when will zenoh-pico support quic?
    1 reply
    Geoff
    @geoff_or:matrix.org
    [m]
    @JEnoch: Is there a specification document of the protocol available? Even a draft would be fine.
    2 replies
    Geoff
    @geoff_or:matrix.org
    [m]
    At the moment my primary area of interest is "how does discovery work?"
    kydos
    @kydos
    @geoff_or:matrix.org, we could cover that in a blog. But in short, for what concerns topology, zenoh has a pluggable scouting protocol that is used to find out if there are any zenoh endpoints arounds. The way in which scouting is performed depends on the network are running on.For instance on an IP network a scouting mechanism leverages multicast, another DNS. Once a zenoh runtime has found an “entry” point into the zenoh network, then a link-state algorighm is used to discover the topology and be able to route data over a mesh — if necessary.
    For what concerns subscribers and queryable discovery, zenoh forwards over the discovered topology advertisement of key expressions. Notice that these may be generalised whenever possible to save bandwidht and overall state. The general idea we use, is that we give enough indications to know which way to data should go.
    As an example, if downstream a node has subscribers for /a/b/one, /a/b/two, …, zenoh may decide to adversise a single subscriber for /a/b/* upstream. This is what we call key expression generalisation and one of the reasonos why we can really drop discovery traffic as we had shown in this blog
    Geoff
    @geoff_or:matrix.org
    [m]
    @kydos: Thanks for the info! If your team has time to write up a more detailed blog post I'd love to read it
    kydos
    @kydos
    We usually do a blog post every two weeks, we’ll definitively add this to the list if not for the next for the one right after!
    Walter E. Gunter, Jr.
    @wegunterjr
    Zenoh router and the dds bridge are awesome!!!! love the --fwd-discovery
    2 replies
    Julien Enoch
    @JEnoch
    Great to start the morning with such feedback! Thanks!! :smile:
    Ahmed Ali Adeel
    @maxmughal7_twitter

    Compiling zenoh v0.5.0-beta.8 error[E0554]:#![feature]` may not be used on the stable release channel
    --> C:\Users\97433.cargo\registry\src\github.com-1ecc6299db9ec823\zenoh-0.5.0-beta.8\src\lib.rs:84:1
    |
    84 | #![feature(async_closure)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^

    error[E0554]: #![feature] may not be used on the stable release channel
    --> C:\Users\97433.cargo\registry\src\github.com-1ecc6299db9ec823\zenoh-0.5.0-beta.8\src\lib.rs:85:1
    |
    85 | #![feature(get_mut_unchecked)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    error[E0554]: #![feature] may not be used on the stable release channel
    --> C:\Users\97433.cargo\registry\src\github.com-1ecc6299db9ec823\zenoh-0.5.0-beta.8\src\lib.rs:86:1
    |
    86 | #![feature(map_into_keys_values)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    error[E0554]: #![feature] may not be used on the stable release channel
    --> C:\Users\97433.cargo\registry\src\github.com-1ecc6299db9ec823\zenoh-0.5.0-beta.8\src\lib.rs:87:1
    |
    87 | #![feature(can_vector)]
    | ^^^^^^^^^^^^^^^^^^^^^^^`

    That means I must install nightly? or there is another way?
    Julien Enoch
    @JEnoch
    Hi @maxmughal7_twitter ,
    Which version of Rust are you using (rustc --version) ?
    Ahmed Ali Adeel
    @maxmughal7_twitter
    Hi, its rustc 1.56.1 (59eed8a2a 2021-11-01)
    Meanwhile I try to rebuild the project...
    cargo update cargo clean cargo run
    Julien Enoch
    @JEnoch
    I had a look, and I confirme those features requires a nightly toolchain.
    In master branch we removed the use of those features, thus it can be built with stable. But you’ll also need to use the zenoh router (zenohd) from master branch (and master branch for Python or C API as well, if required).
    15 replies
    Ahmed Ali Adeel
    @maxmughal7_twitter
    1 reply
    Andreas Lööw
    @icucode
    How do you debug the zenoh-bridge-dds? I have two nodes up and running but can't see any participant in the rest api?
    Julien Enoch
    @JEnoch

    Hi @icucode ,
    You can activate the logs setting the environment variable RUST_LOG=debug (or RUST_LOG=zp=debug to filter only the logs related to DDS).
    You should see a log for each discovered DDS Publication and Subscription. The first 2 discovered are usually the ones from the bridge’s Participant itself and are ignored as you can see on this log:

    [2021-11-18T16:14:39Z DEBUG zplugin_dds::dds_mgt] Discovered DDS subscription dd6410010c0e6c09e28478c500000107 from Participant dd6410010c0e6c09e28478c5000001c1 on DCPSPublication with type org::eclipse::cyclonedds::builtin::DCPSPublication (keyless: false)
    [2021-11-18T16:14:39Z DEBUG zplugin_dds::dds_mgt] Ignoring discovery of dd6410010c0e6c09e28478c500000107 (DCPSPublication) from local participant
    [2021-11-18T16:14:39Z DEBUG zplugin_dds::dds_mgt] Discovered DDS subscription dd6410010c0e6c09e28478c500000207 from Participant dd6410010c0e6c09e28478c5000001c1 on DCPSSubscription with type org::eclipse::cyclonedds::builtin::DCPSSubscription (keyless: false)
    [2021-11-18T16:14:39Z DEBUG zplugin_dds::dds_mgt] Ignoring discovery of dd6410010c0e6c09e28478c500000207 (DCPSSubscription) from local participant

    But after those, you should see other discoveries. Otherwise, it probably means you have a DDS communication issue between the bridge and your DDS apps (or ROS2 nodes).
    2 possible causes:

    • different domain ids are used. Check your DDS configuration or any ROS_DOMAIN_ID environment variable that might be set. You can must set the same domain for the bridge using its -d option.
    • UDP multicast communication issue. That’s the trickiest one… We would need some details on your network setup to understand what could goes wrong.
    10 replies
    Andreas Lööw
    @icucode
    Is it a strict requirement that nodes using the zenoh protocol needs to be in perfect time sync (less than 100 ms)?
    2 replies
    Ahmed Ali Adeel
    @maxmughal7_twitter
    Hi, are these by design?
    1. zenoh::net::Subscriber<'a> has a life time param? How can I avoid/encapsulate it (pointers maybe)?
    2. The session has a clone fn but its private
      I am struggling with unable to clone and integrating life time stuff with bevy ecs? is there a better way?
    2 replies
    Mayur Khimesra
    @mkhimesra_gitlab
    Hi,
    I am integrating with a robot using the zenoh dds plugin, and trying to get mission status via a subscription to the corresponding topic. For certain missions, the data received over SSE is always truncated and hence cannot be decoded. Also, the truncated value field in such cases is not base64 encoded. I am using an html page (modified version of ros2-teleop.html posted by @JEnoch on github) to subscribe to the topic, the screenshot of which (depicting a couple of subscription responses) is as below:
    Subscription responses.PNG
    Looking into the zenoh dds plugin logs (using Z_LOG_PAYLOAD=true, RUST_LOG=trace), it looks like the messages received from DDS are not truncated (len: 2452). I don't see any warn or error logs.
    image.png
    The topic monitor in rqt shows complete topic data.
    Any suggestions how we can fix this issue? Are there any message size limits that could be potentially causing a problem here? Thanks in advance.
    2 replies
    kydos
    @kydos
    Dear Zenohers as some of you know, we have been working for some time toward unifying the zenoh-net and zenoh. In the process of doing this we’ve leveraged builders to ensure that we’ll be able to extend the API w/o breaking backward compatibility. The good news is that the merge is complete and available at https://github.com/eclipse-zenoh/zenoh/tree/apis-merge
    We plan merging the unified API on master the week of the 29th of November. That gives you one week to take a look at give the final feedback / comments before we merge. Before merging we will be making a zenoh release so those of you working out of master will be able to migrate at their pace.
    That said, the migration to the new API should be relatively straight-foward and in general the benefits will outweight the small effort required to port.
    Don’t hesitate to reach out for any questions or comment. That said, I wish all of you a great weekend and for those of you that are based in North America a Happy Thanksgiving.
    Ahmed Ali Adeel
    @maxmughal7_twitter
    @kydos Hi, please in the new API don't put life time parameters on key objects like Session, Subscriber, SubscriberCallback etc, otherwise its very hard to mix it in other contexts, I guess from 1st glance that you might be already using Mutex/Arc to manage memory, I hope its true for most api.
    kydos
    @kydos
    @maxmughal7_twitter the reason why we use lifetimes is that we want to avoid by construction that a session could be closed while there are still entities hanging around. Lifetime allows to impose the proper life-cycle by construction — which is an advantage.
    We have integrated zenoh in various context, can you give some context on the issues that you had.
    Mughal Ahmed
    @greenmughal_gitlab
    Im trying to use it with bevy entity component system. As per their discord channel it is not designed to handle structs with lifetimes. Can you confirm the new api isnt like this?
    kydos
    @kydos
    I see, we where briefly discussing about Bevy today. @OlivierHecart any comments on that? In any case point taken we’ll discuss further with the rest of the team on monday.
    4 replies
    robruh
    @robruh

    Hi,
    I have a problem with the ros2 and zenoh-bridge example from https://zenoh.io/blog/2021-04-28-ros2-integration/#show-me-some-code.

    When I start turtlesim_node and zenoh-bridge and want to run ros2-turtleop.py, I get a warning from zenoh-bridge: [zenoh::net::runtime::orchestrator] Unable to connect to scouted [pid from ros2-turtleop.py]

    Any suggestions how I can fix this? Thanks in advance.

    2 replies
    Julian Oes
    @julianoes
    Good morning, I'm learning about zenoh, reading the docs and starting to play with the examples. (All is very welcoming, I'm impressed...).
    I tried the the zenoh-c net examples, as well as the Python net examples, because that's what I'm most familiar with. C pub to C sub worked, and Python pub to Python sub worked, but mixing the two did not. I'm probably missing something obvious? Like the correct config (port, transport)?
    I built the C library myself, and I installed the Python package using pip3 install --user eclipse-zenoh.
    3 replies
    Julian Oes
    @julianoes

    I'm considering to use zenoh over wifi links that can be good, bad, potentially cutting in and out. The requirements are:

    • A "telemetry" publications where drops do not matter, important is that samples arriving are recent/low latency
    • B "meta protocols" which require reliability such as commands with acks

    Now I have some questions:

    1. From what I understand with zenoh I could use pub/sub for A and then get/eval for B, right?

    2. Now I'm wondering how pub/sub with reliability set to best effort would work under the hood? Does it still try to do re-transmissions and potientally clog up the link and lead to bigger latency, or will it just do simple UDP and not bother about drops?

    3. I assume I would configure the peers to use UDP and not TCP, right? And if so, where is that option set? Is it what you set in the locator param? This was not quite clear to me from my reading so far.

    5 replies
    sihekuang
    @sihekuang:matrix.org
    [m]
    hi, I am trying to see if Zenoh offers client side load balancing like illustrated here https://www.hivemq.com/blog/mqtt-client-load-balancing-with-shared-subscriptions/
    I understand there's something called reliability mode, but i don't think it is the same as client side load balancing right? Is there's any advantage of the reliability mode over the client side load balance? https://zenoh.io/blog/2021-06-14-zenoh-reliability/
    1 reply
    Ahmed Ali Adeel
    @maxmughal7_twitter
    I am attaching WIP video of zenoh in action shooter game that I am working on.
    Julien Enoch
    @JEnoch
    @maxmughal7_twitter , That’s really great!! Thanks for sharing :smile:
    kydos
    @kydos
    @maxmughal7_twitter that’s pretty cool!
    Elias De Coninck
    @eliasdc
    Hi, I am trying to get the entire navigation stack and public discovery working over a WiFi network. I have multiple zenoh bridges running on the robot and on my machine: 2x zenoh-bridge on the robot, one for public topics discover-able using multicast and one with a scope and no multi-casting so a user needs to directly connect to it. This last one is mostly used for debugging and setting up the robot. My problem starts when I want to try setting up navigation stack which uses transient_local topics (e.g. for /map). Locally on my system I see the lidar scans, tf tree, robot model, etc. but the map itself will never load. If I reload the map using the load_map service the map becomes visible as it sends new data to the topic and everyone is already subscribed by then. Is transient_local not supported? I see someone made some commits (eclipse-zenoh/zenoh-plugin-dds#36) to enable it but not sure if it is ever tested or it if it needs to be configured.
    1 reply