Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Julien Enoch
    @JEnoch
    @maxlein : my bad, to get peer mode with the Docker image you currently need to get the eclipse/zenoh-bridge-dds:master image. The latest is not up-to-date. I’ll update it with our latest 0.5.0-beta.8 shortly
    Angelo Corsaro
    @kydos
    @maxlein, looking at the topology you want to setup the easiest thing to do would be the following:
    • Run a zenoh router on the server
    maxlein
    @maxlein
    Ok, the bridge container I am using from you, it's not build by myself.
    Angelo Corsaro
    @kydos
    • Run a dzd instance on the robot and just use the default client mode, no need for that to be a peer on this config
    • run another dzd instance on the laptop once again on client mode
    When running dzd on the robot pass the locator of the router on the server, while on the laptop zenoh scouting will do the job
    There are other topologies you could set-up, but this would be the most straightforward to get started.
    Once you have this working then you could decide to explore a mesh based topology in which all nodes behave like peers.
    Makes sense?
    maxlein
    @maxlein

    Thank you @kydos
    But this would be the setup I tried first, router on server, and default was client mode.
    If my pc also has a locator set up, shouldn't be a problem, or?

    FYI: On the robot and my pc, zenoh runs in a self build container with net=host.
    The container was build from a ros image, so cyclone libs, etc. should also be available

    Angelo Corsaro
    @kydos
    BTW, if you want to further reduce the discovery data, it is useful to ensure that your ROS topic names are “rooted”, thus use the -s to set the scope if this is not the case and then give leverage the -r and -w options for more aggressive generalisation
    The blog mentioned above should serve as a good example. BTW, I’ll also extend the blog to show exactly the commands to run for your use case along with a picture. OK?
    maxlein
    @maxlein
    Would be really nice
    Angelo Corsaro
    @kydos
    Concerning your question above, your PC can specify the locator, that is not a problem.
    Thus, did you manage to have the version with the router running?
    maxlein
    @maxlein
    No didn't work, then I tried to switch to client mode on the clients. But also no success.
    Angelo Corsaro
    @kydos
    That is strange. Can you run it with RUST_LOG=debug on all nodes when using the router and make a github issue ?
    Julien Enoch
    @JEnoch
    @maxlein I just kicked the build:
    https://ci.eclipse.org/zenoh/job/zenoh-plugin-dds/
    In about 15min you should be able to pull/update the latest version of eclipse/zenoh-bridge-dds image from Docker hub.
    maxlein
    @maxlein
    In the blog you use /bot as the scope of zenoh, but this scope has nothing to do with a ROS namespace, or am I missing something?
    Thanks @JEnoch
    Julien Enoch
    @JEnoch
    No, this is an additional prefix that is added in front of a DDS topic name when bridging it to/from a zenoh resource.
    I.e. ROS2 topic /rt/cmd_vel becomes zenoh resource /bot/rt/cmd_vel
    With a single robot, there it little use of it. But with several bots, you should use 1 bridge+scope per robot, and then be able to manage them all within a single zenoh system.
    Angelo Corsaro
    @kydos
    The reason for rooting the resources is that this way zenoh can be far more aggressive on resource generalisation. I hope this is sufficiently clearly explained on the Blog, but if not clear I’ll try to expand there.
    However the intution is that zenoh can figure out how to “compress” discovery data.
    Julien Enoch
    @JEnoch

    Hi all,

    Eclipse zenoh 0.5.0-beta.8 is out!

    Angelo Corsaro
    @kydos
    Good point @JEnoch on the --net host option as one of the problem @maxlein may has seen is that the DDS from ROS and Robot do not manage to discover each other. But again, once we’ll see the log we’ll be able to provide more insights.
    OlivierHecart
    @OlivierHecart
    Hi @OliLay !
    I just pushed to master a fix that should allow support for multicast scouting on multi-homed hosts.
    Note that the fix will not work on windows platform.
    There will be more improvements coming but this fix should be ok for most cases.
    Let me know if you have any issues !
    Oliver Layer
    @OliLay
    Hi @OlivierHecart, thank you for letting me know. I'm gonna try it as soon as I can and then ping you back here :)
    maxlein
    @maxlein
    Thank you again!
    I just posted an issue regarding my problems: eclipse-zenoh/zenoh#78
    Angelo Corsaro
    @kydos
    @maxlein, just took a look at the issue and the problem seems to be tied to DDS discovery. I’ve left a comment for you. Keep us posted.
    maxlein
    @maxlein
    I assumed default ROS_DOMAIN_ID is 1 but it's 0...
    So now it looks as if zenoh registers the topics, but nothing else. Still no data on my machine.
    Angelo Corsaro
    @kydos
    Can you post the new logs?
    maxlein
    @maxlein
    Added some new logs with talker demo on a single machine
    Oliver Layer
    @OliLay

    Hi @OlivierHecart . I tried your fix and it works, the clients can now detect the router in both subnets. Thank you very much! The only problem that remains is that while the client (in debug log level) prints the locators of the router, the client in one subnet still can not connect to the router. I guess this happens because the client tries to connect to the locator of the other subnet, which fails of course. Then the client panics.
    See the debug log of the client:

    -- LOG/pub: [2021-04-07T09:26:04Z DEBUG zenoh::net] Zenoh Rust API v0.5.0-beta.8-13-g655641f
    -- LOG/pub: [2021-04-07T09:26:04Z DEBUG zenoh::net] Config: mode=client
    -- LOG/pub: [2021-04-07T09:26:04Z INFO  zenoh::net::runtime] Using PID: 219FB1FD6E2C4D878E0A76B5841E9F94
    -- LOG/pub: [2021-04-07T09:26:04Z INFO  zenoh::net::runtime::orchestrator] Scouting for router ...
    -- LOG/pub: [2021-04-07T09:26:04Z DEBUG zenoh::net::runtime::orchestrator] UDP port bound to 10.0.0.190:36689
    -- LOG/pub: [2021-04-07T09:26:04Z INFO  zenoh::net::runtime::orchestrator] Found Hello { pid: Some(1A68243413B741F6B37BB9966082E998), whatami: None, locators: Some([Tcp(SocketAddr(11.0.0.22:7447)), Tcp(SocketAddr(10.0.0.201:7447))]) }
    -- LOG/pub: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ZError { kind: Timeout, file: "zenoh/src/net/runtime/orchestrator.rs", line: 628, source: None }', zenoh/examples/zenoh/z_put.rs:26:49

    As you can see, the client now correctly finds the locators of the router, but then I suspect it tries to connect to the address in the 11.x.x.x subnet instead of the 10.x.x.x subnet which it would be able to reach. When starting the client with -e 10.0.0.201:7447, it connects perfectly fine. I used the z_put example as client.
    TLDR: your multicast fix seems to work and multicast scouting works on all interfaces. But the logic for the client to choose which locator to use doesn't work correctly I suppose. Either it should select the most suitable locator (e.g. the one on the same subnet) or should try all locators instead of failing after the first one.

    OlivierHecart
    @OlivierHecart
    Hi @OliLay ! Thanks for the feedback.
    What is supposed to happen is that the router answers to scouting with an Hello message containing both it's locators. Then the client is supposed to try the returned locators one by one until one works. But apparently this last part is not working properly. I'll have a look ASAP.
    Angelo Corsaro
    @kydos
    Hello @maxlein, just left a comment on GitHub, you need to use domain 42 for the second bridge.
    OlivierHecart
    @OlivierHecart

    @OliLay what seems to happen is the following :

    • At transport level, for each connection attempt, there is a number of retries (default 3) and a timeout for each retry (10secs).
    • At upper level, in client mode there is a global timeout (default 3secs) after which the client considers it failed to connect a router.
      So the global timeout triggers before the orchestrator had a chance to try the second locator.

    We need to improve the default behavior changing those default timeouts and maybe more cleverly order the locators before attempting to connect them.

    Anyway until then, you can change those defaults at compile time. Probably the ones to change are the lower level ones so that the attempts do not take ages. You can do it like this :

    export SESSION_OPEN_TIMEOUT=1000
    export SESSION_OPEN_RETRIES=0
    cargo build --release --all-targets
    expploitt
    @expploitt
    Hello, I found an error in the Cargo.toml of the zenoh-storages plugin when I was cross-compiling for cpu-arch aarch64
    The depends line should be:
     `depends = "zenoh (=0.5.0-dev)"`
    instead of
     `depends = "zenoh (=0.5.0~dev)"`
    That difference generates an error when I try to install the zenoh-storages after zenohd .deb. With that change it is all okey :)
    Julien Enoch
    @JEnoch
    Hi @expploitt ,
    Thanks for reporting this! I’ll fix asap.
    Actually I don’t really well understand the behaviour of cargo-deb when generating the package name:
    • with zenoh 0.5.0-beta.8 it generated a package named zenoh_0.5.0~beta.8_amd64.deb (i.e. replacing the - with a ~)
    • now, setting the version to 0.5.0-dev in our master branch, it generates a package named zenohd_0.5.0-dev_amd64.deb (i.e. keeping the -)
      I guess we probably misuse the debian package versionning to keep this -beta.x suffix and need to better understand it...
    expploitt
    @expploitt
    I build this morning and cargo deb generates the .deb files as zenohd_0.5.0-dev_arm64.deb and zenoh-storages_0.5.0-dev_arm64.deb
    Okey, I'm working in the master branch
    Julien Enoch
    @JEnoch
    Yes, that what I also checked on an x86_64=amd64 platform, instead of arm64. I’ll update the Cargo.toml to fix the depends statements
    Fix just pushed in master branch
    expploitt
    @expploitt
    Thanks!