I have a draft blog post I haven’t made public yet that explains it better which I can share off-forum (or on-forum once I’ve hit publish ;)). In a nutshell, I’m aiming to use kubernetes as a swarm control plane for both flight control software and payload software.
At the core of it is the idea that a flight controller should be an app, not a thing. And that a drone should be no less smart than my smartphone.
My endgame goal is a comprehensive open source “integration” project which relies heavily on best-of-breed existing open source projects, that integrates all the components of the stack (reference drone hardware, reference compute hardware, OS, kubernetes, ardupilot, SITL components and any dependencies, SDK, even open compatible reference CADs for 3d-printable parts like the frame), to allow any engineering student on the planet to start cutting a swarm application in the shortest amount of time without having to reinvent flight control, distributed computing, or spend two years on integration. It’s also by no means confined to air drones (same compute platform applies to marine), and automated ground service stations are also in scope but further down the road.
My current platform is pi4b’s running Fedora 32, kubernetes and kubernetes-ansible, etcd as distributed datastore and gluster as a storage tier. Fedora doesn’t “officially” support the 4b yet, but I fixed^H^H^H^H^Hhacked around that: https://medium.com/ironhaul/installing-64-bit-fedora-on-the-raspberry-pi-4-d4a665ea65d3
Ardupilot goes in a container.
Each drone is a 1/3/more sized kube cluster. A swarm is a federation of clusters. Then use custom resources to control swarm free resources (read: available drones that have not yet been assigned a task towards a requested “fleet behavior” object) and kube operators/controllers to program behaviors.
This is an approach that takes 90% of the reinventing distributed computing work out of doing the same swarm application programming using the dronekit approach.