←back to thread

53 points hannesfur | 2 comments | | HN request time: 0.423s | 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. matthewfcarlson ◴[] No.42743416[source]
It's not clear what the hardware requirements for a system that can run this would be. Raspberry Pi is mentioned but it seems like an actual OS (not ESP32 for example) is a requirement.
replies(1): >>42743733 #
2. lmeierhoefer ◴[] No.42743733[source]
You are right that, at the moment, the system inherently requires a 64-bit OS. We currently support Debian-based distros; it should work with other parent distributions as well, but you need to translate the installer script ;) But we definitely need to highlight this more clearly in the docs. Thanks for pointing it out!

We also don’t have a definitive hardware spec requirement yet. We’ve tested it on Raspberry Pi 3s and later models (so anything more capable than a 3 should be fine).

> not ESP32 for example

Running on ESP32 is tricky because it would require porting libp2p to a embedded (which, as far as we know, nobody has done yet). However, we are considering support for embedded “light” nodes that run only a limited portion of the stack. It depends on the feedback we get. Do you have a use case where you’d need it to run on embedded?