←back to thread

Show HN: Decentralized robots (and things) orchestration system

(docs.p2p.industries)
69 points hannesfur | 2 comments | 14 Jan 25 06:31 UTC | HN request time: 0.412s | source

Hi HN, we build an open-source operating system extension for orchestrating robot swarms fully decentralized.

This first beta version allows you to create fully decentralized robot swarms. The system will set up a wireless mesh network and run a p2p networking stack on top of it, such that nodes can interact with each other through various abstractions using our SDKs (Rust, Python, TypeScript) or a CLI.

We hope this is a step toward better inter-robot communication (and a fun project if you have a few Raspberry Pis lying around).

Our mesh network is created by B.A.T.M.A.N.-adv and we’ve combined this with optimized decentralized algorithms. To a user, it becomes very easy to write decentralized applications involving several peers since we’ve abstracted away much of the complexity. Our system currently offers several orchestration primitives (Key-Value Store, Pub-Sub, Discovery, Request-Response, Mesh Inspection, Debug Services, etc.)

Internally, everything except the SDKs is written in Rust, building on top of libp2p. We use gRPC to communicate between the SDKs and the CLI, so libraries for other languages are possible, and we welcome contributions (or feedback).

The C++ SDK and a ROS package that should feel natural to roboticists are in the works. Soon we also want to support a collaborative SLAM and a distributed task queue.

We’d love to hear your thoughts! :)

1. cookiengineer ◴[18 Jan 25 06:25 UTC] No.42746329[source]▶
batman-advanced is a pretty interesting choice for a routing / handshake mechanism. Are your own applications mostly focussed on 802.11s Wi-Fi or where does the choice come from?

In Profinet / Ethernet based networks it's more common to use ARP or mDNS for the discovery because multicast addresses are supported everywhere. Multicast DNS would be independent on top of the existing network layer and compatible with smartphones and other consumer devices (and even printers). That's why I'm asking, was there a specific reason to not use mDNS?

Airprint, airscan, filedrop and other things are based on bonjour (mDNS-SD), and supported pretty well on consumer devices and routers. [1]

[1] http://dns-sd.org/

replies(1): >>42747035 #
2. hannesfur ◴[18 Jan 25 09:27 UTC] No.42747035[source]▶
We chose batman-adv because it's the most widely adopted and supported implementation of a wireless ad hoc mesh network :) Freifunk is running deployments with several thousand nodes.[1] Since that was the scale we were aiming for, this is what we chose. We also considered 802.11s for a long time, but the hardware support is quite poor, especially on a device where people would try something like this: Raspberry Pis.

You are right that mDNS is a popular choice, and we even have it in our codebase to be able to debug on macOS.

However, mDNS is a flooding/multicast protocol, and although batman-adv optimizes those, it puts unnecessary strain on a mesh network. That’s why we didn't go with it.

It also gave us the opportunity to try out this other, in our view, more elegant approach to discovery.

Since IBSS is not really useful outside of Linux popular device support, like smartphones, it fell out of the picture pretty quickly (sadly). However, you can connect bridges to our mesh network (again exposing a batman-adv feature), which would give you the ability to connect phones (and of course, printers) to your robots.

[1]: http://grafana.freifunk-muensterland.de/goto/lAqihJDHg?orgId...