I am using the develop branch of this repo in order to achieve a ground station - robot communication.

The ground station is a laptop running ROS Noetic and works as a WiFi hotspot.
The robot is running ROS Melodic and is connected to the hotspot above.

I can run both receiver and sender on the robot PC and also I can launch the sender on the ground station.
However, when I run the receiver on the ground station I get the following error:

Could not create socket: Address family not supported by protocol
terminate called after throwing an instance of 'std::runtime_error'
  what():  Resource temporarily unavailable
[receiver-2] process has died 

Any ideas why is this happening?

In many multi-robot applications, we need few up-downlink for data to the central system and some from the central-system to all the robots which is inconvenient if we are not using Multicast/Broadcast.

Hi @xqms,

with @alaurenzi we are trying to adopt the nimbro_network framework for the communication between the pilot station and our robots.

We tried to execute the rqt-plugins you developed, but we are not able to see them inside rtq_gui.

We already tried to use the:

rqt --force-discover

with no success.

We also tried to source from install space, but the result is the same: rqt does not show up the plugins.

Any ideas?

Would it be possible to achieve the discovery using multimaster_fkie and enable hosts on the go for the nimbro network?
Did anybody already tried that?
Do we need one node per host to synchronize?

I am trying to build nimbro_network (develop branch) on a Jetson Nano.
All packages, except nimbro_topic_transport are completed successfully.
For the topic transport I get the following error
In file included from /home/smarthome-user/ros_projects/nimbro_ws/src/nimbro_network/nimbro_topic_transport/contrib/wirehair/WirehairTools.h:34:0, from /home/smarthome-user/ros_projects/nimbro_ws/src/nimbro_network/nimbro_topic_transport/contrib/wirehair/WirehairCodec.h:211, from /home/smarthome-user/ros_projects/nimbro_ws/src/nimbro_network/nimbro_topic_transport/contrib/wirehair/wirehair.cpp:30: /home/smarthome-user/ros_projects/nimbro_ws/src/nimbro_network/nimbro_topic_transport/contrib/wirehair/gf256.h:70:14: fatal error: tmmintrin.h: No such file or directory #include <tmmintrin.h> // SSSE3: _mm_shuffle_epi8 ^~~~~~~~~~~~~ compilation terminated.

Following the instructions from here, I tried to locate the tmmintrin.h file, but it is not installed anywhere.

Is it possible to build it on a Jetson device? Are there any modifications that should be made?

Hi @xqms

We've got an issue with the receiver node dying because of segfault (exit code -11) when using the "develop" branch.

@tomlankhorst and I tried to debug this issue and could get a backtrace using gdb (see end of the message). We were wondering if you could provide us with your feedback about this issue. This is our setup:

• a base station runs the receiver node
• an agent runs the sender node
• the agent sends both tcp (sporadic messages) and udp (images and tf) topics

When the agent goes out of connection range and comes back after some minutes, we often get the receiver node dying on the base station. We suspect that Depacketizer::addPacket is called asynchronously on the same object (for example when 2 UDP packets are received) and so addPacket is called twice. But if it's called async, then it will mess up because the value of the iterator will be changing.

Do you have any hint or suggest on how we could fix this issue?

Best,
Marco

Backtrace:

#0  0x00007ffff7d6ce72 in nimbro_topic_transport::Depacketizer::handleMessagePacket (this=0x7fffffffbfb0, it=
    {id = 24190, complete = false, received_symbols = 10, packets = std::vector of length 10, capacity 10 = {std::shared_ptr<nimbro_topic_transport::Packet> (use count 1, weak count 0) = {get() = 0x7fffd48a92b0}, std::shared_ptr<nimbro_topic_transport::Packet> (use count 1, weak count 0) = {get() = 0x7fffd48b0120}, std::shared_ptr<nimbro_topic_transport::Packet> (use count 1, weak count 0) = {get() = 0x7fffd48b06f0}, std::shared_ptr<nimbro_topic_transport::Packet> (use count 1, weak count 0) = {get() = 0x7fffd48b0cc0}, std::shared_ptr<nimbro_topic_transport::Packet> (use count 2, weak count 0) = {get() = 0x7fffd48b1290}, std::shared_ptr<nimbro_topic_transport::Packet> (use count 1, weak count 0) = {get() = 0x7fffd48accd0}, std::shared_ptr<nimbro_topic_transport::Packet> (use count 1, weak count 0) = {get() = 0x7fffd48a9e50}, std::shared_ptr<nimbro_topic_transport::Packet> (use count 1, weak count 0) = {get() = 0x7fffd48a8140}, std::shared_ptr<nimbro_topic_transport::Packet> (empty) = {get() = 0x0}, std::shared_ptr<nimbro_topic_transport::Packet> (use count 1, weak count 0) = {get() = 0x7fffd48aefb0}}, decoder = std::shared_ptr<WirehairCodec_t> (empty) = {get() = 0x0}}, packet=...) at /usr/include/c++/9/bits/shared_ptr_base.h:1020
#1  0x00007ffff7d6df79 in nimbro_topic_transport::Depacketizer::addPacket (this=0x7fffffffbfb0,
    packet=std::shared_ptr<nimbro_topic_transport::Packet> (use count 2, weak count 0) = {...})
    at /home/subt/catkin_ws/src/nimbro_network/nimbro_topic_transport/src/receiver/depacketizer.cpp:44
#2  0x00007ffff7d71432 in std::function<void (std::shared_ptr<nimbro_topic_transport::Packet> const&)>::operator()(std::shared_ptr<nimbro_topic_transport::Packet> const&) const (__args#0=std::shared_ptr<nimbro_topic_transport::Packet> (use count 2, weak count 0) = {...},

First: thanks for making these pkgs available.

This is more a question than a real issue, but there is some ambiguity over how these pkgs are licensed: the readme states that they are "BSD 3 clause" (here with the QCustomPlot library as GPLv3). The nimbro_topic_transport package however has GPLv2 in its package manifest (here). Same for nimbro_service_transport.

I haven't checked the other packages, but could you clarify which statement(s) is (are) correct?

Hi @xqms

Thanks again for sharing this great collection of tools!

I've noticed one strange behavior and was wondering if it's intended to be like that.
Basically every time a topic is sent over nimbro, the first few messages are not received on the receiver side.

This is a quick example to reproduce the mentioned issue:

1. In one terminal to simulate the first machine (sender) run

roslaunch nimbro_topic_transport tcp_sender.launch

2. In a second terminal to simulate the second machine (receiver, running on different roscore) run:

export ROS_MASTER_URI=http://localhost:13311
roslaunch nimbro_topic_transport tcp_receiver.launch 

3. Now in a third terminal (same rosmaster as second machine):

export ROS_MASTER_URI=http://localhost:13311
rostopic echo /recv/my_first_topic

4. Finally we can publish a topic on the first machine in a fourth terminal (package roscpp_tutorials needs to be installed):

rosrun roscpp_tutorials talker /chatter:=/my_first_topic

As it the be noticed in the below screeshot, the received messages in the second machine start with "hello world 3", whereas the talker node on the first machine starts publishing with hello world 0.

So the question is: where are the first 3 messages? Is this an expected behavior?

Hi,

once again thanks for sharing this great tool!

I was wondering if there was a more systematic way to choose the TCP/UDP ports to be used in the launch files.
I saw that if the nimbro_network nodes are launched after the other ROS nodes are already running on the robot, sometimes it may happen that the TCP or UDP ports hard-coded in the launch files are already being used by some oder nodes, resulting then in the error:
[FATAL] [1570092836.939500435]: Could not bind socket: Address already in use
and then the corresponding nimbro_network node that tried to use the occupied port dies.

So far the best thing I could think of, is to: (a) launch regular launch file on the robot, (b) use the solution proposed here to scan available TCP or UDP ports in private range (49152-65535), (c) pick available ports for the nimbro nodes.

Of course this is not ideal and does not ensure that the launch files for nimbro will always have the selected ports as available. Therefore I was wondering if there's another way/method to deal with this problem.

Or maybe should I just use ports within the "registered ports" range (1024 to 49151)? I saw that the TCP Receiver/Sender example uses ports 17001 and 17002 and with these two I have never problems.

Regards,

Marco.

I am trying to build nimbro_network (develop branch) on a Jetson Nano.
All packages, except nimbro_topic_transport are completed successfully.
For the topic transport I get the following error
In file included from /home/smarthome-user/ros_projects/nimbro_ws/src/nimbro_network/nimbro_topic_transport/contrib/wirehair/WirehairTools.h:34:0, from /home/smarthome-user/ros_projects/nimbro_ws/src/nimbro_network/nimbro_topic_transport/contrib/wirehair/WirehairCodec.h:211, from /home/smarthome-user/ros_projects/nimbro_ws/src/nimbro_network/nimbro_topic_transport/contrib/wirehair/wirehair.cpp:30: /home/smarthome-user/ros_projects/nimbro_ws/src/nimbro_network/nimbro_topic_transport/contrib/wirehair/gf256.h:70:14: fatal error: tmmintrin.h: No such file or directory #include <tmmintrin.h> // SSSE3: _mm_shuffle_epi8 ^~~~~~~~~~~~~ compilation terminated.

Following the instructions from here, I tried to locate the tmmintrin.h file, but it is not installed anywhere.

Is it possible to build it on a Jetson device? Are there any modifications that should be made?

I'm trying to setup Nimbro, but am getting errors with mismatching md5sum. The setup is as follows:

• Laptop running Ubuntu 16.04 and ROS Kinetic
• Raspberry Pi 3 running ubuntu-mate and ROS Kinetic
• nimbro_network

When I try to (by hand or code) publish to a topic, e.g. /odom, from the Raspberry Pi 3 I get an error message that the md5sum does not match. For nav_msgs/Odometry:
[ERROR] [1494423321.522783000]: Client [/rostopic_31478_1494423320327] wants topic /am02/odom to have datatype/md5sum [nav_msgs/Odometry/cd5e73d190d741a2f92e81eda573aca7], but our version has [nav_msgs/Odometry/7fffffff7fffffff7fffffff7fffffff]. Dropping connection..
Similar for sensor_msgs/Image (I relaunched and published a different type of message):
[ERROR] [1494423348.232874870]: Client [/rostopic_31620_1494423344032] wants topic /am02/odom to have datatype/md5sum [sensor_msgs/Image/060021388200f6f0f447d0fcd9c64743], but our version has [sensor_msgs/Image/060021387fffffff7fffffff7fffffff]. Dropping connection.

I've checked the md5sum on both with rosmsg md5 nav_msgs/Odometry and rosmsg md5 sensor_msgs/Image, they are identical. If I export ROS_MASTER_URI and skip nimbro it works.

If I publish to /am02/cmd_vel from the laptop, I receive the message on the RPi3 without any issue. If I try the other way, it does not work.

As discovered in AIS-Bonn/catch_ros#15, we currently prefer the catch_ros headers from e.g. /opt/ros/noetic/include in favor of the (correct) ones from the current workspace.

The reason is this line:

... which adds the catch_ros headers to the end. Instead, we should use catkin's list_insert_in_workspace_order() function to correctly insert the additional include path.