If they don’t see it here, they’ll see it when it’s a pull request in source control 
Thank you for the hat links 
Do you think this:
https://www.ebay.com.au/itm/MPU9250-BMP280-10DOF-I2C-SPI-GY-91-BME280-Kompass-Barom-for-Raspberry-Pi-/192534168696
(BMP280 MPU9250 selected from the dropdown) would cut it? Sub-A$10 (I’m aus based) and easier to wire to a GPIO pin on multiple raspies than a hat.
It sounds like I have not understood what it is your trying to do, maybe you can share some more info about your end goal?
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: Installing 64-bit Fedora on the Raspberry Pi 4 | by Miki Shapiro | Ironhaul | Medium
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.
It should do it the only sensor you would still need is a Gps
Awesome thank you.
Order placed. ETA 37 covid-19 years. Not sure what that translates to in dog years 
I’m out of daylight… will look more at GPS options tomorrow. Banggood has some $10 SPI options.
Meanwhile… built arducopter successfully several times and started getting familiar with the arducopter codebase - to try and get PWM happening over GPIO… the dev familiarsation guide on this website is fantastic. Very grateful to whoever put in the effort into documenting…
Navio 2 pretty much does what you want to do i guess. It runs Ardupilot on a rspberry and uses a sensor hat. If not, than i do not understand what you are trying to achieve.
Yes it would work but It is way to expensive with 168€. Especially for three drones (already for one drone)
If this works you could go further(even if this isn’t the goal) and make a sub 40$ mini flight controller with way more than 2mb flash
Imagine you could use a raspi zero with 20€ sensors (including GPS) you would have an 35€ mini flight controller with more than 2mb flash
Technically, navio2 is very much what I’d need. Costwise, their approach doesn’t scale.
What I want needs to scale with cost and be tied to the cost of the compute platform.
Think about the solution cost of a 50, 500 or 5000 drone solution when each drone’s compute pakcage is 3 $50 raspberries with two $10 sensors.
Now think about its cost when its compute package is 3 $50 raspberries with a $370 hat each.
See the problem?
On the proviso that the result may not end up being the lowest latency racing drone in the world, unless I am missing something, everything has already been commoditised, and everything but the sensor chip and ESCs can be replaced with software.
That’s a really good point.
This actually creates a nice spectrum of possibilities, ranging from a pi zero on the low end to full scale kubernetes on the high end.
For single drone applications, this would open the door to
a. a pi-zero based flight controller - as you mentioned - but where you don’t have kubernetes underneath ardupilot, because of insufficient ram. (you can theoretically run it on Rancher’s k3s micro distribution of kubernetes… but my practical experience of running that on 512MB pi zeros was very flaky from a running out of memory perspective).
b. a single 4gb memory pi (let’s say $100 all up with sensors) flight controller that does have kubernetes.
What good would a container orchestrator do to a single node drone?
There could be some benefits, such as knowing what you develop can be scaled once you’re done prototyping with less work, such as testing that container on a cloud service in a SITL environment before pushing it to your drone(s), or a universal API (the kubernetes api) to orchestrate your single drone’s behavior as an alternative to a specialised one like dronekit.
c. … and, from there, you can of course go 3-way on each drone or more.
Just build your own , I’m curious to see how you can tune DMA and make the semaphores getting real time under an additional layer of abstraction
Exactly where I’m at
Thanks for the Mini Zee reference - that’s precisely the kind of project I was looking for pointers to.
Is there a reason you went with adafruit [ EDIT: I meant APM ] and didn’t use a software PWM implementation?
Python scripts that demonstrate software pwm control of ESCs via GPIO have been floating around the internet for a while…
Yep that was the talk in 2015 
… and it has been demonstrated that GPIO are not stable and precise enough , especially when used at higher PWM frame rates as with ESC
I tried different architectures and finally came to the general consensus of using highly performant STM cores with real time chibios and use a Companion Computer (like RPI) for the high level apps
So… I am not experienced enough to have an informed opinion about this. I’m well aware I may be dead wrong on this, even on 2020 assumptions.
that said
on the assumption that
a. My hardware is a decent quad core computer with a ton of ram (caveat: this doesn’t make GPIO resolution any better than the same GPIO bus on a slower computer)…
b. I have full control into how a workload is run, and make the OS scheduler treat it with very high priority compared to other workloads.
c. What I am building is not a performance race drone, and I think a platform can tolerate an increase in response times of a few tens of milliseconds without solution-breaking showstopper consequences.
d. Not trying to replace ESCs with software. They remain.
… so on those assumptions, is there really a realtime problem there?
Do you happen to know where?
Also, does one of the HALs in ardupilot attempt to implement this already?
If you look at Linux based FC you will see they all use some kind of hard timing devices for this purpose
Anyway , been there, done that, meet you at the other side of rainbow
Have fun
Ha
Definitely.
Wish we had something akin to a BBBmini for raspberries, now that Erle & PXFmini appear to have gone away.
Thanks again, looking forward to the wisdom that the end of the rainbow brings…
EDIT: Done a bit more research based on the thread above.
My current trajectory is to
[a] potentially get a navio2 just to get the entire MVP up and running sooner, just because that’s got a tested profile in ardupilot already.
[b] … then start weaning off it. Start by handling sensors on GPIO directly.
[c] gonna listen to lessons learned here… adding a hard clock turns out isn’t all that hard.
The simple hat that does it for $17 - Adafruit 16-Channel PWM / Servo HAT for Raspberry Pi - Mini Kit : ID 2327 : $17.50 : Adafruit Industries, Unique & fun DIY electronics and kits
Or, failing that, just a $12 square signal generator: https://www.banggood.com/DDS-Signal-Generator-Module-0-40MHz-AD9850-2-Sine-Wave-And-2-Square-Wave-p-1239854.html?rmmds=search&cur_warehouse=CN
… can probably do what just a raspberry alone can’t.
[d] … plus, compile kernel with preemptive realtime turned on if needed. (That’s not a biggie, I’m already running custom kernels to add kuberenetes-related bits to the default kernel my hacky Fedora inherited from Raspbian)
Thanks again
Wouldn’t it much easier to buy a cheap fc and control it with a raspberry pi-zero? Somehow i think you are reinventing the wheel 
Depending on what problem one is trying to solve. Your suggested wheel doesn’t solve my problem.
Some applications require the cooperation of many computers.
Think the backend of facebook, or google maps, or a swarm made up of many drones.
Building an individual drone isn’t hard. Neither is putting a raspberry companion computer on one.
But… there’s almost 2 calendar decades and what is probably a cumulative centuries of engineering that’s gone into how to solve the many computers cooperating problem. We have a solution. It’s called Kubernetes and containers. It’s open source. It’s available. And with 4GB or more, all its required internal organs can be run on a drone (so a pi4, not a pi zero; but this isn’t so much about what model of pi to use).
That means that if I want to write an application that assembles 50 marine drones into a helipad, and then breaks it up on one command, writing such a swarm behavior is a 1 month effort, and not a 20 year effort (I’m exagerating here, but you get the point. We don’t have to start from zero. We should be starting from where this technology already is at.)
To do that, I need to make sure the drone brain (ardupilot or PX4) is run in software, not on an appliance, and to add some technology - kubernetes & containers - between the OS (linux) where they run and this software.
To this end, I’m using a flavor of Linux that has all these capabilities as part of the OS itself - Fedora.
Hope that makes sense
Doing the flight controller on Linux is totally possible and has been done with multiple platforms. Back in 2016 I was even compiling Ardupilot in the same board that was flying it (https://www.youtube.com/watch?v=uHbJtMbgjH8&t=20s).
As for PWM, any other bus communication or sensor sampling: avoid the notion that you can “do it in software with GPIO”. Not even the microcontrollers with simplified OS are doing it. They use dedicated HW for that (with some exceptions). Same applies for Linux any other OS: don’t try to write something that will do a pwm by controlling a GPIO, but rather a) use the PWM controller available in the SoC like many have, b) use a dedicated microcontroller with one PWM controller / pulse capture, or c) use an FPGA to create the communication you need; or d) just make use of something not originally intended for that.
For generating the output on Linux boards, take a look in libraries/AP_HAL_Linux/RCOutput_*. Bebop and Disco use a separate CPLD, the ones based in BBB use an “embedded microcontroller” called PRU, most RPI-based use PCA9685 on a I2C bus, Zynq and Aero use an FPGA, Navio2 use a separate microntroller abstracted by kernel interfaces.
For what you want to do it seems it would be suitable to use AP_Periph with a cheap FC, exporting the sensors over CAN to a Linux board that would be running the flight controller. That way most of the jitter-sensitive tasks are actually running in the separate HW and the Linux board has mainly to guarantee the RT characteristics of the mainloop, which is pretty easy.
However you won’t be able to do that without creating additional code for Ardupilot.
Good luck.
Legend, thank you for that.
Loud and clear. Thanks for helping me avoid spending too much time on that landmine. @ppoirier has shared same advice and made clear why (lack of a reliable hardware clock) we don’t have a good soft PWM. I’ve got the $17 adafruit hat on order to do this, and might order a navio2 as well just to prove out the rest of the stack sooner. I don’t want to turn this into a make-your-own-hardware focused project at this stage, and the whole point is working with accessible, commoditised components.
For sensors, you’ve listed a few ways to interface with them - and looking at what’s commoditised, I’d say it’s between using the CAN bus and using I2C-over-GPIO. The thing to keep in the corner of one’s mind is which of these is easier to simultaneously wire into multiple raspberries at the same time without or with minimal hardware switching. A marine drone would like nothing more than 3(or 5) raspberries spreading its compute package to opposite corners of the rig. And if we can make access to at least some sensors shared easily, that makes the design better. Am I right to think I2C would be better for this? Other thoughts on this?
