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?
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! :)
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?
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
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...