Hi all I cross-compiled Zenoh for
aarch64 for a Pi4 (2GB) and I started the router ./zenohd and followed the steps in the documentation of setting up a local memory storage and tried putting hello world on the API. Upon querying the data I get [ ] although the paths are the same.
never mind it works forgot the
--mem-storage /demo/example/** parameter for zenohd
Unable to map ros2 pubisher/listner to Zenoh resources
Setup
- A docker container with
- Zenoh-DDS-bridge installed
- ROS2 foxy with CycloneDDS
- Example publisher and subscriber (from ros2 examples)
Problem/Issue
- The zenoh bridge is startd with
RUST_LOG=debug ./target/release/zenoh-bridge-dds -m peer - A ros2 publisher is started with
ros2 run examples_rclcpp_minimal_publisher publisher_member_function - As shown in the demo here, the user should be able to see the log that the dds plugin has discovered the publisher but it is not happening (Please see the attached image)
Additional information
My CycloneDDS config is as following<?xml version="1.0" encoding="UTF-8"?>
<CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd">
<Domain id="any">
<Discovery>
<ParticipantIndex>
auto
</ParticipantIndex>
<MaxAutoParticipantIndex>
30
</MaxAutoParticipantIndex>
</Discovery>
</Domain>
</CycloneDDS>
6 replies
@JEnoch I am trying an initial Workflow for Docker Artefact Build and Publish on my Fork shantanoo-desai/zenoh#1 Fingers Cross
15 replies
Is there a simple way to cross compile zenoh-c? It seems to hang up on ring (I think its missing a TARGETCC env var?
So finally after a lot of tries there is a good workflow that will help the zenoh team create Docker Artefacts not just for x86 but also for other platforms I just built
zenoh for arm64 and if someone has a Raspberry Pi 4 with docker lying around please give docker run --init -p 7447:7447/tcp -p 7447:7447/udp -p 8000:8000/tcp shantanoodesai/zenoh a spin
I will deep dive into caching mechanisms so that we don't redundantly build a lot of stuff and consume resources. I have also found actions for binary artefacts which implies Binaries for
zenoh as well as Docker images can be built effortlessly for all possible platforms amd64, arm64, i686, armv7 + armv6
Hi, wondering if there is any documented protocol specification available?, https://github.com/eclipse-zenoh/zenoh/blob/master/zenoh/src/net/protocol/proto/msg.rs gives some insight but not the whole picture.
@shantanoo-desai , you are also welcome to contribute a blog to zenoh.io. Just do a pull request on https://github.com/atolab/zenoh-web
Hi all just a heads up. Docker Alpine image for zenoh (~45MB) builds well however is not able to run because I keep getting
Error Relocating: /usr/local/bin/zenohd: __register_atfork: symbol not found
Error Relocating: /usr/local/bin/zenohd: __res_init: symbol not foundDoes someone have an idea regarding this incompatibility with Alpine Docker containers?
Something similar in the lines of This StackOverflow Thread
For Alpine I didn’t try to target x86_64-unknown-linux-gnu.
But I managed to make it work targeting x86_64-unknown-linux-musl, defining RUSTFLAGS '-Ctarget-feature=-crt-static’ (to force dynamic link of the plugins/backends libs, as default is static with MUSL) and having the follwing in my ~/.cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"Also I’m running on MacOS with musl-cross installed.
Hmm I changed the build for aarch64-unknown-linux-musl target but I get
error: cannot produce cdylib for `zenoh-plugin-storages v0.5.0-dev (/project/plugins/zenoh-plugin-storages)` as the target `aarch64-unknown-linux-musl` does not support these crate typesMaybe I am drifting in the wrong direction
Success on Debian-slim (rpi4) docker run --init -d -p 7447:7447/tcp -p 7447:7447/udp -p 8000:8000/tcp shantanoodesai/zenoh:latest for anyone willing to try. Please not there are changes to the docker image so I advice to run it in detached mode with -d. If you wish to give in-memory example a try
docker run --init -d -p 7447:7447/tcp -p 7447:7447/udp -p 8000:8000/tcp shantanoodesai/zenoh:latest --mem-storage demo/example/**everything mentioned in the getting started page works
Thanks @shantanoo-desai !
I just tested on my MacOS (x86 with arm64 emulation) and it run wells, even without the
I just wonder why the zenohd binary is 59Mb while in the
I just tested on my MacOS (x86 with arm64 emulation) and it run wells, even without the
-d option.I just wonder why the zenohd binary is 59Mb while in the
eclipse/zenoh image (alpine x86_64 based) it’s only 5.5Mb. Did you build in release mode ?
32 replies
with zenoh storage and get, is there any thinking on a get + subscribe mechanism? like if I have an some structured data where many attributes remain the same and some are changing relatively often, and I want those updates after the initial get
Hi @shantanoo-desai , regarding building zenoh-pico for Arduino there was an initial attempt from @cguimaraes here. The PR is still marked as work in progress but I believe it could serve as a starting point.
Hi @halfbit:matrix.org ,
Actually I merged last Thursday (eclipse-zenoh/zenoh@59fd21b). It’s in a new side crate named zenoh-ext that extends the
By default the
Actually I merged last Thursday (eclipse-zenoh/zenoh@59fd21b). It’s in a new side crate named zenoh-ext that extends the
zenoh::net::Session with a declare_querying_subscriber() function. You can see an example of usage here.By default the
QueryingSubscriber starts with a query on the same resource it subscribes to (but it could be configured to query on another resource). The results of the query are merged/sorted/deduplicated with the live publications that may occur in parallel, before to be delivered to the QueryingSubscriberuser. At any time, the user can re-issue a query and the same behaviour will re-occur.
@JEnoch just a weird update regarding
This produces
Not sure if this is good or not but I am trying to spin it up in an apline container and see if this works.
musl cross compilation for aarch64 apparently the cdylib was causing problems when compiling for aarch64-unknown-linux-musl but on my local x84_64 based machine I replaced the crates that had cdylib to staticlib and it seems to cross-compile.This produces
*.a files as opposed to *.so files.Not sure if this is good or not but I am trying to spin it up in an apline container and see if this works.
14 replies
Hi, everyone! I just tried the example in "your first zenoh app". First, I launch the dockerized router:
$ podman run --init -p 7447:7447/tcp -p 7447:7447/udp -p 8000:8000/tcp eclipse/zenoh --mem-storage='/myhome/**'Then, I launch the Python script that produces temperature readings, and I see:
Traceback (most recent call last):
File "/***/zenoh-server.py", line 18, in <module>
z = Zenoh({})
zenoh.ZError: IO error (Unable to bind udp port 224.0.0.224:7447) at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/zenoh-0.5.0-beta.8/src/net/runtime/orchestrator.rs:350. - Caused by Address already in use (os error 98)Everything locally. Am I doing something wrong? Shouldn't the peer find the router?
Adding
"multicast_address": "224.0.0.224:7448" to the config works! Thanks, @Mallets
And it's needed to specify the peer too. As a suggestion, it would be great to add these details to the documentation. :)
1 reply
Hi guys looking at the code available I found several definitions that I am not sure if I know what they mean. If someone could clarify the difference between Locator and Broker I would be very pleased. And for example if I am a zenoh router then how should I fill the flags on a Hello message.
Hello @AlexandreVSantos_gitlab a locator is, in a way, an address at which to find a zenoh endpoint and the lower level protocol to use to communicate with it. Over IP networks a zenoh locator may look like
udp/131.176.207.40:7447 or tcp/131.176.207.40:7447. A broker is just en entity mediating communications between two clients.
@Enchufa2 indeed that should be a bit more clear from the docs. @JEnoch, can you look into this or make sure that the right info is more easily accessible?
Hi everyone, according to the key concept docs communicate with other peers could be peer to peer and mesh topology. I'm wondering can I and how to choose the topology. Is it configurable? or it will choose automatically?
Hi @gardenest , you can define the topology by manually interconnecting the different peers with each other. To do so, you need to configure each zenoh session with the following :
- a tcp listener with a specific tcp port to listen on (so that other peers can easily connect to it)
- one or more peers to connect to
- deactivate multicast and gossip discovery so that peers do not connect automatically to each other.
Here is an example in python :
from zenoh import Zenoh
z = Zenoh({"listener": "tcp/0.0.0.0:7447",
"peer": "tcp/127.0.0.1:7448,tcp/127.0.0.1:7449",
"multicast_scouting": "false",
"peers_autoconnect": "false"})
@OlivierHecart Thanks for your reply, I will try on it.
I have another question is about the memory usage of peer. I'm trying to testing it via the example zn_pub.py and zn_sub.py and testing scenario is one subscriber with many publishers. The situation is when new publisher application start, the memory usage of the existed publisher will become larger each time. How can I prevent this kind of situation?
I have another question is about the memory usage of peer. I'm trying to testing it via the example zn_pub.py and zn_sub.py and testing scenario is one subscriber with many publishers. The situation is when new publisher application start, the memory usage of the existed publisher will become larger each time. How can I prevent this kind of situation?
@gardenest I see 2 solutions for this :
- use a zenoh router and configure all pubs and sub as clients.
- configure a "mesh" of peers where each zn_pub is only connected to the zn_sub.
For this second solution, using zn_pub.py and zn_sub.py examples you need to write a config file to deactivate multicast and gossip discovery :
Then you can run zn_sub.py and zn_pub.py like this :$ cat config multicast_scouting=false peers_autoconnect=falsepython3 examples/zenoh-net/zn_sub.py -c config -l tcp/0.0.0.0:7447python3 examples/zenoh-net/zn_pub.py -c config -e tcp/127.0.0.1:7447python3 examples/zenoh-net/zn_pub.py -c config -e tcp/127.0.0.1:7447
@kydos thanks for the explanation
I have another question about session establishment. Looking at some captures taken with wireshark, I can see that the zenoh client when trying to establish a session with a router, sends along with an init header, an attachment header with some payload. Is that for authentication? how should the router handle that information and how should be the response?
I have another question about session establishment. Looking at some captures taken with wireshark, I can see that the zenoh client when trying to establish a session with a router, sends along with an init header, an attachment header with some payload. Is that for authentication? how should the router handle that information and how should be the response?