←back to thread

58 points hannesfur | 5 comments | | HN request time: 1.137s | 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! :)

Show context
Animats ◴[] No.42743950[source]
Read the architecture document here.[1]

The usual problems with these things are discovery and security. Discovery is done via local WiFi broadcast. Not clear how security is done. How do you allow ad-hoc networking yet disallow hostile actors from connecting?

[1] https://docs.p2p.industries/concepts/architecture/

replies(1): >>42744144 #
hannesfur ◴[] No.42744144[source]
We do discovery via the mesh, yes, but instead of broadcasting (like mDNS), we query batman-adv for the current visible neighbors. If a new neighbor is discovered, we will contact them directly (via WiFi) to exchange the addresses in the P2P network and then dial them. From that, we populate the local Kademlia routing table with the content of the neighbor.

Security is still a big issue. In the current state, there is no security other than application-layer encryption (QUIC & TLS v1.3). That is fine for pilot projects, but it should not be used for anything sensitive. Maybe we should point this out more clearly in the docs. However, some Wi-Fi chips (not the ones on Raspberry Pi, sadly) also allow setting a password in adhoc (IBSS) mode and 802.11s has native support for encryption. In general is here a problem with lack of adoption of standards by the WiFi chip manufacturers and with Broadcom (the chip on the RP) a lack of support in the Linux kernel driver.

We are planning to implement authentication and encryption in the upcoming release, but this might be a paid feature.

Typically, enterprise networks are encrypted via 802.11x (since a leak of the key wouldn't compromise the whole network), and we might be able to build a decentralised Radius server, but I'm not very fond of that idea.

Ideally, the damage one can do by joining the network unauthorized should be very limited anyway, and authentication and encryption should happen on Layer 5.

Would love feedback / inspiration / suggestions

replies(2): >>42744818 #>>42745925 #
1. Animats ◴[] No.42745925[source]
It's not encryption that's needed. It's authentication. How do you decide who's allowed to join your mesh if it runs on WiFi discovery?
replies(1): >>42746160 #
2. hannesfur ◴[] No.42746160[source]
Like others suggested a basic step would be to use a certificate based approach where a company (or basically any deployment) gives out certificates for robots allowed to join and you only communicate with them.
replies(1): >>42746227 #
3. Animats ◴[] No.42746227[source]
But how do you distribute the certificates? It's cold-starting peer to peer distributed systems that's hard.
replies(1): >>42746252 #
4. hannesfur ◴[] No.42746252{3}[source]
When you setup the robots you could load them with the PKI and then load each other robot joining with a signed certificate. Not ideal, I admit.

Another way would be to somehow prove that you belong.

replies(1): >>42746380 #
5. Animats ◴[] No.42746380{4}[source]
This is a general problem with all federated systems.

It's annoying that we don't have a decent solution to this even for home automation. You ought to be able to take a "house ID key", probably a Yubikey, and present it to all your devices to tell them "you're mine now". Then they can talk to each other.

There are military cryptosystems which have such hardware. There's a handheld device called the Simple Key Loader.[1] That's what's used to load secure voice keys into radios, encrypted GPS keys into GPS units, identify-friend-foe codes into aircraft, and such. It's 15 years old, runs Windows CE, has a screen with a pen, and is far too big. The Tactical Key Loader is smaller and simpler.[2] 7 buttons and a small screen. About the same size as a Flipper Zero, but ruggedized and expensive.

[1] https://info.publicintelligence.net/SKLInstructionGuide.pdf

[2] https://www.l3harris.com/all-capabilities/kik-11-tactical-ke...