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?