[ros-users] nimbro_network: Multi-master ROS network solution

[Mike Purvis]

Looks awesome. A few quick questions, just to help everyone understand how
the capabilities of this system relate to Concert and fkie_multimaster:

   - Do you handle prefixing/deprefixing TF frames for headers?
      - For fields like Odometry::child_frame_id?
   - When you rate-limit topics like tf and joint_state, do you aggregate
   "full" snapshots, or is it a message-level throttle?
   - Do you handle machine discovery?
      - If so, is it using avahi or some other mechanism?
   - How dependent are you on the network's DNS infrastructure?
   - How much provision has been made for Gazebo simulation of multi-robot
   scenarios?
      - If any, does the user create multiple local roscores on different
      ports, or do you simulate all on the same roscore as Gazebo?
      - Can I simulate lossy connection between my simulated bots?

It's possible some of this is covered in your docs, but I didn't see it on
a quick first pass.

Mike

On 22 September 2015 at 10:20, Max Schwarz via ros-users <
ros-users at lists.ros.org> wrote:

> Hi everyone,
>
> our group has developed a network transport solution for multi-master ROS
> systems. We used it with great success in the DLR SpaceBot-Cup and the
> DARPA
> Robotics Challenge, where our team (NimbRo Rescue) got fourth place.
>
> Opposed to other multi-master solutions, our software is targeted for *bad*
> networks, such as WiFi connections. For example, it can handle large
> latencies
> and large packet-drop ratios without introducing further latency or
> dropping
> messages.
>
> The stack is now available under BSD-3 license here:
>
> https://github.com/AIS-Bonn/nimbro_network
>
> Some features:
>
>  * Topic transport:
>    * TCP protocol for transmission guarantee
>    * UDP protocol for streaming data without transmission guarantee
>    * Optional transparent BZip2 compression using libbz2
>    * Experimental Forward Error Correction (FEC) for the UDP transport
>    * Automatic topic discovery on the receiver side. The transmitter
> defines
>       which topics get transferred
>    * Optional rate-limiting for each topic
>  * Service transport:
>    * TCP protocol with minimal latency (support for TCP Fast-Open is
> included)
>    * UDP protocol with minimum latency
>  * Additional nodes/filters for transmitting the ROS log, TF tree and
>    H.264-compressed camera images.
>  * rqt plugins for visualization and debugging of network issues
>
> For more details, see the included README file. If you have any questions,
> please don't hesitate to ask me. We would also like to hear from you if you
> end up using our software!
>
> Cheers,
>   Max
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20150922/77ec8fc2/attachment.html>