Sigh....I quite literally laid out this exact design in my head during my 6 hour business travel today. I was brainstorming designs for military swarm applications. Congrats lol
Great idea combining batman with libp2p! You guys have the heart in the right place :-).
Currently, your project seems to be an opinionated wrapper ontop of libp2p. For this to become a proper distributed toolkit you lack an abstraction to for apps to collaborate over shared state (incl. convergence after partition). Come up with a good abstraction for that, and make it work p2p (e.g. delta state based CRDTs, or op-based CRDTs based on a replicated log; event sourcing ..). Tangentially related, a consensus abstraction might also be handy for some applications.
This looks super cool, Ive been working in a similar space for some time. I work with open-rmf which is semi-decentralized and provides tools for task and traffic deconfliction (we don't handle the network layer at all). Excited to see more similar software coming up.
One question I have is how quickly can discovery and switching take place. For instance, if I have a robot enter a lift. Can the lift detect the robots entrance and trigger its behaviours?
Very fun. Is this primarily a passion project or are you hoping to get corporate sponsorship & adoption?
Can you provide some insight as to why this would be preferred over an orchestration server? In this context - Would a 'mothership'/Wheel-and-spoke drone responsible for controlling the rest of the hive be considered an orchestration server?
This isn't my area of expertise but I think "Hive mind drones" tickles every engineer.
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 is awesome stuff, I'm going to look into getting this running my Pis this weekend. How hard would it be to add in custom services? I like to play with decentralized algorithms such as Size Estimation and Clock Synchronization (https://jasonfantl.com/) and have always wanted to get them running on real hardware.
I am neophyte in this realm, but I like what I am seeing so far. Since I want to get into robotics for my own fun, I will be looking at it more closely this weekend:D
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.
I've been thinking about building a little tiny SLAM robot to have something to drive around the house when I'm out of town (I don't want always on cameras everywhere but having a camera that can move around sounds useful). The ideas here are awesome and I'm looking forward to the tutorials being more fleshed out.
Show HN: Decentralized robots (and things) orchestration system
(docs.p2p.industries)53 points by hannesfur 14 January 2025 | 26 comments
Comments
Currently, your project seems to be an opinionated wrapper ontop of libp2p. For this to become a proper distributed toolkit you lack an abstraction to for apps to collaborate over shared state (incl. convergence after partition). Come up with a good abstraction for that, and make it work p2p (e.g. delta state based CRDTs, or op-based CRDTs based on a replicated log; event sourcing ..). Tangentially related, a consensus abstraction might also be handy for some applications.
Also check out [iroh](https://github.com/n0-computer/iroh) as a potential awesome replacement for p2p; as well as [Actyx](https://github.com/Actyx/Actyx) as an inspiration of similar (sadly failed) project using rust-libp2p.
Oh, and you might want to give your docs a grammar review.
Kudos for showing!
One question I have is how quickly can discovery and switching take place. For instance, if I have a robot enter a lift. Can the lift detect the robots entrance and trigger its behaviours?
Can you provide some insight as to why this would be preferred over an orchestration server? In this context - Would a 'mothership'/Wheel-and-spoke drone responsible for controlling the rest of the hive be considered an orchestration server?
This isn't my area of expertise but I think "Hive mind drones" tickles every engineer.
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/
Have you ever played any of the Horizon (Zero Dawn/Forbidden West) games? :)
Jokes aside, it looks pretty cool. What kind of hardware have you tested it with so far? Is this using WiFi only?